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. 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(). 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. -- dwmw2
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
