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

[peter williams]

Security of cert path discovery is distinct from path eval. Perhaps investigate the doctrine of key "loading" - an enforced correctness regime.

Typically one uses a trusted agent, whose db is within a crypto boundary (and not just a tcb of a general purpose (ie b1) os. The us wants dns to play that role  - since its a us military asset. Obviously, other nations dont see why the us should have such an advantage in the crypto/cyber warring.

Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:

><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --> 
>
>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 --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20130307/3964a51f/attachment.htm>