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 > earlier versions, though i have not tested). In its current form, SKS > both accepts and transmits (including via standard gossip) *all* > non-exportable certifications.re is no other option
Careful here. Gossip is referring to recon and there is no other option in recon. Keys are just blobs of bits with a hash value. We can control what we accept, to try and make it conform to RFC 4880, et alia,... as much as possible, and we can control what is delivered by the server by cleaning and or filtering. The second is a dangerous approach because we are then controlling what is delivered, i.e., we're censoring. I think the task of verifying what is acceptable after a key is requested is probably best left to the client OpenPGP implementations. > I'd love to be wrong about this, but I've tested it and I'm reporting my > observations. If you have conducted other experiments or made other > observations that contradict this, I would love to hear about them, > specifically. As I see it, we have two related problems here, both involving the no-export signature flag: 1) Dan signs John's key with lsign and then keyserver/export options with export-local-sigs and sends the key with local-sigs to the keyserver network where the lsigs are accepted. This is clearly an error and these sigs should be removed when a key is submitted containing them. On a get, we have to make the call, do we enforce or put it on the client. I leave that for discussion. 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. THIS IS VERY VERY BAD. I think the RFC folks should probably have been more explicit on this case, but to be fair, it's probably a use case they did not anticipate. My compromise suggestion of trying to DTRT but with minimum harm is in the case of 1, where signing key != signed key, strip the non-exportable sig before we import into the key store. In the case of 2, where signing key == signed key (lsign your own key) we have a user either intentionally or accidentally shooting himself in the crypto foot. We can a) hold our noses and accept the key, or b) reject the entire key as malformed -- there is no way to honor the no-export sig flag and still have a valid key. Another possibility is that if there are earlier or later exportable selfsig(s), just strip the errant selfsig with the no-export flag. $0.02 -- keep the change. Discuss. -John -- John P. Clizbe Inet: John (a) Gingerbear DAWT net SKS/Enigmail/PGP-EKP or: John ( @ ) Enigmail DAWT net FSF Assoc #995 / FSFE Fellow #1797 hkp://keyserver.gingerbear.net or mailto:pgp-public-k...@gingerbear.net?subject=HELP Q:"Just how do the residents of Haiku, Hawai'i hold conversations?" A:"An odd melody / island voices on the winds / surplus of vowels"
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel