Subject: CRL Certification Path

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 4 Nov 2003 10:27:43 -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: "Santosh Chokhani" <[email-masked]>
Date: Thu, 6 Nov 2003 08:05:45 -0500

Thomas:

Generally, trust anchor is revoked using out of band means such as manually
deleting it.  Neither X.509 nor RFC 3280 require revocation status checking
of a trust anchor.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, November 06, 2003 4:27 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: AW: CRL Certification Path

Denis, Santosh,

there is another reason why the trust anchor for the certificates
verification path should be different to the trust anchor for the CRLs
verification path. What happens when the certificates trust anchor has to be
revoked? If the root (trust anchor) signs the CRL containing its own
certificate the CRLs verification path becomes invalid.

Regards

Thomas Beckmann
 -------------------------------------
 Thomas Beckmann
 Fachgruppenleiter PKI und Trustcenter
 
 SchlumbergerSema  -
 Competence Center Informatik GmbH 
 Lohberg 10
 D-49716 Meppen
 
 Tel:+49 5931-805-242
 Mobil: +49 174 333 62 31  
 Fax: +49 5931-842-242

 EMail: [email-masked]
 Internet: www.SchlumbergerSema.de

> -----Ursprüngliche Nachricht-----
> Von: Denis Pinkas [mailto:[email-masked]]
> Gesendet: Mittwoch, 5. November 2003 18:17
> An: Santosh Chokhani
> Cc: Tim Polk; Russell Housley; Laura Boyer; Steve Kent;
> [email-masked]; 'OSI Directory List'
> Betreff: Re: CRL Certification Path
> 
> 
> 
> 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