Subject: OCSP - Adoption of response models

From: [email-masked]
Date: Fri, 4 Apr 2003 09:46:57 +0000

RFC2560 offers three valid response models for OCSP (Two too many
in my opinion)

i.   Signed by the CA
ii.  Signed by a VA with explicit delegation by the CA
iii. A local model

Does anyone have a feel for which model boasts the most widespread
adoption ? I feel it should be ii) but suspect its iii) Deployment of the
technology appears to be too scarce at present to make a sensible
judgement.

Opinions appreciated

Chris

This  email  and  any  attachments  are confidential and intended for the addressee
only.   If  you are not the named recipient, you must not use, disclose, reproduce,
copy  or  distribute the contents of this communication.  If you have received this
in error, please contact the sender and then delete this email from your system.

---

From: Florian Oelmaier <[email-masked]>
Date: Fri, 04 Apr 2003 13:19:46 +0200

> ii.  Signed by a VA with explicit delegation by the CA

I have seen 2 installations using a fourth model:

ii-a. Signed by a VA with explicit delegation by any CA in the chain.

Thus it is possible to use one OCSP-Responder signed by the Root-CA to 
answer for all Sub-CAs. Interesting idea. But afaik not RfC-conform.

> technology appears to be too scarce at present to make a sensible

A big use-case of the trust model iii) is www.openvalidation.org. The 
OCSP-Responder there answers for 120 CAs with a certificate you have to 
trust locally.

A lot of large companies seem to like this idea, too. This way they can 
manage the trust a little bit (actually partly doing with OCSP what SCVP 
tries to establish now).

--
Florian Oelmaier
SyTrust S.A.

---

From: "Miguel Rodriguez" <[email-masked]>
Date: Fri, 4 Apr 2003 10:23:45 -0600

A few products (OCSP Clients) support all three models as follows:

i. Check the responder certificate is a CA certificate and to be the
issuer of the target certificate

ii. Check that the response responder certificate was issued by the CA
who issued the target certificate and that it has the ocsp signing key
usage

iii. Check that the responder certificate is specified as trusted
(locally). The client may have  a list of trusted responder certificates

Model (iii) also can arise when checking revocation for the OCSP
responder certificate. For this you have also 3 models:

1. the responder certificate is trusted for its lifetime (ocsp no-check
extension)
2. a CRL must be checked
3. the responder certificate is trusted according to some local policy
(which may include having a list of trusted responder certificates).

Finally, I agree with you that ii) should be the most common. 

Regards,

Miguel A Rodriguez
SeguriDATA
Mexico

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of [email-masked]
> Sent: Viernes, 04 de Abril de 2003 03:47 a.m.
> To: [email-masked]
> Subject: OCSP - Adoption of response models
> 
> 
> 
>

---

From: "Ambarish Malpani" <[email-masked]>
Date: Fri, 4 Apr 2003 22:35:47 -0800

Hi Florian,
    The model you have seen is compliant with the RFC. It is
basically an example of model (iii), where you explicitly
trust the root CA to validate all the certificates and allow
it to delegate that responsibity to the VA that is actually
responding.

Chris, to respond to your original question, (ii) and (iii)
are the two models that I have seen used to most. (ii) is
what people do who have simple PKIs - normally a single
CA or at most a 3 level hierarchy.

(iii) is used in more complicated situations, or in places
where you want a single entity to respond for all the CAs in
your system.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani                                         650.759.9045
Malpani Consulting Services                      [email-masked]
http://www.malpani.biz

> [mailto:[email-masked]]On Behalf Of Florian Oelmaier
> Sent: Friday, April 04, 2003 3:20 AM
> To: [email-masked]; [email-masked]
> Subject: Re: OCSP - Adoption of response models
> 
> 
>

---

From: "Ryan M. Hurst" <[email-masked]>
Date: Sat, 5 Apr 2003 09:12:54 -0800

I agree that what is being referred to as local trust  is valid within the RFC I think the crux of the matter is it implicit or explicit trust; e.g. the issuer is implicitly capable of issuing responses for the certificates it has issued, a VA is explicitly trusted to issue for a set of CAs (I suppose its reasonable for the set to be defined by a certificate chain).

I have seen implementations that have implicitly given the root of trust for the chain the authority to issue responses for the entire chain, I have always viewed this as a derivation since it extends the domain of control of the root to the certificates that its subordinates have issued (and their subordinates). 

Just consider cross-certification: company x's certificate was issued by ttp a, company x cross-certifies company b as such ttp a can revoke company b's certificates using OCSP.

The same problem set is introduced when the va delegated model is extended beyond one level.

