On Thu, Nov 21, 2019 at 10:35:34AM +0800, Martin Thomson wrote: > 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.
I would also be okay with a ClientCertificateRequest. It may not strictly be needed, but it's the safe/conservative option. -Ben _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
