On Tue, Nov 19, 2019, at 11:21, Martin Thomson wrote: > On Tue, Nov 19, 2019, at 10:56, Nick Sullivan wrote: > > The text could be amended to say something like: > > "the allowed extensions for client-generated authenticator requests > > need to have CH listed, and for server-generated authenticator requests > > need to have CR listed" > > The only current extension that supports CR, but not CH is oid_filters, > > which is not relevant to client-initiated authenticator requests. > > I like this resolution.
After discussion at the meeting, I think that I would also be OK with a new Client Certificate Request message type. That means defining what extensions are valid, but I think that this can be done quickly by copying Certificate Request and adding SNI. I think that some code might be able to use the tuple of (role, message type) to decide on what extensions are valid, but a new message type would be a more cautious approach. _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
