[Servercert-wg] [External Sender] Discussion about single-purpose client authentication leaf certificates issued from a server TLS Issuing CA

Thu May 16 15:08:16 UTC 2024

Hey Ryan,
Please note that I sent a correction saying that…
Where I said “you can’t propose clientAuth-only certs that work in Chrome”
I wanted to say “you can’t propose clientAuth-only certs that chain to Chrome Store”

Now, about your question, I don’t think that there’s a use case where the browser can decide which issuer to trust or not when processing a clientAuth certificate. This is a decision of the application that is consuming the certificate for the authentication.

But, on the other hand, we did find also (as mentioned by Dimitris in the form of public tenders) situations where the customer expected clientAuth certificates that were issued under a certain “compliance umbrella”, which in most cases translates in their mind to be trusted but all the relevant Root Programs… In our case, we do issue some clientAuth certs, from the same CAs that are used for personal certs, and so far it seems fine for our particular needs, but maybe we could struggle to fulfil some customer expectations if we only had Roots trusted for serverAuth purposes and we gave them a clientAuth cert that “seems untrusted” (even if not relevant in practice).

In particular, as far as I remember we only found an interoperability issue with Android, as (unless my memory fails me, something that happens) the strong authentication with clientAuth was not working because the client cert was not under a trusted chain.

Right now, the only Root Program that seems to consider clientAuth certs is Microsoft[1], and in their particular case they require WTCA audits, not WTBR.

In summary, I don’t have any strong opinion here. But maybe it could be found beneficial to establish that compliance criteria to set minimums acceptable for these certs, when issued from a CA that is trusted for serverAuth purposes… maybe...

BR/P

[1] https://learn.microsoft.com/en-us/security/trusted-root/audit-requirements

