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

From: "Florian Oelmaier" <[email-masked]>
Date: Fri, 12 Sep 2003 02:20:40 +0200

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: "Ryan M. Hurst" <[email-masked]>
Date: Thu, 11 Sep 2003 16:56:40 -0700

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,

Florian Oelmaier:
> 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

You answered:

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

> 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

>    containing a unique value for extendedKeyUsage in the OCSP signer's
> > [mailto:[email-masked]] On Behalf Of Florian Oelmaier
> > > When the OCSP can answer for several CAs, I guess that attribute
> > 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). 
> > 
> > OCSP-client vendors will not be surprised if you ask them to 
> > include support into their software :)
> > 
> > --
> > Florian Oelmaier
> > SyTrust
> > 
> 
>