Subject: RE: Cached OCSP responses vs. single entry CRLs

From: "Ryan M. Hurst" <[email-masked]>
Date: Mon, 8 Dec 2003 12:04:46 -0800

Carl - These are just a few of the reasons, as for your question consider the scenario of a issuer having to support mixed version/heterogeneous environments. 
 
Although more recent Microsoft clients support partitioned CRLs, that does not mean the ones before this concept existed do, what about clients based on open source implementations, or ones running on other operating systems that do not have support for this concept? 
 
TTPs still need to provide their subscribers and their relying parties with revocation information without having to require subscribers to have different profiled certificates for communication with different constituents. Today if a CDP pointed to a partitioned CRL these clients lacking support for this concept would not be able to validate the CDP.
 
The use of OCSP gets around this issue, as long as we do not introduce any breaking changes into the protocol (and don't forget the RFC did allow for the pre-production concept explicitly).
 
Beyond the deployability concepts above, OCSP has a number of other benefits as well that make it a very natural fit (400 byte responses for example); also considering there are vendors with products that deal with these concepts available today OCSP really is the natural solution. 
 
Ryan

________________________________

From: Carl Wallace [mailto:[email-masked]]
Sent: Mon 12/8/2003 5:39 AM
To: 'Deacon, Alex'; Ryan M. Hurst; [email-masked]
Subject: RE: Cached OCSP responses vs. single entry CRLs

Response to following two comments below...

> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Deacon, Alex
> Sent: Friday, December 05, 2003 7:05 PM
> Subject: RE: Cached OCSP responses vs. single entry CRLs
>
> We looked into this.  The problem is that client support for
> "crl partitioning" (in this case a partition by individual
> serial number) is just about non-existant.
>
> Alex
>

> From: Ryan M. Hurst [mailto:[email-masked]]
> Sent: Friday, December 05, 2003 6:30 PM
> Subject: RE: Cached OCSP responses vs. single entry CRLs
>
> Carl there are a number of reasons, one of the most
> significant being backwards compatibility; many existing
> client implementations do not support partitioned CRLs and
> there is not way to tell from a CDP if the data on the other
> end represents a partitioned CRL or a full one.
>
> Additionally there are commercial OCSP responders out there
> that support this concept, yet very few CAs support the use
> of portioned CRLs to that granularity.
>
> Ryan

The responses regarding lack of client side support are somewhat strange.
It is not possible that deployed client-side support for partitioned CRLs is
less than deployed client-side support for the yet-to-be-defined solution
for cached OCSP. 

On the other side of the transaction, what is the protocol used to populate
the responders that serve pre-produced responses?  Is this something that
would need to be standardized too?  There are already standards-based means
of replicating directories.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 8 Dec 2003 18:04:28 -0500

Ryan:
 
The client concern does not seem to cut the mustard since Carl's argument is
that we do not seem to have a standard for nonceless client, let alone
capability.  For the partitioned CRL, we have well-defined standard.
 
As to the response size, I am sure that a partitioned CRL (one CRL for each
certificate) will be less than 400 bytes you cited.
 
I think partitioning CRL for individual certificate has plusses in terms of
standard and removing the need for client.  It also has directory related
plusses in terms of replication.
 
I think its minuses are in terms of CA's ability to support it (or requiring
delegated CRL issuer, i.e., Indirect CRL Issuer Model) and may be addition
and management of entries under the CA branch for the CRL partitions.
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Ryan M. Hurst
Sent: Monday, December 08, 2003 3:05 PM
To: Carl Wallace; Deacon, Alex; [email-masked]
Subject: RE: Cached OCSP responses vs. single entry CRLs

Carl - These are just a few of the reasons, as for your question consider
the scenario of a issuer having to support mixed version/heterogeneous
environments. 
 
Although more recent Microsoft clients support partitioned CRLs, that does
not mean the ones before this concept existed do, what about clients based
on open source implementations, or ones running on other operating systems
that do not have support for this concept? 
 
TTPs still need to provide their subscribers and their relying parties with
revocation information without having to require subscribers to have
different profiled certificates for communication with different
constituents. Today if a CDP pointed to a partitioned CRL these clients
lacking support for this concept would not be able to validate the CDP.
 
The use of OCSP gets around this issue, as long as we do not introduce any
breaking changes into the protocol (and don't forget the RFC did allow for
the pre-production concept explicitly).
 
Beyond the deployability concepts above, OCSP has a number of other benefits
as well that make it a very natural fit (400 byte responses for example);
also considering there are vendors with products that deal with these
concepts available today OCSP really is the natural solution. 
 
Ryan

  _____

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Tue, 09 Dec 2003 20:59:41 +0100

