On Tue, Jan 8, 2013 at 6:39 AM, Tom Ritter <[email protected]> wrote: > On 6 January 2013 17:55, Jeffrey Walton <[email protected]> wrote: > > H All, > > > > Does anyone know if there is a standard extension to store pin sets > > (re: certificate pinning) in, for example, PKCS #12? > > > > Perhaps in another format? > > > > OIDs? > > > > Placing a pinset in a PKCS #12 certificate (or other format) kills > > two key distribution problems with one stone. > > > I believe at one point TACK (tack.io) had a configuration where the > pins could be specified in an X509 extension, but this seems to be > missing
Yep - we were considering that, but decided against it: TACK (for those not familiar) is a way for a server to "assert" that it should be pinned, within the TLS handshake. The current draft [1] specifies presenting TACK data within a TLS extension, which means changing SSL libraries on the client and server side. To avoid that deployment hurdle, we earlier had an option to allow TACK data within an X.509 extension. Two issues with that: 1) It would allow a CA to create certificates that assert a pin that only the CA has control of; customers might deploy such a certificate without noticing, and end up inadvertently locked-in to the CA. 2) For web servers to make use of TACK without a cooperating CA, they would need to insert a "superfluous certificate" into the chain presented by the TLS server, i.e. a certificate that is not part of the validated chain the client will construct. This violates the TLS RFCs, but almost all browsers ignore superfluous certs. However, Google's Certificate Transparency was considering the "superfluous cert" idea as well, and did more experiments, and found some incompatibilities on (as I recall) a couple older mobile devices. So, to avoid these problems we just bit the bullet and went with a TLS Extension. Trevor [1] http://tools.ietf.org/html/draft-perrin-tls-tack-02
_______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
