Subject: Re: 3280bis: CRL validation

From: "Denis Pinkas" <[email-masked]>
Date: Wed, 15 Jun 2005 16:47:29 +0100

Santosh,
 
>Denis,

>The situation I am discussing is when the CRL Issuer is also the certificate
>issuer.

Who need to solve these kinds of issues one by one.

>As to the indirect CRL, there are no constraints in the standard that the
>indirect issuer needs to be issued a certificate by the CA and the indirect
>CRL issuer cover only one CA.

The concept of "indirect CRL" is currently too broad (and too vague) since it covers 
two very distinct cases (cases a and b). Thse two cases should be given a name 
so that we may easily distinguish between them

>My proposal solves the ambiguity for both direct CRL (i.e., certificate
>issuer DN == CRL issuer DN) and indirect CRL.  

No there is no single solution good for everything.

> For indirect CRL (as I
>responded to Stefan) requires additional trust assumptions that neither
>X.509 nor 3280 have.

The zillion number of cases requires additional assumptions 
and there may be zillions of such assumptions.

:-)

The case where the CA is the CRL issuer is straightforward:

If a certification path is may be constructed, then the same sequence of DNs
from the same root key MUST be used to verify the signature of the CRL.

The case where the CA designates a CRL issuer and where that CRL issuer 
is only issuing certificate revocation status for that single CA has been described 
in my previous e-mail.

If we can first discuss and agree on these two cases, then, and only then, 
we may discuss the zillion number of cases, probably for eternity.

:-)

Denis 

