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

From: "Kyle Hamilton" <[email-masked]>
Date: Mon, 3 Oct 2011 18:30:55 -0700 (Pacific Daylight Time)

On Mon, Oct 3, 2011 at 12:15 PM, Simon Tardell <[email-masked]> wrote:
>> 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?

How about 'no response', which is also a valid case?

I suggest that it should be treated as a negative 'unknown', which should be treated separately from a positive 'unknown' response from the originating PKI, which should be treated differently from a positive "unknown" response signed by the verifier's PKI.  Thus, there is a larger number of states than is contemplated within OCSP.

try { (good from verifier), (good from issuer), (unknown from verifier), (unknown from issuer), (revoked from verifier), (revoked from issuer) } catch (ExceptionNullResponse) { :trysomethingelse }

As it stands, current implementations treat the two unknowns as equal to no response.  This creates the problem that DigiNotar had to be removed for: DN couldn't issue 'good' responses for certificates it didn't know it had issued, so it hopefully responded with 'unknown'.  The handling of the issuer's 'unknown' as somehow conveying less authoritative information than the verifier's own 'unknown', permitting the connection, is what magnified the original CA key misuse into something that required a global-scale code update.

I can think of no use-case where it would be desirable to ignore any useful information from authoritative sources, but evidently the OCSP designers did.

I propose an alternative semantic for the (unknown from issuer) case, to balance the states.  Currently there are 3 + null, and I believe that they should be split into 6 + null.

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

How about, "The OCSP responder which was signed by the originating CA claims it's unknown" versus "The OCSP responder which I'm configured with that isn't signed by the originating CA claims it's unknown"?

There are more variables than the current semantic addresses.

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

OCSP requires that responder certificates not be permitted any other purposes.  So, under this alternate semantic, the compromise of the CA would require the issuance of an OCSP certificate which is either recorded (and hopefully revoked upon discovery) or unrecorded (unknown).  The only thing that can recover from that is revocation of the CA involved.

Furthermore, having an OCSP responder operate from a CRL makes it a blacklist-based problem, which is poor design -- personally, I'm okay with the idea of requiring that public CAs create OCSP responders that interface with their back-end systems.  Private CAs can do whatever they like.

Having the capacity to respond to known bad certs found in the wild by adding them to the CRL would at least permit the OCSP responder to respond with positive "revoked".

"at least for some time" is a false target.  This is what the court system is for -- if there are disputes, the judge or jury figures out who is responsible for what.  The largest attitude adjustment that needs to happen before real progress can be made is that we can ever achieve complete security, or be completely certain that we're not being tricked.  All we can do is reduce the probability to a point we can consider acceptable for our individual purposes.

The "backward compatibility" argument fails too.  Right now, because of the mandate that things stay the broken same, that argument means we effectively can't act to change the standards to protect against the post-standardization identification of a new threat vector at the standards level.  Are we too proud to admit that we were wrong, that we didn't see all threat vectors because we trusted the cryptography?

We know more about the private-sector non-business threat model today than we did 12 years ago.  We need to make the best system that we can from what we have learned thus far.  We have 12 years of knowledge of how people want to interact, how the Internet creates vibrant communities that exist without the assistance we could give them.  These communities suffer the problems that we saw 30+ years ago on the first MUDs, and we have seen just how bad those problems can get (cyberbullying causing suicide because there was no effective way to intervene or hold the perpetrators responsible for their abuses).  In other words, we have seen that our inaction has actually cost lives.

(And no, the problem isn't "they didn't adopt the tools we gave them", it's "we didn't give them tools that they could use".)

The lack of security that exists today is so much worse than what we can create that I feel we're derelicting our duty.

> 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)? 

Several reasons, actually.

First, OCSP was designed to permit corporations to effectively insist to their internal cells that a particular certificate was good or wasn't, overriding the originator.  (That's the reason for the "unknown" response in the first place.)

Second, TLS only permits the atomic assertion of one certificate chain.

Third, it's not our place to dictate how people run their own existences.  It's our place (as developers) to give them usable, useful tools they can use to do so -- because they've certainly paid enough for them.

-Kyle H

---

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

On Tue, Oct 4, 2011 at 03:30, Kyle Hamilton <[email-masked]> wrote:

> I suggest that it should be treated as a negative 'unknown', which should
> be treated separately from a positive 'unknown' response from the
> originating PKI, which should be treated differently from a positive
> "unknown" response signed by the verifier's PKI.  Thus, there is a larger
> number of states than is contemplated within OCSP.
>

