[lamps] Re: [EXT] Re: [TLS] Re: Re: TLS Client Certificates; a survey

["Blumenthal, Uri - 0553 - MITLL" <[e-mail]>]

First — it’s a question who hitchhiked on what, but I’ll leave it alone. Also, when I authenticate my browser’s TLS connection to an email server via PIV smartcard (seems to fit whatever you guys call “webPKI”?) — what EKU do you expect to see in my certificate? (Hopefully, not SAN with domain name? I assure you my identity does not include one! 😉)


I don’t understand where you get the idea that CN/DN would get “only a domain name”. In your PKI — perhaps; definitely not in mine.
Regardless, unlike IPsec/IKE that that is described as a peer-to-peer protocol (Initiator and Responder — but not Client and Server), TLS has been defined as a Client-Server protocol. Thus, both ends presenting “TLSServerAuth” EKU appears weird.
--
V/R,
Uri Blumenthal Voice: [phone] 
Secure Resilient Systems and Technologies Cell: [phone]
MIT Lincoln Laboratory 
244 Wood Street, Lexington, MA 02420-9108 

Web: https://www.ll.mit.edu/biographies/uri-blumenthal <color: rgb(113, 60, 86); margin-top: 0px; margin-bottom: 0px;> 
Root CA: https://www.ll.mit.edu/llrca2.pem <color: rgb(113, 60, 86); margin-top: 0px; margin-bottom: 0px;> 

There are two ways to design a system. One is to make it so simple there are obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.
- C. A. R. Hoare

I was a shepherd to fools
Causelessly bold or afraid.
They would not abide by my rules.
Yet they escaped. For I stayed.
R. Kipling “Epitaphs of the War. Convoy Escort”




From: Seo Suchan <[e-mail]>
Date: Tuesday, March 31, 2026 at 21:24
To: Blumenthal, Uri - 0553 - MITLL <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: [lamps] Re: [EXT] Re: [TLS] Re: Re: TLS Client Certificates; a survey


This Message Is From an External Sender 


But this is about clientauth certificates that hitchhiked on WebPKI, so only CN/DN it will get is a domain name too.



On 2026년 4월 1일 오전 10시 1분 46초 GMT+09:00, "Blumenthal, Uri - 0553 - MITLL" <[e-mail]> 작성함:
Client cert (obviously) proves client identity. Depending on the use case (aka, what the client in question actually is), it could - though typically unlikely - be SAN. But anybody sane would use CN/DN, which was what the certificates were supposed to authenticate. 


Example: I authenticate to a server via certificate on a smartcard. You don’t think that cert contains a server name, I hope? It contains my name, proving to the server that it’s the “possessor” of the token (issued to me) on the other end of this TLS connection. 


—
Regards,
Uri


Secure Resilient Systems and Technologies
MIT Lincoln Laboratory


On Mar 31, 2026, at 20:48, Seo Suchan <[e-mail]> wrote:



This Message Is From an External Sender
This message came from outside the Laboratory.



I kinda think from what certificates in mTLS try to proof, in most time if SAN is domain name Serverauth is more appropriate. aren't client try to proof it's server node XX and this is message for it's users behalf? I have hard time to understand what clientauth certificate for example.com would try to claim, public or not.
26. 4. 1. 09:25에 Blumenthal, Uri - 0553 - MITLL 이(가) 쓴 글:
I have no stake in this fight, as my CAs will do whatever’s appropriate for our use cases, regardless.


But for mTLS, when both client and server expect to authenticate each other via certificates — what KU/EKU is the client’s certificate supposed to have, to ensure it is allowed to authenticate a TLS client? And why the asymmetry (no pun intended) — server does provide a use-case-specific EKU, but a client doesn’t???
--
V/R,
Uri



