[cryptography] Key Archive Formats and Pinsets (Certificate Pinning)?

Trevor Perrin trevp at trevp.net
Tue Jan 8 13:44:07 EST 2013

On Tue, Jan 8, 2013 at 6:39 AM, Tom Ritter <tom at ritter.vg> wrote:

> On 6 January 2013 17:55, Jeffrey Walton <noloader at gmail.com> 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


[1] http://tools.ietf.org/html/draft-perrin-tls-tack-02
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20130108/f515a332/attachment.html>

More information about the cryptography mailing list