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

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 15 Jul 2005 13:13:01 -0400

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)
	
	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: "Denis Pinkas" <[email-masked]>
Date: Thu, 21 Jul 2005 15:34:10 +0100

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: "Stefan Santesson" <[email-masked]>
Date: Thu, 21 Jul 2005 22:24:00 +0100

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?

/Stefan

> 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
> 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
> indirect CRL (iCRL):  A revocation list that at least contains
revocation
> information
> 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
> a delegation for issuing revocation status information from a single
CA,
> that contains
> See processing details for these two cases in
<draft-pinkas-pkix-conf-crl-
> validation-02.txt>
>     information about certificates from more than one CA, including
the
> (seldom ?)

---

From: "Stefan Santesson" <[email-masked]>
Date: Thu, 21 Jul 2005 22:59:56 +0100

Sharon,

I agree.

There is an interesting twist to this if we were to follow Denis
interpretation of 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.

This would then mean that EVEN if a CRL contains revocation information
from 2 CAs it might still not be indirect. Not of one of the CAs was
also the CRL issuer. Then we would only have 1 "authority" other than
the issuing authority.

Pretty interesting interpretation isn't it?

Stefan Santesson 
Program Manager, Standards Liaison 
Windows Security 

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Sharon Boeyen
Sent: den 21 juli 2005 11:43
To: 'Denis Pinkas'; David A. Cooper; Santosh Chokhani
Cc: 'pkix'
Subject: RE: Re: Correction to be done to
<draft-pinkas-pkix-conf-crl-validation-01.txt>

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

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

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 *an authority* other than that which issued
this CRL. 

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. 

>      single CA or may include certificates issued by multiple CAs. 

This would have been true if the X.509 definition had been written
differently. 

Sorry, it is not. 

Page 59 is stating: 

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. 

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

---

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 22 Jul 2005 17:31:06 +0100

Denis,

Your proposal is NOT simpler, NOT easier to implement and impose a
severe change of semantics which would require a new extension OID for
the IDP extension.

That's why I have a hard time taking this as a serious proposal.

Stefan Santesson

> From: Denis Pinkas [mailto:[email-masked]]
> Sent: den 22 juli 2005 08:44
> To: Santosh Chokhani; David A. Cooper; Stefan Santesson
> Cc: pkix
> Subject: Re: RE: Re: Correction to be done to
> Stefan,
> 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
> >
> >
> >> >      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
> >> >      authority.  Whenever the CRL issuer is not the CA that
issued
> >> >I believe the problem is that Denis is interpreting this sentence
as
> >a
> >> >      scope of an indirect CRL may be limited to certificates
issued
> >by a
> >> >the certificateIssuer CRL entry extension in both X.509 and RFC
3280
> >and
> >>    "The CRL issuer MUST assert the indirectCRL boolean, if the
scope
> >of
> >>    CRL issuer.  The authority responsible for each entry is
indicated
> >by

---

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 22 Jul 2005 18:19:23 +0100

Denis,

Make it simple?

In your simple case the CRL would not contain the name of the
certificate issuer anywhere!

Disregarding any increased security vulnerability due to decreased name
matching between cert and CRL, it would require change to existing code
to handle this new special case, introducing detection and special
handling of "delegated CRL".

That is NOT called making things simple. That is creating problems.

Stefan Santesson

> Sent: den 22 juli 2005 08:38
> To: Sharon Boeyen; David A. Cooper; Santosh Chokhani
> Cc: 'pkix'
> 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 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
> >"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).
> 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
> >
> On
Machines
> "indirect
> >CRL"
later
definition.
revocation
issued
revocation
> which
> >>      If the scope of the CRL includes one or more certificates
issued
> >>      scope of an indirect CRL may be limited to certificates issued
by
issuer
> CRL
> >entry extensions.
issue
issuer
> CRL
> >entry extension
> received
> >and accepted
CA,
revocation
the