Re: 3280bis: CRL validation

["Denis Pinkas" <denis.pinkas@xxxxxxxx>]

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:denis.pinkas@xxxxxxxx] 
>Sent: Wednesday, June 15, 2005 4:09 AM
>To: Santosh Chokhani; ietf-pkix@xxxxxxxx
>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: owner-ietf-pkix@xxxxxxxxxxxx 
>>[mailto:owner-ietf-pkix@xxxxxxxxxxxx] On Behalf Of Denis Pinkas
>>Sent: Monday, June 13, 2005 5:14 AM
>>To: ietf-pkix@xxxxxxxx; 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: owner-ietf-pkix@xxxxxxxxxxxx
>>>[mailto:owner-ietf-pkix@xxxxxxxxxxxx] On Behalf Of Denis Pinkas
>>>Sent: Friday, June 10, 2005 12:55 PM
>>>To: ietf-pkix@xxxxxxxx; 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