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. 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. -- David Woodhouse Open Source Technology Centre david.woodho...@intel.com Intel Corporation
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
