OCSP Trusted Responder

I have a question about OCSP Trusted Responders and how they are 
validated.  RFC 2560 defines a Trusted Responder as:

    -- a Trusted Responder whose public key is trusted by the requester

Is there any requirement that an implementation automatically trust a 
responder's public key if its certificate is directly issued by a root 
CA and the intermediate CA that issued the certificate being checked 
chains back to the same root CA?

It would seem that this case would still require some sort of additional 
local configuration to designate the responder's certificate as trusted.

Thanks,
Sean

_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix

Re: OCSP Trusted Responder

In my opinion, this does not fall into the 3 categories listed in 2560.

> -----Original Message-----
> From: pkix-bounces <at> ietf.org [mailto:pkix-bounces <at> ietf.org] On 
> Behalf Of Sean Mullan
> Sent: Monday, February 01, 2010 8:33 PM
> To: pkix <at> ietf.org
> Subject: [pkix] OCSP Trusted Responder
> 
> I have a question about OCSP Trusted Responders and how they 
> are validated.  RFC 2560 defines a Trusted Responder as:
> 
>     -- a Trusted Responder whose public key is trusted by the 
> requester
> 
> Is there any requirement that an implementation automatically 
> trust a responder's public key if its certificate is directly 
> issued by a root CA and the intermediate CA that issued the 
> certificate being checked chains back to the same root CA?
> 
> It would seem that this case would still require some sort of 
> additional local configuration to designate the responder's 
> certificate as trusted.
> 
> Thanks,
> Sean
> 
> 
> _______________________________________________
> pkix mailing list

Re: OCSP Trusted Responder

This is something I've thought about proposing in the past (i.e., issuing
responder certs from a root rather than the issuing sub-CA) but never got
around to putting down on paper.  It strikes me as workable a middle ground
for large PKIs.

-- Tim

>-----Original Message-----
>From: pkix-bounces <at> ietf.org [mailto:pkix-bounces <at> ietf.org] On Behalf Of
>Santosh Chokhani
>Sent: Monday, February 01, 2010 8:19 PM
>To: Sean Mullan; pkix <at> ietf.org
>Subject: Re: [pkix] OCSP Trusted Responder
>
>In my opinion, this does not fall into the 3 categories listed in 2560.
>
>> -----Original Message-----
>> From: pkix-bounces <at> ietf.org [mailto:pkix-bounces <at> ietf.org] On
>> Behalf Of Sean Mullan
>> Sent: Monday, February 01, 2010 8:33 PM
>> To: pkix <at> ietf.org
>> Subject: [pkix] OCSP Trusted Responder
>>
>> I have a question about OCSP Trusted Responders and how they
>> are validated.  RFC 2560 defines a Trusted Responder as:
>>
>>     -- a Trusted Responder whose public key is trusted by the
>> requester
>>
>> Is there any requirement that an implementation automatically

Re: OCSP Trusted Responder

Tim,

This could cause interoperability problems since not all OCSP clients will
accept this trust model.

In addition, this model is not useful for cross-certified environments.  For
cross-certified environments, delegated model works.

> -----Original Message-----
> From: Miller, Timothy J. [mailto:tmiller <at> mitre.org] 
> Sent: Tuesday, February 02, 2010 9:56 AM
> To: Santosh Chokhani; Sean Mullan; pkix <at> ietf.org
> Subject: RE: [pkix] OCSP Trusted Responder
> 
> This is something I've thought about proposing in the past 
> (i.e., issuing responder certs from a root rather than the 
> issuing sub-CA) but never got around to putting down on 
> paper.  It strikes me as workable a middle ground for large PKIs.
> 
> -- Tim
> 
> 
> >-----Original Message-----
> >From: pkix-bounces <at> ietf.org [mailto:pkix-bounces <at> ietf.org] 
> On Behalf Of 
> >Santosh Chokhani
> >Sent: Monday, February 01, 2010 8:19 PM
> >To: Sean Mullan; pkix <at> ietf.org
> >Subject: Re: [pkix] OCSP Trusted Responder
> >

Re: OCSP Trusted Responder

At 8:33 PM -0500 2/1/10, Sean Mullan wrote:
>I have a question about OCSP Trusted Responders and how they are 
>validated.  RFC 2560 defines a Trusted Responder as:
>
>    -- a Trusted Responder whose public key is trusted by the requester
>
>Is there any requirement that an implementation automatically trust 
>a responder's public key if its certificate is directly issued by a 
>root CA and the intermediate CA that issued the certificate being 
>checked chains back to the same root CA?

no.

>
>It would seem that this case would still require some sort of 
>additional local configuration to designate the responder's 
>certificate as trusted.

yes, it would.

Steve
_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix

Re: OCSP Trusted Responder

