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

[Nikos Mavrogiannopoulos]

On 03/05/2013 10:04 AM, Daniel Kahn Gillmor wrote:

> I'm trying to understand the specification of X.509 Key Identifiers
> (e.g. subjectKeyIdentifier and issuerKeyIdentifier).  It looks to me
> like GnuTLS diverges from the "common method" for generating these
> identifiers, but i don't see any documentation that explains the
> divergence.
> 
> I understand that there is no official requirement that these strings
> are formed in any specific way.  However, the canonical RFC for PKIX
> 
>  https://tools.ietf.org/html/rfc5280#section-4.2.1.2
> 
> suggests that the "common method" involves an SHA-1 digest of the
> contents of the BIT STRING subjectPublicKey field.


Hello Daniel,
 Indeed, it is a non-normative suggestion of the RFC that I didn't
follow. That field could even be a counter, there is no advantage into
implementing the rfc way.

> However, GnuTLS appears to calculate the SHA-1 digest over the entire
> DER-encoded subjectPublicKeyInfo object (that is, over the sequence of
> the algorithmIdentifier and subjectPublicKey together).


That is certtool. One may set other values to this field (though it will
not be that easy to get the bit string).

> Here's a hacky implementation using the RFC's suggested common approach,
> followed by a demonstration that OpenSSL uses the "common method" when
> it generates certificates, while GnuTLS's certtool uses the whole
> subjectPublicKeyInfo:


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.

> 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.

> The advantage of making this change would be increased interoperability
> in the future with other TLS implementations and X.509 search tools, and
> closer alignment to the documented "common method".


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?

>  0) do we want GnuTLS to use the RFC 5280 "common method" suggestion, or

>  are we fine with the current implementation?


Personally I am fine, but this isn't the point :) I really would like to
see what advantages would that change provide.

>  2) if we stay with the current implementation, should we reach out to
>  other free X.509 certificate generation tools (notably OpenSSL) and
>  suggest that they reconsider?


Why? If one would like to use a counter to identify his certificates,
that wouldn't be a problem and it would not cause any interoperability
issues, as far as I understand.

regards,
Nikos