It would be great to here from Jonathan (the author) if RFC 7250 is already
sufficient for this use case.

On Tue, Apr 2, 2024 at 10:23 PM Mohit Sethi <mo...@iki.fi> wrote:

> Please see my earlier comment regarding this draft:
> https://mailarchive.ietf.org/arch/msg/tls/g3tImSVXO8AEmPH1UlwRB1c1TLs/
>
> In summary: the functionality of this draft is already achievable by
> using the client_certificate_type extension defined in RFC 7250:
> https://datatracker.ietf.org/doc/html/rfc7250 with certificate type
> value = 0:
>
> https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-3
> .
>
> The table in section 4.2 of RFC8446 even mentions that the extension can
> be included in the ClientHello:
> https://datatracker.ietf.org/doc/html/rfc8446#section-4.2, thereby
> ensuring that the server sends a CertificateRequest message in response
> to the ClientHello received.
>
> OpenSSL already implements this extension since it was needed for
> support raw public keys (RPKs).
>
> As stated earlier: if it is indeed the case that the
> client_certificate_type extension is suitable for the use-case, then
> perhaps it is preferable to not have a separate flag. Otherwise, it
> would make the state machine at the server more complicated (for
> example: handling a ClientHello with both the mTLS flag and the
> client_certificate_type extension.
>
> Therefore, like Ekr, I am mildly negative on adopting this document but
> for different reasons.
>
> --Mohit
>
> On 4/3/24 00:52, Sean Turner wrote:
> > At the IETF 119 TLS session there was some interest in the mTLS Flag I-D
> (
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-jhoyla-req-mtls-flag%2F&data=05%7C02%7Cmohit.sethi%40aalto.fi%7C42877de6d3d64135e49e08dc534a463b%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638476825681199391%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=ERzWFcuBlAfobNyGCcgKDhCl9wex9LOQ%2F3yPYC7idfU%3D&reserved=0);
> also, see previous list discussions at [0]. This message is to judge
> consensus on whether there is sufficient support to adopt this I-D.  If you
> support adoption and are willing to review and contribute text, please send
> a message to the list.  If you do not support adoption of this I-D, please
> send a message to the list and indicate why.  This call will close on 16
> April 2024.
> >
> > Thanks,
> > Deirdre, Joe, and Sean
> >
> > [0]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Ftls%2F9e2S95H9YgtHp5HhqdlNqmQP0_w%2F&data=05%7C02%7Cmohit.sethi%40aalto.fi%7C42877de6d3d64135e49e08dc534a463b%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638476825681208049%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=eEU6ZPJ5cmfqLHQuM3UYXrFKCJuKaaJVc8Ssk5erRjk%3D&reserved=0
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=05%7C02%7Cmohit.sethi%40aalto.fi%7C42877de6d3d64135e49e08dc534a463b%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638476825681214744%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=%2B9CGIKB31GI9RMQG62I1rTnbHaDPfSynvlmwrkPn%2FpQ%3D&reserved=0
>
> _______________________________________________
> 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

Reply via email to