Editors of 3280 and X.509:
There is a security hole in the X.509 and RFC 3280 certification path validation for CRL, which can be exploited or result in undesirable behavior when global name uniqueness among various PKI is not assured.
The problem manifests itself when a relying party can not verify signature on a CRL using the certificate issuer public key and thus needs to build a certification path for the CRL. This could occur when a CA has re-keyed after the certificate whose revocation status is being checked, was issued.
Neither RFC 3280 nor X.509 require that the certification path for the CRL have some semblance to the certification path for the certificate whose status is being checked. For example, Section 6.3.3 Step “f” of RFC 3280 states only the following for the certification path for the CRL:
“Obtain and validate the certification path for the complete CRL issuer. If a key usage extension is present in the CRL issuer's certificate, verify that the cRLSign bit is set.”
A set of rules along the following lines should be added to RFC 3280 and to X.509:
1. Certification path for the CRL shall begin with the same trust anchor as the certification path for the certificate whose status is being checked
2. The issuer names in the certification path for the CRL shall match one for one with the issuer names in the certification path for the certificate, starting with the trust anchor and ending with the last certificate in the certification path for the CRL. During name matching, all self-issued certificates in both paths shall be ignored.
3. Certification path for the CRL shall be valid for at least one of the certificate policies acceptable to the relying party.
Rule 3 above is less restrictive and more appropriate rule would be
Alternative rule 3: Certification path for the CRL shall be valid for at least the same certificate policies that the certification path for the certificate is valid for. This comparison shall be performed by converting the policies to the relying party domain.
An obvious question comes to mind:
§ What about Indirect CRL?
Requiring that the Indirect CRL Issuer be from the trust domain as the certificate is a good idea and not overly restrictive given that we can not guarantee global name uniqueness among all the PKIs trusted by a relying party.
Another alternative to all of the above pontification is to require the relying parties to ensure that all trust anchors are constrained to disjoint name spaces, i.e., intersection between the permitted name spaces for any two trust anchors is null.
Santosh Chokhani
Orion Security Solutions, Inc.
1489 Chain Bridge Road, Suite 300
McLean, Virginia 22101
(703) 917-0060 Ext. 35(voice)
(703) 917-0260 (Fax)
chokhani@xxxxxxxxxxxx
Visit our Web site
http://www.orionsec.com