proposal: crypto/tls: add SetOCSPStaple function

[gregory-m]

OCSPStaple should be updated by server after it expiration.
Today we can't update it directly without data races, and the only one workaround is use tls.Config.GetCertificate and return certificate with OCSPStaple populated.

Can we add SetOCSPStaple function with mutex to tls.Certificate (just like SetSessionTicketKeys) to simplify this?

Thanks.

[bradfitz]

/cc @agl

[adg]

Ping @agl. Does this make sense?

[adg]

Ping

[agl]

Yes, this makes sense. I had originally expected people to atomically switch the tls.Config for this sort of thing, but that doesn't appear to be how things are working out.

[kreichgauer]

Chatted with @agl about this. tls.Certificate is occasionally passed by value (e.g., tls.LoadX509KeyPair returns a Certificate; tls.Config.Certificates is a []tls.Certificate). So we would end up copying mutexes in a few places. AFAICT this is technically okay because copies would be made shortly after initialization (i.e. before anyone could reasonably call SetOCSPStaple). Though I don't know if this would pass review.

Alternatively, we could add a GetOCSPStable callback, returning a staple for a given certificate. But would either solution really add much convenience over using GetCertificate? Maybe improving documentation of Certificate.OCSPStaple is a better solution.

[odeke-em]

How's it going with this issue? There hasn't been much activity since early December 2016, but the proposal was accepted, or are we too late in the cycle to do anything?

[FiloSottile]

This didn't get implemented, and GetCertificate and GetConfigForClient became the standard way to update anything in the server configuration. Caddy for example uses it to dynamically set OCSPStaple.

I think we should not add complexity to tls.Certificate, nor yet another callback. Reverting the Proposal-Accepted and passing it to the proposal committee.

[gregory-m]

I also poked the code after it was accepted, and I don't see good way to implement it without rewriting huge part of code because of problems mentioned by @kreichgauer.

[rsc]

Based on the lack of movement since the acceptance 3 years ago and the implementation difficulties noted above, and also the general lack of activity on this issue, this now seems like a likely decline.

Leaving open for a week for final comments.

[rsc]

No change in consensus, so declined.