On Tue, Sep 13, 2011 at 1:53 AM, Yoav Nir <[email protected]> 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 _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
