keygrip format [was: Re: GnuPG 2.1.x and 2.2.x keyring formats]

[Daniel Kahn Gillmor]

On Thu 2017-12-07 19:57:48 +0100, Werner Koch wrote:
> On Thu,  7 Dec 2017 16:52, gnupg-devel at gnupg.org said:
>> I'm asking these questions because I have a C# email library that
>> uses Bouncy Castle for OpenPGP support that I'm trying to make
>> interoperable with GnuPG as much as I can.
>
> Hmmm.  I can't give an offical guarantee that the format will always be
> the same.  The keygrip is computed by a function in Libgcrypt.

Can you guarantee that the keygrip will remain stable?

Given that gpg-agent addresses the keys by keygrip, for interoperability
purposes i think we need to commit to an official guarantee about
keygrip calculation, and it ought to be publicly stable.

keyformat.txt says:

>>>    [2] The keygrip is a unique identifier for a key pair, it is
>>>    independent of any protocol, so that the same key can be used with
>>>    different protocols.  PKCS-15 calls this a subjectKeyHash; it can be
>>>    calculated using Libgcrypt's gcry_pk_get_keygrip ().

But RSA has made it much harder to find copies of the PKCS-15 standard
these days, and it hasn't made it through to the IETF yet, afaict.

However, it looks like there's a copy here:

    http://tjscott.net/pki/pkcs/pkcs15.pdf

which says:

>>>> subjectPublicKeyHash:
>>>> 
>>>> An OCTET STRING which contains the SHA-1 hash of the public key
>>>> associated with the private key.  In the RSA case, the modulus of the
>>>> public key shall be used, and the hash is to be done on the
>>>> (network-order or big-endian) integer representation of it.  The
>>>> hash-algorithm shall be SHA-1.  In the case of Elliptic Curves, it is
>>>> recommended that the hash be calculated on the x-coordinate of the
>>>> public key's ECPoint OCTET STRING. As an alternative, the hash can also
>>>> be used as the CommonKeyAttributes.iD.
>>>> 
>>>> NOTE 
>>>> 
>>>> This is different from the hash method used e.g. in IETF RFC 2459
>>>> ([32]), but it serves the purpose of being independent of certificate
>>>> format – alternative certificate formats not DER-encoding the public key
>>>> has been proposed.

Is that worth documenting explicitly?

fwiw, RFC 2459 has been superceded (twice!) and RFC 5280 is now the
preferred recommendation from the IETF.  Its recommendations for
generating key identifiers is here:

   https://tools.ietf.org/html/rfc5280#section-4.2.1.2

it recommends digesting the ASN.1 "BIT STRING subjectPublicKey", which
is more than just the public key modulus or the ECPoint X coordinate,
and has the advantage that two keys of different formats will not have
colliding keygrips.

Right?  Using the mechanism defined in PKCS-15, what prevents an RSA key
from having the same keygrip as an ECC key?

     --dkg