Different meanings of "Pinning"

[Nikos Mavrogiannopoulos]

On 01/04/2013 08:37 PM, Simo Sorce wrote:


>> While the current WebSec draft focuses on HTTP, I don't think it's
>> fair to say that the concept of restrictive-pins is an HTTP-only
>> approach. Certainly, alternative proposals such as TACK [1] explore
>> key continunity algorithms at the TLS layer, and there has been active
>> discussion at both IETF 84 and IETF 85 regarding restrictive-pins for
>> other TLS-using protocols, such as IMAP.
>>
>> I think there is significant value in being able to share these pins
>> on a system-level basis. Even for something as restricted as HTTP, a
>> user may have multiple possible HTTP clients on their machine: a
>> libcurl using updater, wget straight from the shell, Firefox,
>> Chromium, etc. Being able to collaborate, between applications, on
>> those key lifecycles strikes me as particularly valuable, especially
>> when considering the 'wget' fire-and-forget nature.
> 
> Yeah the multiple-clients angle makes a lot of sense indeed.
> Seem a bit complex to implement/define at first, maybe better deferred
> to a second round.


I don't see why is that. I seems (to me) quite straightforward to define
PINs for the trust store. It is even already done in the existing
document. [Possibly an additional flag to indicate a restrictive PIN is
required, and a way to search the store using the SubjectAltName extension.]

regards,
Nikos