On Fri, 18 Jul 2025 at 19:37, Eric Rescorla <[email protected]> wrote: > I've now had a chance to look at this draft.
Thanks! On this point: > In terms of the integration with TLS, I don't think the negotiation > structure is quite right. Specifically, you indicate support for this > mechanism with a CMW_Attestation flag in CH, which is then > acknowledged in EE, but then you provide the actual data in a > different extension (cmw_attestation) in Certificate. There are > two problems here: > > 1. You can't use flags this way. > 2. CH is generally not the right place. > > For point 1, draft-ietf-tls-tlsflags explicitly prohibits the use of a > flag to signal an actual extension: > > For a flag that does require a response, the only proper response is > the same flag in a flags extension. This extension MUST NOT be used > to specify extensions where the response is a proper extension with > content. Essentially, we want a feature flag that the peers can negotiate before the feature is used. Having an upfront signal allows the peers to fall back to "normal" TLS if one of them is not implementing expat -- provided that falling back is still considered acceptable by the RP. In this mode of use, no other content needs to be exchanged apart from "I want to do expat; can you do it too?", "yes/no". Therefore, the use of flags seemed appropriate since the "response" is just the acknowledgement of the feature flag. The attestation credential carried in the cmw_attestation is instead a response to the authenticator request. That being said, I may be misunderstanding something important. (Note also that this is just an initial proposal for negotiation and that richer signals could be added to this phase in future, which would require something entirely different from a simple flag.) cheers, t _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
