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.pechanec@xxxxxxxxxx>