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

[Daniel Kahn Gillmor]

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 :)

PKCS 11 offers a way for tools to do two things:

 A) Get access to use secret key material that belongs to the user or
system exercising the tool.

 B) Get access to identity certificates of several kinds:
  B1) certificates associated with the secret key material from A (certs
identifying the user)
  B2) certificates belonging to authorities, which may or may not be
trusted by the user to identify other parties.


I have no strong objections to either A or B1 -- my understanding of the
PKCS 11 API is that it can handle those use cases well, and can help
users manage their cryptographic identities across tools.

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?

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 contribute to the Monkeysphere project [0], which has its own
formalization of this process [1] for our web-browser plugin and agent.
 I'm sure the project would be happy to write a PKCS 11 plugin to
formalize this kind of use, if it fits.

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.

 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?

 If this sort of thing doesn't belong in p11-glue, where *should* an
interface like this belong?

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

Regards,

	--dkg

[0] http://web.monkeysphere.info/
[1] http://web.monkeysphere.info/validation-agent/protocol/Q

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/p11-glue/attachments/20110707/102baa94/attachment.pgp>