Subject: 3280bis: CRL Entry Extensions

From: "Denis Pinkas" <[email-masked]>
Date: Wed, 15 Feb 2006 16:44:04 +0100

The text from 3280 was:

5.3  CRL Entry Extensions

   All CRL entry extensions used in this specification are non-critical.
   Support for these extensions is optional for conforming CRL issuers
   and applications.

The text in 3280bis is:

   Support for the CRL entry extensions defined in this specification is
   optional for conforming CRL issuers and applications.

You will note that the first sentence disappeared. In fact that statement 
was untrue since 3280 contained the description of a single critical 
crlEntryExtension: the Certificate Issuer CRL entry extension.

3280 contains the following sentence:

   A CRL validation MUST fail if it encounters a critical CRL entry extension
   which it does not know how to process.

3280bis contains a similar sentence:

   If a CRL contains a critical CRL entry extension that the 
   application cannot process then the application MUST NOT use 
   that CRL to determine the status of certificates.

The main difference between 3280 and 3280bis is that, based on the statement 
“all CRL entry extensions used in this specification are non-critical “, 
implementations conformant to 3280 could ignore CRL entry extensions, 
unless the CRL had a critical CRL extension which “advertised” the presence 
of critical CRL entry extensions.

Since CRL extensions are tested before CRL entry extensions, this was not a problem.

A CRL extension that is critical and not recognized invalidates the whole CRL.

A critical CRL entry extension that is critical and not recognized should normally 
invalidate the entry, not the whole CRL.

The Certificate Issuer CRL entry extension is the single CRL entry extension 
that affects subsequent CRL entries. All other CRL entry extensions defined 
at this time only affect the entry where they appear.

With the current text from 3280bis, implementers would have to test all remaining 
CRL entries from a CRL, even if a match on one CRL entry is found !

Unless clearly advertised otherwise using a critical crlExtensions field , 
the idea is to avoid to check the presence of crlEntryExtensions field in entries 
where the serial number of interest does not match. 

This can be achieved since the presence of the Certificate Issuer CRL entry extension 
is always announced using a critical CRL extension, i.e. the issuing distribution point 
CRL extension with the indirectCRL indicator set.

The general rule shall then be: 

“Unless indicated otherwise using a critical CRL extension in the crlExtensions field, 
a CRL entry extension only affects the certificate(s) specified in that entry”.

This sentence should replace the current sentence which is:

   If a CRL contains a critical CRL entry extension that the 
   application cannot process then the application MUST NOT use 
   that CRL to determine the status of certificates.

Other changes that are the consequence of this are staightforward.

Denis

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 16 Feb 2006 06:04:14 -0800

Upon further review, Denis may be saying the following somewhat related
things.

1.  The indirect CRL indicator serves as the statement that certificate
issuer entry extension affects other entries.  3280 Bis seems to cover
this adequately since the descriptions of the two fields point to
one-another.

2.  Even if you do not recognize a critical certificate issuer entry, if
you do not encounter it in early portion of a CRL and the certificate of
interest is issued by the CRL issuer and is in the early portion, the
relying party can assume that the certificate is no good, without
raising a denial of service attack. I agree with that.  But, in order to
bring that thought into 3280 Bis, first the community needs to agree on
the need to enhance CRL processing section to address the processing of
indirect CRL.

3.  If a critical CRL entry extension is defined in the future and if
the value of that extension may impact other entries, there should also
be a critical extension in the CRL extensions to assert that.  This is a
new concept for both X.509 and 3280.  Adding this concept will not
impact existing CAs, clients or backward compatibility.  

-----Original Message-----
From: Santosh Chokhani 
Sent: Wednesday, February 15, 2006 2:43 PM
To: pkix
Subject: RE: 3280bis: CRL Entry Extensions

Stefan,

I agree with your observation.

I do not agree with Denis's observation since there is no mechanism
today in an extension semantics to indicate the scope of the object the
extension impacts.  Thus, the fact that certificate issuer extension
does affect other entries can not be communicated to relying parties
unless they recognize the extension itself.

This is a chicken and egg problem and the only solution I know is to
make entry extensions 4-tuple: OID, criticality, scope and value.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stefan Santesson
Sent: Wednesday, February 15, 2006 11:48 AM
To: Denis Pinkas; pkix
Subject: RE: 3280bis: CRL Entry Extensions

Denis,

I think you hit a valid point.
One should not have to further process the CRL once an entry matching
the target certificate has been found. This may have to be clarified.

However, we don't know if new or privately defined CRL entry extensions
may affect other entries.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Denis Pinkas
Sent: den 15 februari 2006 07:44
To: pkix
Subject: 3280bis: CRL Entry Extensions

The text from 3280 was:

5.3  CRL Entry Extensions

