Implement multiple OCSP stapling extension

NEW
Unassigned

Status

--
enhancement
9 years ago
5 months ago

People

(Reporter: briansmith, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(URL)

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

Updated

8 years ago
Depends on: 360420
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.
See Also: → bug 665739
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.

Comment 3

7 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.

Comment 4

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

Comment 5

6 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

Comment 6

5 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
You need to log in before you can comment on or make changes to this bug.