Subject: RE: delta CRL security considerations

From: "David Cross" <[email-masked]>
Date: Fri, 27 Apr 2001 13:54:34 -0700

Sounds good

David B. Cross

-----Original Message-----
From: Tim Polk [mailto:[email-masked]] 
Sent: Friday, April 27, 2001 1:40 PM
To: [email-masked]
Subject: delta CRL security considerations

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: "Trevor Freeman" <[email-masked]>
Date: Sun, 29 Apr 2001 23:16:32 -0700

A similar comment can be made on the use of the Issuing Distribution
Point extension, which is another, critical, but not mandated to be
suported extension in the CRL.

-----Original Message-----
From: Paul Hoffman / IMC [mailto:[email-masked]] 
Sent: Friday, April 27, 2001 2:21 PM
To: Tim Polk; [email-masked]
Subject: Re: delta CRL security considerations

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

---

From: "Bob Jueneman" <[email-masked]>
Date: Mon, 30 Apr 2001 14:52:59 -0600

Sam, I agree completely.  Maybe I fell into a semantic trap by seeming to imply that "publish" meant "push all the way out to every user, whether they want them or not."  That wasn't my intent.  By "publish" I meant "make available in a directory to anyone who looks there."

In most cases, the distance between the CA and a standard repository or directory is probably measured in meters, so that bandwidth is not much of a concern.  But the bandwidth consumed by all of the users, and especially those that may be at sea or otherwise have only limited communications facilities available to them, is very much a concern.

Bob

>>> Sam Schaen <[email-masked]> 04/30/01 02:41PM >>>

Bob Jueneman wrote:

> Tim,
>
> 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]

---

From: Hal Lockhart <[email-masked]>
Date: Mon, 30 Apr 2001 17:56:38 -0400

This might be the time to mention a slightly different point about delta
CRLs and bandwidth. In David Cooper's paper, he assumes that the metric to
be optimized is peak bandwidth. While this is probably correct for many or
most organizations, it is at least possible that some will want to optimize
aggregate bandwidth. (For example, if you pay by the byte.) Almost any use
of delta CRLs will reduce this.

Hal

> From: Bob Jueneman [mailto:[email-masked]]
> Sent: Monday, April 30, 2001 4:53 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Sam, I agree completely.  Maybe I fell into a semantic trap 
> by seeming to imply that "publish" meant "push all the way 
> out to every user, whether they want them or not."  That 
> wasn't my intent.  By "publish" I meant "make available in a 
> directory to anyone who looks there."
> 
> In most cases, the distance between the CA and a standard 
> repository or directory is probably measured in meters, so 
> that bandwidth is not much of a concern.  But the bandwidth 
> consumed by all of the users, and especially those that may 
> be at sea or otherwise have only limited communications 
> facilities available to them, is very much a concern.
> 
> Bob
> 
> > 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]
> 
> 
>