comparison with other stored security state mechanisms [was: Re: Sharing Trust Policy between Crypto Libraries]
stefw at redhat.com
Fri Jan 4 13:33:42 PST 2013
-----BEGIN PGP SIGNED MESSAGE-----
On 01/04/2013 12:08 AM, Daniel Kahn Gillmor wrote:
> On 12/20/2012 12:38 PM, Stef Walter wrote:
> 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:
This is related to (among other things) the "key pinning" concept
> currently advanced in the websec working group:
> (see also my recent e-mail on this list 'Different meanings of
> 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
> 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/
-----END PGP SIGNATURE-----
More information about the p11-glue