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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

> Since I did not involve myself in the process, I do not know if those
> goals were excluded for some legitimate reason, but the discussion
> preceding makes it sound like they were not met.

They weren't.  And the I-D covers semantics in such a way that it
defines an abstract API, but perhaps it needs to be made more explicit.

Nico
-- 






[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]