Subject: Re: RE: Re: Correction to be done to <draft-pinkas-pkix-conf-crl-validation-01.txt>

From: "Denis Pinkas" <[email-masked]>
Date: Fri, 22 Jul 2005 16:43:40 +0100

Stefan,

>Denis,

>Quote:
>"Thus, in the simplest case, where a CA designates another entity to
>issue revocation status information for some of its certificates, the
>certificate issuer CRL entry extension is not needed, neither the
>indirectCRL boolean."

>I can't believe you are serious about this!
>You are just trying to drive us mad, right?

>How much more "indirect" can it be?

Everything is a matter of wording. I would not call it "indirect". 
See my explanations to Sharon.

If a name was needed for it, I would call it "delegated CRL" 

Page 7:

CRL issuer: an optional system to which a CA delegates the
                 publication of certificate revocation lists.

"Problems" with CRLs arise only when CRLs contain revocation 
status information about certificates from several CAs.

The point is not simply a vocabulary problem, but that that it is 
possible *for a RP* to support CRLs issued by CRL Issuers that 
are not CAs, without the need to support the indirectCRL boolean 
and the certificate issuer CRL entry extension and this makes the 
algorithm simpler, easier to implement, faster, etc ...

Denis 

>/Stefan
> 
>
>> -----Original Message-----
>> From: [email-masked]
>[mailto:[email-masked]]
>> On Behalf Of Denis Pinkas
>> Sent: den 21 juli 2005 07:34
>> To: David A. Cooper; Santosh Chokhani
>> Cc: 'pkix'
>> Subject: Re: Re: Correction to be done to <draft-pinkas-pkix-conf-crl-
>> validation-01.txt>
>> 
>> 
>> David,
>> 
>> >Santosh Chokhani wrote:
>> >
>> >>Denis,
>> >>
>> >>A sentence in 3280 may be ambiguous. The definition and State
>Machines
>> are
>> >>not at odds. Also, if you point to the specific location of the
>sentence
>> in
>> >>3280, I will be happy to determine if this is being taken out of
>context
>> or
>> >>not.
>> 
>> >Santosh,
>> 
>> >Denis is referring to the final sentence in the following paragraph:
>> 
>> >      CRL issuers issue CRLs.  The CRL issuer is either the CA or an
>> entity
>> >      that has been authorized by the CA to issue CRLS.  CAs publish
>CRLs
>> >      to provide status information about the certificates they
>issued.
>> >      However, a CA may delegate this responsibility to another
>trusted
>> >      authority.  Whenever the CRL issuer is not the CA that issued
>the
>> >      certificates, the CRL is referred to as an indirect CRL.
>> 
>> >I believe the problem is that Denis is interpreting this sentence as
>a
>> >definition when it is not one.  Here is the definition of indirect
>CRL
>> >in X.509:
>> 
>> You mean that RFC 3280 contains no formal definition of what an
>> Indirect CRL is.
>> 
>> A good practice for RFCs would be to follow ISO editing rules where
>> there MUST be a separate section for formal definitions.  :-)
>> 
>> However the extracted sentence is the earliest use of the wording
>> "indirect CRL"
>> in the document saying what an indirect CRL is. It is not explained
>later
>> on.
>> 
>> The definition from X.509 you mention is thus not an RFC 3280
>definition.
>> 
>> >      indirect CRL (iCRL):  A revocation list that at least contains
>> >revocation information
>> >      about certificates issued by authorities other than that which
>> >issued this CRL.
>> 
>> The X.509 definition is NOT :
>> 
>> indirect CRL (iCRL):  A revocation list that at least contains
>revocation
>> information
>> about certificates issued by *an authority* other than that which
>issued
>> this CRL.
>> 
>> The X.509 definition is NOT either:
>> 
>> indirect CRL (iCRL):  A revocation list that at least contains
>revocation
>> information
>> about certificates issued by *one or more* authorities other than that
>> which issued
>> this CRL.
>> 
>> >In order to help avoid this confusion in 3280bis, I have removed the
>> >sentence "Whenever ...." from 3280bis draft -01 and have added the
>> >following paragraph:
>> >
>> >      If the scope of the CRL includes one or more certificates
>issued by
>> >      an entity other than the CRL issuer, then it is an indirect
>CRL.
>> 
>> Arhh!  Once again: "certificates issued by .. CRL issuer".
>> 
>> >      The
>> >      scope of an indirect CRL may be limited to certificates issued
>by a
>> >      single CA or may include certificates issued by multiple CAs.
>> 
>> This would have been true if the X.509 definition had been written
>> differently.
>> 
>> >      If the
>> >      issuer of the indirect CRL is a CA, then the scope of the
>indirect
>> >      CRL MAY include certificates issued by the issuer of the CRL.
>> 
>> This is ruled out by the current quoted sentence.
>> 
>> >I believe that this text is fully consistent with the X.509
>definition
>> >of indirect CRL
>> 
>> Sorry, it is not.
>> 
>> > as well as the descriptions of the indirectCRL flag and
>> >the certificateIssuer CRL entry extension in both X.509 and RFC 3280
>and
>> >the algorithm in section 6.3.3 of RFC 3280.
>> 
>> Page 59 is stating:
>> 
>>    "The CRL issuer MUST assert the indirectCRL boolean, if the scope
>of
>>    the CRL includes certificates issued by authorities other than the
>>    CRL issuer.  The authority responsible for each entry is indicated
>by
>>    the certificate issuer CRL entry extension (section 5.3.4)".
>> 
>> It is clear that this flag is present when there are certificate
>issuer
>> CRL entry extensions.
>> 
>> Thus, in the simplest case, where a CA designates another entity to
>issue
>> revocation
>> status information for some of its certificates, the certificate
>issuer
>> CRL entry extension
>> is not needed, neither the indirectCRL boolean.
>> 
>> The way to fix the problem is simple: either adopt (but add "may") the
>> definition of X.509
>> or make it clearer by saying:
>> 
>> indirect CRL (iCRL):  A revocation list that at least *may* contain
>> revocation information
>> about certificates issued by more than one CA.
>> 
>> and add for clarification:
>> 
>> delegatedCRL (dCRL):  A revocation list issued by a CRL Issuer that
>> received and accepted
>> a delegation for issuing revocation status information from a single
>CA,
>> that contains
>> revocation information about certificates issued by that single CA.
>> 
>> See processing details for these two cases in
><draft-pinkas-pkix-conf-crl-
>> validation-02.txt>
>> that is now available.
>> 
>> The benefits are:
>> 
>>  1) a very simple CRL processing when the CRL contains revocation
>> information
>>     about certificates from a single CA.
>> 
>>  2) a (much) more complex CRL processing when the CRL contains
>revocation
>>     information about certificates from more than one CA, including
>the
>> (seldom ?)
>>     case where the CRL issuer is also a CA.
>> 
>> Denis
>> 
>> >Dave

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 22 Jul 2005 16:07:14 +0100

Denis,

> algorithm simpler, easier to implement, faster, etc ...

I think this'd be a bad idea. Aside from anything else, it
assumes that some relationships between certificate and
CRL issuers won't change over time. Those do change and if
this were adopted the RP's wouldn't have a way to easily
see that.

Stephen.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 22 Jul 2005 18:08:58 -0400

All of the CRL and Indirect CRL related changes Dennis has proposed are not
required, change the standard, make the standard less secure, and/or do not
solve the issue of name collisions.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stephen Farrell
Sent: Friday, July 22, 2005 11:07 AM
To: Denis Pinkas
Cc: Santosh Chokhani; David A. Cooper; Stefan Santesson; pkix
Subject: Re: Correction to be done to
<draft-pinkas-pkix-conf-crl-validation-01.txt>

Denis,

> algorithm simpler, easier to implement, faster, etc ...

I think this'd be a bad idea. Aside from anything else, it assumes that some
relationships between certificate and CRL issuers won't change over time.
Those do change and if this were adopted the RP's wouldn't have a way to
easily see that.

Stephen.