Subject: Re: 3280bis: CRL validation

From: "Denis Pinkas" <[email-masked]>
Date: Thu, 16 Jun 2005 15:06:46 +0100

Santosh,

You (still) attempt to escape the question.

The case of "full" indirect CRLs can be very complex.
Depending of the trust assumptions that are made, there may be "zillions" of solutions.

Please leave the full story for later and address only, for the time being,
what is necessary to solve the "simple" case :

The CRL is signed by a CRL issuer that is NOT the CA, but the CRL 
contains revocation status information for a single CA.

Denis

>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:[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: Thu, 16 Jun 2005 11:11:25 -0400

Denis,

See responses in line in [Santosh:]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Denis Pinkas
Sent: Thursday, June 16, 2005 10:07 AM
To: [email-masked]; Santosh Chokhani
Subject: Re: 3280bis: CRL validation

Santosh,

[Santosh: I am neither trying to evade your question nor deal with what you
say.  I simply fail to see what you are saying and its relevance to my
point.  I have been saying since 09/2003 that we have a problem with
"certificate certification path" and "CRL certification path".  I have
provided a solution that is simple and robust.  I have said that the
solution can be made as robust for indirect CRL as it is for direct CRL if
we make some trust assumptions as to who can be the indirect CRL issuer.
You say that my solution is "over-complex".  I provided my refutation for
that.  Instead of responding to that refutation, your response takes on
directions that are not relevant to my point of CRL path problem. I have
provided logical proof of the solution and its simplicity.  If you want to
discuss the security weakness of the solution or how to make it simpler or
provide a complete alternative that is simpler, I will be glad to review it.
Absent that I do not feel qualified to debate on an issue that I do not
understand or see.]

The case of "full" indirect CRLs can be very complex.
Depending of the trust assumptions that are made, there may be "zillions" of
solutions.

[Santosh: The solution I have proposed covers all the cases.  Please note
that my solution is additive in the sense that all the certificate,
certification path processing, and CRL processing requirements of 3280 still
apply.]

Denis

>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.
>
>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: Stephen Farrell <[email-masked]>
Date: Thu, 16 Jun 2005 16:58:14 +0100

Denis, Santosh,

I've love to chime in here with comments on
draft-pinkas-zillions-00.txt and/or
draft-chokhani-solution-00.txt but I
can't seem to find those documents ;-)

Any chance you can write up your approaches
in the IETF preferred way? Given that the
discussion has been going on so long already,
I'd say the overhead of using xml2rfc, or
whatever tool you prefer, is now acceptable
and might allow for a much better discussion
in Paris and on the list.

Note that I'm not suggesting that such documents
necessarily need to become RFCs or PKIX work
items, e.g. if one solution gained WG concensus
the relevant text could be included in 3280bis.

Stephen.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 16 Jun 2005 13:38:09 -0400

Stephen,

I would draft an I-D if the WG would support such an effort and agree that
this remains to be done.

In the interim, I prepared a detailed briefing for November PKIX meeting and
since have written a paper.

It would be inappropriate to post these to the list.  But, I would be happy
to send these to you if you want.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stephen Farrell
Sent: Thursday, June 16, 2005 11:58 AM
To: Santosh Chokhani; Denis Pinkas
Cc: [email-masked]
Subject: Re: 3280bis: CRL validation

Denis, Santosh,

I've love to chime in here with comments on draft-pinkas-zillions-00.txt
and/or draft-chokhani-solution-00.txt but I can't seem to find those
documents ;-)

Stephen.