Try to look at it from the client's perspective. It can act in three
different ways: Accept the cert, reject cert, or look for more information.
So that is what the protocol should communicate. It is a bit unfortunate
that the names of these responses are "good", "revoked" and "unknown". I
would be perfectly happy with keeping the protocol as is and change the
labels to "accept", "reject", "whydontyouasksomeoneelse".

As it stands, current implementations treat the two unknowns as equal to no
> response.  This creates the problem that DigiNotar had to be removed for:

DigiNotar did answer revoked for non issued certs (from Sept 1, a bit tardy,
but nonetheless). So apparently something else prompted the removal of
DigiNotar from the list of 176 trusted certs.

> How about, "The OCSP responder which was signed by the originating CA
> claims it's unknown" versus "The OCSP responder which I'm configured with
> that isn't signed by the originating CA claims it's unknown"?
>
> OCSP requires that responder certificates not be permitted any other
> purposes.  So, under this alternate semantic, the compromise of the CA would
> require the issuance of an OCSP certificate which is either recorded (and
> hopefully revoked upon discovery) or unrecorded (unknown).  The only thing
> that can recover from that is revocation of the CA involved.
>

I am not sure I follow -- an OCSP responder that get its information from
the CA, whitelist or blacklist, would be about as corrupt as the CA once the
CA gets corrupted.

> The "backward compatibility" argument fails too.  Right now, because of the
> mandate that things stay the broken same, that argument means we effectively
> can't act to change the standards to protect against the
> post-standardization identification of a new threat vector at the standards
> level.  Are we too proud to admit that we were wrong, that we didn't see all
> threat vectors because we trusted the cryptography?
>

I don't agree. The standard does not prevent OCSP responders from preventing
non issued certs being used. It is just not spelled out how to. I am not
against doing that, but I am saying it will not help much.

> The lack of security that exists today is so much worse than what we can
> create that I feel we're derelicting our duty.

I can agree to that, but that can't be fixed here. We have to get away from
the 176 trusted certificates. It is, as noted elsewhere, an inherently
broken system. I believe that can be done without breaking the current
protocols (neither OCSP nor TLS).

> First, OCSP was designed to permit corporations to effectively insist to
> their internal cells that a particular certificate was good or wasn't,
> overriding the originator.

There are a lot of wishes that went into the design of OCSP. That would be
one.

