Brian Smith (:briansmith, :bsmith, use NEEDINFO?) Reporter
	Description • 14 years ago

Yngve N. Pettersen at Opera is/was working on an improvement on the OCSP stapling extension that would allow the entire cert chain to be stapled. I am not sure if he is still pursuing it or not. 

http://www.ietf.org/mail-archive/web/tls/current/msg05871.html

I know there was some discussion about making it an OCSP extension instead of a TLS extension, but IMO the TLS-based mechanism is much better:

http://www.ietf.org/mail-archive/web/tls/current/msg06765.html

	Kai Engert (:KaiE:)
	Comment 1 • 12 years ago

There have been complaints that multi-OCSP-stapling causes the handshake to be "too big", making the initial handshake much slower.

The caching feature proposed in bug 665739 could be useful to neutralize this addition.

	Brian Smith (:briansmith, :bsmith, use NEEDINFO?) Reporter
	Comment 2 • 12 years ago

I think we should try to implement mechanisms for pre-loading/pre-fetching validity/revocation information about intermediates before we attempt to implement this. It think it is likely that we will be able to avoid needing this at all.

	Leen Besselink
	Comment 3 • 12 years ago

(In reply to Kai Engert (:kaie) from comment #1)
> There have been complaints that multi-OCSP-stapling causes the handshake to
> be "too big", making the initial handshake much slower.

If it is "too big", what if someone would create an extension to SSL/TLS to compress the certificate ?

(I suggested it before in an other forum talking about SPDY and header compression if I remember correctly)

The client would have a new extension to the client-hello to show it is supported and the server replies with the certificates compressed.

A quick check on the certificate of paypal.com shows me that gzip compression gets about 45% reducation in size.

	Rob Stradling
	Comment 4 • 11 years ago

Yngve's multi-stapling draft has now been published as RFC 6961.

	Rob Stradling
	Comment 5 • 11 years ago

(In reply to Kai Engert (:kaie) from comment #1)
> There have been complaints that multi-OCSP-stapling causes the handshake to
> be "too big", making the initial handshake much slower.
> 
> The caching feature proposed in bug 665739 could be useful to neutralize
> this addition.

Latest status on Cached-Info + Multi-Stapling:
http://www.ietf.org/mail-archive/web/tls/current/msg09566.html

	Adrian Hall
	Comment 6 • 10 years ago

Great concept, really should be implemented and pushed as being the normal practice.

During the TLS handshake a server provides a certificate chain. If it also provides stapled status for every certificate in the chain, then verification is done without having to set up extra connections to CRL or OCSP responders (and worrying about the security/reliabilty of the extra connections).

Should be combined with "Must Staple" server policies, ie. don't connect to the server unless it  provides a fully OCSP stapled certificate chain. If the server cannot get OCSP statuses for its own certificates then why should the client even bother trying. The load on CRL or OCSP responders would then just be from servers getting their stapling statuses.

From a server viewpoint:- be responsible, check all certificates in the chain have a current OCSP status before passing them to clients and include the statuses to show it. If you cannot confirm all certificates are current then don't accept connections.

It is definitely worth a bit of extra data to simplify the connection sequence.

If the servers supply the all the necessary OCSP data during handshake, is there still a need for clients to cache it?

Adrian