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

From: "Denis Pinkas" <[email-masked]>
Date: Mon, 18 Jul 2005 17:57:28 +0100

>Denis,

>The specific sentence in 3280 may need to be revised or may have been taken
>out of context.

Thank you for finally acknowledging the fact that the current definition of 
an "indirect CRL" is incompatible with your "State Machine".

There are several ways to correct the problem. Among them :

1) keep the State Machine and change the definition of an indirect CRL.
2) take draft-pinkas-pkix-conf-crl-validation-02.txt (it is not yet published) 
    and change the definition of an indirect CRL.

Now you see the common point: in both cases the proposal is to change 
the definition of an indirect CRL, but the reason for changing it are quite different.

You want to change it so that your State Machine keeps working, whereas 
I want to change it to make the case where a CA designates its own CRL issuer
easy and simple to implement. That case may be handled without the 
need to support both the IDP extension and the certificate issuer CRL entry 
extension.

This may definitively encourage implementers to implement the case where 
the CA designates its own CRL issuer.

The case where a CRL issuer serves more than one CA is less likely to happen.
                                     
In addition, note that when an indirect CRL may contain serial numbers from 
certificates issued by more than one CA, then it is possible to go backwards. 
It is of course also possible to go onwards as you mentioned, but this is NOT 
mandatory.

Denis 

>A CRL issuer asserts indirect CRL flag when the CRL is supposed to cover
>certificates not issued by the CRL issuer.  Note that there may not be any
>entries for other CAs since none of their certificates may be revoked.
>
>But, the CRL issuer can cover the certificates issued by the CRL issuer (if
>it is a CA) in that indirect CRL.
>
>The State Machine is correct.
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On
>Behalf Of Denis Pinkas
>Sent: Monday, July 18, 2005 6:05 AM
>To: 'pkix'; Santosh Chokhani
>Subject: Re: Correction to be done to
><draft-pinkas-pkix-conf-crl-validation-01.txt>
>
>
>
>Santosh,
>
>>My apologies to the list for typo.
>>
>>In the last paragraph, "CRL issuer" was meant to say "certificate 
>>issuer". It is corrected below.
>>
>>-----Original Message-----
>>From: Santosh Chokhani [mailto:[email-masked]]
>>Sent: Friday, July 15, 2005 1:09 PM
>>To: 'pkix'
>>Subject: RE: Correction to be done to
>><draft-pinkas-pkix-conf-crl-validation-01.txt>
>
>
>>Denis,
>
>>The indirect CRL state machine is as follows:
>
>>	initial value of certificate_issuer_state = issuer field in the CRL
>>(1)
>
>The current sentence of RFC 3280 is : "Whenever the CRL issuer is not the CA
>
>that issued the certificates, the CRL is referred to as an indirect CRL".
>
>This means that when a CRL is an indirect CRL, then none of the certificates
>
>that are present in the CRL can be issued under the name that is present 
>in the issuer name of the CRL.
>
>So unless the definition of an indirect CRL is modified, the certificate
>issuer name
>cannot default to the issuer name of the CRL.
>
>So the "state machine" you propose is not correct.
>
>Stefan said:
>
>"Finally I do not worry too much about deployed products concerning
>indirect CRLs since this is an almost non used feature as far as I know."
>
>It is time to fix the issue so that cases where the various cases where CA 
>is not the issuer of the CRL can be undertsood and implemented.
>
>Some are simpler than others.
>
>Your message triggered another look to my I-D on that topic and I noticed 
>that a case was forgotten in <draft-pinkas-pkix-conf-crl-validation-02.txt>
>:
>a CRL could contain the same serial number, but from different CAs.
>
>This is now handled in <draft-pinkas-pkix-conf-crl-validation-02.txt> 
>that has been posted before the dead line for submissions, but is 
>not yet available.
>
>
>Denis
>	
>>	certificate_issuer  = value in the CRL entry extension and if the
>>extension is absent, certificate_issuer = certificate_issuer_state (2)
>>
>>	certificate_issuer_state = certificate_issuer
>>
>>It is secure, standard compliant and provides for interoperability.  It is
>>probably too complex in comparison to doing nothing and yet to be defined
>>Denis's algorithms on a variety of CRL processing matters.
>>
>>If the indirect CRL issuer is not a CA, the first revoked certificate entry
>>will contain a certificate issuer field.  There are numerous other
>>situations when first revoked certificate entry will contain a certificate
>>issuer field, but this is of no interest to a relying party that wants to
>>write a secure, interoperable, simple (i.e., not complex) CRL processing
>>logic.
>>
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]] On
>>Behalf Of Denis Pinkas
>>Sent: Friday, July 15, 2005 4:24 AM
>>To: pkix
>>Subject: Correction to be done to
>><draft-pinkas-pkix-conf-crl-validation-01.txt>
>>
>>
>>
>>
>>A correction needs to be done to 
>><draft-pinkas-pkix-conf-crl-validation-01.txt>.
>>
>>As explained in a previous e-mail, the certificate issuer name cannot
>>default to the name of the CRL issuer, hence the following text 
>>extracted from section 6.3.3.3 is incorrect :
>>
>>        (ii) check if there exists a previous CRL entry
>>             and if that CRL entry contains a Certificate
>>             Issuer CRL entry extension and go back to (1).
>>
>>                If there is no previous CRL entry, then
>>                check if the name of the issuer of the CRL
>>                matches the name of the issuer field of the
>>                target certificate.
>>
>>                 - If it does, then set the cert_revoc_status
>>                   variable to REVOKED and if the CRL entry
>>                   extension " reasonCode " is present in
>>                   that CRL entry, then set the revoc_reason
>>                   variable to the value contained in that CRL
>>                   entry extension and the algorithm
>>                   terminates.
>>
>>                 - If it does, then set the cert_revoc_status
>>                   variable to NOT_REVOKED and the algorithm
>>                   terminates.
>>
>>It would need to be corrected (and greatly simplified)
>>in the following way:
>>
>>          (ii) If there is no previous CRL entry, then
>>               this is an error in the structure of the CRL
>>               and the algorithm terminates.
>>
>>               Otherwise, check if that CRL entry contains
>>               a Certificate Issuer CRL entry extension and
>>               go back to (1).
>>
>>Denis
>>
>>
>>
>>

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 18 Jul 2005 12:03:12 -0400

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.

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Monday, July 18, 2005 12:57 PM
To: 'pkix'; Santosh Chokhani
Subject: Re: Correction to be done to

