On Tue, 2015-05-05 at 09:47 -0700, Ryan Sleevi wrote: > On Tue, May 5, 2015 8:55 am, David Woodhouse wrote: > > I'm talking about the serial numbers of the certs issued *by* the two > > "My CA"s. > > Good to have that clarification :) > > Different CAs (in as much as different public keys), but with the same > DER-encoded subject name (not necessarily the same DER-encoded issuer > name, but that's irrelevant), and the same starting serial number (1). > > The question is how to distinguish certificate (or public key) objects > between the two, so that we could construct an unambiguous identifier.
To be honest, I wasn't really asking that question — I was mostly just
objecting to the suggestion that 'CKA_ISSUER + CKA_SERIAL_NUMBER' was
an *answer* to it.
> So to uniquely identify a certificate, you look up for *all* CKA_SUBJECT
> matches, then get the CKA_VALUE/CKA_URL to do the comparisons.
Assuming you *have* the issuer in your local database, of course.
Which you might not.
> Does that work for PKCS#11 URLs? Absolutely not. That's because there IS
> NOT a unique disambiguator that can be provided apriori if you don't know
> the certificate. As Bob notes, it's entirely valid for two objects to have
> the same CKA_ID and distinct CKA_SUBJECTs. In fact, that's *explicitly*
> called out in the description of CKC_X_509
>
> "Since the keys are distinguished by subject name as well as identifier,
> it is possible that keys for different subjects may have the same CKA_ID
> value without introducing any ambiguity."
>
> Further, I'm having a hard time finding a normative reference in any
> of the PKCS#11 RFCs that require the CKA_ID values be unique for a
> given CKA_SUBJECT (only non-normative descriptions that they should
> be, or are intended to be).
CKA_ID is supposed to match the X509v3 Subject Key Identifier. From
§4.6.3 of v2.40 of the PKCS#11 specification:
"Note that with the version 3 extensions to X.509 certificates, the
key identifier may be carried in the certificate. It is intended
that the CKA_ID value be identical to the key identifier in such a
certificate extension, although this will not be enforced by
Cryptoki."
I don't see any reason to believe the SKI should be unique for any
given CKA_SUBJECT. Why *not* re-use the private key and just issue a
new CSR and get a new certificate to go along with it?
> Is this a problem in practice? Unknown. But it does indicate that the
> PKCS#11 URIs are not in and of themselves sufficient to uniquely and
> unambiguously identify an object, per spec.
No, for now I'd say it's definitely not a problem in practice. There
*might* be some motivation to extend the URI scheme to allow the
creation of guaranteed-unique URIs (but oops, this list's broken¹
Reply-To: setting just dropped the person most likely to undertake
that).
But in the meantime, in *practical* usage, it's perfectly fine. Sure,
it's *possible* to construct a scenario where you can't create an
unambiguous string that specifies the object you want. But that was
already true for PK11_GetCertByNickname() anyway. And in the common
case where the user just has a cert in a hardware crypto token, or
wants to reference a cert in their GNOME keyring or NSS database, the
CKA_ID is almost *always* going to be entirely
sufficient.
--
dwmw2
¹ http://david.woodhou.se/reply-to-list.html
smime.p7s
Description: S/MIME cryptographic signature
-- dev-tech-crypto mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-crypto
