Issuer Fingerprint (was: Vanity Keys)

[David Shaw]

On Jan 13, 2015, at 6:33 AM, Werner Koch <wk at gnupg.org> wrote:
> 
> [Moving discussion to gnupg-devel]
> 
> On Tue, 13 Jan 2015 10:41, nicholas.cole at 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?

My feeling is that whether we do a notation or an assigned subpacket, we do it via the IETF process.  FWIW, adding an IETF namespace notation is via EXPERT REVIEW, which may be simpler than CONSENSUS.  I lean somewhat towards a subpacket for several reasons (size, reusability), though.

I don't want to use a notation from the user namespace until we get to the "real" subpacket or notation, as we'll end up with both, ultimately, with some code using the user notation and some using the subpacket/IETF notation.  We can end up stuck in that state for a long time, and have to support both for backwards compatibility reasons for even longer.

David