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

[Ryan Sleevi]

On Tue, Jan 15, 2013 at 9:36 AM, Stef Walter <stefw at redhat.com> wrote:
> 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).

It's much more helpful to think of this in terms of RFC 5914 (as
described by RFC 6024), or as explained in RFC 5937.

The reason being is that you don't always want to anchor to the
additional fields within the certificate - even when you can. I seem
to recall that a number of certificates within NSS's root store would
contain otherwise invalid constraints/policies if they were used to
initialize the search path.

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

A trust anchor is minimally an association of subject & public key.
There MAY be multiple trust anchors for the same subject & public key,
each with unique constraints. This is not uncommon in bridge or mesh
topologies. The important thing is realizing that, in terms of
'primary index', neither cert nor subj+public key are unique
identities.

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

Mozilla has found, as we have on the Chrome team, that it's
insufficient to blacklist based on issuer + serial. We also maintain a
blacklist based on subjectPublicKeyInfo. This is to address situations
where cross-signed certificates may not have been disclosed, but which
trust should be revoked (due to a key compromise), as well as to
handle the fact that some CAs have failed to conform to RFC
3280/5280's requirements of unique serial numbers for a given issuer.

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

Port is not or - it's an AND. Collectively, both TACK and HPKP operate
on the concept of an origin (scheme, host, 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
>
> _______________________________________________
> p11-glue mailing list
> p11-glue at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/p11-glue