Subject: Re: [pkix] Revising OCSP

From: [email-masked]
Date: Mon, 26 Jul 2010 01:38:51 -0700 (PST)

On Tue, Jul 13, 2010 at 3:01 PM, Stephen Kent <[email-masked]> wrote:
> At 5:42 PM -0400 7/13/10, Miller, Timothy J. wrote:
>>
>>  > Did I miss something in this thread?
>>
>> Yes.  The decision to trust or not trust any signature authority on any
>> OCSP response is *entirely* in the hands of the requestor. Always has been,
>> always will be, and nothing in the standard can change that.
>>
>> -- Tim
>
> Tim,
>
> I think your answer is a bit too glib.
>
> I agree that the RP always gets to decide who to trust for what. However,
> when we write a standard we have the opportunity to make precise statements
> about what forms of behavior (e.g., due to local configuration) MUST.
> SHOULD, or MAy be supported. We also have an obligation to alert users and
> developers to adverse security implications associated with some choices.
>
> So, if a CA issues a cert to an OCSP responder (with the appropriate EKU) we
> should note what the expected scope is for that responder.

If the X.509 certificate providing metadata (including 'proof of right to exist') for the CA in question explicitly names that OCSP-responding host, should we trust that the root's delegation of 'ocspResponder' is expected to span the entire PKI under that root?

-Kyle H

---

From: Stephen Kent <[email-masked]>
Date: Mon, 26 Jul 2010 04:42:29 -0400

>>...
>If the X.509 certificate providing metadata (including 'proof of 
>right to exist') for the CA in question explicitly names that 
>OCSP-responding host, should we trust that the root's delegation of 
>'ocspResponder' is expected to span the entire PKI under that root?
>
>-Kyle H

Kyle,

I can't reliability parse the 4-line sentence above.  Can you try 
restating your question, maybe using 2-3 shorter sentences?

Steve

---

From: Kyle Hamilton <[email-masked]>
Date: Mon, 26 Jul 2010 03:56:16 -0700

> restating your question, maybe using 2-3 shorter sentences?
Sorry about that.

Root CA 'O=Prime' creates a delegation for OCSP responses, 'CN=status',
eKU:ocspResponder (but does NOT state that it's an ocspResponder
specifically for 'OU=Doppelganger')
Root CA 'O=Prime' creates a delegation for 'OU=Doppelganger';
CA:true,pathlen:5; ocspResponder:'OU=status'.

Should this be allowed to occur within the same PKI hierarchy?  That is,
the same authority that created 'status' also created 'Doppelganger'.) I
think that the CA specifying its ocspResponder when it receives its own
trust from the same anchor should be allowed.

(I feel that reminding people that 'Any CA' in the meaning of the specs
is 'Any CA within the same PKI hierarchy' is appropriate right about
now, since so many people seem to have forgotten... but then again, with
the number of cross-certificates that have been popping up, any one of
them that had an appropriate policyMapping could be considered
authoritative for its own direct clients, including downstream-trusting
cross-certified CAs.)

'OU=Doppelganger' creates a delegation for 'OU=Revenant';
CA:true,pathlen:4; ocspResponder:'O=Prime/CN=status'

This would be Doppelganger using its own authority to create Revenant,
which seems to be where the remains of someone's empirical power base
ended up... anyway, now the question is, since it's been created by an
entity delegated the power to do so, will CN=status necessarily have
information on its certificate statuses?

Well, for that, let's look at another possibility:

When Prime signed Doppelganger, did it sign it with an extendedKeyUsage
of ocspResponder?  Put more specifically, did Prime grant Doppelganger
the right to set up its own OCSP, or delegate the right to grant
Revenant the right to set up its own?

If specifying its own OCSP responder is an inherent right of a CA, that
departs significantly from the classic chain-of-least-privilege, where
the root doles out authority to act within its influence sparingly and
explicitly.

-Kyle H

---

From: Stephen Kent <[email-masked]>
Date: Tue, 27 Jul 2010 06:24:21 -0400

Kyle,

>trust from the same anchor should be allowed.

I find the syntax of your example rather confusing. What does 
"creates a delegation" mean? In what cert extension does the 
"ocspresponder" appear?  are you referring to an AIA extension value? 
I'm confused.

>authoritative for its own direct clients, including downstream-trusting

where in the RFC 2560 do you see "any CA."

>Revenant the right to set up its own?

do you mean when Prime issued a CA cert to doppleganger? there is no 
requirement that a CA cert contain a specific EKU value in order to 
put that value in any of the certs that it issues. So, I don;t 
understand your example here.

>the root doles out authority to act within its influence sparingly and

I have never encountered the phrase "chain of least privilege." (The 
phrase "principle of least privilege" is well-know in the security 
arena, but has nothing to do with this discussion.) The quick answer 
to your question is that yes, any CA is allowed to issue an EE cert 
to an entity that it wants to name as an OCSP responder. If a 
superior CA does not want a subordinate CA in the same organization 
to designate an OCSP responder, there are procedural ways to convey 
and enforce this.

Steve