Re: [Sks-devel] SKS should not accept or replay non-exportable certifications
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 remain non-compliant. Any thoughts or suggestions on how to resolve this problem? A hack would be to have a filter on, which strips them by default, and clean=off disables that. The data's out there, trying to pretend it's not would be problematic in many ways, so we might as well just ensure that normal retrievals don't pick up the sigs, and also of course block _new_ uploads of such sigs. Actually, the hack here, as discussed over on gnupg-users, is trying to use lsign to mark a key to keep it off of the keyservers. The problem is that produces a key, that if the erroneous use is followed, that has no binding self-sig on the UID. While a regular certification and a self-sig are both signatures, the selfsig performs other important functions within OpenPGP. There is nothing to fix here, either in SKS or in GnuPG. The thread on GnuPG-users has the needed discussion. -- 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 ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] SKS should not accept or replay non-exportable certifications
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 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. Although I am inclined to think the current behavior is a bug, I'm also inclined to think this is making a mountain out of a molehill. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] SKS should not accept or replay non-exportable certifications
Daniel Kahn Gillmor wrote: Someone™ (0x75D292D353ADACCD) made a non-exportable certification on your user ID John P. Clizbe jpcli...@keyservers.net (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-exportable certification, in contravention of the OpenPGP standard. Well, thank you for at least admitting your key vandalism. And because you, err Someone™, made and uploaded a regular local signature as opposed to a self-sig, it gets cleaned when I refresh my key. GPG won't import your bogus sig -- I suppose it could be forced to do it, but I'm really not interested in your self-created corner-case. To me, that's the system operating as it should. There's LOTS of cruft out there on the keyservers and in most cases, the clients handle it. BTW: childish stunts such as this ARE NOT the way to sway or to win my opinion. They are more likely to lead me to the opinion that the perpetrator is overly prone to extreme histrionic outbursts. (As some friends of mine would say, OH MARY! @_@ The drama-llama called. He wants his hump back. or Drama Queen, take your Drama-meen.) There is nothing to fix here, either in SKS or in GnuPG. The thread on GnuPG-users has the needed discussion. I don't think this conclusion is warranted. Then code the patch and quit the hissy-fit. Note -- honoring the not-exportable flag on a self-sig breaks the standard in IMO a worse way, UID(s) without binding sig(s). 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. As some of the other posters on the GnuPG-Users thread pointed out, there are other ways _within_ the standard to handle what you want to get accomplished. Key vandalism and histrionics do not advance your cause. -- 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
Re: [Sks-devel] SKS should not accept or replay non-exportable certifications
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 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. Cheers, Chris. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