Not all OCSP clients accept the trust models *currently* in the RFC, so I
fail to see the significance of that objection.  :)

The main justification I see for a root-issued responder cert is revocation
of responder certs.  Responder certs under the CA-delegated model can't be
revoked for obvious reasons, and the Trusted Responder model either pushes
the same problem elsewhere or ends you up managing self-signed
responders--with all the pain and suffering that implies.  Under the
CA-signed model the responder can be revoked, but how many PKIs burden their
CAs with OCSP duties?

With root-issued responders, we can use the root CRL to revoke responder
certs which in turn allows an infrastructure to issue long-lived OCSP keys
with a lot less risk (and without resorting to hacky renewal techniques).
IMHO ocsp-nocheck is an ugly hack.

This would be more valuable the larger the PKI and the larger the pool of
relying parties grows.

FWIW, I see no reason why root-issued wouldn't be as functional under
cross-certification as CA-delegated is.

-- Tim

>-----Original Message-----
>From: Santosh Chokhani [mailto:SChokhani <at> cygnacom.com]
>Sent: Tuesday, February 02, 2010 12:44 PM
>To: Miller, Timothy J.; Sean Mullan; pkix <at> ietf.org
>Subject: RE: [pkix] OCSP Trusted Responder
>

Re: âґ` :Re: OCSP Trusted Responder

At 4:39 PM +0800 2/3/10, zhouzhipeng 54906 wrote:
>Dear Stephen,
>Can U pls share me some words of your first reponse below:
>
>>  >Is there any requirement that an implementation automatically
>>  trust
>>  >a responder's public key if its certificate is directly issued by
>>  a
>>  >root CA and the intermediate CA that issued the certificate being
>>  >checked chains back to the same root CA?
>>
>>  no.
>
>I am a little confused why not trust the public key published in the 
>certificates.
>Thanks very much.
>Zhipeng

Only the CA that issued the cert in question is authorized to specify an
OCSP responder for the certs in question.

The question was whether there was a requirement for a relying party 
to trust a "root" CA  issue a cert for an OCSP responder.  The answer 
is no, there is no such requirement.

Steve
_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix

Re: OCSP Trusted Responder

See in-line.

> -----Original Message-----
> From: Miller, Timothy J. [mailto:tmiller <at> mitre.org]
> Sent: Tuesday, February 02, 2010 3:32 PM
> To: Santosh Chokhani; Sean Mullan; pkix <at> ietf.org
> Subject: RE: [pkix] OCSP Trusted Responder
>
> Not all OCSP clients accept the trust models *currently* in
> the RFC, so I fail to see the significance of that objection.  :)
Standards are about interoperability and hence doing things outside the 
standard is
going to cause interoperability problems.
>
> The main justification I see for a root-issued responder cert
> is revocation of responder certs.  Responder certs under the
> CA-delegated model can't be revoked for obvious reasons, and
> the Trusted Responder model either pushes the same problem
> elsewhere or ends you up managing self-signed
> responders--with all the pain and suffering that implies.
> Under the CA-signed model the responder can be revoked, but
> how many PKIs burden their CAs with OCSP duties?
>
> With root-issued responders, we can use the root CRL to
> revoke responder certs which in turn allows an infrastructure
> to issue long-lived OCSP keys with a lot less risk (and
> without resorting to hacky renewal techniques).
> IMHO ocsp-nocheck is an ugly hack.
You do not need no-check.  You can use partitioned CRL.  Most applications
support it.

Re: âÒ'` :Re: OCSP Trusted Responder

>Only the CA that issued the cert in question is authorized to specify an
>OCSP responder for the certs in question.

Not true; the Trusted Responder model allows the relying party to trust an
*arbitrary* cert to sign responses for *any* issuing CA.

>The question was whether there was a requirement for a relying party
>to trust a "root" CA  issue a cert for an OCSP responder.  The answer
>is no, there is no such requirement.

The follow-on question is: Should it?  I think there are advantages to a
Root-delegated model (detailed in other postings).

-- Tim

_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix

Re: OCSP Trusted Responder

>Standards are about interoperability and hence doing things outside the
>standard is going to cause interoperability problems.

In case you hadn't noticed, I'm not asking to go outside the standard, I'm
talking about enhancing the standard.  Not the same thing at all. 

>In cross certified environments, a root can be simply another CA in the
>trust chain and hence special logic for root will not apply to the relying
>parties in cross certified domain.

It's not so much 'special logic for root' as it is 'special logic for
ancestor' which *would* apply in a cross-certified environment.  Even in the
cross-cert case a PKI still a tree-like structure, and it seems to me to be
conceptually simple to permit an ancestor to sign OCSP responses for its
descendents.  We can use namespace constraints to prohibit OCSP signing
across the PKI boundaries. 

-- Tim

_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix