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:37:31 +0100

>Denis, I'm sorry but I really am not following your thought processes at
>all. 

Sharon,

First, I appreciate the time you spent digging into the past. 

Please forget about the vocabulary for a while, otherwise 
you will not follow my "thought process" that I will try to explain..

If you take the case of a simple scheme where a CRL Issuer accepts 
to issue revocation status information from only one CA, then from 
a RP point of view the certificate issuer CRL entry extension is not 
needed. By implication the indirect CRL boolean that signals the 
presence of that extension is not needed either. 

Now, we can come back to the vocabulary issue:  since the indirectCRL 
boolean is not needed, I would not call that kind of CRL an indirect CRL.

Using the rules that I have described in <draft-pinkas-pkix-conf-crl-validation-02.txt>, 
in sections 6.3.3.1 and 6.3.3.2, I believe it is possible to securely support that 
simple scheme, ... unless I made an error in them, but until now nobody as yet 
demonstrated a case where these rules, *from a RP point of view*, would be insufficient.

So why make things complicated, when they can be simple ?

>X.509 does include a definition for indirect CRLs. RFC 3280 is a profile of
>X.509 not a replacement for it. Therefore there is no need to redefine terms
>in 3280 that are defined in 509. There is no harm in clarifying terms in
>3280 if the group so chooses but a profile should not alter the intent of a
>definition. 
>
>I take your point that the 509 definition says "authorities" instead of
>"authority or authorities". I have taken the time (a lot of it!!!) to dig
>through my files to track the history of that definition as I was the editor
>of X.509 at the time it was added. (Sometimes I am happy that I'm such a
>packrat).
>
>The definition that has been quoted by David from X.509 was added as an
>outcome of the April 1999 meeting in Orlando Florida. It was part of the
>resolution of Canadian comment number 24 submitted to that meeting against
>the X.509 PDAM. The relevant part of the disposition of that comment was
>recorded as "Accepted with a few minor modifications to the proposed text.
>Also a definition for indirect CRL will be added." I was the author of the
>Canadian comment submitted to that meeting and I was also the editor that
>created the definition that is now in X.509 as a result of that comment
>disposition. Let me assure you that with both hats on it WAS my intention
>that any CRL that included revocation notices for certificates that were
>issued by any authority other than that which issued the CRL is an indirect
>CRL. 

On my side, my understanding was as I explained. Only when the CRL covers 
certificates from more than one CA, are both the certificate issuer CRL entry extension 
needed and the indirectCRL boolean needed. In RFC 3280 the requirements for 
these two fields are in two consecutive sentences within the same short paragraph 
so why I believe(d) they come together.

I hope that this allows at least you to understand my thought process, even if 
you have a different opinion.

Denis

> I will be happy to submit a defect report to X.509 to change
>"authorities" to "authority or authorities". As the editor and the submitter
>of the ballot comment that drove the discussion to add the definition in the
>first place I will happily admit I made an error in using the term
>"authorities" in that definition. 
>
>Cheers,
>Sharon
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On
>Behalf Of Denis Pinkas
>Sent: Thursday, July 21, 2005 10:34 AM
>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: "Santosh Chokhani" <[email-masked]>
Date: Fri, 22 Jul 2005 17:58:06 -0400

Denis,

X.509 and 3280 are clear and do not need all these cases your e-mail
contains.  An indirect CRL bit must be asserted if a CRL is supposed to
cover certificates issued by one or more CAs other than the CRL Issuer.

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Friday, July 22, 2005 11:38 AM
To: Sharon Boeyen; David A. Cooper; Santosh Chokhani
Cc: 'pkix'
Subject: Re: RE: Re: Correction to be done to

>Denis, I'm sorry but I really am not following your thought processes 
>at all.

Sharon,

Using the rules that I have described in
<draft-pinkas-pkix-conf-crl-validation-02.txt>, 
in sections 6.3.3.1 and 6.3.3.2, I believe it is possible to securely
support that 
simple scheme, ... unless I made an error in them, but until now nobody as
yet 
demonstrated a case where these rules, *from a RP point of view*, would be
insufficient.

>X.509 does include a definition for indirect CRLs. RFC 3280 is a 
>profile of X.509 not a replacement for it. Therefore there is no need 
>to redefine terms in 3280 that are defined in 509. There is no harm in 
>clarifying terms in 3280 if the group so chooses but a profile should 
>not alter the intent of a definition.
>
>"authority or authorities". I have taken the time (a lot of it!!!) to 
>dig through my files to track the history of that definition as I was 
>the editor of X.509 at the time it was added. (Sometimes I am happy 
>that I'm such a packrat).
>
>outcome of the April 1999 meeting in Orlando Florida. It was part of 
>the resolution of Canadian comment number 24 submitted to that meeting 
>against the X.509 PDAM. The relevant part of the disposition of that 
>comment was recorded as "Accepted with a few minor modifications to the 
>proposed text. Also a definition for indirect CRL will be added." I was 
>the author of the Canadian comment submitted to that meeting and I was 
>also the editor that created the definition that is now in X.509 as a 
>result of that comment disposition. Let me assure you that with both 
>hats on it WAS my intention that any CRL that included revocation 
>notices for certificates that were issued by any authority other than 
>that which issued the CRL is an indirect CRL.

On my side, my understanding was as I explained. Only when the CRL covers 
certificates from more than one CA, are both the certificate issuer CRL
entry extension 
needed and the indirectCRL boolean needed. In RFC 3280 the requirements for 
these two fields are in two consecutive sentences within the same short
paragraph 
so why I believe(d) they come together.

I hope that this allows at least you to understand my thought process, even
if 
you have a different opinion.

Denis

>"authorities" to "authority or authorities". As the editor and the 
>submitter of the ballot comment that drove the discussion to add the 
>definition in the first place I will happily admit I made an error in 
>using the term "authorities" in that definition.
>
>Cheers,
>Sharon
>
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Denis Pinkas
>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.
>
>revocation information about certificates issued by *an authority* 
>other than that which issued this CRL.
>
>revocation information about certificates issued by *one or more* 
>authorities other than that which issued
>this CRL.
>  
>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
>definition of X.509 or make it clearer by saying:
>
>revocation information about certificates issued by more than one CA.
>
>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