Subject: [pkix] OCSP Trusted Responder

From: Sean Mullan <[email-masked]>
Date: Mon, 01 Feb 2010 20:33:26 -0500

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

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 1 Feb 2010 21:18:33 -0500

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Sean Mullan
> Sent: Monday, February 01, 2010 8:33 PM
> To: [email-masked]
> 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:
> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 2 Feb 2010 09:56:01 -0500

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

>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Santosh Chokhani
>Sent: Monday, February 01, 2010 8:19 PM
>To: Sean Mullan; [email-masked]
>Subject: Re: [pkix] OCSP Trusted Responder
>

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 2 Feb 2010 13:44:25 -0500

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.

> From: Miller, Timothy J. [mailto:[email-masked]] 
> Sent: Tuesday, February 02, 2010 9:56 AM
> To: Santosh Chokhani; Sean Mullan; [email-masked]
> 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
> 
> 
> >> From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> >> Of Sean Mullan
> >> 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?
> >>

---

From: Stephen Kent <[email-masked]>
Date: Tue, 2 Feb 2010 14:15:45 -0500

At 8:33 PM -0500 2/1/10, Sean Mullan wrote:
>Is there any requirement that an implementation automatically trust 
>a responder's public key if its certificate is directly issued by a 

no.

>additional local configuration to designate the responder's 

yes, it would.

Steve

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 2 Feb 2010 15:32:27 -0500

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

>From: Santosh Chokhani [mailto:[email-masked]]
>Sent: Tuesday, February 02, 2010 12:44 PM
>To: Miller, Timothy J.; Sean Mullan; [email-masked]
>> On Behalf Of

---

From: Stephen Kent <[email-masked]>
Date: Wed, 3 Feb 2010 18:48:44 -0500

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:
>
>>  trust
>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

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 3 Feb 2010 19:14:16 -0500

See in-line.

> Sent: Tuesday, February 02, 2010 3:32 PM
> 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).
You do not need no-check.  You can use partitioned CRL.  Most applications
support it.

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

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 4 Feb 2010 10:34:42 -0500

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

>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

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 4 Feb 2010 10:48:45 -0500

>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

---

From: Stephen Kent <[email-masked]>
Date: Thu, 4 Feb 2010 12:51:43 -0500

At 3:29 PM +0800 2/4/10, zhouzhipeng 54906 wrote:
>But "root" meanings the certifate issued by the root CA should be 
>accepted since the public key of root CA is accepted.
>Is that correct.
>Thanks.
>Zhipeng

No, that is not correct. The fact that a CA is designated as a "root" 
(technically, a Trust Anchor) does NOT imply that it is authorized to 
revoke certs issued by CAs that are verified via a path to that 
"root."

Let me try to give an example to see if that helps.

CA1 -> CA2 -> CA3 -> EE

In this example, CA1 issues a (CA) cert to CA2, which issues a (CA) cert to CA3
which issues end entity (EE) certs to a set of users.

The basic CRL model does NOT allow CA1 or CA2 to revoke any of the E 
certs issued by CA3. (See RFC 5280, page 48.)

Indirect CRLs allow a CA to explicitly designate another entity to 
manage revocation for that CA, but note that 5280 does not require 
support for indirect CRLs. Note also that a CA may designate an 
entity as an OCSP server, by issuing a cert to that entity, with an 
appropriate EKU value.

If CA2 or CA3 want to have CA1 manage an OCSP server for their certs, 
then they can issue certs that contain an AIA extension  with the 
OCSP access method OID, and a URI for an OCSP responder operated by 
CA1, but these CAs would still need to issue a cert to that responder 
(operated by CA1) OR the RPs would have to be locally configured with 
CA1 as an explicitly trusted OSCP responder.

Note also that OCSP cites three cases of authorized OCSP responders:

    -- the CA who issued the certificate in question
    -- a Trusted Responder whose public key is trusted by the requester
    -- a CA Designated Responder (Authorized Responder) who holds a
       specially marked certificate issued directly by the CA, indicating
       that the responder may issue OCSP responses for that C

