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

From: "Ryan M. Hurst" <[email-masked]>
Date: Thu, 11 Sep 2003 17:27:28 -0700

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

Ryan
-----Original Message-----
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 :)

> > > 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.

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

> -----Original Message-----
> 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
> -----Original Message-----
> 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
> 
> > -----Original Message-----
> > 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.
> > 
> > 
> > 
> > > -----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: "Florian Oelmaier" <[email-masked]>
Date: Fri, 12 Sep 2003 02:56:41 +0200

> 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.

> 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! 
> 
> - 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 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.
> > 
> > >     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
> > > 
> > > 
> > >    The key that signs a certificate's status information 
> need not be 
> > > the
> > > > Subject: Re: [OCSP] are several requests for different 
> CAs at once 
> > > > valid ?
> > > > 
> > > > 
> > > >