Hi Dennis, RFC 7250 Section 4.1 says:
If the client has no remaining certificate types to send in the client hello, other than the default X.509 type, it MUST omit the client_certificate_type extension in the client hello. That seems to explicitly exclude sending the single entry 0 to me. Regards, Jonathan On Thu, 4 Apr 2024, 16:43 Dennis Jackson, <ietf= 40dennis-jackson...@dmarc.ietf.org> wrote: > Hi Jonathan, > > My reading of RFC 7250 is the same as Mohits. Although the RFC talks about > raw public keys and a new codepoint for them, it is building on RFC 6091 > which defined a similar extension and the X509 codepoint. > > It seems fine for you to send the client_certificate_type extension with > the single entry 0 (X509). You also have the option of using a value > assigned for private use (224 and up) for your specific use case of > indicating a search engine crawler willing to provide a client cert. > > Best, > Dennis > On 04/04/2024 11:17, Jonathan Hoyland wrote: > > Hi all, > > Thanks for the feedback here. > > With respect to RFC 7250, as I mentioned earlier on list, there seen to be > two issues. First it changes the semantics of the extension slightly, and > second the RFC explicitly excludes x.509 certs. > > IIUC the semantics of the extension are "I have a weird client cert", not > "I have a client cert". > > With respect to whether this needs to be a working group item, I'm not > particularly averse to this being an independent document if that's where > the WG thinks it should go. > In my opinion, however, there are two things that it would be good to get > input from the TLS WG on. > > One, this is a change from all previous versions of TLS in which the > client cannot induce auth, does enabling this break anyone's assumptions? > > Two, I'd like a low flag number because it saves bytes on the wire, but > there is a discussion to be had as to how common this flag will be versus > other flags. > (Non-attack) Bot traffic is very common, but it's not the majority of > traffic by any means. > > Regards, > > Jonathan > > > > On Thu, 4 Apr 2024, 01:17 Christopher Patton, <cpatton= > 40cloudflare....@dmarc.ietf.org> wrote: > >> 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 >> > > _______________________________________________ > TLS mailing listTLS@ietf.orghttps://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
