Re: [TLS] New version of Multiple OCSP mode of Certificate Status extension

[Rob Stradling <[e-mail]>]

On Tuesday 27 July 2010 11:35:56 Yngve Nysaeter Pettersen wrote:
> Hello all,
> 
> Based on the ongoing PKIX discussion about an update of OCSP, I (finally)
> realized the the problem my multiple-ocsp TLS extension is designed to fix
> can be fixed in another way, by adding an OCSP extension instead.

Hi Yngve.  That's an interesting idea, but (from my viewpoint as an OCSP 
Responder implementer) I'm not convinced that we should do it.

You ended by suggesting that the Multiple OCSP TLS Extension should still be 
standardized and implemented widely (in clients and servers that support OCSP 
Stapling).  If this happens, then surely it would render your newly proposed 
OCSP Response Extension redundant?

IMHO, implementing a temporary solution with drawbacks (larger responses and 
increased traffic load) doesn't seem like the best way forward.

If the OCSP Response Extension were implemented widely, it might have a 
negative effect on the chances of the OCSP TLS Extension becoming widely 
adopted.
(Consider the ongoing Subject->CN versus SAN->dNSName situation for encoding 
domain names in X.509 certificates for use with the SSL/TLS protocols.  The 
"proper" solution, SAN->dNSName, has been standardized for years.  However, 
the "temporary" solution, Subject->CN, is still widely used and refuses to die 
despite the fact that it is inferior and has been deprecated for a long time).

You say that "the OCSP response generator will have easier access to the 
required OCSP response(s) to be embedded".
For some certificate chains, yes, the same OCSP Responder is authoritative for 
all certificates in the chain.  But this is not a requirement, and it is 
certainly not always the case.
Some OCSP Responders would need to act as OCSP Clients in order to obtain OCSP 
Responses from other Responders which it would then put into your proposed 
OCSP Response Extension.  This is development effort for OCSP Responder 
implementers that would not be needed to support the Multiple OCSP TLS 
Extension.  (Also, note that servers which already support "single" OCSP 
Stapling are already able to act as OCSP Clients).

I think we should just concentrate efforts on the "proper" solution (i.e. the 
Multiple OCSP TLS Extension), in order to increase the likelihood that we'll 
end up where we ultimately want to be.

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