Subject: [pkix] OCSP handling versus the DigiNotar incident, best practices?

From: "Kyle Hamilton" <[email-masked]>
Date: Sat, 1 Oct 2011 07:00:10 -0700 (Pacific Daylight Time)

All,

There appears to be no differentiation in OCSP libraries and OCSP-consuming applications as to "valid" versus "unknown" responses, and no differentiation between "responded unknown" and "non-responded unknown".

I have a bit of a problem with this, as it permits the magnification of errors (error in CA key control magnified by error in OCSP handling compounds to critical incident).

Would it make sense to change the interpretation of an "unknown" response from a CA's OCSP responder from "the OCSP responder doesn't know what the CA hasn't told it" to "the CA doesn't know about this certificate at all, so it's best to treat it as revoked"?

Or is this something that will be so contentious here that it must be separately profiled?

-Kyle H

---

From: "Liaquat Khan" <[email-masked]>
Date: Mon, 3 Oct 2011 18:59:17 +0100

Hi Kyle

Changing the OCSP responder functionality in this way has been discussed a
few times before.  I believe you are asking for a white-list check rather
than a black-list.  I.e. "good" response only if the certificate was issued
by the CA and is not revoked.  From past experience, I don't think this will
be accepted as a change to the standard because of the already installations
out there (since many OCSP responders work off CRLs, without access the DB
of issued certs).  Easiest route to achieving what you want is the use of
specific profiles IMO.  I also agree with you that this is an important
point.   

Regards
Liaquat

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kyle
Hamilton
Sent: 01 October 2011 15:00
To: [email-masked]
Subject: [pkix] OCSP handling versus the DigiNotar incident, best practices?

All,

There appears to be no differentiation in OCSP libraries and OCSP-consuming
applications as to "valid" versus "unknown" responses, and no
differentiation between "responded unknown" and "non-responded unknown".

I have a bit of a problem with this, as it permits the magnification of
errors (error in CA key control magnified by error in OCSP handling
compounds to critical incident).

Would it make sense to change the interpretation of an "unknown" response
from a CA's OCSP responder from "the OCSP responder doesn't know what the CA
hasn't told it" to "the CA doesn't know about this certificate at all, so
it's best to treat it as revoked"?

Or is this something that will be so contentious here that it must be
separately profiled?

-Kyle H

---

From: Simon Tardell <[email-masked]>
Date: Mon, 3 Oct 2011 21:15:36 +0200

> Would it make sense to change the interpretation of an "unknown" response

No, it wouldn't. You can't change the semantics of the protocol. Look at it
this way: What can a client do with a "good", "revoked" and "unknown"
response respectively? With a "good" response it can proceed, with "revoked"
it stops, and with "unknown" it can ask another responder if one is
available (or download CRLs). If "unknown" means "I KNOW this certificate
was never issued" the behavior of the client must be different -- it should
act identically in the "revoked" and "unknown" case, and there would be no
way to tell a client that someone else might have better information about
the status of a certificate.

If you want to assert something about the issuance of a certificate you
could do so through an extension in SingleResponse. In my mind, it would do
little to address the DigiNotar case, though. If the OCSP responder is
dependent of the CA, then a compromise of the CA would compromise the
responder, at least for some time. If the OCSP responder asserts the
issuance of a certificate entirely independent of the CA it is in effect a
CA of its own. If so, why don't just issue two certs from two independent
CAs and require both of them to be valid (generalize to n of m to get your
required level of security and redundancy)?

Simon Tardell,
Technology Nexus.

On Sat, Oct 1, 2011 at 16:00, Kyle Hamilton <[email-masked]> wrote:

> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 3 Oct 2011 20:10:35 -0400

> the status of a certificate.

No, there is a huge difference between "I do not know the status of
this cert" and "I know that there is no such cert".

This was lossage when first proposed and it is going to be fixed. The
discussion in PKIX was driven by a commercial position that is no
longer operative (it is an ex-dot-com, if you hadn't merged him to his
perch he would be pushing up the daisies, etc.)

The point of OCSP was to communicate information. I need to
communicate information that differentiates the two very distinct
conditions. The other CAs seemed to be similarly convinced of that
need when we met last week. So what this group is being asked is HOW
to communicate said information not 'whether'.

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

---

From: Simon Tardell <[email-masked]>
Date: Tue, 4 Oct 2011 11:41:15 +0200

> this cert" and "I know that there is no such cert".
Which is my point. Furthermore, from the clients point of view, "I know
there is no such cert" is equivalent to "this cert is revoked (and will stay
revoked until it maybe is issued)". There are only three outcomes:
use-this-cert, don't-use-this-cert or
ask-someoneelse-about-this-cert-because-my-papers-are-in-a-mess.

Hence, if you need to assert a certificate was not issued (ever or yet), you
should answer revoked, possibly qualifying with reason code certificateHold
if you want to cater for the possibility it might be issued in the future.
If you need to differentiate between revoked and not issued (but I don't see
 why, please enlighten me) you could do so by introducing a critical single
extension.

What I don't want to see is that the semantics of the "unknown" response
changes.

> to communicate said information not 'whether'.
Of course. But it won't solve the DigiNotar problem. DigiNotar did exactly
what I mentioned above: they started to respond "revoked" for all
certificates they didn't know were issued. And how did it help? The problem
is that the OCSP responder isn't independent in any meaningful sense of the
word. If you can't trust them to run a CA, you can't trust them to run an
OCSP responder.

(This is not an argument that we shouldn't decide what to answer in the case
of "non-issued", it is just to say, it doesn't help much, and it is not the
best way to solve the underlying problem.)

Simon Tardell.

---

From: Piyush <[email-masked]>
Date: Tue, 4 Oct 2011 08:17:38 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Phillip Hallam-Baker
> Sent: Monday, October 03, 2011 5:11 PM
> To: Simon Tardell
> Cc: [email-masked]; Kyle Hamilton
> Subject: Re: [pkix] OCSP handling versus the DigiNotar incident, best
> practices?
> 
> > No, it wouldn't. You can't change the semantics of the protocol. Look
> > at it this way: What can a client do with a "good", "revoked" and
> "unknown"
> > available (or download CRLs). If "unknown" means "I KNOW this
> > certificate was never issued" the behavior of the client must be
> > different -- it should act identically in the "revoked" and "unknown"
> > case, and there would be no way to tell a client that someone else
> > might have better information about the status of a certificate.
> 
> No, there is a huge difference between "I do not know the status of this
> cert" and "I know that there is no such cert".
> 
> discussion in PKIX was driven by a commercial position that is no longer
> operative (it is an ex-dot-com, if you hadn't merged him to his perch he
> would be pushing up the daisies, etc.)
> 
> 
> The point of OCSP was to communicate information. I need to communicate
> information that differentiates the two very distinct conditions. The
other
> CAs seemed to be similarly convinced of that need when we met last week.
> So what this group is being asked is HOW to communicate said information
> not 'whether'.
> 

While I agree that the two conditions are distinct, I'm interested in
understanding the need for "is issued" information to be communicated by
OCSP responder. The fact that RP is checking the revocation status indicates
that it has verified that the said CA issued the certificate and that it
chains up to a trust anchor that RP trusts. 
If you are talking about the case where CA is compromised, then all bets are
off any way. You cannot trust an OCSP responder that is acting on behalf of
that CA.

-Piyush