Subject: RE: [OCSP] are several requests for different CAs at once valid ?

From: "Liaquat Khan" <[email-masked]>
Date: Thu, 11 Sep 2003 10:13:48 +0100

I agree this is common.  Ascertia's OCSP responder behaves in a similar
way.  We have one key pair for responding to relying parties, but the
public key can be certified by each CA that the responder is responding
for.  

More than one certificate can then be attached to responses being sent
out. 

Regards,
LK

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Ambarish Malpani
Sent: 11 September 2003 06:31
To: Julien Stern; [email-masked]
Subject: RE: [OCSP] are several requests for different CAs at once valid
?

Hi Julian,
    Responses inline of the behavior of the Valicert responder.

Regards,
Ambarish

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Julien Stern
> Sent: Wednesday, September 10, 2003 9:25 AM
> To: [email-masked]
> Subject: [OCSP] are several requests for different CAs at once valid ?
> 
> 
> 
> Hi all,
> 
> I was wondering if it was ok to send an OSCPRequest containing
> requests for several certificates issued by different CAs ?

This works fine. The server responds for all certs in the request.
For servers it doesn't have information for, it returns unknown.

> 
> In case this is ok, more specifically, when trying to figure out
whether
> the signer should be trusted, OCSP defines three models:
> 
> i)   Directly signed by the CA
> ii)  Signed by a specific certificate with the correct extension
directly
>      issued by the CA
> iii) Signed by a certificate which is directly trusted by the user
> 
> My first question obviously does not make sense in case i) as there
> is only one signature per response. It is simple in case iii) as there
> is no relationship any more between the certs to be checked and the
OCSP
> responder.
> 
> A more problematic case is ii). One could imagine that several
> certificates with the "OCSP delegation extension" are delivered to
> an OSCP responder by different CAs. In that case, these certificates
> should either have the same name, or the same public key, depending
> on how the OSCP responder chooses to identify itself. It this setting
> valid ? SHOULD/MUST it be supported ?

The Valicert responder could be configured to respond by name/key or
to respond by key only if the names of all the certs issued to
it by various CAs didn't match.

> 
> 
> And while I'm at it, I would also be interested by knowing what the
> existing implementations return in the optional "certs" field of the
> BasicOCSPResponse depending on the aforementionned trust model, if
> anyone has a clue ...

The responder's cert(s). Could have more than one, if you have
delegated certs from multiple CAs.

> Thanks a lot.
> --
> Julien Stern

---

From: "Florian Oelmaier" <[email-masked]>
Date: 11 Sep 2003 09:25:40 -0000

Hello Julien,

please find the answers regarding the SyTrust CertControl OCSP Responder inline. Just to add: I just checked www.openvalidation.org. We get a lot of testing requests there (around 20.000 per month) and more than 99% percent are single certificate requests.

> requests for several certificates issued by different CAs ?

SyTrust CertControl supports that.  I have to admit, that it may well be that early versions of CertControl (2 years ago) had problems with multi-cert requests. But that was long ago :)

But note: there are some configurations where it may not possible for CertControl to answer for all certs in your request. For example when CertControl operates as an OCSP-Proxy but is configured to relay the answer of the "original" proxy unaltered. Given that you ask for certificates that get forwarded to different OCSP-Responders, it is not possible for CertControl to consolidate the responses in "relaying-mode". You would have what we call "hiding mode" for that, where CertControl constructs its own answer based on the information it got.

So you should be aware that the response may contain less information than requested.

> valid ? SHOULD/MUST it be supported ?

SyTrust CertControl currently operates only by name. So CertControl would require you to use the same DN for all the certificates. I see your point, identification by key will be added soon.

> BasicOCSPResponse depending on the aforementionned trust model, if

With CertControl this is not an implementation but an configuration issue. We know some CertControl installation that choose not to deliver any certificate at all, some others append the whole certificate chain. As stated by some other, the most common configuration is that the OCSP-Responder append its own certificate. But dont rely on it in your client :)

-- 
Florian Oelmaier
SyTrust

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 12 Sep 2003 00:03:11 +1200

"Florian Oelmaier" <[email-masked]> writes:

>SyTrust CertControl supports that.  I have to admit, that it may well be that
>early versions of CertControl (2 years ago) had problems with multi-cert
>requests. But that was long ago :)

It looks like things have changed somewhat since I last checked responders,
which would have been around 2000 or 2001 some time.  Certainly back then the
situation was pretty dire, going from source code comments I made at the time
(invalid CA certs, responder gets the OCSP ID calculation wrong, expired CA
cert, hasn't been seen operating for six months, another one with IDs wrong,
etc etc).  Maybe people could post indications of responder URLs and sample
certs that could be used for testing...

