Re: [websec] Certificate Pinning via HSTS

[Adam Langley <[e-mail]>]

On Tue, Sep 13, 2011 at 1:53 AM, Yoav Nir <[e-mail]> wrote:
> I can think of two reasons.

You're basically right. Quoting from my
http://www.imperialviolet.org/2011/05/04/pinning.html

"In general, hashing certificates is the obvious solution, but the
wrong one. The problem is that CA certificates are often reissued:
there are multiple certificates with the same public key, subject name
etc but different extensions or expiry dates. Browsers build
certificates chains from a pool of certificates, bottom up, and an
alternative version of a certificate might be substituted for the one
that you expect.

For example, StartSSL has two root certificates: one signed with SHA1
and the other with SHA256. If you wished to pin to StartSSL as your
CA, which certificate hash would you use? You would have to use both,
but how would you know about the other root if I hadn't just told you?

Conversely, public key hashes must be correct:

Browsers assume that the leaf certificate is fixed: it's always the
starting point of the chain. The leaf certificate contains a signature
which must be a valid signature, from its parent, for that
certificate. That implies that the public key of the parent is fixed
by the leaf certificate. So, inductively, the chain of public keys is
fixed, modulo truncation.

The only sharp edge is that you mustn't pin to a cross-certifying
root. For example, GoDaddy's root is signed by Valicert so that older
clients, which don't recognise GoDaddy as a root, still trust those
certificates. However, you wouldn't want to pin to Valicert because
newer clients will stop their chain at GoDaddy."


Public key hashes are hashes of the SubjectPublicKeyInfo, which should
be nailed down in any spec.

There is the possibility of a cert getting reissued with a difference
SPKI, but the same effective public key. (i.e. omitting a NULL
AlgorithmIdentifier.Parameters). However, I'm not aware of any
instances of this actually happening.


Cheers

AGL