Subject: delta CRL security considerations

From: Tim Polk <[email-masked]>
Date: Fri, 27 Apr 2001 16:39:44 -0400

Folks,

It appears that the WG consensus is to remove the requirement for 
publication of full CRLs with every delta CRL from son-of-2459.  As a 
result, there is a possibility that minimally compliant PKI clients will 
not have the same information provided to clients that process delta 
CRLs.  It seems appropriate to note this fact in the security 
considerations section.  We are proposing insertion of four new sentences 
into the paragraph on revocation.  I have supplied the entire paragraph 
here.  The new text begins and ends with two asterisks.

-------- excerpt from security considerations ----

The availability and freshness of revocation information will affect the 
degree of assurance that ought to be placed in a certificate. While 
certificates expire naturally, events may occur during its natural lifetime 
which negate the binding between the subject and public key.  If revocation 
information is untimely or unavailable, the assurance associated with the 
binding is clearly reduced.  **Relying parties might not be able to process 
every critical extension that can appear in a CRL.  CAs SHOULD take extra 
care when making revocation information available only through CRLs that 
contain critical extensions, particularly if support for those extensions 
is not mandated by this profile.  For example, if revocation information is 
supplied using a combination of delta CRLs and full CRLs, and the delta 
CRLs are issued more frequently than the full CRLs, then relying parties 
that cannot handle the critical extensions related to delta CRL processing 
will not be able to obtain the most recent revocation 
information.  Alternatively, if a full CRL is issued whenever a delta CRL 
is issued, then timely revocation information will be available to all 
relying parties.**  Similarly, implementations of the Path Validation 
mechanism described in section 6 that omit revocation checking provide less 
assurance than those that support it.

----------------end of excerpt------------

Your comments would be appreciated.

Thanks,

Tim Polk

---

From: "Michael Myers" <[email-masked]>
Date: Fri, 27 Apr 2001 13:53:24 -0700

Tim,

A proposed amendment.

Mike

> The availability and freshness of revocation information will
> affect the degree of assurance that ought to be placed in a
> certificate. While  certificates expire naturally, events may
> occur during its natural lifetime which negate the binding
> between the subject and public key.  If revocation information
> is untimely or unavailable, the assurance associated with the 
> binding is clearly reduced.
> To the extent these principles apply to the certificate and
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> CRL profiles which are the subject of this document,
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> **Relying parties might not be able 
> to process every critical extension that can appear in a CRL.
> . . .

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Fri, 27 Apr 2001 14:21:06 -0700

I think this is OK, but similar words have to go into the deltaCRL 
section as well. Some implementors might not think through the really 
nasty implications of not issuing full CRLs when they should.

--Paul Hoffman, Director
--Internet Mail Consortium