ietf
[Top] [All Lists]

Re: [saag] PKCS#11 URI slot attributes & last call

2014-12-31 23:35:53
On Fri, 19 Dec 2014, Jan Pechanec wrote:

On Fri, 19 Dec 2014, Nico Williams wrote:

On Fri, Dec 19, 2014 at 03:19:00PM -0800, Henry B (Hank) Hotz, CISSP wrote:
Does this ID, in fact, define an API which is sufficient to support
realistic, interoperable code across a significant range of libraries
and platforms? Is there a unique way to reference the authentication
credential on my guaranteed-unique government-issued smart card
regardless of which reader on which platform it’s plugged into?

Excellent questions.

As to the first: it's a rather abstract API.  I'm a bit concerned about
some of the semantics, that we might need to make matching a bit more
flexible.

IIRC there's a token that requires a login even to see public objects.
I might want to have a way to say "match public objects that don't
require login".

Or, I might want to provide slot/token attributes as hints, but not as
required attributes, that match preferentially but which are ignored if
not.

Abstract operations that I think should be described:

- given a PKCS#11 URI, return a PKCS#11 provider (e.g., a handle
  returned by dlopen()/LoadLibrary*(), or a v-table, or whatever is
  appropriate in the caller's given programming language);

  This is described, actually.

- given a PKCS#11 URI (and, optionally, a PKCS#11 provider) return a
  PKCS#11 provider and relevant PKCS#11 handles (token, session,
  object);

  This is also described.

- given a PKCS#11 URI return a list of URIs for all matching tokens
  and/or objects;

  This is not described.

  E.g., given "pkcs11:" output a list of all {provider, slot},
  {provider, slot, token}, {provider, slot, token, public object} URIs
  for actual slots, tokens, public objects.

  E.g., given "pkcs11:" and a PKCS#11 session return all {provider,
  slot, token, object} URIs for actual objects reachable via that
  session.

- given a PKCS#11 provider and handle of some sort, return a URI for
  it, with an option to include or exclude slot/token matching
  attributes.

  This is also not described, IIRC.

      so, as well as we have "PKCS#11 URI Matching Guidelines" 
section, we might need "PKCS#11 URI Generation Guidelines" to discuss 
these things about "reverse mapping".  I will take a look at it.

        I've been thinking about this for the past days and I'm not 
sure if such guidelines should be provided since it very much depends 
on how a URI will be used and in what scenarios.

        for example, if referencing a key pair, an "id" attribute is 
there to distinguish multiple public-key/private-key pairs held by the 
same subject.  However, I think that if used on a command line to 
provide an access to the key pair, it would be used only if there 
really were multiple keys of the same name.  And that information I 
may acquire only when I try not to use those attributes when I get an 
error message about multiple key pairs - which may or may not be 
acceptible.  On the other hand, it may be a good idea to use it always 
if such a URI would be provided in a long lived configuration file, 
for example.

        similarly with a token.  To uniquely identify a token (either 
to refence it by itself or because I have objects of the same name in 
multiple tokens), manufacturer and serial number should be used but 
again, I'd rather use the token (name) attribute unless I have 
multiple tokens of the same name.  What is more, if the token is not 
guaranteed unique then I may need library attributes (say for soft 
tokens in multiple libraries).  And even that may not be sufficient if 
I link to the same libraries from different file paths in which case 
the module attributes may be needed.  Again, I'd want to use all these 
attributes only when such a situation arises.

        if the consensus is that I should provide a paragraph that 
would summarize ideally in a more succint way what I've been saying 
above (or whether I should do something else) I will try to come up 
with a reasonable text but at this point I still don't think it is 
necessary.

        thank you, Jan.

-- 
Jan Pechanec <jan(_dot_)pechanec(_at_)oracle(_dot_)com>