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. > >And perhaps because there's a long history of people making the >mistake of assuming that the X.509 subject is unique (I've fixed bugs >in certificate chain validation in both OpenSSL and GnuTLS because of >that), as well as jumping through hoops to present the full trust >chain on the wire in the OpenConnect VPN client, because the Cisco ASA >had the same issue). > >So by omitting CKA_SUBJECT we make it harder for people to make the >same mistake. > >Those are just guesses though. > > -- Jan Pechanec <jan.pecha...@oracle.com> -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