>-----Original Message-----
>From: Denis Pinkas [mailto:[email-masked]] 
>Sent: Wednesday, June 15, 2005 4:09 AM
>To: Santosh Chokhani; [email-masked]
>Subject: Re: 3280bis: CRL validation
>
>
>Santosh,
>
>The good news is that we have the same concern. We care about name
>collisions 
>and want to describe a solution to this problem so that secure
>implementations 
>can be built.
>
>>Denis,
>
>>It is not clear from this e-mail thread what the solution is, what the 
>>certificate issuer as the existing extension is (unless you mean the 
>>CRL entry extension, which is not required or recommended and is 
>>useless in the direct CRL).  It is also not clear what problem this 
>>solution is addressing.
>>
>>The problem I am addressing is as follows.  Let us say that there are 
>>following PKIs:
>>
>>Root 1 --> CA A --> Orion
>>Root 2 --> CA B --> CA I --> Orion
>>Root 2 --> CA C --> CA J --> Orion
>>
>>Assuming that the three Orions are distinct, I am addressing the 
>>problem that the wrong CRL does not get fetched and used.
>
>Fine. We are also in the case where :
>
>  -  the CRL Issuer is NOT the CA.
>  -  the CRL applies to one CA only (the revocation information is for a
>single CA)
>
>This means that the CRL issuer is nominated by the CA that has issued 
>the target certificate.
>
>>If you can describe how you solve this problem, what extensions 
>>certificates and CRLs have in them and what the relying parties do with 
>>them, I will be happy to determine if the solution deals with the 
>>problem and if it is less complex than what I proposed.
>
>In order to verify a leaf certificate, a certification path MUST first be
>built 
>up to one root key. Once it is built (and all digital signatures are
>verified), then 
>it must be verified that no certificate from that certification path is
>revoked.
>
>The leaf certificate MUST include a CRL DP extension.
>That CRL DP extension MUST include a cRLIssuer field.
>The name contained in the cRLIssuer field MUST be identical to the subject
>name 
>contained in a CRL Issuer certificate that has been issued by the *same* CA 
>that has issued the target certificate.
>
>Since every certificate from a certification chain may be considered as 
>a target certificate, the controls described for the leaf certificate also
>apply.
>
>That's all. 
>
>The case where the CRL contains information for more than one CA 
>is much more complex and we are then in the "zillion" number of cases.
>
>Denis
>
>>-----Original Message-----
>>From: [email-masked] 
>>[mailto:[email-masked]] On Behalf Of Denis Pinkas
>>Sent: Monday, June 13, 2005 5:14 AM
>>To: [email-masked]; Santosh Chokhani
>>Subject: Re: 3280bis: CRL validation
>>
>>
>>
>>Santosh,
>>
>>Since it took you less thah 15 minutes to reply, it means that you did 
>>not pay enough attention to the content of my short message.  :-)
>>
>>>Denis,
>>
>>>We may be solving different problems.
>>
>>Certainly. You try to solve a more complex problem that belongs to the 
>>case
>>b) category. Once case a) is solved, then we can talk of the "zillions"
>>cases b).
>>
>>> I am solving the problem of names not being unique.
>>
>>You would have to be more specific so that I can really make sure what 
>>you mean here.
>>
>>> There is no need or benefit to adding a new extension.
>>
>>As far as I am concerned, I am using currently defined extensions.
>>
>>>May be you are proposing to list the names of the CA's in the path in
>>>this extension.
>>
>>This was my proposal to solve the "zillions cases", but not to solve 
>>case a).
>>
>>> If so, the solution does not fit today's extensions and lacks agility
>>>of the algorithm I proposed and has the same or greater complexity.
>>
>>For case a), one single name is necessary. That name cannot be 
>>ambiguous
>>since it can only be given by the CA that has issued the target
>certificate.
>>
>>
>>My point is the following:
>>
>>"For case a), the name(s) contained in certificateIssuer MUST be 
>>certified
>>by the CA that has issued the certificate where the extension appears".
>>
>>Denis
>>
>>>It will not reduce the complexity since the same matching will be
>>>requiring.
>>>
>>>You saying that you do not understand my posting is akin to turning a
>>>deaf ear to a discussion.
>>>
>>>-----Original Message-----
>>>From: [email-masked]
>>>[mailto:[email-masked]] On Behalf Of Denis Pinkas
>>>Sent: Friday, June 10, 2005 12:55 PM
>>>To: [email-masked]; Santosh Chokhani
>>>Subject: Re: RE: 3280bis: CRL validation
>>>
>>>
>>>
>>> >Denis,
>>>
>>>>What is your solution?
>>>
>>>There are two cases to consider for CRL issuers.
>>>
>>>  a) the CRL Issuer issues revocation information for a single CA;
>>>  b) the CRL Issuer issues revocation information for more than one 
>>> CA.
>>>
>>>Case a) is simple, while case b) is more much complex (this is the
>>>"zillions of cases").
>>>
>>>We may have a simple and secure rule for case a).
>>>The certificateIssuer extension from a certificate is defined as :
>>>
>>>     certificateIssuer ::= GeneralNames
>>>
>>>with
>>>
>>>     certificateIssuer ::= GeneralNames
>>>
>>>with
>>>
>>>     GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
>>>
>>>In that case the name(s) contained in certificateIssuer MUST be
>>>certified by the CA that has issued the certificate where the extension 
>>>appears.
>>>
>>>This means that the CRL Issuer can only be nominated by the CA that 
>>>has
>>>issued the certificate.
>>>
>>>Denis
>>
>>
>>
>
>Regards,
>
>Denis Pinkas
>
>
>

Regards,

Denis Pinkas

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 15 Jun 2005 14:04:31 -0400

Denis,

The solution I have provided is comprehensive and covers both the direct and
indirect CRL situations.

As my e-mail to Stefan said, if we constrain the standards in the area of
indirect issuer, we can add additional constraints to the algorithm.

I do not see a comprehensive solution in what you suggest let alone
something that is simpler than the algorithm I propose.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Denis Pinkas
Sent: Wednesday, June 15, 2005 11:47 AM
To: [email-masked]; Santosh Chokhani
Subject: Re: 3280bis: CRL validation

Santosh,

>The situation I am discussing is when the CRL Issuer is also the 
>certificate issuer.

>As to the indirect CRL, there are no constraints in the standard that 
>the indirect issuer needs to be issued a certificate by the CA and the 
>indirect CRL issuer cover only one CA.

The concept of "indirect CRL" is currently too broad (and too vague) since
it covers 
two very distinct cases (cases a and b). Thse two cases should be given a
name 
so that we may easily distinguish between them

:-)