From: Carl Wallace

Santosh Chokhani wrote:

> The client concern does not seem to cut the mustard since Carl's 
> argument is that we do not seem to have a standard for nonceless 
> client, let alone capability.  For the partitioned CRL, we have 
> well-defined standard.
>  
> As to the response size, I am sure that a partitioned CRL (one CRL for 
> each certificate) will be less than 400 bytes you cited.
> I think partitioning CRL for individual certificate has plusses in 
> terms of standard and removing the need for client.  It also has 
> directory related plusses in terms of replication.
>  
> I think its minuses are in terms of CA's ability to support it (or 
> requiring delegated CRL issuer, i.e., Indirect CRL Issuer Model) and 
> may be addition and management of entries under the CA branch for the 
> CRL partitions.

You are missing a major minus of partitioning CRL that many/most client 
don't support partitioned CRL, but worst do not properly recognize the 
cRLIssuer part of the CRLDP, and will not be able to match it to the IDP 
inside the crl, so they can be pushed to trust a partionned CRL for a 
cert it doesn't apply too.
*That* is the concern for lack of client side support. In the current 
state of things, partionned CRL is very probably a security hazard for 
many clients.

Meanwhile using cached OCSP without any of the addition discussed here 
is not a problem as long as the client is configured not to require a nonce.
The proposed OCSP change is an optimization, not absolutly required.

---

From: "Carl Wallace" <[email-masked]>
Date: Tue, 9 Dec 2003 18:19:44 -0500

> [mailto:[email-masked]] On Behalf Of Jean-Marc 
> Desperrier
> Subject: Re: Cached OCSP responses vs. single entry CRLs
> 
> is not a problem as long as the client is configured not to 
> require a nonce. The proposed OCSP change is an optimization, 
> not absolutly required.
> 

As you pointed out in a subsequent post, a client that doesn't support
partitioned CRLs should choke on a critical IDP and (possibly) be unable to
determine the revocation status of the certificate in question.  This is
similar to an OCSP client that uses nonces when interacting with a caching
OCSP responder.  Faulty implementations are a different matter.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 9 Dec 2003 23:45:32 -0500

Jean-Marc:

To match the DP in the IDP in CRL, you need to match the DP in CDP in the
certificate.  cRLIssuer field needs to come in to play only if there is an
indirect CRL issuer.

If the client does not know how to process a critical extension (which IDP
is) and still uses a PKI object (certificate or CRL), I am sure lots of
other things can go wrong.  Just look at some of the other vulnerabilities
identified and corrected over the last few months.

As to lack of client side support, when did that became a basis for putting
out yet another standard and requiring yet another client side plug-in.  I
am sure adding IDP processing to certificate and CRL processing is lot
easier than defining and adding an OCSP client.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Jean-Marc Desperrier
Sent: Tuesday, December 09, 2003 3:00 PM
To: [email-masked]
Subject: Re: Cached OCSP responses vs. single entry CRLs

From: Carl Wallace

Santosh Chokhani wrote:

> each certificate) will be less than 400 bytes you cited. I think 
> partitioning CRL for individual certificate has plusses in terms of 
> standard and removing the need for client.  It also has directory 
> related plusses in terms of replication.
>

---

From: "Michael Myers" <[email-masked]>
Date: Thu, 11 Dec 2003 21:01:14 -0700

-----Original Message-----
From: Carlisle Adams
Sent: Tuesday, December 09, 2003 12:00 PM
To: Michael Myers
Subject: Re: MUST reject in OCSPv1

Hi Mike,

[. . .] you may forward the content of this message to the list
if you
wish.

It's pretty clear to me that clients use a nonce when they want
to guarantee
a fresh response from the other end (the nonce is returned in a
signed
message).  If the client doesn't care about freshness, it has no
reason to
use the nonce since that is the ONLY purpose that the nonce
serves.

So, if a client puts a nonce in its request, the server MUST
return it in
the response.  If the responder requirement is softened to a
SHOULD, then
the client requirement has to be strengthened to "if the
response comes back
without the client's nonce included, the client MUST reject the
message".
Again, if the client doesn't care about freshness, then it MUST
NOT put a
nonce in the request.  If it does put a nonce in the request,
then a
response without it MUST NOT be acceptable.  This only makes
sense:  if you
explicitly ask for a security service on a response
(confidentiality,
authenticity, integrity, freshness, whatever) and the response
shows up
without it, this must be unacceptable.  I don't care so much
whether the
behavioral requirement is on the client or on the responder
(although I
would prefer it to be on the responder), but the result must be
that the
request has not been completed.

Carlisle.