[Sks-devel] SKS should not accept or replay non-exportable certifications

[Daniel Kahn Gillmor]

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 address@hidden:~$ 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 address@hidden:~$ 

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

pgpV1ZkUlzZ8A.pgp
Description: PGP signature