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.
J.
>> 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
>
--
Jan Pechanec <jan.pechanec@xxxxxxxxxx>