Subject: RE: straw poll on certs in CRLs

From: "Kemp, David P." <[email-masked]>
Date: Wed, 7 Mar 2007 18:07:06 -0500

No, the detrimental effect is when a client does know
how to make use of the information, already has it in a cache,
yet keeps getting it over and over because there is no
way for that client to request a non-extended CRL.  A few
certs in a 5MB CRL isn't much overhead, but a few certs in
a previously-2KB partitioned CRL is a different story.

The point is that this is not an essential capability, it is
an optimization to minimize the number of round trips and the
number of repositories a client must contact.  If certs and
CRLs are simply made available from the same repository or
cache, the primary justification for the extension
(unavailability of a cert repository when the CRL repository
is available) disappears.  This 90% solution can be deployed
with no changes whatsoever to standards or products.

If that isn't good enough, and one simply must have a single
get from a single repository, the "No" votes want PKIX to
consider a late-binding option (which can be performed
or not when the CRL is requested) as an alternative to
the proposal for early binding (which is always performed when
the CRL is generated, and thus always impacts every user of
that CRL whether they want it or not).

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Hallam-Baker, Phillip
Sent: Wednesday, March 07, 2007 4:04 PM
To: Paul Hoffman; Guida, Richard [JJCUS]; Stefan Santesson;
[email-masked]
Subject: RE: straw poll on certs in CRLs

The extension causes the CRL to grow but not the amount of data that the
client needs to process.

The only case in which there are detrimental effects is when a client
that does not have the ability to make use of the information receives a
crl with the information unasked for.

Such effects are fully the type of thing we expect application providers
to take note of in making their implementation decisions. Market forces
should provide ample discipline.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Hoffman
> Sent: Wednesday, March 07, 2007 2:32 PM
> To: Guida, Richard [JJCUS]; Stefan Santesson; [email-masked]
> Subject: RE: straw poll on certs in CRLs
> 
> 
> At 2:20 PM -0500 3/7/07, Guida, Richard [JJCUS] wrote:
> >Paul - perhaps I am missing something here (would not be the first
> >time...) but the proposal is that it be a non-critical 
> extension and as 
> >such, under RFC3280, relying party software can indeed ignore it if 
> >they fail to recognize it, correct?
> 
> Yes, definitely. But that's not the concern of many of the 
> "no" folks have voiced.
> 
> >  Your e-mail said "turned it on" but I was not clear what 
> you meant by that.
> 
> Good point; I should have said "deployed, perhaps by default".
> 
> Issuing CRLs with this extension causes the CRL to grow, 
> possibly significantly. Transmitting this kruft in every CRL 
> retrieval, particularly in protocols that require CRL 
> retrieval, is wasteful. 
> Further, other folks have proposed better solutions that 
> allow more useful information to be given to the relying 
> party than the one-size-fits-all view that the CRL issuer 
> knows all possible chains it should include in the CRL.
> 
> --Paul Hoffman, Director
> --VPN Consortium
> 
>

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 7 Mar 2007 13:03:43 -0800

The extension causes the CRL to grow but not the amount of data that the client needs to process.

The only case in which there are detrimental effects is when a client that does not have the ability to make use of the information receives a crl with the information unasked for.

Such effects are fully the type of thing we expect application providers to take note of in making their implementation decisions. Market forces should provide ample discipline.

---

From: "Sharon Boeyen" <[email-masked]>
Date: Thu, 8 Mar 2007 10:16:07 -0500

Dave, this message explains EXACTLY the reason for my no vote. Thanks
for crystallizing it!!!!

Cheers,
Sharon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Kemp, David P.
Sent: Wednesday, March 07, 2007 6:07 PM
To: [email-masked]
Subject: RE: straw poll on certs in CRLs

No, the detrimental effect is when a client does know
how to make use of the information, already has it in a cache, yet keeps
getting it over and over because there is no way for that client to
request a non-extended CRL.  A few certs in a 5MB CRL isn't much
overhead, but a few certs in a previously-2KB partitioned CRL is a
different story.

The point is that this is not an essential capability, it is
an optimization to minimize the number of round trips and the number of
repositories a client must contact.  If certs and CRLs are simply made
available from the same repository or cache, the primary justification
for the extension (unavailability of a cert repository when the CRL
repository is available) disappears.  This 90% solution can be deployed
with no changes whatsoever to standards or products.

If that isn't good enough, and one simply must have a single get from a
single repository, the "No" votes want PKIX to consider a late-binding
option (which can be performed or not when the CRL is requested) as an
alternative to the proposal for early binding (which is always performed
when the CRL is generated, and thus always impacts every user of that
CRL whether they want it or not).