Subject: RE: 3280bis: CRL validation

From: "Manger, James H" <[email-masked]>
Date: Tue, 21 Jun 2005 11:57:21 +1000

No Santosh, it was not a change of subject.  You mistakenly though my earlier email was about a CRL that lists certs from different CAs with the same name so I tried to explain it in another way.  It was your mistake so I only sent the response to you, but I am happy to share it with PKIX.  I was not matching 2 CRL DPs either.

I eventually found your proposal again: http://www.orionsec.com/crldp-idp-v3.ppt.  It assumes the same name appearing in different certs refers to the same entity as long as the cert paths have the same prefix upto the end of the shorter path (excluding the final certs in each path).

My example of an indirect CRL revoking certs from 2 CAs:
1st cert path: "root" -> "CA1" -> "EE3" (with cRLIssuer="CRL0")
2nd cert path: "root" -> "CA2" -> "EE4" (with cRLIssuer="CRL0")
"CRL0" issues a CRL revoking "EE3" & "EE4", including the appropriate certificateIssuer extension ("CA1" & "CA2") in each entry respectively.

QUESTION 1: Who can issue "CRL0"'s own cert for this setup to work, making only the minimal assumption that each CA has its own namespace?

QUESTION 2: Who can issue "CRL0"'s own cert for this setup to work with Santosh's proposal?

ANSWER 1: There is no solution.  The cRLIssuer fields are certified by different CAs so the minimal assumption is that they refer to different entities.  [Actually, if "CRL0" got 2 certs, one from "CA1" and another from "CA2", perhaps it could work]

ANSWER 2: "root" -> "CRL0".  Only if "CRL0" gets a cert from "root" will its cert path be a prefix of the cert paths for both "EE3" and "EE4".  In this case, the subject DN "CRL0" certified by "root" is assumed to refer to the same entity as the cRLIssuer "CRL0" certified by "CA1" and by "CA2".

Assuming DNs are globally unambiguous is a reasonable assumption for some systems so it should be allowed.  It is easy to explain: if the DN is the same, assume the entity is the same.

Assuming each CA has its own namespace is probably prudent for some systems.  It is slightly harder to explain: if the sequence of DNs from a trust point are the same, assume the entity is the same.  Indirect CRLs revoking certs from 2 or more CAs don't make much sense in this model so they should be described separately from indirect CRLs for a single CA.

Assuming the namespace used by a CA is a superset of the namespace of its parent is probably reasonable for some systems (does it hold for VeriSign...?).  Santosh's proposal explains matching in this situation.

Perhaps 3280bis needs to describe CRL validation under at least these 3 different assumptions.  Perhaps relying party software and CAs MUST indicate which of these assumptions they make.

James

-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]] 
Sent: Monday, 20 June 2005 10:58 PM
To: Manger, James H
Subject: RE: 3280bis: CRL validation

This is a change in subject. Right?  Is there a reason you do not wish to
share this with the list and do not wish to agree with me or stand corrected
on the old point?

See the algorithm proposal from Nov. PKIX meeting briefing.

To limit the trust model for indirect CRL Issuer, see my response on this
thread to Stefan 5-12 days back on what makes sense 

If you are interested in this topic, read my postings on archives as early
is Fall 2003.  Once you understand what I am saying, you would be in a
position to jump in the fray.

Also you never match 2 CRL DPs.  So, what you are saying below is incorrect.
In order to understand what I am saying, you need to understand 3280
processing rules completely.

-----Original Message-----
From: Manger, James H [mailto:[email-masked]] 
Sent: Sunday, June 19, 2005 8:38 PM
To: [email-masked]
Subject: RE: 3280bis: CRL validation

"CRL0" issues a CRL revoking certs from "CA1" & CA1".
"CA1" issues a cert to "EE3" listing "CRL0" in the crlDistPoint. "CA2"
issues a cert to "EE4" listing "CRL0" in the crlDistPoint. "CAx" issues a
cert to "CRL0".

A relying party verifying "EE3"'s cert needs to match
 "CRL0" (crlDistPt) from a cert issued by "CA1", to
 "CRL0" (subject) from a cert issued by "CAx".
A relying party verifying "EE4"'s cert needs to match
 "CRL0" (crlDistPt) from a cert issued by "CA2", to
 "CRL0" (subject) from a cert issued by "CAx".

