[gnutls-devel] X.509 "Key Identifiers" in GnuTLS

[Daniel Kahn Gillmor]

Thanks for helping me get my head around this, Nikos.

On 03/05/2013 05:27 PM, Nikos Mavrogiannopoulos wrote:
> That is certtool. One may set other values to this field (though it will
> not be that easy to get the bit string).

right, i should have said that i was describing certtool's default
keyIdentifier implementation, not GnuTLS's as a whole.

> Is there any advantage on using the RFC suggested approach? The
> authority and subject key identifiers are implementation specific, so it
> would not make much difference whether you add something like that or not.

Well, if there were actually a standard mechanism for deriving a keyID
from a pubkey (e.g. like an OpenPGP "fingerprint"), that could make path
resolution more straightforward (e.g. you could ignore all keys that do
not have the indicated keyID). But, of course, no such standard exists. :/

>> diff --git a/lib/x509/x509.c b/lib/x509/x509.c
>> index 57f540a..009f053 100644
>> --- a/lib/x509/x509.c
>> +++ b/lib/x509/x509.c
>> @@ -2667,7 +2667,7 @@ _gnutls_get_key_id (gnutls_pk_algorithm_t pk, gnutls_pk_params_st * params,
>>        return GNUTLS_E_SHORT_MEMORY_BUFFER;
>>      }
> 
> A solution for what you describe cannot be at this function. This
> returns the key identifier which is IMO correctly set to be the hash of
> the SubjectPublicKeyInfo.
> 
> If you'd really like that functionality you may add a new function that
> gets the rfc-xxx ID. Then maybe add an option to certtool to use it.

Ah, this is an interesting approach.  The more i've thought about this,
the more i think GnuTLS is doing the right thing, and the "common
method" is actually misguided.

One reason i'd want this is (for example) to implement some sort of
pinning infrastructure for a tool that builds a table of pins indicated
by keyID.

However, since the two most acive pinning proposals actually use
GnuTLS's style of KeyID derivation, i think this isn't a good reason to
implement the "common method" in GnuTLS.

> I don't really see why would this increase interoperability. The
> authority key ID field is transparently read by implementations and
> compared with the subject key ID of the CA certificate. There is no
> other action done. Could you elaborate?

given what i now understand about the state of the infrastructure, i
think you're right that there isn't much of a win here.

Given that the certificates in question can be given arbitrary
subjectKeyIdentifiers, and that many TLS stacks (like browsers) keep a
cache of previously-seen certs, i wonder if a malicious server could jam
up the cert processing by feeding the browser a bunch of bogus
certificates with colliding identifiers.  This is probably not something
we can resolve in GnuTLS, though.

So i think the only thing that remains is to document why this is a
divergence from the RFC's "Common Method" -- and i think we have several
good reasons.

Nikos, would you be averse to a changeset that adds a bit of
documentation about how this distinction is made?

Regards,

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1027 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20130306/4d67f9a0/attachment.pgp>