On Tue, 2015-05-05 at 12:29 +0100, Alan Braggins wrote: > On 04/05/15 21:53, David Woodhouse wrote: > > > On Mon, May 4, 2015 1:25 pm, David Woodhouse wrote: > > > > Surely that's not unique? Using the above example, surely the first > > > > certificate issued by the 2010 instance of 'My CA', and the first > > > > certificate issued by the 2015 instance, are both going to have > > > > identical CKA_ISSUER and CKA_SERIAL_NUMBER, aren't they? > > > No, every subject and serial must be unique. If the 2010 and 2015 instance > > > are distinct bytes, they need distinct serial numbers. > > I was speaking of the serial numbers of certificates issued *by* those two > > separate CAs. Or are you suggesting that those sets of serial numbers muat > > be disjoint? > You mean the 2015 instance is a re-signing of the "same" certificate? > Isn't the signature included in the "distinct bytes", meaning it's still a > new certificate which needs a new serial number, even if it's based on > the same request and the request is signed by the same key.
Nonono, forget the CKA_SERIAL_NUMBER on the 'My CA' objects. Those are irrelevant — and yes, if those two were actually issued by the same ancestor CA then you're quite right that they'll need to have different serial numbers. That wasn't what I was talking about though. I'm talking about the serial numbers of the certs issued *by* the two "My CA"s. Let's assume each CA starts at '1' — that in each case the CKA_SERIAL_NUMBER of the first cert issued *by* 'My CA' is "1". Now, since each of those CAs issues a cert with CKA_SERIAL_NUMBER="1", and in both cases the CKA_ISSUER of that issued cert is 'My CA', that means the combination of CKA_ISSUER and CKA_SERIAL_NUMBER does *not* uniquely identify a certificate, surely? (Unless the two CAs in question are expected to use *disjoint* number spaces for the CKA_SERIAL_NUMBER of certificates that they themselves issue?) > (But that the CKA_SUBJECT and CKA_ID pair will uniquely identify the > private key that both certificates apply to. Years of working with HSMs > have left me with the attitude that the private key is the important bit, > and any certificate is someone else's problem, so issuer and serial number > are irrelevant :-) > But I do realize that's not the typical application view.) Right. And this is what we have the X509v3 Subject Key Identifier and Authority Key Identifier for :) That's exactly my point above. CKA_ISSUER doesn't uniquely specify the issuer. The X509v3 Authority Key Identifier is a whole lot better. This is precisely the background which made me object to the statement about CKA_ISSUER+CKA_SERIAL_NUMBER being unique. I'm *sick* of people assuming that CKA_ISSUER is meaningful :) My employer has a habit of creating new CAs with the same subject as old ones. So I've dealt with a number of bugs where validation fails because some piece of code assumes that it can find the issuer of a given certificate by looking for the first CA in the database whose CKA_SUBJECT matches the CKA_ISSUER of the certificate in question. Depending on the order of the certs in the ca-trust file, OpenSSL used to select the *wrong* one of the many CAs with matching subject, then check the signature and declare it invalid (which I fixed in RT#1942). It also used to send the wrong one on the wire in an SSL exchange, and I have code in the OpenConnect VPN client to explicitly add the *right* ones. When doing validation from a PKCS#11 trust database like p11-kit -trust, GnuTLS also had a similar issue which I fixed more recently. I found another such bug just *yesterday* in the pesign tool when I was looking at the issues with NSS's lack of integration with the system PKCS#11 configuration. So you'll forgive me if I object to Bob's assertion that 'the only unique way to identify a cert is CKA_ISSUER and CKA_SERIAL_NUMBER" even though it's a digression from the real topic at hand. It pushes my buttons :) -- 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
