Re: OCSP handling versus the DigiNotar incident, best practices?
Kyle Hamilton <kyanha <at> kyanha.net>
2011-10-04 01:30:55 GMT
On Mon, Oct 3, 2011 at 12:15 PM, Simon Tardell <simon <at> tardell.se> 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
_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix
RSS Feed