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.pechanec@xxxxxxxxxx>