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

[Stef Walter]

On 01/15/2013 02:48 PM, Gabor Toth wrote:
>> Although PKCS#11 has some ugly aspects, it does have an extensible
>> object model, and using it allows us to plug into and interoperate with
>> the various consumers of trust information already around (such as NSS
>> and so on).
> 
>> But that's not to say there shouldn't be an additional or simpler API on
>> top of it.
> 
> I think it makes sense to provide such an API. If we do that, the underlying
> storage implementation would not matter that much, though. As the pinning
> implementation would require additional code anyway, how would PKCS#11 be
> advantageous for interoperability in the this case?

It's not absolutely necessary, but here's the logic behind that:

Most object storage mechanisms have many of the same traits, you can
write, read query objects and so on. But a key store has something
special: You can use (private) keys in the store without reading them
out. PKCS#11 is such a key store API.

Some related work I've been doing is trying to work with the various
crypto libraries and allow them to share the same certificate and key
stores. This work is based on PKCS#11.

NSS and GnuTLS already use PKCS#11 for interacting with private keys,
and certificates. NSS already retrievs its trust information via PKCS#11.

Although it's not absolutely necessary for the crypto libraries to
retrieve their trust information via PKCS#11, it does provide a straight
forward way to model and implement this stuff, since the crypto
libraries already use (or will/should use) PKCS#11 for their private key
and certificate storage needs.

Lastly, It's often hard to get the crypto libraries to agree on a
certain dependency, so having a barebones abstract C API object model
such as the one in PKCS#11, implementable by multiple providers, and
usable by multiple consumers, makes things much easier.

So that's why I've been working with the concept of using PKCS#11 as a
good way to represent the model of storing this trust policy.

PKCS#11 is not a panacea, it has many warts and so on. But as PKCS#11 is
already being used for key storage needs, using PKCS#11 for trust policy
doesn't add complexity above that.

As brought up earlier having another simpler API on top of this is a
great idea.

See: http://p11-glue.freedesktop.org/

> Also, the possibility for storing multiple pins for a peer should be considered,
> although that could also be left to be defined by the pinning extensions.

For sure. For example TACK wants 2 tacks to be storable. There should
definitely be the possibility for multiple pins records for a peer.

>> Similar to certificate extensions these key pinning extensions can be
>> marked as critical or not. If one is critical it must be understood and
>> respected in order for the key pinning to be used.
> 
> What's the purpose of this flag? These pinning protocols are more like
> replacements and not enhancements to each other, I would imagine a priority
> indication could work better here.

As mentioned elsewhere repeatedly by others, the point of key pinning is
to say "use these keys and no others for this peer" (ie:
host+protocol+port).

So the question arises, what if there are pins of multiple pin records
stored for a peer, perhaps of different types? By marking one or more of
these pin records of them critical, the marked pins are marked as the
ones that should used when connecting to the peer.

Obviously in an advanced power-user UI, the user could play security
guard and decide to override or go around a pin marked in this way. But
when the system is functioning normally, these critical flags play a key
role.

Cheers,

Stef