Peter.

---

From: "Florian Oelmaier" <[email-masked]>
Date: 11 Sep 2003 12:52:12 -0000

> Maybe people could post indications of responder URLs and sample

http://www.openvalidation.org/useocspservicenew.htm

New design pending :)

I will open an interop-test section on openvalidation.org and will consolidate all the URLs posted here to the site. This way we can get a directory of Responder-Tests. 

-- 
Florian Oelmaier
SyTrust

---

From: "Ryan M. Hurst" <[email-masked]>
Date: Thu, 11 Sep 2003 12:50:33 -0700

I have to agree that this is certainly a common customer request; I have
always been leery of implementing such behavior however. The main reason
is that because this behavior would extend the scope of influence of an
issuing CA from having control over the identity of the sub ca to
include direct control over the certificates issued by the sub CA. 

As for the concept of a single request for the status of many
certificates issued by different CAs this can be accomplished using the
defined trust models outlined in other threads. 

For example if a client supports responder identification by key and the
responder has a single key pair certified by each CA he responds for it
is possible to put those certificates in the responder certificate bag
and have a client be able to validate that response as a delegated
response in each case.

When you start to think about a single request representing a query for
multiple potentially un-related CAs you also need to start thinking
about what if the CA has the status to say 2 of 5? Clients should be
able to support this concept, in this case (assuming the client has a
locally configured list of responders like in Mozilla) the client could
try the next responder in his list for 3-5 and work through his
responder list until he found the answer he wanted.

It is also possible with direct trust to accomplish this, but this is
very straight forward.

It would be nice if the OCSP RFC could have a son-of that was clearer on
these concepts, of all the implementations I have worked on in the past
several years these are some of the more common questions people have.

Ryan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Florian Oelmaier
Sent: Thursday, September 11, 2003 4:54 AM
To: Julien Stern
Cc: [email-masked]
Subject: Re: [OCSP] are several requests for different CAs at once valid
?

> When the OCSP can answer for several CAs, I guess that attribute
> certificates would be more appropriate than having different
> certificates with the same public key signed by several CAs,
> but that would clearly make the clients and the servers much more
> complex, so I'm fairly happy with the way it is ...

Perhaps one thing to add here: It seems to be a fairly common
requirement that an OCSP-client is configured to trust OCSP-responses
from a responder delegated by a CA that is higher in the hierarchy than
the CA in question.

So a company having some Sub-CAs and one OCSP-Responder for all of them
would issue a certificate including OCSP-delegation using the Root-CA.
Now the clients trust this OCSP-Responder for certificates issued by the
Root-CA or any of its Sub-CAs (or Sub-Sub-CAs). 

This seems to be a popular configuration. This means the OCSP-client
vendors will not be surprised if you ask them to include support into
their software :)

-- 
Florian Oelmaier
SyTrust

---

From: "Ryan M. Hurst" <[email-masked]>
Date: Thu, 11 Sep 2003 18:57:09 -0700

I gotcha now, this is something we called "VA Delegation" at ValiCert ;)
I don't think any of the RFC documented trust models are relevant to
this though.

On a side note, we have recently implemented an OCSP client for Windows
and the new TLS extensions that allow a server to provide a cached OCSP
response to its client. Some things we did that would be interesting to
other folks would be:
	* Only HTTP is supported as a transport (no HTTPS)
	* HTTP GETs are performed in the first attempt with a fall back
to 
	  HTTP POST if the server connects but doesn't support GET.
	* Requests do not contain a nonce, and a nonce's in the
Responses are
	  ignored.
	* Requests only consist of a single CertID, although responses
with
	  multiple CertIDs are used
	* Responses with critical extensions are treated as errors, all
other
	  extensions are ignored
	* Only CA signed or CA delegated responses are trusted
	* Request signing is not supported

We have interoped with several implementations, including yours
successfully; full attendees going to the MSFT Profesional Developers
Conference will get a build of Windows including this capabilities in
it.

If any of you have also implemented the TLS extensions, let us know as I
would like to interop with some one else on this.

Ryan

-----Original Message-----
From: Florian Oelmaier [mailto:[email-masked]] 
Sent: Thursday, September 11, 2003 5:57 PM
To: Ryan M. Hurst; 'Ambarish Malpani'; 'Julien Stern'
Cc: [email-masked]
Subject: RE: [OCSP] are several requests for different CAs at once valid
?