The case you are asking about, i.e., a "root" CA is NOT one of those listed.

I hope this answers your question.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 4 Feb 2010 13:05:53 -0500

>*arbitrary* cert to sign responses for *any* issuing CA.

True, but my response to the context in which the question was posed, 
which asked if a root CA was automatically authorized to revoke certs 
for CAs further down the path.

>Root-delegated model (detailed in other postings).

I've read you arguments and did not find them persuasive.

Steve

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 4 Feb 2010 19:19:27 -0500

See in-line. 

The general question is do we need another tool here given that existing
model scales well two different ways.

> Sent: Thursday, February 04, 2010 10:49 AM
> 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. 
Need to address backward compatibility.  Need to bring client vendors to
agree.

> >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. 
So this is not root, but saying any ancestor in the chain can be issuer
of a Responder certificate.  Need to address backward compatibility.
Need to bring client vendors to agree.  It also seems to change the
trust model.  The existing mechanisms address the concerns you might
have.

---

From: zhipeng zhou <[email-masked]>
Date: Mon, 08 Feb 2010 17:29:17 +0800

Thanks very much, Stephen.
May I further raise a question: if CA2 revokes CA3, may the E certs issued by CA3 be revoked either.
Thanks.
Zhipeng 

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Friday, February 05, 2010 1:52 AM
To: zhouzhipeng 54906
Cc: [email-masked]
Subject: Re: âÒ‘` :Re: ???` :Re: [pkix] OCSP Trusted Responder

No, that is not correct. The fact that a CA is designated as a "root" 
(technically, a Trust Anchor) does NOT imply that it is authorized to revoke certs issued by CAs that are verified via a path to that "root."

CA1 -> CA2 -> CA3 -> EE

In this example, CA1 issues a (CA) cert to CA2, which issues a (CA) cert to CA3 which issues end entity (EE) certs to a set of users.

The basic CRL model does NOT allow CA1 or CA2 to revoke any of the E certs issued by CA3. (See RFC 5280, page 48.)

Indirect CRLs allow a CA to explicitly designate another entity to manage revocation for that CA, but note that 5280 does not require support for indirect CRLs. Note also that a CA may designate an entity as an OCSP server, by issuing a cert to that entity, with an appropriate EKU value.

If CA2 or CA3 want to have CA1 manage an OCSP server for their certs, then they can issue certs that contain an AIA extension  with the OCSP access method OID, and a URI for an OCSP responder operated by CA1, but these CAs would still need to issue a cert to that responder (operated by CA1) OR the RPs would have to be locally configured with
CA1 as an explicitly trusted OSCP responder.

Steve

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 8 Feb 2010 04:45:27 -0500

If CA 2 revokes CA 3 and CA 2 --> CA 3 certificate is in the certification path, the certification path is invalid regardless of the status of CA 3 --> EE certificate.

So, the revocation status of CA 3 issued certificates does not matter.  They should not be trusted.

