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

Jeffrey Walton noloader at gmail.com
Tue Jan 8 15:17:23 EST 2013

On Tue, Jan 8, 2013 at 1:44 PM, Trevor Perrin <trevp at trevp.net> wrote:
> 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.
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


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


More information about the cryptography mailing list