> On 16 May 2024, at 16:02, Ryan Dickson <ryandickson at google.com> wrote:
> 
> Hi Pedro,
> 
> Sharing our perspective below:
> 
> > I don’t know if you didn’t mention Chrome for a particular reason, but actually that’s the Root program that makes me scratch my head while reading these discussions… because AFAIK they only include Roots for TLS serverAuth purposes, and not for clientAuth. So (again AFAIK, I may be wrong) you can’t propose clientAuth-only certs that work in Chrome unless these come from a Root that is included for TLS serverAuth.
> 
> For applicants to the Chrome Root Store, your description above is correct. Specifically, our current expectations for applicant hierarchies are described in Section 4 <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.chromium.org_Home_chromium-2Dsecurity_root-2Dca-2Dpolicy_-234-2Ddedicated-2Dtls-2Dserver-2Dauthentication-2Dpki-2Dhierarchies&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AFTYu1HAQdkStwzgxyDbKOLyDwTHEezL5yeqoxeZ0fc&m=kXyArKCCVIqitaP6Uq7rVvwQDnuSe1MGTZswZGso_L9LYYi3KBLXOg-dmRCOV2Kq&s=nElULCZFCaU40AtnBW82KQdRdcgtLfQUWZ6lX8Xj5WA&e=> of our policy (which, for now, allows the clientAuth EKU so long as it’s accompanied by the serverAuth EKU).
> 
> As I understand it, common use cases for clientAuth include smart card logon and mTLS. Neither of these cases are relevant to browsers for the purpose of establishing encrypted connections to websites. They, instead, are relevant to the relying party servers looking to authenticate someone or something (e.g., another server or a device) before granting access or initiating communications. 
> 
> During our last F2F update (October 2023 <https://urldefense.proofpoint.com/v2/url?u=https-3A__cabforum.org_uploads_5-2DCABF-2DF2F-2D60-2DChrome-2DBrowser-2DUpdate.pdf&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AFTYu1HAQdkStwzgxyDbKOLyDwTHEezL5yeqoxeZ0fc&m=kXyArKCCVIqitaP6Uq7rVvwQDnuSe1MGTZswZGso_L9LYYi3KBLXOg-dmRCOV2Kq&s=Icbe8ZErIf-QdVWXmRdIp5rWmOCoGpobxLCNwBp2epQ&e=>), we described future exploration related to phasing out clientAuth use cases from the CAs included in the Chrome Root Store. From our perspective, de-coupling public and private PKI use cases such as mTLS creates opportunities for increased simplicity (e.g., help focus policies, profiles, and corresponding practices with intended relying party use cases) and agility (e.g., automation). Doing so also presents the opportunity for CA Owners to better serve their unique customer enterprise use cases without being beholden to root program policies, and possibly even the BRs. We are and will continue to explore this proposed change.
> 
> Are you, or anyone else, able to share:
> (1) a use case for how or why browsers need to rely on the clientAuth EKU for establishing encrypted connections to websites?
> (2) the perceived benefit to root program operators and their product users for supporting clientAuth use cases in the root stores that are intended to serve website authentication use cases? 
> 
> Thanks,
> Ryan (on behalf of the Chrome Root Program)
> 
> 
> On Thu, May 16, 2024 at 5:20 AM Pedro FUENTES via Servercert-wg <servercert-wg at cabforum.org <mailto:servercert-wg at cabforum.org>> wrote:
>> Hello Dimitris,
>> I’m following closely this as I find very important.
>> 
>> About…
>>> This is easy to answer. Some use cases need single-purpose client authentication certificates. There are numerous use cases where client authentication certificates are used for strong authentication, I'm sure you are aware of such use cases. While client authentication use cases can ALL be supported by non-public CAs, there are some regulatory requirements that demand such certificates be issued from an audited and publicly-trusted CA. In fact, HARICA has participated in public tenders where client authentication certificates need to be issued from a CA that chains to Apple, Microsoft and Mozilla Root Stores. Client authentication certificates are asked in addition to server TLS certificates.
>> 
>> 
>> I don’t know if you didn’t mention Chrome for a particular reason, but actually that’s the Root program that makes me scratch my head while reading these discussions… because AFAIK they only include Roots for TLS serverAuth purposes, and not for clientAuth. So (again AFAIK, I may be wrong) you can’t propose clientAuth-only certs that work in Chrome unless these come from a Root that is included for TLS serverAuth.
>> 
>> Apart of that, just to say that my current understanding is that the BR as they are today don’t allow the issuance of these certificates, so maybe it’s more pragmatic to assume the status-quo, and focus the discussion if the BR should be modified to implicitly or explicitly allow this.
>> 
>> Just my two cents…
>> 
>> P 
>> 
>> 
>> 
>> WISeKey SA
>> Pedro Fuentes
>> CSO - Trust Services Manager
>> Office: + 41 (0) 22 594 30 00 <tel:+41%2022%20594%2030%2000>
>> Mobile: + 41 (0) 791 274 790
>> Address: Avenue Louis-Casaï 58 | 1216 Cointrin | Switzerland
>> Stay connected with WISeKey <http://www.wisekey.com/>
>> 
>> THIS IS A TRUSTED MAIL: This message is digitally signed with a WISeKey identity. If you get a mail from WISeKey please check the signature to avoid security risks
>> 
>> CONFIDENTIALITY: This email and any files transmitted with it can be confidential and it’s intended solely for the use of the individual or entity to which they are addressed. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. If you have received this email in error please notify the sender
>> 
>> DISCLAIMER: WISeKey does not warrant the accuracy or completeness of this message and does not accept any liability for any errors or omissions herein as this message has been transmitted over a public network. Internet communications cannot be guaranteed to be secure or error-free as information may be intercepted, corrupted, or contain viruses. Attachments to this e-mail are checked for viruses; however, we do not accept any liability for any damage sustained by viruses and therefore you are kindly requested to check for viruses upon receipt.
>> 
>> _______________________________________________
>> Servercert-wg mailing list
>> Servercert-wg at cabforum.org <mailto:Servercert-wg at cabforum.org>
>> https://lists.cabforum.org/mailman/listinfo/servercert-wg <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cabforum.org_mailman_listinfo_servercert-2Dwg&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AFTYu1HAQdkStwzgxyDbKOLyDwTHEezL5yeqoxeZ0fc&m=kXyArKCCVIqitaP6Uq7rVvwQDnuSe1MGTZswZGso_L9LYYi3KBLXOg-dmRCOV2Kq&s=mnfqiM5Phhlnf-Tpz3d9oDfOeepsntKogke_tgXdF9M&e=>

WISeKey SA
Pedro Fuentes
CSO - Trust Services Manager
Office: + 41 (0) 22 594 30 00
Mobile: + 41 (0) 791 274 790
Address: Avenue Louis-Casaï 58 | 1216 Cointrin | Switzerland
Stay connected with WISeKey <http://www.wisekey.com/>

THIS IS A TRUSTED MAIL: This message is digitally signed with a WISeKey identity. If you get a mail from WISeKey please check the signature to avoid security risks

CONFIDENTIALITY: This email and any files transmitted with it can be confidential and it’s intended solely for the use of the individual or entity to which they are addressed. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. If you have received this email in error please notify the sender

DISCLAIMER: WISeKey does not warrant the accuracy or completeness of this message and does not accept any liability for any errors or omissions herein as this message has been transmitted over a public network. Internet communications cannot be guaranteed to be secure or error-free as information may be intercepted, corrupted, or contain viruses. Attachments to this e-mail are checked for viruses; however, we do not accept any liability for any damage sustained by viruses and therefore you are kindly requested to check for viruses upon receipt.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20240516/e505bae2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3407 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20240516/e505bae2/attachment-0001.p7s>