The case where the CA designates a CRL issuer and where that CRL issuer 
is only issuing certificate revocation status for that single CA has been
described 
in my previous e-mail.

:-)

Denis 

>collisions and want to describe a solution to this problem so that 
>secure implementations
>can be built.
>
>>Denis,
>
>  -  the CRL applies to one CA only (the revocation information is for 
>a single CA)
>
>In order to verify a leaf certificate, a certification path MUST first 
>be built up to one root key. Once it is built (and all digital 
>signatures are verified), then
>The name contained in the cRLIssuer field MUST be identical to the 
>subject name contained in a CRL Issuer certificate that has been issued 
>by the *same* CA that has issued the target certificate.
>
>>> If so, the solution does not fit today's extensions and lacks 
>>>agility of the algorithm I proposed and has the same or greater 
>>>complexity.
>>
>>>certified by the CA that has issued the certificate where the 
>>>extension appears.
>>>

Regards,

Denis Pinkas

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 15 Jun 2005 16:24:14 -0400

Denis,

When you say that the concept of indirect CRL covers two very distinct 
cases, are you referring to these two cases?

>  b) the CRL Issuer issues revocation information for more than one CA.
>
>Case a) is simple, while case b) is more much complex (this is the "zillions of cases").
>

The concept of indirect CRLs is very simple: If the scope of the CRL 
includes certificates that have an issuer name (i.e., the contents of 
the issuer field in the certificate) that is different that the issuer 
name of the CRL (i.e., the contents of the issuer field in the CRL), 
then it is an indirect CRL. If the scope of the CRL only includes 
certificates that have the same issuer name as the CRL, then it is not 
an indirect CRL. In what way is the concept of indirect CRLs vague?

The scope of an indirect CRL may include certificates issued by one or 
more CAs, but the mechanisms work the same way no matter how many 
different CA's certificates are included in the scope of the CRL.

If you have a certificate and a CRL with different issuers (i.e., 
different DNs in the issuer fields), the following must be verified to 
determine if the scope of the CRL includes the certificate:

(1) The certificate must include a cRLDistributionPoints extension with 
a distribution point that has the cRLIssuer field present and include 
the DN from the issuer field of the certificate.

(2) The CRL must include an issuingDistributionPoint field with 
indirectCRL set to TRUE.

(3) If the issuingDistributionPoint field in the CRL includes a 
distributionPoint name, the cRLDistributionPoints extension in the 
certificate must include a matching distributionPoint name (as specified 
in section 6.3.3, step (b)(2)(i)).

(4) The onlyContainsUserCerts, onlyContainsCACerts, and 
onlyContainsAttributeCerts flags in the issuingDistributionPoint 
extension in the CRL must all be false or the flag that is set to true 
must be appropriate for the type of certificate.

If the certificate is covered by the CRL, then one can scan the revoked 
certificates list to see if the certificate is revoked for one of the 
reasons covered by the CRL using the certificateIssuer CRL entry 
extension to determine the issuer name associated with each serial 
number listed (if the entry includes a certificateIssuer CRL entry 
extension, the use that issuer name; if the entry does not include a 
certificateIssuer CRL entry extension, use the issuer name from the most 
recent preceding entry to include this extension; if the entry does not 
include a certificateIssuer CRL entry extension and no preceding entry 
included this extension, then the issuer name is the value from the 
issuer field in the CRL).

You keep insisting that there are "zillions of cases" that need to be 
addressed. How does the fact that an indirect CRL happens to cover 
certificates issued by more than one CA complicate matters. Note that 
there is no need to consider the possibility that an indirect CRL will 
cover certificates issued by two different CAs that issue certificates 
under the same name:

X.509, Clause 7 (Public-keys and public-key certificates): NOTE 1 – Although
the CAs are unambiguously defined by a distinguished name in the DIT,
this does not imply that there is any relationship between the organization
of the CAs and the DIT.

X.509, Clause 8.3.2.1 (Subject alternative name extension): For every name
form used in the GeneralName type, there shall be a name registration system
that ensures that any name used unambiguously identifies one entity to both
certificate issuer and certificate users.

Dave

Denis Pinkas wrote:

>> certificate