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

[Dimitris Zacharopoulos (HARICA)]

On 16/5/2024 12:20 μ.μ., Pedro FUENTES 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,

No particular reason. It's just a relatively new Root Program compared 
to others and I haven't bumped into a public tender that requires it :)

> 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.

AFAIK Apple and Mozilla also don't have a specific "trust bit" for 
Client Authentication. Only Microsoft does.

>
> 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,

Sure, but that's not what we are discussing here. We are looking whether 
this was done "on purpose" or "by accident"

> 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.

I don't want to assume the status-quo is here to stay without a 
confirmation that the current rules are intended to be this way. If they 
were not intended and there is no opposition to keeping this 
restriction, fine. We will just add some language to clarify this.

If there is opposition and CAs want to allow the right to issue 
clientAuth Certificates from serverTLS issuing CAs, then we need to 
discuss more. I'm not sure if there are any other options.


Dimitris.

>
> Just my two cents…
>
> P
>
>
> *
> 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/3beb5d9a/attachment.html>