stapling extensions to public keys instead of certificates? [was: Re: Sharing Trust Policy between Crypto Libraries]

[Stef Walter]

On 01/04/2013 04:12 PM, Simo Sorce wrote:
> On Thu, 2013-01-03 at 23:28 +0100, Stef Walter wrote:
>> Which raises the question (for me at least):
>>
>> If it makes sense to store trust policy associated the public key *of*
>> a certificate instead of the certificate itself (see question above),
>> then should stapled certificate extensions should always be associated
>> with a given public key, and never with a certificate directly?
>>
>> Obviously this depends on the earlier questions.
> 
> Why would it make any sense to store trust policies associated to a key
> rather than the cert ? Sorry if I haven't seen the rationale, feel free
> to point me at anywhere where it is explained.
> If there isn't a good reason I would think it makes little sense.

So here are the different things we currently want to store, and how
those things would be associated/looked-up.

If possible we should only model one way to lookup each type of
information. That way implementations don't need to try to find (for
example) an X.509 anchor stored in several ways, but can rely on one way
to look it up.


1. X.509 anchors

Although it is possible to conceptualize a CA anchor as just being a
public key (Yassir Elley helped remind me of this), in we trust more
information about root CA's than just that. Although not all of an
anchor certificate is used, we do use the notBefore and notAfter fields
in validation algorithms, and various certificate extensions can be used.

There are many references to this in RFC 5280, including in Section 6.2 [1].

So in essence when a distributor/admin marks a root CA as an anchor,
they are 'anchoring' based more than just public key, but many of the
other fields in the certificate. It would be inappropriate to
automatically replace a root CA with another based on the same key, but
with a different expiry date (for example).

Therefore it seems to me to make sense to lookup X.509 anchor
information based on the certificate and not the key.

2. Stapled Certificate Extensions

These are extensions that adjust the policy of an X.509 certificate. The
extensions are used together (overriding) extensions in the certificate.
Therefore using stapled certificate extensions for a given certificate
with a second certificate based on the same public key could have
unexpected consequences as far as trust policy.

Therefore it seems to me to make sense to lookup stapled certificate
extensions based on the certificate and not the key.

3. Blacklist

Here's where things get more complicated. In order to properly represent
X.509 blacklists one needs to do the lookup based on issuer + serial.
This allows representation of stored CRLs as well as the blacklist
information that Mozilla and others hold for the various CA break-ins [2].

Would it also make sense to have a global blacklist of public keys?
Daniel brought that up in another email, this needs some thought, and
I'll reply to his email about this.

Note that if we do have these two separate black lists, then each
certificate in an X.509 chain would need to be looked up repeatedly,
once via issuer + serial, and once for the black list. That's sorta
ugly, but that never stopped anyone :)

4. Pinned Keys

These are associated with a host + protocol (and/or port).


So to summarize only one I can see where public keys form the
association (primary-key in database speak) would be black lists, and
that's only if we do need a big list of blacklisted keys.

Cheers,

Stef

[1] http://tools.ietf.org/html/rfc5280#section-6.2

[2] Search for CKT_NETSCAPE_UNTRUSTED in this file:
http://mxr.mozilla.org/seamonkey/source//security/nss/lib/ckfw/builtins/certdata.txt?raw=1