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

[peter williams]

Some ietf users (eg nsa) build upon the std, profiling and extending the places it intends such specialization to occur. For example, you would expect nsa key management culture to more hardened than the typical unix webserver running ssl. Signed key (vs cert) compromise message may flood suitable routing protocols intending to flash a key compromise notice (concerning some hsm for a ca, say).

In that world kmid are used, that may go into the cert fields to assists cert/key loading by csps (not in pkix scope) or chain discovery (partly in pkix scope) or chain validation for pkix complying cert-using systems.

Remember pkix is just a profile of x509, not a design of a key mgt system. 

Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:

><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --> 
>
>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
>
>_______________________________________________
>Gnutls-devel mailing list
>Gnutls-devel at lists.gnutls.org
>http://lists.gnupg.org/mailman/listinfo/gnutls-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20130305/16a887e5/attachment-0001.htm>