The text in 3280bis is:

You will note that the first sentence disappeared. In fact that
statement 
was untrue since 3280 contained the description of a single critical 
crlEntryExtension: the Certificate Issuer CRL entry extension.

   A CRL validation MUST fail if it encounters a critical CRL entry
extension
   which it does not know how to process.

The main difference between 3280 and 3280bis is that, based on the
statement 
"all CRL entry extensions used in this specification are non-critical ",

implementations conformant to 3280 could ignore CRL entry extensions, 
unless the CRL had a critical CRL extension which "advertised" the
presence 
of critical CRL entry extensions.

Since CRL extensions are tested before CRL entry extensions, this was
not a problem.

A CRL extension that is critical and not recognized invalidates the
whole CRL.

A critical CRL entry extension that is critical and not recognized
should normally 
invalidate the entry, not the whole CRL.

The Certificate Issuer CRL entry extension is the single CRL entry
extension 
that affects subsequent CRL entries. All other CRL entry extensions
defined 
at this time only affect the entry where they appear.

With the current text from 3280bis, implementers would have to test all
remaining 
CRL entries from a CRL, even if a match on one CRL entry is found !

Unless clearly advertised otherwise using a critical crlExtensions field
, 
the idea is to avoid to check the presence of crlEntryExtensions field
in entries 
where the serial number of interest does not match. 

This can be achieved since the presence of the Certificate Issuer CRL
entry extension 
is always announced using a critical CRL extension, i.e. the issuing
distribution point 
CRL extension with the indirectCRL indicator set.

"Unless indicated otherwise using a critical CRL extension in the
crlExtensions field, 
a CRL entry extension only affects the certificate(s) specified in that
entry".

Denis

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 16 Feb 2006 07:23:02 -0800

You may be misunderstanding me.  Saying that the solution I know is
4-tuple is not a suggestion to go in the direction.

Also, why not simply deprecate indirect CRL.  It is not worth the
trouble.

BTW, the only PKI implementation I know of that uses the indirect CRL,
does it for multiple CAs.

Of all the positions, my most favorite is to deprecate the whole concept
of indirect CRL.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Jean-Marc Desperrier
Sent: Thursday, February 16, 2006 8:21 AM
To: pkix
Subject: Re: 3280bis: CRL Entry Extensions

> make entry extensions 4-tuple: OID, criticality, scope and value.
I don't agree. The only solution is to Keep It Simple and Stupid :
"Remove from the PKIX profile any case where a CRL entry extension 
affects other entries."

Of course, we have to live with the legacy of the Certificate Issuer crl

entry extension.

But I see a way to handle that if we consider that :
- nobody actually needs indirect CRL that cover several CA
This is quite a bit of complexity to implement correctly, and it's a 
nice toy but it doesn't cover a real life problem (anybody, feel free to

contradict me if you have a reason to think otherwise).
The real life problem is too large CRLs, not a desire to cover several 
CA with one CRL which would make that problem even bigger.
- then we can restrict the use of the Certificate Issuer  crl entry 
extension to the case where it's present only on the very first crl 
entry and implementation can handle it by pretending it's a CRL 
extension applied to the whole CRL content.

So I would be in favor of doing this :
- to deprecate in PKIX the use of indirect CRL that cover several CA.
Conformant implementation MUST generate indirect CRL that cover only one

CA and set the Certificate Issuer crl entry extension only on the first 
crl entry.
- to say that conforming implementation MUST
   * reject at load CRL that have a Certificate Issuer extension on any 
entry extension but the very first one.
   * or implement the full X509 rules to support indirect CRL that cover

several CAs

Then we should precise somewhere that indirect crl match a certificate 
when their issuer matches the cRLIssuer in the CRL Distribution Points 
of the cert *and* (they are empty *or* the Certificate Issuer  crl entry

of first crl entry of the crl matches the issuer of the certificate).

---

From: "Denis Pinkas" <[email-masked]>
Date: Thu, 16 Feb 2006 17:39:14 +0100

I see many emails coming from [email-masked] and 
since there is no name of first name at the end, it is hard to guess who it may be.
Before this is fixed, would commenters please place your first name or your name at the end ?

First of all it is important to remember that conforming applications or CAs 
are not required to support indirect CRLs.

I share the point of view that we should deprecate the use of indirect CRLs 
in this profile, at least when the indirect CRL covers the certificates from more than one CA. 
This covers two cases: 

a) the case where a CA is also a CRL issuer for its own certificates, 
   but has been designated by another CA to handle the revocation information 
   from that other CA, and
 
b) the case where two CAs have designed the same CRL Issuer.

