Re: [TLS] comments on draft-ietf-tls-tls13-19

[Ryan Sleevi <[e-mail]>]

On Sun, Apr 23, 2017 at 6:34 AM, Ilari Liusvaara <[e-mail]>
wrote:
>
> I meant if anyone has seen a OCSP response from "public" CA lately that
> lacks NextUpdate.
>

Why would it matter? Are you suggesting we determine what should be part of
TLS based on what CAs are doing? That's going to be sadness all around :)


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

I have no desire to support multistaple within Chrome. That it's specified
is great, but I believe multistaple is, for the general _browser_ case,
unnecessary. That's not to say it's not useful in other venues or in
specialized cases, which is the only reason I haven't complained here.


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

Again, that's public CAs. There are more participants in the ecosystem than
that. I don't think it's necessary or appropriate to set an upperbound
based on the Baseline Requirements. For that matter, I don't believe it's
necessary or appropriate to set an upperbound in TLS at all.


>
>
> As for what the TLS library I have written does if OCSP staple lacks
> NextUpdate, it outright causes handshake failure and fatal alert.
>

So far, the preference on our end has been for a TLS library that doesn't
have to have deeply-ingrained knowledge of the PKI, including OCSP, and
instead treat these as separate layers. This PR necessitates that awareness
by force of spec, and as such, makes it either unnecessarily difficult to
implement or simply unlikely to be implemented. Given that stapling
"issues" exist even without stapling, it does seem an unnecessary reach to
include within the spec.