Well, sounds like it's an open issue My view is that it should be explicitly allowed, but I don't feel that strongly about it. I do, however, feel strongly that the draft should say explicitly one way or the other.
On Mon, May 9, 2022 at 8:10 AM Yoav Nir <ynir.i...@gmail.com> wrote: > > > > On 14 Apr 2022, at 1:51, Benjamin Kaduk <bkaduk= > 40akamai....@dmarc.ietf.org> wrote: > > > > On Wed, Apr 13, 2022 at 10:56:49AM -0700, Eric Rescorla wrote: > >> Consider the case where the client wants to offer some capability that > >> the server then responds to with real data, rather than just an > >> acknowledgement. > >> > >> For instance, supposing the SCT extension from RFC 6962 did not exist, > >> the client would want to indicate support in CH and the server would > >> send the SCT in CERT, but this extension would need to be non-empty > >> and hence not a flag. draft-ietf-tls-tlsflags-09 seems a bit > >> uncelar on this point (unless I'm missing it) but I think we > >> should explicitly allow it. > > > > In my head this was already disallowed. I couldn't swear to whether > > we actually talked about it previously or not, though. > > I’m pretty sure we haven’t discussed this (or at least, I wasn’t in the > room). In my head it’s also disallowed. In the text, it’s not explicitly > disallowed, but the text does talk about response flags that are in flag > extensions, not about responses that are in other extensions or other > messages. So implicitly disallowed? > > Yoav > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