> I am not sure I understand your "CA List" model, are you 
> saying "Here is a list of responders that can respond for 
> this CA" if so then this just sounds like a flexible version of iii

I am saying: "Here are some CAs, whose delegated responders are
explicitly trusted [in this trust setting]". 

The Use-Case is something like: A company has some Subs under a
corporate root, which delegates trust to all corporate OCSP reponders.
My clients shall trust all these responders. If I add another responder
(e.g. due to loadbalancing issues), I want this responder to be trusted
without rolling out its certificate.

The configuration that answers the question "How to determine a trusted
OCSP-Responder?" is called trust setting in our client. The question
"Which trust setting is used for a certain certificate?" can be
configured through a set of filters. For example I can use another trust
setting for Digital Signature Cert as I do for Authentication or
Encryption Cert. I could also use different trust settings based on the
cert issuer.

BTW: All these things are done to emulate SCVP with OCSP. Now that SCVP
is nearly finished, I expect the people using these configurations to
adopt SCVP rather quickly.

> From: Florian Oelmaier [mailto:[email-masked]] 
> Sent: Thursday, September 11, 2003 5:21 PM
> To: Ryan M. Hurst; 'Ambarish Malpani'; 'Julien Stern'
> Cc: [email-masked]
> Subject: RE: [OCSP] are several requests for different CAs at 
> once valid ?
> 
> 
> Hello Ryan,
> 
> > [rmh] My concern is the implicit trust of the root's va
> > not the explicit configuration (III). Although I dislike client 
> > side configuration due to manageability issues the use of direct
> > trust (III) to accomplish this is kosher in my book :)
> 
> > > > requirement that an OCSP-client is configured to trust 
> > > > OCSP-responses from a responder delegated by a CA that is higher
> > > > in the hierarchy than the CA in question.
> 
> I agree completely with you. By no way I wanted to encourage 
> people to see that as an implicit way of operation. Maybe i 
> was not clear enough on that! 
> 
> In our OCSP-Client you may configure any combination of three modes:
> - implicit trust (models i and ii)
> - list of explicitely trusted responders (model iii)
> - CA list: all OCSP-Responders having a OCSP-delegation 
> certificate of any root-CA in that list are trusted (model iii ???)
> 
> These trust settings may be configured differently for 
> different set of certificates.
> 
> I also know that our OCSP client is not the only client 
> working that way
> :)
> 
> Sorry for the confusion,
> 
> -- 
> Florian Oelmaier
> SyTrust
> 
> 
> > From: Ryan M. Hurst [mailto:[email-masked]]
> > Sent: Friday, September 12, 2003 1:57 AM
> > To: Florian Oelmaier; Ambarish Malpani; Julien Stern
> > Cc: [email-masked]
> > Subject: RE: [OCSP] are several requests for different CAs at 
> > once valid ?
> > 
> > 
> > In-line
> > From: Florian Oelmaier [mailto:[email-masked]]
> > Sent: Thursday, September 11, 2003 4:45 PM
> > To: 'Ambarish Malpani'; 'Julien Stern'; Ryan M. Hurst
> > Cc: [email-masked]
> > Subject: RE: [OCSP] are several requests for different CAs at 
> > once valid ?
> > 
> > Hello Ambarish,
> > 
> > last time I brought this model to the attention of the list I said:
> > 
> > Florian Oelmaier:
> > > 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.
> > 
> > You answered:
> > 
> > > 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.
> > 
> > Educated by your comment, I changed my mind and told people
> > that this mode of operation IS RfC conform using the model 
> > (iii). Should I change my mind again? Is it conform or is it not?
> > 
> > BTW: I never said that I think this is a good idea - I just
> > stated that this seems to be a fairly popular idea. And - 
> > Peter coming into my mind
> > - not always do the people out there care if a special 
> > sophisticated configuration is RfC-conform or not. 
> > 
> > Ryan wrote:
> > > I have to agree that this is certainly a common customer 
> request; I 
> > > have always been leery of implementing such behavior however. The 
> > > main reason is that because this behavior would extend 
> the scope of 
> > > influence of an issuing CA from having control over the 
> identity of 
> > > the sub ca to include direct control over the 
> certificates issued by 
> > > the sub CA.
> > 
> > I see that point - but there are configurations out there
> > where such deliberations are not of concern. Sometimes this 
> > direct control of the root CA is what the customer actually 
> > wants. Often Sub-CAs are only used to overcome certain 
> > compatibility problems. [rmh] My concern is the implicit 
> > trust of the root's va not the explicit configuration (III). 
> > Although I dislike client side configuration due to 
> > manageability issues the use of direct trust (III) to 
> > accomplish this is kosher in my book :)
> > 
> > Again: I am not promoting this model. I do not promote an
> > inclusion into the RfC nor anything else. I am just saying 
> > people are using it out there. Thus our software supports it. 
> > Before the above mention discussion there was a disclaimer 
> > that this is not RfC conform - after Ambarishs comments in 
> > April this disclaimer was removed :) Perhaps I need to put it 
> > in again.
> > 
> > --
> > Florian Oelmaier
> > SyTrust
> > 
> > > From: Ambarish Malpani [mailto:[email-masked]]
> > > Sent: Friday, September 12, 2003 12:06 AM
> > > To: 'Florian Oelmaier'; 'Julien Stern'
> > > Cc: [email-masked]
> > > Subject: RE: [OCSP] are several requests for different CAs at
> > > once valid ?
> > > 
> > > 
> > > 
> > > Hi Florian,
> > >     This is *not* allowed by RFC 2560. For CA delegated trust, it 
> > > specifically says that the CA needs to *directly* issue  the 
> > > delegation certificate to the responder.
> > > 
> > > 
> > > Regards,
> > > Ambarish
> > > 
> > > 
> > > 2.6  OCSP Signature Authority Delegation
> > > 
> > >    The key that signs a certificate's status information 
> need not be 
> > > the
> > >    same key that signed the certificate. A certificate's issuer
> > >    explicitly delegates OCSP signing authority by issuing a
> > > certificate
> > >    containing a unique value for extendedKeyUsage in the 
> > OCSP signer's
> > >    certificate. This certificate MUST be issued directly to the
> > >    responder by the cognizant CA.
> > > 
> > > 
> > > 
> > > > [mailto:[email-masked]] On Behalf Of 
> > Florian Oelmaier
> > > > Subject: Re: [OCSP] are several requests for different 
> CAs at once 
> > > > valid ?
> > > > 
> > > > 
> > > > 
> > > > > certificates with the same public key signed by several
> > > > CAs, but that
> > > > > would clearly make the clients and the servers much more
> > > > complex, so
> > > > requirement that an OCSP-client is configured to trust 
> > > > OCSP-responses from a responder delegated by a CA that is 
> > higher in
> > > > the hierarchy than the CA in question.
> > > > 
> > > > So a company having some Sub-CAs and one OCSP-Responder
> > for all of
> > > > them would issue a certificate including OCSP-delegation
> > using the
> > > > Root-CA. Now the clients trust this OCSP-Responder for
> > certificates
> > > > issued by the Root-CA or any of its Sub-CAs (or Sub-Sub-CAs).
> > > > 
> > > > vendors will not be surprised if you ask them to include support
> > > > into their software :)
> > > > 
> > > > --
> > > > Florian Oelmaier
> > > > SyTrust
> > > > 
> > > 
> > > 
> > 
> > 
> > 
> > 
> 
> 
> 
>

