On Mon, Dec 29, 2014 at 11:13:18PM -0800, Jan Pechanec wrote:
On Fri, 19 Dec 2014, Jan Pechanec wrote:
On Fri, 19 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.
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.
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 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
--