I'm reading there as being no consensus to make this change, so I plan not to absent chair directive.
-Ekr On Mon, Apr 24, 2017 at 6:26 AM, Ryan Sleevi <ryan-ietf...@sleevi.com> wrote: > > > On Mon, Apr 24, 2017 at 3:58 AM, Nikos Mavrogiannopoulos <n...@redhat.com> > wrote: > >> >> That's intentional. > > > And misguided. It violates the layering. > > >> Not every application is firefox or chrome and thus >> application writers cannot be expected to set sane defaults for OCSP >> validity time _when the nextUpdate field is missing_. > > > Not every TLS implementation should be required to process the PKI. > > >> The reason they >> cannot be expected to do that, is that it is not by way obvious what to >> do. Ilari's implentation closes the connection, mine sets a limit of 15 >> days, and I guess each and every other one behaves differently. It is >> the role of the standards to clarify uncertainties for implementers or >> forbid such options (I'd equally be happy if we have a text that >> forbids an empty nextUpdate field in OCSP responses to be used in the >> context of TLS 1.3 ocsp stapling). >> > > Can you point to where the spec supports your behaviours? That is, where > it's a valid reading of the spec to close the connection or to set a limit > of 15 days. > > The point is that it's not a valid reading of the spec. It is, instead, an > application profile. And that's great. I don't think anyone would > realistically be arguing that applications or other specifications cannot > profile the spec to their needs. While I remain unconvinced that TLS is the > right thing, what you're describing here is simply a decision you've made > for your community. That doesn't mean that because you and Ilari have made > different decisions, that should be imposed on the spec. > > >> > Given that stapling "issues" exist even without stapling, it does >> > seem an unnecessary reach to include within the spec. >> >> There is a usability and interoperability issue there. > > > Not within the spec. Within the profile you've done for your community. > > >> Given that there >> is no common interpretation of what the missing nextUpdate field means >> in terms of validity, there some equally valid interpretations: >> 1. the response is invalid for use in TLS 1.3 >> > > That's not an equally valid interpretation. A missing nextUpdate is > defined in the relevant OCSP specs. > > >> 2. the response is valid for a limited amount of time 1, 7, 8, 9, 15 >> days >> > > That's not an equally valid interpretation. A missing nextUpdate is > defined in the relevant OCSP specs. > > >> 3. the response is valid for an unlimited amount of time (which raises >> the question of why staple at all in that case?) >> > > A missing nextU... you get the idea. > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