>The specific sentence in 3280 may need to be revised or may have been 
>taken out of context.

1) keep the State Machine and change the definition of an indirect CRL.
2) take draft-pinkas-pkix-conf-crl-validation-02.txt (it is not yet
published) 
    and change the definition of an indirect CRL.

Now you see the common point: in both cases the proposal is to change 
the definition of an indirect CRL, but the reason for changing it are quite
different.

You want to change it so that your State Machine keeps working, whereas 
I want to change it to make the case where a CA designates its own CRL
issuer easy and simple to implement. That case may be handled without the 
need to support both the IDP extension and the certificate issuer CRL entry 
extension.

The case where a CRL issuer serves more than one CA is less likely to
happen.
                                     
In addition, note that when an indirect CRL may contain serial numbers from 
certificates issued by more than one CA, then it is possible to go
backwards. 
It is of course also possible to go onwards as you mentioned, but this is
NOT 
mandatory.

Denis 

>A CRL issuer asserts indirect CRL flag when the CRL is supposed to 
>cover certificates not issued by the CRL issuer.  Note that there may 
>not be any entries for other CAs since none of their certificates may 
>be revoked.
>
>But, the CRL issuer can cover the certificates issued by the CRL issuer 
>(if it is a CA) in that indirect CRL.
>
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Denis Pinkas
>So unless the definition of an indirect CRL is modified, the 
>certificate issuer name cannot default to the issuer name of the CRL.
>
>>It is secure, standard compliant and provides for interoperability.  
>>It is probably too complex in comparison to doing nothing and yet to 
>>be defined Denis's algorithms on a variety of CRL processing matters.
>>
>>If the indirect CRL issuer is not a CA, the first revoked certificate 
>>entry will contain a certificate issuer field.  There are numerous 
>>other situations when first revoked certificate entry will contain a 
>>certificate issuer field, but this is of no interest to a relying 
>>party that wants to write a secure, interoperable, simple (i.e., not 
>>complex) CRL processing logic.
>>
>>From: [email-masked] 
>>[mailto:[email-masked]] On Behalf Of Denis Pinkas

---

From: "David A. Cooper" <[email-masked]>
Date: Mon, 18 Jul 2005 18:40:19 -0400

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:

      indirect CRL (iCRL):  A revocation list that at least contains 
revocation information
      about certificates issued by 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.  The
      scope of an indirect CRL may be limited to certificates issued by a
      single CA or may include certificates issued by multiple CAs.  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.

I believe that this text is fully consistent with the X.509 definition 
of indirect CRL 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.

Dave

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 19 Jul 2005 07:21:10 -0400

David Cooper,

Thanks.  The new definition is clearer and the State Machine is accurate.

I would replace the last "MAY" with "MAY also".  Thus, the text would
become:

      CRL MAY also include certificates issued by the issuer of the CRL.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of David A. Cooper
Sent: Monday, July 18, 2005 6:40 PM
To: Santosh Chokhani
Cc: 'pkix'
Subject: Re: Correction to be done to
<draft-pinkas-pkix-conf-crl-validation-01.txt>

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,

Dave