Subject: Re: [pkix] An alternative proposal Was: Fwd: New Version Notification for draft-hamilton-cmr-00.txt

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 1 Nov 2011 12:18:16 +0000

On 10/28/11 11:14 AM, "Kyle Hamilton" <[email-masked]> wrote:

>On Wed, Oct 26, 2011 at 2:02 PM, Phillip Hallam-Baker <[email-masked]>
>wrote:
>> Thinking laterally on this issue.
>> The issue here seems to come up with the problem that OCSP does not
>>have a
>> proper response code for 'does not exist',
>
>I have no problem at all with improving OCSP, as a separate item.  I
>really want to improve it, actually.  The problem is that by
>definition, any OCSP responder which can respond with a "does not
>exist" will be required to respond in that manner for any and every
>certificate serial number which is not listed on the CRL.  CRL cannot
>meaningfully feed such a responder.

Since OCSP services can be delegated, the responder may not have access to
the CA database.  A responder without access to the CA database can *only*
respond with 'revoked' or 'good.'  Technically the 'good' answer is 'I
don't know otherwise' because it represents the absence of data.

Don't presume that a responder is synonymous with a CA.  There are
compelling reasons to divorce these services, and real PKIs do so in
practice.

-- T

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 1 Nov 2011 14:01:59 -0400

On Tue, Nov 1, 2011 at 8:18 AM, Miller, Timothy J. <[email-masked]>wrote:

> practice

Such as?

People advanced this claim when OCSP was being developed. I have never seen
any particularly good argument as to why the Valicert model of doing things
was better than having the CA do the work. They certainly lost the argument
in the market.

Allowing a random third party to make use of the OCSP protocol to publish
whatever information they might be able to provide is unobjectionable.

Requiring that the protocol be *only* capable of supporting the
capabilities of such a third party responder is nonsense on stilts. It was
bogus then and it is bogus now.

If the OCSP responder knows that a certificate should not exist it should
be able to say so. Responding 'not invalid' for not revoked and does not
exist is no longer acceptable.

-- 
Website: http://hallambaker.com/

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 1 Nov 2011 20:24:14 +0000

>Such as?

Such as limiting untrusted, unverified entities from accessing services on
component where critical key material and critical services are kept.  We
call this "risk mitigation."

>People advanced this claim when OCSP was being developed. I have never
>seen any particularly good argument as to why the Valicert model of doing
>things was better than having the CA do the work. They certainly lost the
>argument in the market.

The largest PKI on the planet operates this way, and no fewer than two
companies have sufficient business that they continue to offer delegated
OCSP service software and appliances.  I find your definition of "lost"
rather strange.

>capabilities of such a third party responder is nonsense on stilts. It
>was bogus then and it is bogus now.

Behavior of OCSP services using any of the trust models must be
consistent, else client responses will not be consistent and system
failures will result.

>exist is no longer acceptable.

If the OCSP specification permits 'does not exist' (DNE) then the behavior
of Direct and Delegated trust responders are inconsistent with the
behavior of CA-signed responders; they *cannot* respond with DNE, and a
response of 'unknown' in that case is likewise improper.  What behavior
would you expect from a client in this case?

-- T