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>
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: slot attributes & last call, (continued)
- Re: slot attributes & last call, Jaroslav Imrich
- Re: slot attributes & last call, Nico Williams
- Re: slot attributes & last call, Jan Pechanec
- Re: slot attributes & last call, Nico Williams
- Re: PKCS#11 URI slot attributes & last call, Jan Pechanec
- Re: PKCS#11 URI slot attributes & last call, Nikos Mavrogiannopoulos
- Re: PKCS#11 URI slot attributes & last call, Darren J Moffat
- Re: [saag] PKCS#11 URI slot attributes & last call, Henry B (Hank) Hotz, CISSP
- Re: [saag] PKCS#11 URI slot attributes & last call, Nico Williams
- Re: [saag] PKCS#11 URI slot attributes & last call, Jan Pechanec
- Re: [saag] PKCS#11 URI slot attributes & last call,
Jan Pechanec <=
- Re: [saag] PKCS#11 URI slot attributes & last call, Nico Williams
- Re: [saag] PKCS#11 URI slot attributes & last call, Jan Pechanec
- Re: [saag] PKCS#11 URI slot attributes & last call, Nico Williams
- Re: PKCS#11 URI slot attributes & last call, Jan Pechanec
- Re: [saag] PKCS#11 URI slot attributes & last call, Stephen Farrell
- Re: PKCS#11 URI slot attributes & last call, Jan Pechanec
|
|
|