>  (That's the reason for the "unknown" response in the first place.)
>

Another reason, more important, in my mind, was to build some some support
for redundancy into the protocol.

> Second, TLS only permits the atomic assertion of one certificate chain.

That's true in a limited sense of the word, only. But enhancing the
browsers' behavior when it comes to validation of the claimed identity of
the server is an encumbrance of the browser makers.

/Simon

---

From: "Bentkofsky, Michael" <[email-masked]>
Date: Tue, 4 Oct 2011 13:23:11 +0000

I am writing this having implemented an OCSP responder for a large set of CA's (as my e-mail address would suggest), however I am no longer in charge of that service so these views are my own.

I know that we grappled with these issues to implement our OCSP responder, and made several choices that complicate this a bit more. Although we ultimately chose to implement "good" to mean "issued + not revoked" I know many CA's implement "good" to mean "not revoked", but that doesn't mean the cert being validated was ever issued. We chose to use "unknown" to mean "never issued", but the problem remained that this response is unsigned and could be forged. So what's a poor client to do? The only clear case is "revoked" in reality.

I know that I have felt with the increasing reliance on OCSP for certificate verification, and questions like this manifesting themselves in client implementation choices like failing-back to CRL when OCSP doesn't give a clear answer suggests an opportunity to re-think the approach a bit.

Michael

From: [email-masked] [mailto:[email-masked]] On Behalf Of Simon Tardell
Sent: Tuesday, October 04, 2011 6:11 AM
To: Kyle Hamilton
Cc: [email-masked]; Kyle Hamilton
Subject: Re: [pkix] OCSP handling versus the DigiNotar incident, best practices?

On Tue, Oct 4, 2011 at 03:30, Kyle Hamilton <[email-masked]<mailto:[email-masked]>> wrote:

On Mon, Oct 3, 2011 at 12:15 PM, Simon Tardell <[email-masked]<mailto:[email-masked]>> wrote:
Would it make sense to change the interpretation of an "unknown" response

Try to look at it from the client's perspective. It can act in three different ways: Accept the cert, reject cert, or look for more information. So that is what the protocol should communicate. It is a bit unfortunate that the names of these responses are "good", "revoked" and "unknown". I would be perfectly happy with keeping the protocol as is and change the labels to "accept", "reject", "whydontyouasksomeoneelse".

As it stands, current implementations treat the two unknowns as equal to no response.  This creates the problem that DigiNotar had to be removed for:

DigiNotar did answer revoked for non issued certs (from Sept 1, a bit tardy, but nonetheless). So apparently something else prompted the removal of DigiNotar from the list of 176 trusted certs.

I am not sure I follow -- an OCSP responder that get its information from the CA, whitelist or blacklist, would be about as corrupt as the CA once the CA gets corrupted.

I don't agree. The standard does not prevent OCSP responders from preventing non issued certs being used. It is just not spelled out how to. I am not against doing that, but I am saying it will not help much.

I can agree to that, but that can't be fixed here. We have to get away from the 176 trusted certificates. It is, as noted elsewhere, an inherently broken system. I believe that can be done without breaking the current protocols (neither OCSP nor TLS).

First, OCSP was designed to permit corporations to effectively insist to their internal cells that a particular certificate was good or wasn't, overriding the originator.

There are a lot of wishes that went into the design of OCSP. That would be one.

Another reason, more important, in my mind, was to build some some support for redundancy into the protocol.

That's true in a limited sense of the word, only. But enhancing the browsers' behavior when it comes to validation of the claimed identity of the server is an encumbrance of the browser makers.

/Simon

---

From: Stephen Kent <[email-masked]>
Date: Tue, 4 Oct 2011 11:12:29 -0400

>...
>
>I know that we grappled with these issues to implement our OCSP 
>responder, and made several choices that complicate this a bit more. 
>Although we ultimately chose to implement "good" to mean "issued + 
>not revoked" I know many CA's implement "good" to mean "not 
>revoked", but that doesn't mean the cert being validated was ever 
>issued. We chose to use "unknown" to mean "never issued", but the 
>problem remained that this response is unsigned and could be forged. 
>So what's a poor client to do? The only clear case is "revoked" in 
>reality.
>
>I know that I have felt with the increasing reliance on OCSP for 
>certificate verification, and questions like this manifesting 
>themselves in client implementation choices like failing-back to CRL 
>when OCSP doesn't give a clear answer suggests an opportunity to 
>re-think the approach a bit.
>
>Michael

I'm confused by the comment above: " ... failing-back to CRL when 
OCSP doesn't give a clear answer..." A CRL does not tell an RP if a 
cert is valid. It has the same limitation as an OCSP response (not 
coincidentally) in that it tells an RP only of an issued, not yet 
expired, cert has been revoked.  cert validation is a separate 
processing step.  PKIX developed SCVP to enable an OCSP-like 
server-based validation capability.  I do not envision PKIX changing 
OCSP to offer SCVP-style functionality. Read the SCVP requirements 
doc to understand why PKIX chose to not "tweak" OCSP to provide this 
sort of capability.

Steve

---

From: "Bentkofsky, Michael" <[email-masked]>
Date: Tue, 4 Oct 2011 15:42:55 +0000

Steve,

I was referring to discussions like these:

http://www.gnupg.org/documentation/manuals/gnupg/Certificate-Options.html

"B[y] default OCSP checks are disabled. The enable option may be used to enable OCSP checks via Dirmngr. If CRL checks are also enabled, CRLs will be used as a fallback if for some reason an OCSP request won't succeed."

http://technet.microsoft.com/en-us/library/ee619754%28WS.10%29.aspx

"Determining Preference between OCSP and CRLs ..."

(longer discussion)

http://www.carbonwind.net/blog/post/Random-SSLTLS-101-OCSPCRL-in-practice.aspx

Thanks,
Michael

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Tuesday, October 04, 2011 11:12 AM
To: Bentkofsky, Michael
Cc: Simon Tardell; [email-masked]
Subject: Re: [pkix] OCSP handling versus the DigiNotar incident, best practices?

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 4 Oct 2011 12:05:52 -0400

At 3:42 PM +0000 10/4/11, Bentkofsky, Michael wrote:
>"B[y] default OCSP checks are disabled. The enable option may be 
>used to enable OCSP checks via Dirmngr. If CRL checks are also 
>enabled, CRLs will be used as a fallback if for some reason an OCSP 
>request won't succeed."
>

In that context, the comparison makes sense, i.e., OCSP and CRLs are 
intended to be (roughly) equivalent mechanisms for conveying 
revocation status. That's appropriate, but the rest of your message 
was discussing the issue of the ambiguity of OCSP responses, as 
interpreted by different responders. Hence the confusion.

Steve

---

From: Martin Rex <[email-masked]>
Date: Tue, 4 Oct 2011 21:54:31 +0200 (MEST)

Stephen Kent wrote:
> 
> Bentkofsky, Michael wrote:
> >

I share your notion that OCSP and CRLs are intended to be roughly
equivalent mechanisms for conveying revocation status.  This is
particularly true for "local" OCSP responsers working on CRLs.

But the OCSP & CRL scheme has some design weaknesses. it identifies
certs only weakly (by issuer&serial rather than certificate hash)
and it is based on the somewhat flawed assumption that a CA is
fully aware of all certs that where signed with the CA's key.

The latter is somewhat ignorant of the realities of disaster recovery.
I would _not_ be surprised if most CA issuance could be made to fail
(keeping track of issued certs), so that traces/accounting info of
recently issued certs can be logically or physically destroyed by
a sufficiently potent attacker (like a local admin) and desaster
recovery (re-install from backup) will lead to the situation that
the most recently issued certs are not on record.

It appears that in the DigiNotar case, remote logical deletion of trace/audit
files was sufficient to preclude timely revocation of a "*.google.com"
certificate.  Other possibilities for an attacker to hide from revocation
checking might be to create new certs with previously issued serials from
innocuous real certs, or create new certs without CRL&OCSP info in
X.509 certificate extensions.

The whole OCSP & CRLs model seems to be vitally dependent on the premise
that it is impossible to subvert a CA.  As it turns out, this premise
is fatally flawed.

There is nothing that protocols can do for you when a "trusted CA" is
compromised while the CA does not know about it yet, of course.
But I would hope that there is a desire to do better than DigiNotar
*when* it happens.

The current solution to the problem: "Kill the CA and the entire PKI
surrounding this CA along with it, and as fast as possible"
seems like a somewhat strange concept for disaster recovery, and
IMHO rather like a lack thereof.

-Martin

---

From: Stephen Kent <[email-masked]>
Date: Mon, 10 Oct 2011 15:47:52 -0400

>fully aware of all certs that where signed with the CA's key.

A CRL almost always is signed by the CA that issued the cert, and 
that CA is responsible for the cert serial #. So, that should be 
strong enough.  In OCSP,
there is also an implied scope for the OCSP server. So, while a hash 
has a certain attraction, I don't think it's critical.

Steve

---

From: Stephen Wilson <[email-masked]>
Date: Tue, 11 Oct 2011 08:04:24 +1100

There are a bunch of subtle technicalities in this thread, but I am left 
wondering about a simpler, higher level question.  People on this list 
with more engineering familiarity with browsers across the board may 
know ...

Generally speaking, wouldn't the rogue CA problem be greatly ameliorated 
if browsers checked CRLs and validated certificate paths properly?  Is 
it not the case that browser software (and S/MIME email clients etc). 
are pretty crap in this regard?

Cheers,

Steve Wilson.

Lockstep

http://lockstep.com.au
Lockstep Consulting provides independent specialist advice and analysis
on digital identity and privacy.Lockstep Technologies develops unique
new smart ID solutions that enhance privacy and prevent identity theft.

On 5/10/2011 2:12 AM, Stephen Kent wrote:
>> not revoked" I know many CA's implement "good" to mean "not revoked", 
>> but that doesn't mean the cert being validated was ever issued. We 
>> chose to use "unknown" to mean "never issued", but the problem 
>> remained that this response is unsigned and could be forged. So 
>> what's a poor client to do? The only clear case is "revoked" in reality.
>>
> I'm confused by the comment above: " ... failing-back to CRL when OCSP 
> doesn't give a clear answer..." A CRL does not tell an RP if a cert is 
> valid. It has the same limitation as an OCSP response (not 
> OCSP to offer SCVP-style functionality. Read the SCVP requirements doc 
> to understand why PKIX chose to not "tweak" OCSP to provide this sort 
> of capability.
>
> Steve
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>
>