---

From: "Ryan M. Hurst" <[email-masked]>
Date: Fri, 12 Sep 2003 10:47:45 -0700

Vadin

My definition of dynamic signing in the context of OCSP is "Signing of
responses on demand" e.g. generating a unique response and signature for
each request.

As for the "expected timeframe" that is a policy decision by the issuer
of the responses.

As for "How the client can be convinced the server supplied a fresh
enough response" the responses contain a ProducedAt value which
indicates when the response was made, this value can be used by the
client to determine if the "freshness" is adequate for their local
policy.

Ryan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Vadim Fedukovich
Sent: Friday, September 12, 2003 8:16 AM
To: [email-masked]
Subject: Re: [OCSP] are several requests for different CAs at once valid
?

Dear Ryan,

should one read it as a definition:
dynamic signing is a set of pre-produced (or batch-generated) responses?

What is expected timeframe between a revocation request submitted
by a private key owner and availability of an updated OCSP response?

How a client can be convinced the server supplied a fresh enough
response?
..the reason for a client to check the current status is to get some
profs
instead of just trusting the server

thank you,
Vadim

On Fri, Sep 12, 2003 at 07:47:21AM -0700, Ryan M. Hurst wrote:
> Vadim - Traditionally OCSP responders generate and sign responses
on-demand (dynamically), this requires the responders to scale their
infrastructure to handle very high peak volumes. Since many clients,
ours included cache responses this results in most traffic happening at
a fixed time the use of  pre-produced (or batch generated responses)
allows for a number of intersting deployment scenarios leveraging
proxies which enable high volume deployments of OCSP.
> 
> To be clear our client doesnt require this type of deployment, we just
implemented it in such a way to allow for it as our goal is to be able
to support internet scale revocation checking with our customers.
> 
> Ryan
> 
> 
> 
> From: Vadim Fedukovich
> Sent: Fri 9/12/2003 5:33 AM
> To: [email-masked]
> Subject: Re: [OCSP] are several requests for different CAs at once
valid ?
> 
> 
> On Thu, Sep 11, 2003 at 08:57:58PM -0700, Ryan M. Hurst wrote:
> > Done in order to support pre-produced OCSP responses, our goal is to
create solution capable of being deployed in distributed enviroments and
in volumes in-practical to support dynamic signing. This is also why we
default to GET, most HTTP proxies do not support caching of POSTs.
> > 
> > Ryan
> > 
> 
> Dear Ryan,
> 
> what exactly is dynamic signing?
> 
> Vadim
> 
> > 
> > 
> > From: Peter Gutmann
> > Sent: Thu 9/11/2003 8:00 PM
> > To: [email-masked]; [email-masked];
[email-masked]; [email-masked]
> > Cc: [email-masked]
> > Subject: RE: [OCSP] are several requests for different CAs at once
valid ?
> > 
> > 
> > "Ryan M. Hurst" <[email-masked]> writes:
> > 
> > >Requests do not contain a nonce, and a nonce's in the Responses are
ignored.
> > 
> > Done in order to make replay attacks feasible?
> > 
> > Peter.

