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

[Ryan Dickson]

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://www.chromium.org/Home/chromium-security/root-ca-policy/#4-dedicated-tls-server-authentication-pki-hierarchies>
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://cabforum.org/uploads/5-CABF-F2F-60-Chrome-Browser-Update.pdf>), 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> 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 <+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
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20240516/78e3dc84/attachment-0001.html>