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

[Stef Walter]

On 01/15/2013 08:30 PM, Ryan Sleevi wrote:
> On Tue, Jan 15, 2013 at 9:36 AM, Stef Walter <stefw at redhat.com> wrote:
>> 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.

Thanks for pointing those out. RFC 5914 is an adequate (albeit clumsy)
ASN.1 format for representing trust anchor information in a byte stream.
It supports stapled certificate extensions.

But yes, it does make it clear that trust anchors need not always be
signed certificates.

FWIW, I'm thinking of removing the ASN.1 stuff from our model for now.
It's not really necessary to come up with yet another format for anchors
in addition to the TAF stuff in RFC 5914.

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

This is solved neatly by using stapled certificate extensions and
overriding extensions you don't want to anchor.

So correct me if I'm wrong, but it seems that in the end of the day we
can treat an X.509 trust anchor as:

 subjectPublicKeyInfo + subject Name + zero or more stapled Extensions

As you might expect, a certificate has these contents as well.

The sad thing about departing from the trust anchor == certificate
concept is that you lose the ability to retrofit current crypto
libraries easily to use this trust information. Most expect to be fed
X.509 certificates as trust anchors. Will give this some more thought.

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

Yeah, perhaps primary-key is a bit strong. We're not looking for a
uniqueness here. We're looking for something by which a crypto library
or application can use to reliably lookup trust anchors.

Given the above (ie: trust anchors need not always be certificates) this
association ends up being the subject Name for trust anchors. Obviously
you may get between 0 and N results for a given subject Name. But one is
guaranteed to discover the relevant X.509 anchors.

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

So callers essentially have to look at the blacklist (for X.509 usage at
least). Once via issuer + serial and once via subjectPublicKeyInfo.
Doesn't seem to be any way around that.

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

Where is this defined? I may have missed something but neither TACK [1]
or HPKP [2] mention ports or the concept of an 'origin'. Is there
something we can reference here?

Cheers,

Stef

[1] https://tools.ietf.org/html/draft-perrin-tls-tack-02

[2] http://tools.ietf.org/html/draft-ietf-websec-key-pinning-04