Subject: Re: delta CRL security considerations

From: "Bob Jueneman" <[email-masked]>
Date: Mon, 30 Apr 2001 11:03:54 -0600

Tim,

Publishing a full CRL every time a delta is published does seem to negate most of the benefit of the delta CRL approach.

But realistically, probably 90% or more of certificate revocations will be for relatively benign reasons -- someone changed their name, address, department, or even the organization they work for -- but their keys have not been compromised.

Without falling into the nonrepudiation tar pit, it may be worth observing that in virtually all of those cases, the individual involved is still liable for whatever they might have been liable for before their status changed, UNLESS there was a change in the extent to which an individual was acting as an authorized agent of the organization, e.g., a purchasing agent or an officer of the company.

You might want to consider adding something to the security considerations section that recommends that a full CRL be published along with a delta for any revocations for cause, such as key compromise or change or agency.  For the rest of the revocations, presumably it will be sufficient to wait until the next regularly scheduled CRL, whenever that is.

I'm not terribly concerned about minimally compliant relying party software.  Anyone who is using certificates for any important purpose, as opposed to say casual e-mail or routine SSL server certificates, will almost certainly not use such minimally compliant software.

Bob

Robert R. Jueneman
Security Architect

Novell, Inc -- the leading provider of Net services software

>>> Tim Polk <[email-masked]> 04/27/01 02:39PM >>>
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: Sam Schaen <[email-masked]>
Date: Mon, 30 Apr 2001 16:41:29 -0400

> Publishing a full CRL every time a delta is published does seem to negate most of the benefit of the delta CRL approach.

I just wanted to dispute the above statement.  We [DOD] have an architecture in which the CAs and Directories are connected either by high speed LAN or ATM network.  We're not as concerned about the bandwidth cost of pushing the full CRLs to the directory as the total bandwidth from all the end entities fetching CRLs from the directory.  To the extent that end-entities can make use of delta CRLs
instead of full CRLs, we think there would be an advantage in our environment.  Clearly there will be other environments that would be concerned with the cost of publishing the full CRL.

[snip]