> 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
