Re: [saag] PKCS#11 URI slot attributes & last call

[Nico Williams <[e-mail]>]

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
--