---

From: "Florian Oelmaier" <[email-masked]>
Date: 15 Sep 2003 14:28:14 -0000

> My code treats a nonceless response as pretty much worthless (it could be > a replay, there's no way to tell) and rejects it.  I've heard from a 
> few other vendors out there, and there's a mixture of implementations 
> rejecting nonceless messages as insecure, and "performance-tuned" 
> implementations deliberately sending them to make replays possible.

Our client is configurable. The standard is to issue a warning ("no replay protection"), but it can be configured to reject or accept it. On the other hand our client always includes a nonce into his requests (Why not? Even if the responder cannot answer it due to preproduced responses, I do not loose anything by asking for one - and on the client a nonce has nothing to do with performance).

> [...]  As a side-benefit, you can advertise your product as a 
> high-performance OCSP responder...

LOL. We do that :) And in the standard config our responder always uses fresh responses and always! includes a nonce into it. 

Just to clarify for the casual reader: including a nonce is not a performance issue by itself. If one wants to include a nonce, it is not possible to use pre-produced responses anymore.

-- 
Florian Oelmaier
SyTrust

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 16 Sep 2003 10:01:56 +1200

"Ryan M. Hurst" <[email-masked]> writes:

>More sillyness, The response has a thisUpdate, nextUpdate and ProducedAt;
>these values are adequare for communicating the freshness necessary to
>comminicate publication policy to the user.

That assumes perfectly synchronised clocks, which has been known for at least
20 years to be a weak point in security protocols, because now you're
including something that most users don't regard as security-relevant in your
TCB.  I've seen machines with clocks that were out by decades, and the users
didn't notice (see my paper at Usenix Security '02 on common security
pitfalls).  PCs with clocks that are out by hours or tens of minutes are
extremely common... hmm, to save me re-typing a pile of stuff, see the design
details for RTCS for more on this.  In fact some of the issues raised during
this debate have been almost a checklist of the design requirements for RTCS
(and yes, I do agree with the people who have pointed out that the only way to
get OCSP to scale in any useful way is to pre-generate responses, and by
extension allow for replay attacks :-).

Peter.

---

From: "Florian Oelmaier" <[email-masked]>
Date: 17 Sep 2003 13:07:56 -0000

The text below was meant as a proposal to change the RfC and NOT as a hint for an OCSP-client developer!

Sorry for not being clear on that one, Peter.

On Thu, 18 Sep 2003 01:01:00 +1200, [email-masked] (Peter Gutmann) wrote :

> >If we want the OCSP responder to know beforehand, if the client will 
> >accept a pre-produced response or not, add a CRITICAL flag to the
> >extension. This way the client can indicate in the request if it is 
> > willing to accept a response without nonce.
> 
> Uhh, except that the RFC says the critical flag can't be set for this.
> 
> Peter.
>

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 18 Sep 2003 01:01:00 +1200

"Florian Oelmaier" <[email-masked]> writes:

>If we want the OCSP responder to know beforehand, if the client will accept a
>pre-produced response or not, add a CRITICAL flag to the extension. This way
>the client can indicate in the request if it is willing to accept a response
>without nonce.

Peter.