On Mon, 2017-04-24 at 09:26 -0400, Ryan Sleevi wrote: > > > On Mon, Apr 24, 2017 at 3:58 AM, Nikos Mavrogiannopoulos <nmav@redhat > .com> wrote: > > That's intentional. > > And misguided. It violates the layering.
That's a respectable opinion. I disagree. > > 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. So you point is that as long as you don't use OCSP responses there is no interoperability issue. That's very interesting point. More interestingly you delegate that definition to an application profile. Could you refer to such application profiles for TLS which define how OCSP responses are to be used? regards, Nikos _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