I do think this is a legitimate problem for widespread OCSP deployment, but not the only one; most of the issues that come to mind are not standard related but implementation based:
Responder Trust
Responses should be as small as possible, certificates are big and need to be communicated numerous times, There should be a mechanism to tell the responder not to send certificates if it knows them, or a way for a responder to tell the client where to get them (ala AIA) instead of sending them each time.
In large PKIs vendors often use a single responder (cluster) to issue responses, why should they have to maintain separate certificates for all of them; it should be possible to define some implicit trust for the trust anchor to refer to where to get information about all of its certificates, and its issuers certificates. This is especially helpful since many issuers have revocation information available via OCSP but not all of the certificates have a AIA /w OCSP specified.
Most implementations only support a limited subset of the usefull trust models and there is no clear way to determin other than testing them.
Responder Identification
The RFC defines both a HTTP GET and POST method, but the AIA does not communicate which way the responder expects to be communicated with; This is particularly important since in practice it is possible to cache GETs and not POSTS.
Response Caching
Without caching it is not possible to deploy OCSP in a volume necessary to support ssl server certificate revocation checking for the internet.
For OCSP to scale there needs to be support for caching, most http proxies do not support post caching, most OCSP implementations do not support GET retrievals.
Most OCSP implementations do not set the http cache expiration headers so if OCSP responses were to be cached they would likely be cached indefinably causing failed validations.
Responder Load
Just like with CRLs responder load usually happens at a fixed time (nextUpdate) so issuers need to scope deployment so accommodate peeks vs. having load distributed. Servers should "shift" the nextUpdate to control this, and clients should intelligently pre-fetch information to help distribute the load.
OCSP allows for a single request to consist of many unrelated certIds, this is great for chain validation however most responders do not support this (or at least do it correctly).
OCSP allows for response pre-production this is important for a internet scale solution however most responders do not support this.
Responder Freshness
OCSP does not provide a mechanism for the client to request a real-time response, this makes deploying a system that serves cached responses most of the time and dynamic ones on demand not really viable.
Its important to know that when something was signed the certificate associated with that signature was not revoked, it is not normally to check the validity at the time of verification; that is if the data is time stamped and the signer included its own OCSP response. PKCS7/CMS allows for CRLs to be included for this reason however there is no way to include OCSP responses, Denis has done a informational RFC for historical signatures that has this concept in it but if all you want is a standard place to put OCSP in a PKCS7/CMS you are out of luck.
These are all solveable problems, they are just things that I think most implementations do not take these things into concern today.
Ryan M. Hurst
Program Manager
Windows Security
Microsoft Corporation

From: Ambarish Malpani
Sent: Fri 4/4/2003 10:35 PM
To: Florian Oelmaier; [email-masked]; [email-masked]
Subject: RE: OCSP - Adoption of response models

Hi Florian,

Regards,
Ambarish

---

From: "Liaquat Khan" <[email-masked]>
Date: Sun, 6 Apr 2003 19:41:29 +0100

Hi Chris

In our OCSP responder, we implement:
- model ii (most common in my opinion)
- model iii (i.e. where the VA is certified by a Root CA or some other CA)
- model iv (where the VA's keys are directly trusted by end-users, but is
not the CA)

I have seen model (i) implemented by some CA vendors, typically for
infrastructure certificates (rather than end-user certificates).  Although I
have not really seen "live" examples.

Our OCSP clients (e.g. ARP) support all four models, following an approach
similar to that described in Miguel's earlier email.

Regards,
LK

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: 04 April 2003 10:47
To: [email-masked]
Subject: OCSP - Adoption of response models

i.   Signed by the CA

Opinions appreciated

Chris

This  email  and  any  attachments  are confidential and intended for the
addressee
only.   If  you are not the named recipient, you must not use, disclose,
reproduce,
copy  or  distribute the contents of this communication.  If you have
received this
in error, please contact the sender and then delete this email from your
system.

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Sun, 06 Apr 2003 02:36:36 +0200

>Just like with CRLs responder load usually happens at a fixed time (nextUpdate) so issuers need to scope deployment so accommodate peeks vs. having load distributed. Servers should "shift" the nextU…
Are they really many clients that cache OSCP response until nextUpdate ?
OCSP just simply generates lot of load.
IMO large scale use can only be handled with a network of responders, 
not a single one.

>OCSP does not provide a mechanism for the client to request a real-time response, this makes deploying a system that serves cached responses most of the time and dynamic ones on demand not really vi…
This can be done by setting up clients so that will not use a nonce 
usually, getting a pre-produced response, and when they need a real time 
response, they'll use the nonce in the request.

---

From: "Ryan M. Hurst" <[email-masked]>
Date: Mon, 7 Apr 2003 08:19:06 -0700

From: Jean-Marc Desperrier
Sent: Sat 4/5/2003 4:36 PM
To: [email-masked]
Subject: Re: OCSP - Adoption of response models

[rmh] Well, I know of several but either way my statements were not necessarily based on what clients do today; instead they were intended to communicate what I beleive is necessary to scale the protocol to support ssl server revocation in "internet" volumes. It is cost pro-hibitive for a certificate issuer to operate enough OCSP responders to handle peek loads associated with every get to a the amazons and ebays of the worlds especialy considering that in many cases one issuer may be responsible for 60+% of the certificate issuence.

[rmh] I recognize that the protocol has a nonce, and the nonce could be interpreted as you say; additionally I have seen several implementations that do but with that being said the RFC does not describe behavior in this area as a result I have also seen many implementations thatbehave poorly when no monce is suppplied.