I think I only allow the server to set bits that had been set by the client.
A server that supports this extension and also supports at least one of the flag-type features that use this extension and that were declared by the ClientHello extension SHALL send this extension with the intersection of the flags it supports with the flags declared by the client. > On 29 Mar 2019, at 22:30, Martin Thomson <m...@lowentropy.net> wrote: > > In addition to this, the document would seem to allow a server to set bit k > if the client did not set that bit. (Or more generally, the responder can set > bits the initiator did not set. ) > > In fitting with the TLS model, I would recommend allowing a responder to set > only bits that the initiator sets. Other bits being set would be an error. > > On Fri, Mar 29, 2019, at 19:59, John Mattsson wrote: >> Hi, >> >> The document only talks about use in ClientHello, ServerHello, and >> EncryptedExtensions. I think it should also discuss usage in >> CertificateRequest, Certificate from the server, and Certificate from >> the client. It should likely be left to the document that specifies a >> specific feature to determine where it can be used. >> draft-thomson-tls-sic-00 uses the tls_flags extension in >> CertificateRequest. >> >> Cheers, >> John >> >> >> _______________________________________________ >> 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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
