On Tue, Jan 8, 2013 at 1:44 PM, Trevor Perrin <[email protected]> wrote: > > 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. Notwithstanding lock-in, the CA industry has proven itself to be untrustworthy, so I think its a good choice. My apologies to the innocent parties lumped in there (for completeness, Trustwave is not one of them, despite Mozilla's back room dealings).
> 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. rather than TACK, why not add the extension directly, without the need for a separate call to request the TACK (and the need for the place holder). Covering everything under the one signature. I can get a two year certificate for under $20 US. Those things are throwaway. Plus, I would think ISPs would offer it as a value added service (a new certificate, which includes the pin set). ***** "Traditionally, a TLS client verifies a TLS server's public key using a certificate chain issued by some public CA." The world created smarter mices: http://bugs.python.org/issue1589 and http://blog.spiderlabs.com/2011/07/twsl2011-007-ios-ssl-implementation-does-not-validate-certificate-chain.html. **** Also, I noticed the draft lacked the word "critical". The solution would seem to beg for a critical extension that becomes critical after a grace period. Or a "CriticalAfter" extension that is woefully missing (IIRC). I believe it solves the "server-software-never-updated" syndrome. Clients with updated software will do the right thing when they encounter the OID after a certain date, even if the server does not mark the extension as critical. Downlevel clients that never update (Windows Mobile, many Android, et al) don't know what to do with the OID, so they can shit or go blind. It does not really matter to me since the platform is defective (full of exploitable security bugs). Users don't use it; and I don't allow it in the Enterprise without a knuckle pounding fight. Plus, waiting for the industry to "do the right thing" and provide security related updates is hopeless in most cases, and I don't believe it will be fixed until its mandated by law. Mandating updates won't work unless the penalties are severe enough to upset the risk/benefit equations. So we need untainted legislation that was not influenced by special interest groups. That's an even more difficult problem. Jeff _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
