comparison with other stored security state mechanisms [was: Re: Sharing Trust Policy between Crypto Libraries]

[Stef Walter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/04/2013 12:08 AM, Daniel Kahn Gillmor wrote:
> On 12/20/2012 12:38 PM, Stef Walter wrote:
>> http://p11-glue.freedesktop.org/doc/sharing-trust-policy/
> 
> In addition to the list of alternate extension mechanisms reviewed
>  in this document, It might be useful to compare chromium's
> internal blacklist/security state mechanism:
> 
> https://src.chromium.org/viewvc/chrome/trunk/src/net/base/transport_security_state_static.json
>
>
>
> 
This is related to (among other things) the "key pinning" concept
> currently advanced in the websec working group:
> 
> https://tools.ietf.org/html/draft-ietf-websec-key-pinning
> 
> (see also my recent e-mail on this list 'Different meanings of 
> "Pinning"?').
> 
> Similarly to websec-key-pinning, HSTS and TACK are examples of 
> per-peer secure communications policy that would ideally be shared
>  across applications:
> 
> HSTS: https://tools.ietf.org/html/rfc6797
> 
> TACK: http://tack.io 
> https://tools.ietf.org/html/draft-perrin-tls-tack
> 
> I don't think the current draft can support any of these 
> mechanisms, and perhaps they're out of scope; but maybe there are 
> parts of them that shouldn't be out of scope?

So, bringing this back to the original thread...

I agree with the various posts that there would be value in sharing
public key pinning information between implementations (especially
when multiple implementations are working with the same protocol and
hosts, ie: http).

As Daniel and Simo noted it seems that we should split out work on key
pinning information from the certificate trust policy work. The two
could share a store, be accessed in related ways, but the actual data
and methods for retrieving it are very different.

Certificate Trust Policy
 * Stapled certificate extensions seem to be a easy to implement and
   comprehensive mechanism. These neatly build off of the current
   certificate chain validation algorithms.
 * Trust policy information is retrieved from the store about a
   the certificate (or perhaps spki). It can be imagined as the
   primary-key (in database parlance).
 * Biggest use case is a static set of anchors/blacklist/policy
   prepared and updated by a vendor or system builder. Although
   obviously can be reconfigured by user or admin.

Public Key Pinning
 * The host name is the primary-key (in database parlance). Policy
   is retrieved about the host, including a possibly pinned spki/hash.
 * What you might call the 'trust policy' for key pinning is very
   different from that for certificate chains.
   * Key pinning includes concepts like: force-security-for-this-host,
     use-one-of-these-keys-for-host, min_generations, max-age-for-pin,
     when-was-key-last-seen, include-subdomains, and so on
     (paraphrasing based on my basic grasp of the tack/pinning specs).
   * Even things like ExtendedKeyUsage purposes, while at first glance
     seem like they could apply to pinned public keys, don't really make
     sense in practice. If a key is pinned to a host, then these
     purposes are superfluous.
 * Stapled certificate extensions do not apply here, and do not
   represent an easy to implement mechanism to build off of anything
   we already have.
 * Less used as static anchors stored by a vendor or system builder
   (Chromium notwithstanding :P), and rather as a dynamic store of
   information frequently and automatically updated.
 * The complete problem space is still being hashed out, and hasn't
   really converged yet. Which is good, cool to see progress and
   discussion, but hard to make sure we can model exactly what's needed.

Obviously these two trust schemes can be used together. In addition
they could both share a blacklist of public keys.

So in my opinion, these can be complementary, could live in the same
store (eg: as PKCS#11 objects), but we I don't think we should try to
shoe-horn them into the same concept and implement them the same way.

I'll clarify this in the certificate trust policy document (and
perhaps rename it) to make it clear this isn't dealing with key
pinning. That's for later.

Cheers,

Stef
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlDnSrAACgkQe/sRCNknZa+4rACdEF1G8Jo8U/0j1dtHEh/8g/wh
jZkAnidaEo5gKg+xWQ2A9HYLXRj/ljrs
=XVEx
-----END PGP SIGNATURE-----