So which CA should "CAx" be if we only want to make the minimal assumption
that names are unambiguous in the context of the issuing CA?  There is no
solution.  For an indirect CRL covering more than one CA the minimal
assumption is insufficient. Could your algorithm work in this case? (I can't
find your algorithm to check myself -- there have been too many emails on
this topic!)

[It is not about a CRL issuer revoking certs from different CA's with the
same name]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, 17 June 2005 10:40 PM

Just the way, CA defines its own name space, we can assume that a CRL Issuer
does not issuer revocation information for two or more distinct CAs that
have identical DN.  Thus, what you say is not a problem. If you think folks
out there are setting up CRL Issuer that issues revocation information
covering two or more distinct CAs with the same name, we can add a sentence
to the X.509 and 3280.

The problem I am trying to solve is obtaining correct revocation information
when CA and CRL Issuer names are not guaranteed to be globally unique.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Manger, James H
Sent: Thursday, June 16, 2005 9:05 PM

...
With an indirect CRL covering certificates from more than one CA there is no
longer a single CA to provide the namespace for all names being matched.
Consequently, the minimal assumption that names are only unambiguous in the
context of one CA is no longer sufficient.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 20 Jun 2005 22:32:33 -0400

James,

My proposal does not require assumptions about name space except a CA does
not issue certificate for two or more distinct entities with the same DN.

To strengthen the security of indirect CRL, you need to constrain trust
assumptions as I have described in a e-mail on this threat few days back.

Once you make the trust assumptions about who a CA can delegate the CRL
issuance to, it does not matter if the delegate does this for one CA or
multiple CAs. 

-----Original Message-----
From: Manger, James H [mailto:[email-masked]] 
Sent: Monday, June 20, 2005 9:57 PM
To: Santosh Chokhani; pkix
Subject: RE: 3280bis: CRL validation

No Santosh, it was not a change of subject.  You mistakenly though my
earlier email was about a CRL that lists certs from different CAs with the
same name so I tried to explain it in another way.  It was your mistake so I
only sent the response to you, but I am happy to share it with PKIX.  I was
not matching 2 CRL DPs either.

I eventually found your proposal again:
http://www.orionsec.com/crldp-idp-v3.ppt.  It assumes the same name
appearing in different certs refers to the same entity as long as the cert
paths have the same prefix upto the end of the shorter path (excluding the
final certs in each path).

My example of an indirect CRL revoking certs from 2 CAs:
1st cert path: "root" -> "CA1" -> "EE3" (with cRLIssuer="CRL0") 2nd cert
path: "root" -> "CA2" -> "EE4" (with cRLIssuer="CRL0") "CRL0" issues a CRL
revoking "EE3" & "EE4", including the appropriate certificateIssuer
extension ("CA1" & "CA2") in each entry respectively.

QUESTION 1: Who can issue "CRL0"'s own cert for this setup to work, making
only the minimal assumption that each CA has its own namespace?

QUESTION 2: Who can issue "CRL0"'s own cert for this setup to work with
Santosh's proposal?

ANSWER 1: There is no solution.  The cRLIssuer fields are certified by
different CAs so the minimal assumption is that they refer to different
entities.  [Actually, if "CRL0" got 2 certs, one from "CA1" and another from
"CA2", perhaps it could work]

ANSWER 2: "root" -> "CRL0".  Only if "CRL0" gets a cert from "root" will its
cert path be a prefix of the cert paths for both "EE3" and "EE4".  In this
case, the subject DN "CRL0" certified by "root" is assumed to refer to the
same entity as the cRLIssuer "CRL0" certified by "CA1" and by "CA2".

Assuming DNs are globally unambiguous is a reasonable assumption for some
systems so it should be allowed.  It is easy to explain: if the DN is the
same, assume the entity is the same.

Assuming each CA has its own namespace is probably prudent for some systems.
It is slightly harder to explain: if the sequence of DNs from a trust point
are the same, assume the entity is the same.  Indirect CRLs revoking certs
from 2 or more CAs don't make much sense in this model so they should be
described separately from indirect CRLs for a single CA.

Assuming the namespace used by a CA is a superset of the namespace of its
parent is probably reasonable for some systems (does it hold for
VeriSign...?).  Santosh's proposal explains matching in this situation.

Perhaps 3280bis needs to describe CRL validation under at least these 3
different assumptions.  Perhaps relying party software and CAs MUST indicate
which of these assumptions they make.

James

-----Original Message-----

...