RE: 3280bis: CRL validation

["Santosh Chokhani" <chokhani@xxxxxxxxxxxx>]

Denis,

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.

My proposal solves the ambiguity for both direct CRL (i.e., certificate
issuer DN == CRL issuer DN) and indirect CRL.  For indirect CRL (as I
responded to Stefan) requires additional trust assumptions that neither
X.509 nor 3280 have.

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