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 11:05:08 +0100

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

Regards,

Denis Pinkas

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 18 Jul 2005 09:37:32 -0400

Denis,

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

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,

>In the last paragraph, "CRL issuer" was meant to say "certificate 
>issuer". It is corrected below.
>

>	initial value of certificate_issuer_state = issuer field in the CRL

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

So unless the definition of an indirect CRL is modified, the certificate
issuer name
cannot default to the issuer name of the CRL.

Stefan said:

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.

Denis

Regards,

Denis Pinkas