Subject: No subject given

From: [email-masked]
Date: Fri, 21 May 1999 13:15:46 GMT

Hi,
     
In the process of implementing a PKIX compliant certificate management 
client, I have come across some strangeness in the PKIX certificate 
chain construction process, and I'd be very grateful if anyone can 
shed any light.
     
Starting at the beginning: I receive a certificate ostensibly 
belonging to a sender (C1), and I want to find the certificate that 
issued it in order to construct a complete chain back to a trusted 
root. There are three places where I might find the issuer cert: a 
local store of trusted root certs, a collection of untrusted 
certs handed to me by client code, and a remote repository 
containing untrusted intermediate certs. 
     
In order to help me identify an issuer, I will find in the certificate the 
issuing entity's DN. I also have none, any or all of the following:
     
     -issuer serial number
     -issuer key Id
     -issuer unique Id
     
1) Suppose, first, that none of these are present, but I find two 
(or more) certificates owned by the entity named in the issuer field of C1. 
How do I distinguish which is the right one?  I assume I can only try 
to verify the signature on C1 with the key in each of the candidate 
issuers, and see which one works. It is possible, I assume, that both 
may work if a CA has had the same key certified by two superior CAs. 
In that case I have to fork my candidate chains, keep going until I 
find a root and then check that the root policies are acceptable.
     
Effectively I use signature verification to distinguish which 
certificate to use. But this means that I cannot distinguish between 
signature verification failing due to a forged/corrupted subject 
certificate, and due to a wrong choice of issuer. So if I find only 
one certificate locally, and the signature does not verify, this might 
be simply because I have the wrong issuer certificate; and I will 
return a false negative. 

Is it permissible for a CA to have the same key certified by two different 
CAs? If so, it seems that it would be possible for a two certificates to have 
the same issuer name and serial number, which seems wrong. 
     
2) Suppose the certificate does contain an issuer serial number, but I 
don't have a certificate locally with that DN + serial number. 
However, I do have a certificate locally with that DN, and this 
certificate contains the same key, which therefore successfully 
verifies C1. Is it acceptable for me to use this as my issuer 
certificate? It is of course possible that I'm not processing the 
authority key identifier at all, in which case I don't even realise 
that this may be an issue.  

Are these scenarios even valid?

Thanks,

Will

---

From: Darren Harter <[email-masked]>
Date: Fri, 21 May 1999 16:47:41 +0100

Will,

Comments/thoughts inline...

-----Original Message-----
From:	[email-masked] [SMTP:[email-masked]]
Sent:	Friday, May 21, 1999 2:16 PM
To:	[email-masked]
Subject:	No subject given

[DH]  Intro snipped.

     -issuer serial number
     -issuer key Id
     -issuer unique Id

[DH]  One possible way to distinguish them would be through the algorithm.  Ensure that the algorithm specified in the body of C1 matches the algorithm in the Subject Public Key info of the candidate cert.

[DH]  I tend to verify the signatures after I've found a trusted root.  Build up a tree of possible certification paths, but only validate the one with a trusted root at the top.  If you have more than one with a trusted root just pick one.  Working this way also allows you to cope with cross certification without verifying the sig on a non-trusted root cert.

[DH]  IMHO you should not use the public key from any cert until you have verified the signature of that cert. A consequence of this is that you cannot verify the sig on C1 until you have verified the sig on its issuer cert - unless the issuer cert is one of your trusted roots.

[DH]  The answer to the first part is clearly yes.  But your second assumption doesn't hold.  It is the responsibility of each CA to ensure that it never generates certificates with duplicate serial numbers.  You never get two certs with the same serial number from the same issuer.  In your case you have two different issuers and therefore two different issuer DNs.  the serial number sets are therefore distinct.  You could of course have to different DNs but have the same serial number

[DH]  Part of the answer to this is a local security policy issue.  If your app only understands v1 or v2 certs you can use it (subject to local policy).  If your app does understand v3 certs but does not handle Authority Key Identifier AND it is not critical present then you could again use the cert.  However, if your app does understand Authority Key Identifier or it is critical you cannot use the cert.

Thanks,

Will
 
Hope this all helps,

Regards,

Darren

------------------------------------------------------------------------
Darren Harter BSc (Hons) CEng MBCS
Entegrity Solutions Corp
http://www.entegrity.co.uk
http://www.entegrity.com
Tel:  +44 (0) 1452 371383
Fax: +44 (0) 1452 371384
Cell: +44 (0) 7801 812850
Email: mailto:[email-masked]