PKCS#11 scope (or, "how should a well-integrated system help users consistently identify their peers?")

[Stef Walter]

On 07/08/2011 01:38 AM, Daniel Kahn Gillmor wrote:
> As promised, here's an attempted short version of my concerns about
> PKCS#11's scope.  Hopefully, i'm just confused and wrong, and someone
> will point me in the right direction :)

I think it's far less of a case of being confused or wrong, and just
that some of the solutions to these problems haven't matured yet. The
solution we've been working on with PKCS#11 trust assertions is
different in scope that what you might be imagining.

http://p11-glue.freedesktop.org/trust-assertions.html

> My concern is about B2, which limits/constrains how tools can use PKCS
> 11 to effectively identify/verify the identity of the remote party in
> any communication.
> 
> In particular, i don't think the traditional PKCS 11 library interface
> answers the right question, which leads to duplication/re-implementation
> of remote-party verification across pkcs11-using tools.
> 
> i think the ultimate question most tools want to ask is something along
> these lines:
> 
> ========================
>  * i'm communicating via protocol X with a peer who i think is (or who
> claims to be) known as Y.
> 
>  * that peer has proved (or claims to be able to prove) possession of
> public key Z.
> 
> --> is key Z considered acceptable to identify peer Y over protocol X?
> ========================
> 
> 
> This question, along with the ability to provide possible supplementary
> information like certificates wrapping Z, or intermediate certificates
> that might lead to Z's cert from a trusted authority, is what i think
> such a library needs to provide.
> 
> Some authorities might be relevant for some protocols, but not for
> others (e.g. many browsers have "allow to certify web sites" different
> from "allow to certify software authors"); Some authorities might be
> relevant for some peers, but not others (e.g. the Brazilian Gov't CA
> might be fine for web sites in the .br zone, but unreasonable for .ar).
>  And some end-entities might be associated with public keys based simply
> on a trust-on-first-use/persistence-of-presence (aka TOFU-POP) approach,
> depending on the user's requirements.
> 
> Is there any way that a PKCS 11 client can currently ask such a question
> of a PKCS 11 plugin?  If not, is there any thought of extending PKCS 11
> to handle this?

With the PKCS#11 Trust Assertions we've defined a mechanism for PKCS#11
plugins to expose bits of information (the assertions) on which these
trust decisions can be based, such as verifying the identity of a peer.
Said another way, it provides 'storage' for 'trust' to use, not the
'trust' itself.

The reason PKCS#11 was chosen as the interface for this storage, is
primarily pragmatic: PKCS#11 can model storage of such objects, and it's
pretty ubiquitous. NSS has been been storing its 'trust objects' via
PKCS#11 for a long time, although this was never really formalized.

There's certainly room to work on a better identity verification model
and logic for applications to plug into, just like you outline. I'm not
convinced that PKCS#11 would be an appropriate API for this to happen over.

> It would be great if the job of any networked communication tool would
> be "just":
> 
>  a) establish tentative connection with a peer (note: this is a very
> loose concept and it probably varies greatly depending on the
> communication protocol in use)
> 
>  b) get public key associated with that peer (ensuring, if possible,
> that the peer does in fact control that public key)
> 
>  c) hand the (public key, protocol, peer) over to a standard library for
> verification that there is an acceptable match.
> 
> Asking each tool to take a list of authorities from the library (or even
> a list of authorities, marked with various trust markings) and draw its
> own inference seems like a potentially bad duplication of effort.  It
> seems simultaneously bug-prone, wasteful, and providing a poor user
> experience (e.g. nuanced identity verification decisions made using one
> tool won't necessarily take effect in other tools, even when using the
> same PKCS 11 libs).

I agree with your point. It's a pretty hard problem to solve in a
generic way right now. That's because:

I think that the identitify verification models, and trust models that
are in popular use are really immature. Hopefully in the near future
we'll see solid progress in this area. Things stagnated for a while in
this field, but are heating up again with many new ideas being brought
to the table.

Right now the best way for people to get somewhat standard identity
verification is to use crypto libraries like NSS or gnutls. It's a shame
there are more than one implementation. But by plugging them all into
PKCS#11 trust assertions, we can achieve some semblance of coherent
behavior for users.

Those are just some thoughts on this stuff, not discouraging more work
on it. On the contrary I hope that this PKCS#11 Glue effort will spur
more interest and further work in this area :)

> So my questions to the p11-glue folks are:
> 
>  Does something like the above already exist in PKCS 11?  i'd be very
> happy to learn that it is all there, and i just haven't read the spec
> correctly.

I think PKCS#11 Trust Assertions are a decent way to expose *storage* of
these trust bits. Currently these trust assertions are only defined for
X509 certificates. So far we've purposely left out defining trust
assertions for other subjects (like OpenPGP keys) because I'm a firm
believer in making sure specifications match the real world :)

But again, like you brought up, this is an incomplete solution. Trust
assertions need to be accompanied by logic that uses them (and other
inputs) to verify identities and make trust decisions.

>  If not, does this seem like something that might be in-scope for
> p11-glue, if properly specified?  Or should is there a different
> fundamental question?

I think it could be, although this is going take a big effort.

> Sorry for the lengthy post; i look forward to discussing these issues
> with you.

Me too. These are interesting issues, and I'm glad you're thinking about
them :)

Cheers,

Stef