Subject: RE: OCSP identifiers

From: "Bob Jueneman" <[email-masked]>
Date: Mon, 20 Nov 2000 10:51:36 -0700

Santosh is quite correct -- there are situations which favor the use of CRLs, and there are situations which favor an on-line responder mechanism, and there are some interesting possibilities involving a blending of the two functions.

Consider the case where there is very limited bandwidth available from a given installation or community of interest back to the CA or the potential OCSP responder.  For example, take a carrier battle group at sea, perhaps during wartime.  

Depending on the emissions security rules in effect at the time, it is quite possible that the bandwidth back to a shore-based facility might be zero -- no communications are allowed at all.  Yet satellite-based CRL reception might very well be feasible, and in particular a delta-CRL approach.

In this case, a local OCSP responder and/or a directory containing CRLs may be the most efficient way to distributing certificate validity information onboard the individual ships, and the choice of OCSP vs. locally distributed CRLs can be made based on the requirements of the information consumers.

In another hypothetical case, an Enterprise may wish to institute a centralized control over which end-entities will be considered "trusted," based in part on, but certainly not limited to the certificate validity status of the end-entity.  For example, a hospital might not care what VeriSign thinks about the certificate validity of say Dr. Kevorkian -- the hospital may decide to reject any digitally signed orders, access control requests, etc., based on their own criteria.

In that case again, the responder can be anyone whom the RP trusts to make those decisions, either voluntarily or by edict.

Bob

>>> Santosh Chokhani <[email-masked]> 11/20/00 09:57AM >>>
Ambarish:

I do not mean to get in the middle of the debate.  The issues in
architecting a solution for revocation information notification to relying
party are very complex and require consideration of topics such as:

v The communication model, i.e., which class of users are communicating with
which class of users.  For example, if a user communicates with several
users who are subscriber to the same CA, a single CRL from the CA will
provide lot of relevant information and the user.  On the other hand, if a
user is communicating with several users, all belonging to different CA,
each CRL is offering only information relevant to one user.
v The directory architecture in terms of where they are located and what
portions of the directory information is replicated and/or shadowed.
v The communication band-width available.
v The bind time to access the repository
v Size of the revocation response from the repository, e.g. CRL size
v Processing load on the repository, specially for digital signature
generation on the revocation information
v Processing load on the user workstation, specially for digital signature
verification on the revocation information

OCSP suffers from the following drawbacks:

v Since the revocation information is produced at the server, the
communication channel between the relying party and the server must be
secured, most likely by using digital signatures
v Signed operations will limit server scaleability since digital signature
generation is computationally intensive
v Since the revocation information is produced at the server, the scheme
requires a trusted server as opposed to an untrusted repository
v Revocation of server public key requires a method for checking server
public key status.  This method is likely to be using the server public key
as an additional trust anchor or relying on a CRL mechanism.
v There needs to be  non-suppressable mechanism for the CA to provide
revocation information to the trusted server 
v There are no standards in the area of CA to provide non-suppressable
mechanism(s) for the revocation information to the trusted server

From my experience, the most scaleable and versatile revocation notification
means can be achieved by using a combination of the following:

v Use of CRL
v Replication of CA directory entry for fast access to CRL
v Use of ARL
v Consolidation of ARL for all CAs in a domain through the use of
Distribution Points 
v Consolidation of all the reason codes of key compromise for all
certificates in domain through the use of Distribution Point extension.
This CRL can be issued very frequently to meet the freshness requirements of
the domain.  This mechanism makes the CRL mechanism as current as the OCSP
v Partitioning routine revocation information using Distribution Point CRL
if CRLs become too large

There are several other factors that can help improve the CRL retrieval
efficiency.  These include:

v Repositories require the encoded CRL to send to the relying parties.  The
repositories also require decoded CRL to perform searches.  It may desirable
for the repository to store both encoded and decoded form as opposed to
performing encoding or decoding for each request
v Bind operation to repository can be slow if authentication is required.
If the repository does not store any private information, bind operations
for retrieval can be configured to require no authentication'
v CRL size can be reduced by having a short validity period for the
certificates, by using a coarse DN so that reorganization does not
invalidate a name, and not revoking for some reasons such as name change,
transfer, etc.)

I hope this helps.

-----Original Message-----
From: Ambarish Malpani [mailto:[email-masked]] 
Sent: Monday, November 20, 2000 11:53 AM
To: 'Bland, Graham'; 'Simon Tardell'; [email-masked] 
Subject: RE: OCSP identifiers

Hi Graham,
    Not quite true. There are a bunch of cases, where a root CA
certifies subCAs OCSP responders directly, whose status needs to
be checked by looking up the cert with the root's OCSP responder
(in practice, this second lookup gets optimized out).

Anyway, there are real life models, where a responder is trusted
because of a cert issued by a CA, but not necessarily trusted for
that CA. So it is possible to want to revoke an OCSP responder's
certificate.

Regarding CRLs - these are (as Simon said) a great way of getting
a snapshot of the statuses a CA has assigned. Also, by having CAs
produce and publish new CRLs as soon as there is a revocation event,
this becomes a great way of passing revocation data from a CA to
a responder.

