Re: [TLS] OCSP must staple

[Viktor Dukhovni <[e-mail]>]

On Thu, Jun 05, 2014 at 10:05:22AM -0700, Brian Smith wrote:

> I read the document. I disagree with the documented semantics of the
> extension when it appears in a CA certificate.

[ Apologies if my understanding of how the revocation process works
in practice is a bit stale, perhaps things are better now than the
last time I looked. ]

This extension introduces a requirement to implement OCSP stapling
predicated on the assumption, that we have usable revocation
mechanisms, and that all that remains is for clients to learn in
a reasonably timely manner that a certificate has been revoked.

It also assumes that servers are generally deployed in environments
where periodically obtaining OCSP responses from the server's CA
for stapling is practical.

There at this time to my knowledge no standard companion protocol
for OCSP that allows the holder of a key pair (when the private
key is not lost) to sign a request to the CA to revoke the
certificate.  Instead, it is my impression, that we have "challenge
phrases" that are often not set or lost, and CA-specific interfaces
to activate revocation.

If, this is indeed the case, then I claim that mandatory OCSP
stapling is putting the cart before the horse.  Only a tiny fraction
of certificates can be effectively revoked.  I would like to see
CAs stop publishing CRLs entirely (solving the scaling issue for
mass revocations as with Heartbleed), implement only OCSP, and
provide a standard zero-cost revocation protocol when the private
key is available (or when a miracle happens and the "challenge"
password is actually known).

Once revocation is a scalable working process, then we can benefit
from insisting on OCSP stapling, provided we figure out what to do
with servers that don't have any way to reach out and refresh OCSP
responses for stapling, nor support interface for an agent to
obtain the response on the server's behalf and push it into the
server's configuration.

-- 
	Viktor.