Subject: CRL Certification Path

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 4 Nov 2003 10:26:44 -0500

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)
[email-masked]
Visit our Web site
http://www.orionsec.com

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 05 Nov 2003 18:17:14 +0100

Santosh,

Thank you for raising the issue.

I agree that the current text is too vague.

> 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:
> 
>       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.

This text is not sufficient.

The CA can nominate a CRL Issuer for the management of the revocation status 
of the certificates that it issues and thus the path is one leg longer, 
since the Issuing CA issues a certificate to nominate the CRL issuer. The 
text above does not capture this point.

Denis

> certificate is valid for.  This comparison shall be performed by 
> converting the policies to the relying party domain.
> 
> 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.
> 
> 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

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 6 Nov 2003 08:04:19 -0500

Denis:

Rules 1 through 3 are only when certificate issuer is the same as the CRL
issuer.

My original post had a single rule for indirect CRL (it emanate from the
same trust anchor.  The rule you propose is secure, but much more
restrictive and represents a change in both X.509 and RFC 3280.  Neither
require certificate based delegation of the indirect CRL issuer by the
certificate issuer.  This change in the standard may cause backward
compatibility problem (I know at least one PKI that does Indirect CRL, but
without certificate based delegation by the certificate issuer.  I think the
following is appropriate for the Indirect CRL:

1.	Certification path for the Indirect 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 certificate
issued to the Indirect CRL issuer or the certificate issuer, whichever
terminates first.  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.

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Wednesday, November 05, 2003 12:17 PM
To: Santosh Chokhani
Cc: Tim Polk; Russell Housley; Laura Boyer; Steve Kent; [email-masked];
'OSI Directory List'
Subject: Re: CRL Certification Path

Santosh,

Denis

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 06 Nov 2003 16:22:57 +0100

Santosh,

> restrictive and represents a change in both X.509 and RFC 3280.  
                                ^^^^^^
I would say a clarification.

RFC 3280 states:

    CRL issuer: an optional system to which a CA delegates the
                publication of certificate revocation lists;

I do not believe that this means an upper CA in the chain, but *the* CA 
which isues certificates and is responsible to provide revocation status 
information using either CRLs or OCSP responses.

RFC 3280 states:

    However, a CA may delegate this responsibility to
    another trusted authority.  Whenever the CRL issuer is not the CA
    that issued the certificates, the CRL is referred to as an indirect
    CRL.

When CRLs are used, CAs are also responsible to place the location of the 
CRL issuer in the CRL DP extension for the certificates they issue. It is 
thus not an upper CA that is responsible for this, as your proposed text 
would permit for this.

Your text below is thus not appriopriate.

Denis

 > Neither

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 6 Nov 2003 10:38:28 -0500

Denis:

My reading of X.509 and RFC 3280 is that "the delegation" is referring to
the Indirect CRL Issuer name assertion in the CRL Distribution Point
extension of the certificate.  It does not imply or mandate that the CA
issue a certificate to the CRL issuer.

I would like RFC 3280 editors' view on this.

In terms of delegation to only an upper CA, you are misinterpreting my
text..  The reason I said "whichever terminates first" is to accommodate
your scenario of the certificate issuing CA issuing a certificate to
Indirect CRL issuer.

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Thursday, November 06, 2003 10:23 AM
To: Santosh Chokhani
Cc: [email-masked]; 'OSI Directory List'
Subject: Re: CRL Certification Path

Santosh,

> Rules 1 through 3 are only when certificate issuer is the same as the 
> CRL issuer.
> 
> My original post had a single rule for indirect CRL (it emanate from 
> the same trust anchor.  The rule you propose is secure, but much more 
                                ^^^^^^

RFC 3280 states:

RFC 3280 states:

Denis

> compatibility problem (I know at least one PKI that does Indirect CRL, 
> but without certificate based delegation by the certificate issuer.  I 
> think the following is appropriate for the Indirect CRL:
> 
> certificate, starting with the trust anchor and ending with the 
> certificate issued to the Indirect CRL issuer or the certificate 
> issuer, whichever terminates first.  During name matching, all 
> self-issued certificates in both paths shall be ignored.
> 
>>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.
>>
>>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.
>>