[SSL Observatory] Diginotar broken arrow as a tour-de-force of PKI fail

Rob Stradling rob.stradling at comodo.com
Tue Sep 13 07:58:23 PDT 2011


On Tuesday 13 Sep 2011 04:08:05 Chris Palmer wrote:
> On Sep 12, 2011, at 4:28 AM, Rob Stradling wrote:
> > A properly-designed mechanism is always a nice idea.  But I'll take
> > inelegently-patched-up OCSP if that's the best that all required parties
> > can agree to.
> 
> OCSP's privacy and reliability/performance/availability problems are fatal.
> It's going to have to be something else.

OCSP Stapling solves OCSP's Privacy problem (and some of its Reliability, 
Performance and Availability problems too!), doesn't it?

IINM, the only way that a "something else" solution could do any better on the 
Privacy front would be to mandate the use of Stapling (or at least mandate 
that some kind of Intermediate Server MUST be involved, so that the Revocation 
Server never sees the Client's IP Address).

AFAICT, Peter's RTCS I-D doesn't solve the Privacy problem any better than 
RFC2560.  It assumes direct communication between the Client and the RTCS 
Server.

So maybe the "something else" solution would involve writing an I-D to extend 
the Certificate Status Request (aka Stapling) TLS Extension to support "RTCS 
Stapling".  This I-D would need to mandate the use of a nonce (to address some 
of Peter's criticisms of OCSP), which would force the TLS Server to obtain 
fresh information from the RTCS Server during the TLS handshake (either via 
vanilla RTCS, or via HTTPS-with-RTCS-Stapling with the RTCS Server).

Presumably this suggested I-D would be in scope for the TLS WG (not the PKIX 
WG) and perhaps the TLS WG would be less inclined to reject the idea of 
whitelist-based certificate status checking.  ;-)

Reasonable approach?  Sneaky politics?  Unworkable for some reason?

Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online



More information about the Observatory mailing list