> Behalf Of zhipeng zhou
> Sent: Monday, February 08, 2010 4:29 AM
> To: 'Stephen Kent'
> Cc: [email-masked]
> Subject: Re: [pkix]庖慲 :Re: ???` :Re: OCSP Trusted Responder
> 
> (technically, a Trust Anchor) does NOT imply that it is 
> authorized to revoke certs issued by CAs that are verified 
> via a path to that "root."
> 
> In this example, CA1 issues a (CA) cert to CA2, which issues 
> a (CA) cert to CA3 which issues end entity (EE) certs to a 
> set of users.
> 
> The basic CRL model does NOT allow CA1 or CA2 to revoke any 
> of the E certs issued by CA3. (See RFC 5280, page 48.)
> 
> Indirect CRLs allow a CA to explicitly designate another 
> entity to manage revocation for that CA, but note that 5280 
> does not require support for indirect CRLs. Note also that a 
> CA may designate an entity as an OCSP server, by issuing a 
> cert to that entity, with an appropriate EKU value.
> 
> If CA2 or CA3 want to have CA1 manage an OCSP server for 
> their certs, then they can issue certs that contain an AIA 
> extension  with the OCSP access method OID, and a URI for an 
> OCSP responder operated by CA1, but these CAs would still 
> need to issue a cert to that responder (operated by CA1) OR 
> the RPs would have to be locally configured with

---

From: Stephen Kent <[email-masked]>
Date: Mon, 8 Feb 2010 13:59:41 -0500

>issued by CA3 be revoked either.

If CA2 revokes the cert it issued to CA3  (if no other path from CA3 
exists to a trust anchor accepted by a given relying party), the the 
EE certs issued under CA2 are no longer verifiable. CA2 has not 
revoked those certs directly, but its revocation of CA2's cert has a 
similar effect (subject to the caveat I mentioned in parenthesis 
above).

Steve

---

From: zhipeng zhou <[email-masked]>
Date: Tue, 09 Feb 2010 20:04:20 +0800

Hi Steve,
Sorry, pls let me give a scenario:
The EE has gotten two certs from CA3 and CA4 respectively.
 CA1 -> CA2 -> CA3 -> EE;
CA1 -> CA2 -> CA4 -> EE;

Given CA3 has been revoked by CA2 and EE is also been monitored as a bad device(call the cert issued by CA3 to EE as CERT-1).
Of cause, since CA2 has been revoked, the CERT-1 will not pass the cert verification naturally.
Meanwhile the cert  issued from CA4 to EE (called as CERT-2) has never been used before.
Then, will the CERT-2 still be valid or not, given the precondition that EE is a bad device.
Thanks.
Zhipeng

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Tuesday, February 09, 2010 3:00 AM
To: zhipeng zhou
Cc: [email-masked]
Subject: RE: ï—· :Re: ???` :Re: [pkix] OCSP Trusted Responder

>issued by CA3 be revoked either.

If CA2 revokes the cert it issued to CA3  (if no other path from CA3 exists to a trust anchor accepted by a given relying party), the the EE certs issued under CA2 are no longer verifiable. CA2 has not revoked those certs directly, but its revocation of CA2's cert has a similar effect (subject to the caveat I mentioned in parenthesis above).

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 9 Feb 2010 13:30:42 -0500

At 8:04 PM +0800 2/9/10, zhipeng zhou wrote:
>Given CA3 has been revoked by CA2 and EE is also been monitored as a 
>bad device(call the cert issued by CA3 to EE as CERT-1).

The fact that CA3 revoked CERT-1 that it issued to the EE is irrelevant when
a relying party validates CERT-2, issued to the same EE, by CA4. The 
names in the two certs might or might not be the same, the public 
keys might be the same or different, the serial numbers WILL be 
different, ...

Until CA4 decides to revoke CERT-2, that cert is valid. The ways in which CA4
might learn that EE is a "bad device" are outside the scope of X.509 
and PKIX standards.

Steve

---

From: zhipeng zhou <[email-masked]>
Date: Wed, 10 Feb 2010 11:43:30 +0800

Thanks, steve, for your kind response.

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Wednesday, February 10, 2010 2:31 AM
To: zhipeng zhou
Cc: [email-masked]
Subject: RE: è¸? :Re: ???` :Re: [pkix] OCSP Trusted Responder

>Then, will the CERT-2 still be valid or not, given the precondition 

The fact that CA3 revoked CERT-1 that it issued to the EE is irrelevant when a relying party validates CERT-2, issued to the same EE, by CA4. The names in the two certs might or might not be the same, the public keys might be the same or different, the serial numbers WILL be different, ...

Until CA4 decides to revoke CERT-2, that cert is valid. The ways in which CA4 might learn that EE is a "bad device" are outside the scope of X.509 and PKIX standards.

Steve