CRLs are not scalable where they need to be distributed to a large number
of clients [read thousands/hundreds of thousands]. They are a perfectly
good way of distributing revocation data to a single client (the
responder), which can then take on the responsibility of:
a. Replicating to other responders
b. Providing OCSP responses to a large number of clients.

Also, there are real deployments where a person normally wants to revoke at
the CA, but desires to, as an emergency action, suspend directly at the
responder - so the responder uses both the CA's data (its CRL) and its own
local database to see what the status of a certificate is.

Hopefully, this helps explain the benefits of using CRLs and OCSP together.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [email-masked] 
339 N. Bernardo Ave.                          http://www.valicert.com 
Mountain View, CA 94043

> -----Original Message-----
> From: Bland, Graham [mailto:[email-masked]] 
> Sent: Monday, November 20, 2000 8:09 AM
> To: 'Simon Tardell'; [email-masked] 
> Subject: RE: OCSP identifiers
> 
> 
> Simon,
> 
> Sorry but there are still some practical caveats to be applied here.
> 
> If the OCSP responder is independent of the CA in question 
> then trust is
> entirely between the requestor and the responder, in this 
> case the issuer
> has no knowledge of nor involvement in the trust and cannot 
> invalidate the
> responder in any way.

Agreed.

> 
> In the second case where the responder is a logical part of the CA in
> question, the OCSP response is signed with the certificate 
> issuing key.
> The only way the CA can invalidate the responder is by 
> revoking its own
> issuing key which effectively requires a reconfiguration of 
> the requestor as
> the CA key would have to be implicitly trusted.  Practically 
> in this case
> the CA can simply shut down the responder.  I cannot see a 
> case where the CA
> would allow the use of its key and not have this level of control.

Agreed.

> 
> The third case is where the responder is a CA designated 
> responder with a
> specially marked certificate directly issued by the CA.
> In this case the logistics of the process do not make sense.
> Assuming the responder is being used to either:  
> 1. provide a more timely response than CRLs 
> 2. avoid having to manage the retrieval of CRLs
> 
> In order to validate the OCSP response I must now either 
> retrieve a CRL or
> Authority Information access (OCSP?) in order to validate the 
> response.  If
> the CRL is required then apart from a possible size reduction 
> in the CRL I
> have to implement all the logic required to have verified the 
> certificates
> status myself reducing the value of 2. Using a CRL here may 
> not satisfy the
> timeliness required by 1.  If Authority Information Access is 
> specified then
> I have just entered a loop (assuming this specifies an OCSP 
> responder which
> I then have to verify) 
> 
> So practically it is very difficult for a CA to invalidate an 
> OCSP responder
> apart from by shutting it down, I would guess that 
> specifically trusted
> responders or directly CA owned responders (which are 
> effectively implicitly
> trusted) are the only practical methods that can be used. 
> (unless anybody
> else has any other methods)
> 
> 
> Graham Bland
> 
> 
> 
> 
> -----Original Message-----
> From: Simon Tardell [mailto:[email-masked]] 
> Sent: 20 November 2000 15:16
> To: 'Bland, Graham'; Simon Tardell; [email-masked] 
> Subject: RE: OCSP identifiers
> 
> 
> > Simon,
> > 
> > There is no requirement 
> 
> Retracted. I don't know why I wrote that. It's Monday, I suppose.
> 
> The point that I'd like to make though, is that there certainly is no
> trouble deriving trust in the responder from trust of the 
> issuer (that is,
> the issuer can invalidate the responder if it feels like).
> 
> Simon.
> 
> Simon Tardell, Software Architect, SmartTrust
> voice +46 8 7755225, fax +46 8 7267912, cell +46 70 3198319
> [email-masked], http://www.smarttrust.com 
> ______________________________________________________________
> _________
> 
> This message is confidential and is intended for the addressee only;
> unless clearly stated that this disclaimer should not apply, this 
> e-mail is not intended to create legally binding commitments on 
> behalf of any company in the British Interactive Broadcasting 
> Holdings Limited group,  nor do its contents reflect the corporate 
> views or policies of any such company. Any unauthorised disclosure, 
> use or dissemination, either whole or partial, is prohibited. If you 
> are not the intended recipient of the message, please notify the
> sender immediately.
> ______________________________________________________________
> _________
>

---

From: Michael Ströder <[email-masked]>
Date: Tue, 21 Nov 2000 10:18:16 +0100

Bob Jueneman wrote:
> 
> In another hypothetical case, an Enterprise may wish to institute
> a centralized control over which end-entities will be considered "trusted,"
> based in part on, but certainly not limited to the certificate validity
> status of the end-entity.

I consider this case to be an authorization issue in opposite to
just validate
the certificate itself. IMHO this is not the purpose of OCSP
although the protocol might seem handy for this.

RFC2560:

"1.  Abstract
   This document specifies a protocol useful in determining the
current
   status of a digital certificate without requiring CRLs."

Maybe the term "status of a digital certificate" has to be better
defined in this discussion.

Ciao, Michael.