From: David Adrian <[e-mail]> <58329727-4e14-476e-b522-ff29edc0854c>
Date: Tuesday, March 31, 2026 at 20:01
To: Mike Ounsworth <[e-mail]> <30123228-8b4d-4934-8bef-c736c454b18c>
Cc: Nico Williams <[e-mail]> <9030c577-75e4-4437-a1d5-8828cc014697>, David Benjamin <[e-mail]> <85f8bf22-355f-4e3a-b709-504e5a9c2207>, Salz, Rich <rsalz=[e-mail]> <39ef0cf4-92b9-49dd-b787-0e90a92ca4cf>, Tls <[e-mail]> <e714a74d-b44b-4bab-8362-0ee64d762514>, [e-mail] <43735ef5-9d41-4373-9fe7-6d5bc62e2c9b> <[e-mail]> <4b558736-1795-4208-926d-1e6cb9cd6058>
Subject: [EXT] [lamps] Re: [TLS] Re: Re: TLS Client Certificates; a survey


This Message Is From an External Sender
This message came from outside the Laboratory.



> > Does the IETF have a Liason to the Chrome Root Program?
> 
> + @David Benjamin and @David Adrian both participate in IETF.

Speaking for the Chrome Root Program [1], the policy does not introduce a blanket prohibition on all CAs from issuing TLS certificates containing both clientAuth and serverAuth EKUs. Rather, after March 15, 2027, the Chrome Root Store will, by default, only include anchors representing serverAuth-only hierarchies.

This does not preclude CAs from:
- Continuing to issue from hierarchies that may be trusted elsewhere
- Issuing clientAuth certificates from a new hierarchy

Nothing also stops non-Chrome clients from altering the content of their trust stores to trust CAs relevant to their use case.

History has taught us that commingling PKI use cases causes more harm than good. It is a consistent security problem when PKI hierarchies intended for public web sites get entangled in non-web use cases. As an example, such behavior slowed the deprecation of SHA-1 in 2018 because payment card terminal implementations and their corresponding root stores could not be updated.

The plan to move to serverAuth only was first communicated to CA Owners at a CABF meeting in 2021 [2]. It is designed to prevent more situations like the one above from happening in the future.

[1]: https://googlechrome.github.io/chromerootprogram/#introduction <b8ecfe8e-c6b0-4d98-a527-5e39faeb9ac7>
[2]: https://drive.google.com/file/d/1pwhslUTqqkJci84nzyP4jUEmop4MeSVP/view <8e4a7a14-40d6-44ad-b876-a87b20adef04>


On Mon, Mar 30, 2026 at 4:53 PM Mike Ounsworth <[e-mail] <2eed0562-4e3c-41ca-a0da-9b4826adc12d>> wrote:
> Does the IETF have a Liason to the Chrome Root Program?


+ @David Benjamin <772192e8-0ae1-4d55-a7d3-0d8558343eac> and @David Adrian both participate in IETF.


On Mon, 30 Mar 2026 at 15:40, Nico Williams <[e-mail] <aa796e94-2468-457f-853b-b5c3feef1d2e>> wrote:
On Mon, Mar 30, 2026 at 08:04:54PM +0000, Salz, Rich wrote:
> The overwhelming response (strong consensus) — both posted and via
> private replies — is that applications will just switch to
> TLS-Server-Auth identities for the client side.

That violates RFCs 5280 & 8446 and vitiates the Chrome Root Program's
new policy. Whatever problem that policy change meant to addres might
only be made worse by this approach (sure, only for those apps that
implement this workaround, but for those, yes, it will be worse).

There has to be a better way.

Does the IETF have a Liason to the Chrome Root Program? Can we reach
out to them and ask them? When I did they simply did not respond, but
if the IETF TLS and/or LAMPS WG chairs, or IETF Security ADs reach out
to them perhaps they'll respond -- failing that then maybe the IETF
Chair or the IAB.

Nico
--

_______________________________________________
Spasm mailing list -- [e-mail] <cbbbea6d-891e-42ae-af1b-c4a38615c070>
To unsubscribe send an email to [e-mail] <aa8e755b-acd1-428f-be0a-2b6c48f764db>
_______________________________________________
TLS mailing list -- [e-mail] <e5e25659-c889-492f-b116-3efa3dfc80f1>
To unsubscribe send an email to [e-mail] <524c1d73-3023-417c-ad68-b0007292f0af>



_______________________________________________ Spasm mailing list -- [e-mail] <d6a58b98-ea01-409b-aa38-79242467ab2e> To unsubscribe send an email to [e-mail] <530e0b90-02c3-45dd-a9a0-f86e7f5f7d9e> 
_______________________________________________
Spasm mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]