[Moving discussion to gnupg-devel] On Tue, 13 Jan 2015 10:41, nicholas.c...@gmail.com said:
> Or a new revision of the standard, I suppose. But I think that one or A new key and signature packet version will take years to develop and deploy. Thus I think it is better to first do something within the standard which will be backward compatible. We currently use this subpacket: 5.2.3.5. Issuer (8-octet Key ID) The OpenPGP Key ID of the key issuing the signature. A new optional subpacket: 5.2.3.27. IssuerFingerprint (N-octet Key Fingerprint) The OpenPGP Fingerprint of the key issuing the signature. For current versions of OpenPGP N has the value 20. Future versions of OpenPGP may specify a different scheme for the fingerprint and thus another value for N. Implementations should thus be prepared for other fingerprint lengths but honor this subpacket only if N is 20. could be used to overcome duplicate key id problems. The subpacket type octet for that new subpacket would be 33. Note that Adding a new Signature subpacket MUST be done through the IETF CONSENSUS method, as described in [RFC2434]. which takes quite some time. Should be pursue this task or take a quick solution by using notation data? The size of a signature will increase by 22 or even more when using the notation data approach. This is noticeable but given that we are anyway moving to the smaller ECC algorithms I think this is acceptable. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users