[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: OCSP Algorithm Agility
At 7:04 AM -0700 9/21/07, Hallam-Baker, Phillip wrote:
The way I see it, the process of transition from one algorithm to
another has two sets of constraints, the first is the security
considerations, the second is the operational/management
considerations.
In the past security issues have been the alpha and omega of PKI.
The only justification accepted for a change has been to improve
security. So we end up with a whole slew of arbitrary operational
constraints and then wonder why people have such difficulty
deploying and maintaining these systems.
If we want to deploy new algorithms we have to decouple the OCSP and
Cert issuing infrastructures, otherswise we will perpetually be in
situations where we are waiting for an evolution in one
infrastructure before a change can be made in the other.
Fully agree up to here.
We have to get PKIX in order before we start proposing work for the
TLS group. Than means making OCSP algorithm agile.
And mostly agree with this. Where I disagree with Phill (I think) is
what "algorithm agile" means. My reading of OCSP is that it is
*already* fully algorithm agile.
From Phill's message at the start of this thread, I think what he
means is "agile in a way that is not susceptible to downgrade attacks
by a MITM". The list then went into the design of an anti-downgrade
revision to OCSP. This is quite similar to the discussion we had in
the DKIM WG on a very similar topic.
The most important feature of these attacks is that Mallory can
impersonate the OCSP responder by signing a message with a
compromised algorithm. I contend that this attack is isomorphic to
the problem of, even with no algorithm agility, Mallory impersonating
the OCSP responder using a stolen signing key. In fact, the latter
seems much more likely than the former in the real world.
We haven't even thought about how an OCSP responder could say in an
unspoofable fashion "here is my legitimate signing key, don't trust
that stolen key". That is been a non-issue for all these years,
probably because it is intractable without going out-of-band. The
compromised-algorithm problem is likely to be just as intractable
without going out of band. Once we go out of band, the OCSP responder
simply gives the key and algorithm of the day.
So, can we can safely say that OCSP is algorithm agile without
needing a solution to the compromised algorithm problem? If not, how
is the problem different operationally from the stolen-key problem?
--Paul Hoffman, Director
--VPN Consortium