On Sep 14, 2013, at 1:51 AM, John Clizbe wrote:
> I agree with Werner and Dave Shaw that you are wrong. If you are so convinced
> you are correct, post, with _ALL_ the particulars not just those that support
> your stance, to the IETF-OpenPGP list and get their opinion.
To be clear, the thing I
On 14/09/13 23:00, Robert J. Hansen wrote:
> On 9/14/2013 3:08 PM, Daniel Kahn Gillmor wrote:
>> Let me also be clearer about why i find this bug serious...
>
> I am still not seeing why this bug is serious. It still seems to be a
> case of mountains and molehills.
A bug is a bug. I've got a mou
On 2013-09-14 at 20:46 -0500, John Clizbe wrote:
> 2) JimBob lsigns his own key, creating a non-exportable selfsig then delsigs
> all of the exportable selfsigs. This is shooting oneself in the foot. If we
> honor no-export on a selfsig, we create keys with UIDs that have no binding
> signature. T
On Sat, Sep 14, 2013 at 08:46:05PM -0500, John Clizbe wrote:
> As I see it, we have two related problems here, both involving the no-export
> signature flag:
> 2) JimBob lsigns his own key, creating a non-exportable selfsig then delsigs
> all of the exportable selfsigs. This is shooting oneself
On Sat, Sep 14, 2013 at 05:00:28PM -0400, Robert J. Hansen wrote:
> On 9/14/2013 3:08 PM, Daniel Kahn Gillmor wrote:
> > If the keyserver network actively forwards these certifications,
> > then users of the keyserver network and local certifications stand a
> > greater risk of global data leakag
Daniel Kahn Gillmor wrote:
> On 09/14/2013 05:00 PM, Robert J. Hansen wrote:
> [dkg wrote]:
>>> > I have told numerous people that the keyserver network will not
>>> > propagate local signatures.
>>
>> This is true.
>
> No, unfortunately, it is not true in any way for SKS 1.1.4 (and probably
> ea
On Fri, 2013-09-13 at 20:33 -0400, Robert J. Hansen wrote:
> In what bizarro universe is SKS an implementation of RFC4880?
Well it uses/processes OpenPGP message formats (i.e. by
storing/publishing them).
___
Sks-devel mailing list
Sks-devel@nongnu.org
On 09/14/2013 05:00 PM, Robert J. Hansen wrote:
[dkg wrote]:
>> > I have told numerous people that the keyserver network will not
>> > propagate local signatures.
>
> This is true.
No, unfortunately, it is not true in any way for SKS 1.1.4 (and probably
earlier versions, though i have not tested)
On 9/14/2013 3:08 PM, Daniel Kahn Gillmor wrote:
> Let me also be clearer about why i find this bug serious...
I am still not seeing why this bug is serious. It still seems to be a
case of mountains and molehills.
> I have told numerous people that the keyserver network will not
> propagate lo
Wow, this has really gotten on the wrong foot. Sorry about that; let me
try to get it back on track.
John, i'm sorry that i made the example non-exportable signature on your
key. That was a dumb thing for me to do; I clearly should have made the
demonstration on another example key. I screwed u
On 9/13/2013 8:22 PM, Christoph Anton Mitterer wrote:
> And I guess the intention of the RFC is rather clear (with or without
> MUSTs)... implementations should not export such signatures... and SKS
> counts IMO as an "implementation".
In what bizarro universe is SKS an implementation of RFC4880?
On 9/13/2013 7:51 PM, John Clizbe wrote:
> I agree with Werner and Dave Shaw that you are wrong. If you are so
> convinced you are correct, post, with _ALL_ the particulars not just
> those that support your stance, to the IETF-OpenPGP list and get
> their opinion.
Although I agree with DKG that t
On Fri, 2013-09-13 at 18:09 -0400, Daniel Kahn Gillmor wrote:
> Did anyone on this list expect the keyserver network to
> propagate non-exportable certifications?
Nah,... not really, IMHO it should be considered a bug, and ideally such
existing signatures should be removed if possible.
And I gues
Daniel Kahn Gillmor wrote:>
> Someone™ (0x75D292D353ADACCD) made a non-exportable certification on
> your user ID "John P. Clizbe "
> (2048R/0x2313315C435BD034). Someone else uploaded that key to a
> keyserver (ok, i admit it was me :P). The keyserver network is
> currently propagating that non-e
On 9/13/2013 6:09 PM, Daniel Kahn Gillmor wrote:
> The intent is pretty clear, despite it not rising to the level of an RFC
> 2119 MUST. Did anyone on this list expect the keyserver network to
> propagate non-exportable certifications?
I did, and I think I'm speaking as a reasonable, rational hum
On 09/13/2013 06:01 PM, Robert J. Hansen wrote:
> I don't see a MUST in there. The language is not explicit without it.
> Is it a case of they SHOULD always, they MAY always, or they MUST
> always? Without specification it's unclear.
The intent is pretty clear, despite it not rising to the leve
On 9/13/2013 5:48 PM, Daniel Kahn Gillmor wrote:
> RFC 4880 is explicit:
>
> Some implementations do not represent the interest of a single user
> (for example, a key server). Such implementations always trim local
> certifications from any key they handle.
I don't see a MUST in there. The la
On 09/13/2013 05:09 PM, John Clizbe wrote:
> Phil Pennock wrote:
>> On 2013-09-12 at 19:40 -0400, Daniel Kahn Gillmor wrote:
>>> While this seems like it is probably a fixable bug for someone who knows
>>> their way around the codebase, I forsee problems with synchronizing the
>>> pool, if some SKS
Phil Pennock wrote:
> On 2013-09-12 at 19:40 -0400, Daniel Kahn Gillmor wrote:
>> While this seems like it is probably a fixable bug for someone who knows
>> their way around the codebase, I forsee problems with synchronizing the
>> pool, if some SKS keyservers start following the spec and others r
On 2013-09-12 at 19:40 -0400, Daniel Kahn Gillmor wrote:
> While this seems like it is probably a fixable bug for someone who knows
> their way around the codebase, I forsee problems with synchronizing the
> pool, if some SKS keyservers start following the spec and others remain
> non-compliant.
>
SKS appears to be in violation of RFC4880 by freely importing and
exporting non-exportable certifications.
Background
--
The OpenPGP specification includes a certification subpacket known as
"Exportable Certification". When present, and set to 0, it indicates
that the certification is "l
21 matches
Mail list logo
