On Sat, Apr 22, 2017 at 11:42:06PM +0200, Kurt Roeckx wrote: > On Sat, Apr 22, 2017 at 03:00:17PM +0300, Ilari Liusvaara wrote: > > On Sat, Apr 22, 2017 at 07:53:50AM -0400, Eric Rescorla wrote: > > > On Fri, Apr 21, 2017 at 10:52 AM, Nikos Mavrogiannopoulos > > > <n...@redhat.com> > > > wrote: > > > > > > > On Tue, 2017-04-11 at 13:47 -0700, Eric Rescorla wrote: > > > > > > > > > Do you have any thoughts on what text we should insert here? I admit > > > > > to being not that familiar with the practical matters of OCSP > > > > > stapling. > > > > > > > > My issue with OCSP when used under TLS was how to determine the > > > > validity of the response when the nextUpdate field is missing. I've > > > > added some text for that introducing an (arbitrary) upper limit at: > > > > https://github.com/tlswg/tls13-spec/pull/974 > > > > > > > > > This text looks good to me, but it is is a normative change and we've > > > been through WGLC so I'd like to hear from a few other people that they're > > > OK > > > with it (or have the chairs tell me that silence is consent). David > > > Benjamin? > > > Richard Barnes? Ryan Sleevi? > > > > I searched what minimum standards for "public" CAs say. The maximum > > lifetime there is 10 days (but IIRC some widely-used root program has > > lower limit, might have been 7 days).. > > > > Anybody happens to know a CA that doesn't put NextUpdate in? If so, > > what's the OCSP issuance frequency?
> <Snip BR rules> I meant if anyone has seen a OCSP response from "public" CA lately that lacks NextUpdate. And the 12 month update interval for intermediates is IMO just crazy, and won't work properly in TLS 1.3, now that multistaple is pretty much a baseline feature. Looking at those rules, 7 day default would still work fine with 4 day issue frequency. And 7 days also seems to be the limit for various kinds caching (e.g. tickets, subcerts, etc...) that circumvent revocation in various drafts and specs. As for what the TLS library I have written does if OCSP staple lacks NextUpdate, it outright causes handshake failure and fatal alert. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