Even if we recommend not to issue CRLs for the cases a) and b) above, 
relying parties have nevertheless to be ready to reject such CRLs (the citation below is: 
"BTW, the only PKI implementation I know of that uses the indirect CRL,
does it for multiple CAs").

However, I am hesitant to also deprecate the use of indirect CRLs in the case 
the indirect CRL covers one single CA.

A citation below is: "Then we should precise somewhere that indirect crl match 
certificate when their issuer matches the cRLIssuer in the CRL Distribution Points 
of the cert". [I could not understand the " *and* (they are empty *or*]

The above condition would be fine and *fully sufficient*, if there was a way to indicate 
that the CRL covers the certificates issued by single CA.
 
For a CRL not issued by the CA, but covering only the certificates from that CA, 
there would be no need to use the Certificate Issuer CRL entry extension at all.

Very unfortunately, since such a CRL is called an indirect CRL, then the 
indirectCRL Boolean is needed in the IDP extension and then this forces to 
"bite the bullet" of the Certificate Issuer CRL entry extension. 
It is worthwhile to notice that the trouble comes from the definition of 
indirect CRL, a change in the definition would solve the issue !

Some comments on another anonymous email on the same topic, seen today:

 [Denis]. I would rather say :
"1.  The indirect CRL indicator serves as the statement that certificate
issuer entry extension MAY be present and, if present, affects subsequent entries.

2.  Even if you do not recognize a critical certificate issuer entry, if
you do not encounter it in early portion of a CRL and the certificate of
interest is issued by the CRL issuer and is in the early portion, the
relying party can assume that the certificate is no good, 

[Denis]. This is correct and could be used as a rule to avoid to parse 
the CRL entries up to the end.

without raising a denial of service attack. I agree with that.  But, in order to
bring that thought into 3280 Bis, first the community needs to agree on
the need to enhance CRL processing section to address the processing of
indirect CRL.

[Denis]. Yes.

[Denis]. Yes. This is along the idea I proposed.

Denis    

>of first crl entry of the crl matches the issuer of the certificate).

Regards,

Denis Pinkas

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 16 Feb 2006 10:03:19 -0800

Denis,

If you care to know, several of the items below were from me.

As to the your statement, "For a CRL not issued by the CA, but covering
only the certificates from that CA, there would be no need to use the
Certificate Issuer CRL entry extension at all."  While this may be true,
there would be a need to change the standard in order to secure
communicate to the relying parties which issuer is covered by the CRL.

Note that just because I am sharing my thoughts and analysis, it does
not mean I am advocating that the Standard be changed.

Santosh Chokhani

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Denis Pinkas
Sent: Thursday, February 16, 2006 11:39 AM
To: pkix
Cc: owner-ietf-pkix
Subject: Re: RE: 3280bis: CRL Entry Extensions

I see many emails coming from [email-masked] and 
since there is no name of first name at the end, it is hard to guess who
it may be.
Before this is fixed, would commenters please place your first name or
your name at the end ?

First of all it is important to remember that conforming applications or
CAs 
are not required to support indirect CRLs.

I share the point of view that we should deprecate the use of indirect
CRLs 
in this profile, at least when the indirect CRL covers the certificates
from more than one CA. 
This covers two cases: 

a) the case where a CA is also a CRL issuer for its own certificates, 
   but has been designated by another CA to handle the revocation
information 
   from that other CA, and

Even if we recommend not to issue CRLs for the cases a) and b) above, 
relying parties have nevertheless to be ready to reject such CRLs (the
citation below is: 
"BTW, the only PKI implementation I know of that uses the indirect CRL,
does it for multiple CAs").

However, I am hesitant to also deprecate the use of indirect CRLs in the
case 
the indirect CRL covers one single CA.

A citation below is: "Then we should precise somewhere that indirect crl
match 
certificate when their issuer matches the cRLIssuer in the CRL
Distribution Points 
of the cert". [I could not understand the " *and* (they are empty *or*]

The above condition would be fine and *fully sufficient*, if there was a
way to indicate 
that the CRL covers the certificates issued by single CA.
 
For a CRL not issued by the CA, but covering only the certificates from
that CA, 
there would be no need to use the Certificate Issuer CRL entry extension
at all.

indirectCRL Boolean is needed in the IDP extension and then this forces
to 
"bite the bullet" of the Certificate Issuer CRL entry extension. 
It is worthwhile to notice that the trouble comes from the definition of

 [Denis]. I would rather say :
"1.  The indirect CRL indicator serves as the statement that certificate
issuer entry extension MAY be present and, if present, affects
subsequent entries.

without raising a denial of service attack. I agree with that.  But, in
order to
bring that thought into 3280 Bis, first the community needs to agree on
the need to enhance CRL processing section to address the processing of
indirect CRL.

[Denis]. Yes.

Denis    

Regards,

Denis Pinkas