RE: OCSP Algorithm Agility

[Paul Hoffman <[e-mail]>]

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