On Tue, 30 Dec 2014, Nico Williams wrote:
[discussion about an abstract "list PKCS#11 resource URIs"
operation elided.]
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.
Which attributes to use for the listing would have to be
context-specific. Most apps/users would never want to match on slot
attributes, but some might. We can't say much about that.
yes, and I think it will be important to state in the text
that the choice of exact set of attributes is context specific.
Users will mostly not be writing PKCS#11 URIs, that's for sure. PKCS#11
is not very user-friendly...
Where a PKCS#11 URI is used, I suspect it will be produced by an
application, and then cut-n-pasted around as necessary by the user.
Do we have to say much about how the app should go about forming a URI
for a PKCS#11 resource? It depends.
If the same app will consume the same URI, then we need not say
anything. If a different app will consume the same URI then we might
have to. This is about inter-app interoperation.
I'd say it does not matter much whether it's the same
application which is gonna use the generated URI or not, it's all
about the context - if it's enough or not.
As to how to say anything about this, here's what comes to mind:
Given a PKCS#11 URI template [RFC6570], an application MAY support
listing URIs of PKCS#11 resources such that the resulting URIs can
later be used to access the same resources if the template captured
the necessary context.
I like the use of the templates. I just quickly read through
the RFC. It looks that, for example, when generating a key pair, the
application could support a default template with empty variables
which would be used to optionally list a URI based on the
CK_OBJECT_HANDLE of the generated key pair. And it could accept a
different one to override the default. As mentioned above, I'd like
to explicitly express that URI list is context specific. I slightly
modified the paragraph above:
When listing URIs of PKCS#11 resources the exact set of
attributes used in a URI is inherently context specific. A
PKCS#11 URI template [RFC6570] support MAY be provided by a
URI generating application to list URIs to access the same
resource(s) again if the template captured the necessary
context.
I think we wouldn't need to say more about the matter.
thank you, J.
I don't think we could say much more without gaining experience with
deployment.
Caveat emptor: I'm not too conversant with URI templating, so I don't
know how to phrase this correctly...
Nico
--
Jan Pechanec <jan(_dot_)pechanec(_at_)oracle(_dot_)com>