Different meanings of "Pinning"? [was: Re: Sharing Trust Policy between Crypto Libraries]

[Simo Sorce]

On Thu, 2013-01-03 at 17:48 -0500, Daniel Kahn Gillmor wrote:
> On 12/20/2012 12:38 PM, Stef Walter wrote:
> > http://p11-glue.freedesktop.org/doc/sharing-trust-policy/
> 
> This document talks about certificate pinning, using the definitions
> from RFC 6125, like:
> 
>  https://tools.ietf.org/html/rfc6125#page-11
>  https://tools.ietf.org/html/rfc6125#section-6.6.2
> 
> which in turn references:
> 
>  http://www.w3.org/TR/wsc-ui/
> 
> But recent work on public key pinning has a subtly different specification:
> 
>  https://tools.ietf.org/html/draft-ietf-websec-key-pinning
> 
> In particular, the former specification treats a pin as a list of
> approved matches.  That is, a certificate is allowed for a use it
> normally wouldn't have been.
> 
> The more recent work treats a pin as finite and exhaustive "allowlist"
> -- that is, if a pin exists for a given peer, and an otherwise-valid
> certificate appears that does *not* match a known pin, it will be rejected.
> 
> Both sorts of behavior are conceptually useful in some circumstance, and
> it's a shame that they share the main word "pinning".
> 
> The stapled-extensions draft appears to be able to accomodate the former
> style of "pinning", but i don't think it's capable of storing the info
> required by the more recent work on key pinning, even though that work
> would benefit from a platform-wide data storage as well.
> 
> If we're willing to accept this lack, we should at least make an
> explicit reference to the websec-key-pinning work to indicate that it is
> not supported (though i'd rather find a way to support it).
> 
> Any thoughts?

The websec draft seem limited to the HTTP protocol and thus application
specific, doesn't look to me as something that should be necessarily
platform-wide. Would good to document though.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York