On 05/03/2015 02:17 AM, David Woodhouse wrote:
On Sat, 2015-05-02 at 18:33 -0700, Jan Pechanec wrote:On Fri, 1 May 2015, David Woodhouse wrote:On Fri, 2015-05-01 at 11:35 +0100, Alan Braggins wrote:On 30/04/15 17:56, David Woodhouse wrote:Has anyone looked at implementing RFC7512 support, allowing an object to be specified by a PKCS#11 URI?I don't suppose you know why RFC 7512 uses CKA_ID but not CKA_SUBJECT, when PKCS#11 says " The*CKA_ID*attribute is intended as a means of distinguishing multiple public-key/private-key pairs held by the same subject" and "it is possible that keys for different subjects may have the same*CKA_ID*value without introducing any ambiguity"?That question would be better directed to the authors of the RFC. I've added Jan to Cc. Yes, in isolation both CKA_SUBJECT and CKA_ID are ambiguous since multiple certificates can exist with the same subject, and multiple certificate can exist with the same private key (hence the same CKA_ID). I'm not quite sure of the motivation for omitting CKA_SUBJECT from the URI specification. Perhaps because it's redundant to a *certain* extent with CKA_LABEL — in the relatively rare case that CKA_ID isn't actually unique, hopefully CKA_LABEL is sufficient to disambiguate.Hi David, that's a very good question. It was a deliberate decision back in the days of filing the first I-D in March 2010. I didn't want to delve into a certificate. I know there is a key ID in X.509 v3 which is expected to be in CK_ID if present in the cert, but I didn't want to go beyong an id. Any other component path attributes are directly PKCS #11 related. I thought about adding CK_SUBJECT there while writing 00 based on what we were doing with Darren (cc'ed) in Solaris those days. But then, CKA_START_DATE and CKA_END_DATE could be useful as well, to pick valid certificates, for example, and also CKA_SERIAL_NUMBER and CKA_ISSUER, and even CKA_HASH_OF_SUBJECT_PUBLIC_KEY. Possibly something else. The scheme definition would grow significantly and in general we were concerned that the more complex the scheme would become to be, the more difficult would be to use it. Using the "object" attribute seemed like the best way to identify a key, with an ID if needed, and possibly library attributes. Also note that comparing URIs would become more difficult as the subject attribute would need to be normalized (how exactly?). So, we started with a basic list of attributes we thought were enough to identify an object or token and expected people to tell us what else was useful for them. That's how we added library-* and slot-* attributes (after a long discussion a few years ago, we deliberately decided not to use a slot since its ID is not stable across PKCS #11 module initialization, but then again, someone asked for it and we thought that it was just better to add it), and we also added query component attributes, including the PIN in the URI, which we also initially opposed to have but were convinced to add by early adopters. And in those more than 5 years since the draft 00, no one asked for the CKA_SUBJECT attribute. Having said that, I assumed that other URI attributes might be needed in the future, possibly with new versions of the PKCS #11 standard; I didn't see anything new in upcoming 2.40 useful to be added to the URI though. So, if there is a strong feeling about a new attribute, there is always a way of patching the parser and filing an I-D to extend the scheme, and let the community decide. In this situation though, I still believe that it's better not to put the certificate subject in there, due to the reasons mentioned above. Regards, Jan.Hi Jan, Thanks for the prompt response (as ever), which I've cited in its entirety since I'm not sure it made it to the list. For the case of NSS, I suspect the lack of CKA_SUBJECT shouldn't be a real problem. I've just started looking at NSS with a view to fixing it to take PKCS#11 URIs, and it looks like the common way of specifying a certificate is by its "nickname", which is CKA_LABEL, using the PK11_FindCertFromNickname() function.
So in NSS, CKA_LABEL is simply a short cut to CKA_SUBJECT. That is NSS looks up a cert from the nickname and picks all the certs that match that cert's subject. The idea (back 2 decades ago when this was implemented) was that nickname was the user facing name for the cert 'identity'. Multiple certs made up that identity (auth certs, non-repudiation certs, key exchange/encryption certs, expired versions of the above). As a result CKA_LABEL is not unique to a cert (anymore than a subject is). LABEL is not required as well (certain intermediate CA's may not have a label associated with them).
Currently the only unique way to identify a cert is CKA_ISSUER and CKA_SERIAL_NUMBER unless you want to include the value. The PKCS #11 working group is active again at OAISIS. If we want a unique object identifier
I think we just need to either extend PK11_FindCertFromNickname() to spot when the string it's given starts with 'pkcs11:' and treat it as a URI instead, or add a new parallel function PK11_FindCertFromURI().
If we are OK for the URI to return multiple certs, then use of CKA_ID or CKA_LABEL/CKA_SUBJECT is fine.
Assuming that the application doesn't have any tokens named 'pkcs11'. The current nickname spec in NSS is 'token:nickname'. I think that that is a fair assumption, but we just need to be clear That is what is happening.I'm inclined to favour the former, since it means that applications which take nicknames on the command line would Just Work when given RFC7512 URIs, without needing to modify the applications at all.
Referring to the mini-howto at https://bugzilla.redhat.com/1217727#c1 (a bug against the pesign utility) which shows how to deal with the NSS issues around PKCS#11 usability, this would basically *solve* the lack of URI support without having to touch pesign at all. Then we only need to deal with the fact that NSS doesn't load the system-configured PKCS#11 tokens by default, which is an orthogonal issue probably outside the scope of your interest, Jan.
smime.p7s
Description: S/MIME Cryptographic Signature
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
