Subject: RE: 3280bis: CRL Entry Extensions

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 15 Feb 2006 11:49:07 -0800

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

   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: Jean-Marc Desperrier <[email-masked]>
Date: Thu, 16 Feb 2006 14:20:43 +0100

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