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 "local", meaning that it is specific to some private domain, and should not be passed to other implementations. The spec explicitly says [0]: The receiver of a transported key "imports" it, and likewise trims any local certifications. In normal operation, there won't be any, assuming the import is performed on an exported key. However, there are instances where this can reasonably happen. For example, if an implementation allows keys to be imported from a key database in addition to an exported key, then this situation can arise. 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. SKS does follow this spec, from what i can tell. It does not trim non-exportable certifications either at import or on export. This seems like a serious bug. Example ------- Take a look at key 0x1C26505E4A5009CB96B7E638EA3EB6304530AFCC [1], which I created to test this. The certificate contains only public key, a User ID packet, a non-exportable self-sig, and a non-exportable third-party certification. This key *has no exportable certifications*. nonetheless, SKS 1.1.4 imported it, storing both of these certifications, and it exports it with those certifications as well: 0 dkg@alice:~$ wget -q -O- 'http://keys.mayfirst.org/pks/lookup?op=get&search=0xEA3EB6304530AFCC' | pgpdump | grep -i exportable Hashed Sub: exportable certification(sub 4)(1 bytes) Exportable - No Hashed Sub: exportable certification(sub 4)(1 bytes) Exportable - No 0 dkg@alice:~$ Resolution? ----------- 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? --dkg [0] https://tools.ietf.org/html/rfc4880#section-5.2.3.11 [1] http://keys.mayfirst.org/pks/lookup?op=get&search=0xEA3EB6304530AFCC
pgpnJQePp4F7o.pgp
Description: PGP signature
_______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel