Hey Chris & Chris, This seems like a useful near-term approach, but also probably something that might want to migrate to DANE over time.
Is there any particular reason you're using key fingerprints instead of cert fingerprints? It seems like the latter might be slightly easier to implement, since you don't have to parse the cert. --Richard On Sep 12, 2011, at 5:56 PM, Chris Palmer wrote: > Hi all, > > Chris Evans and I work at Google on the Chrome security team. We have > devised this specification for a new extension to Strict Transport > Security to allow site operators to "pin" certificates: UAs will > require that TLS connections be validated with at least one of the > public keys identified in the new "pins" directive in the HSTS header. > (Sites can pin to one or more public keys in end entity, subordinate > CA, and/or root CA certificates, for flexibility and disaster > recovery.) > > We hope that this mechanism opens up the benefits of certificate > pinning to more sites. Currently, Chrome can "pre-load" HSTS behavior > and certificate pins for sites, but the mechanism for doing this > (email us!) does not scale. > > We eagerly anticipate your comments, questions, concerns, et c. As you > can see from the Ideas section, there are some unanswered questions > about the behavior of UAs and hosts, and possible extensions to the > policy. > <CertificatePinningExtensionforHSTS.pdf>_______________________________________________ > websec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/websec _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
