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