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

[Clint Wilson via Servercert-wg]

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

FWIW, Apple does indeed have a specific trust bit for id-kp-clientAuth EKU and 
allows for (and ships) dedicated clientAuth Root CAs in the Apple Root Program 
(as outlined in 2.1.3 of the ARP Policy).



smime.p7s
Description: S/MIME cryptographic signature
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

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

[Clint Wilson via Servercert-wg]

> On May 16, 2024, at 1:19 AM, Dimitris Zacharopoulos (HARICA) 
>  wrote:
> 
> 
> 
> On 15/5/2024 11:07 μ.μ., Clint Wilson wrote:
>> Hi Dimitris,
>> 
>> I guess I’m confused about how this is relevant to the scope of the CA/BF as 
>> it seems quite orthogonal to the questions you posed initially. Regardless 
>> of how clients check certificates, the question is about the issuance of a 
>> certificate.
>> As a side-note, the question that comes to mind for me is what would be the 
>> reason to allow issuance of clientAuth-only certificates by a subCA that 
>> also issues TBR-compliant TLS certificates? Why is such a thing necessary or 
>> valuable? 
> 
> 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.
> 
> The good practice here is for the CA to create a TC non-TLS SubCA that 
> includes the id-kp-clientAuth EKU and issue single-purpose client 
> authentication certificates off of that TC SubCA. However, some CAs might 
> have used a TLS SubCA, that also includes the id-kp-clientAuth EKU, to issue 
> those single-purpose client authentication certificates. This was allowed 
> before SC-62.

Right, fully agreed here — and a step further, beyond being a good practice, I 
think it’s the only compliant practice. The way to do this is through a 
dedicated clientAuth subCA if using a multi-purpose Root CA.

> 
>> Regardless of the conclusion to the questions you posed, I’m failing to see 
>> why we would want any other outcome than to have subCAs which issue 
>> TBR-compliant TLS certificate always and only issue TBR-compliant TLS 
>> certificates. Perhaps if you could help me understand the motivations behind 
>> seeking clarity on this, I would be better able to understand how/why these 
>> questions have been posed (even if those motivations are simple idle 
>> curiosity, that would still help).
> 
> I don't object to the change of the goal from "we don't really care so much 
> about non-TLS server leaf certificates" to "we only want server TLS-capable 
> CAs to issue server TLS leaf certificates". There's a difference. I'm trying 
> to establish if the prohibition of single-purpose clientAuth certs was 
> intended in SC-62 or not. To the best of my recollection, we didn't intend to 
> enforce that, "only server TLS leaf certificates are to be issued from server 
> TLS-capable Issuing CAs".

(Just to confirm, you don’t object to this change?)
Ah, this is quite interesting (genuinely) as my understanding is that one of, 
if not the, primary goals of SC-62 was to ensure only TLS leaf certificates 
could be issued from server TLS-capable CAs. This was done by ensuring the 
allowed uses of CA Key material in-scope of the TBRs are comprehensively 
defined as certificate profiles.

> 
> This is why I insisted in establishing the past motivation before the group 
> decides where to go. Based on this outcome , we can add more clarity in the 
> BRs. To put this very clearly, if we didn't intend to enforce that only 
> server TLS leaf certs should be issued from server TLS-capable CAs, then the 
> current language that prohibits issuance of single-purpose client 
> authentication certificates from server TLS-capable CAs, is an unintended 
> prohibition that we should fix it. If no CA is interested to lift this 
> prohibition, then we should just add clarification language that every 
> certificate issued from a server TLS-capable Issuing CA is in scope of the 
> TLS BRs and it MUST be a leaf server-TLS Certificate which MAY have 
> additional EKUs (as described in the corresponding table in the BRs). If the 
> group decides to lift this unintended prohibition, we could add rules around 
> the policy OIDs (e.g. that the TLS BR OIDs must not be used in no-TLS server 
> certificates).

This makes sense to me; it is relevant to understand the intended outcome in 
addition to the outcome itself. I think there’s agreement that the outcome 
itself has been to prohibit the issuance of single-purpose client 
authentication certificates from server TLS-capable CAs. 
As far as the intended outcome, I believe that’s roughly the same as the 
outcome itself, though there was also discussion of further updates with the 
hypothetical future “Profiles 2.0” ballot that a fair number of items were 
pushed off to. For example, the current allowance for anyPolicy in som

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

[Pedro FUENTES via Servercert-wg]

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

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

[Ryan Dickson via Servercert-wg]

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

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
), 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@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 *
> *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

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

[Dimitris Zacharopoulos (HARICA) via Servercert-wg]

On 16/5/2024 3:21 μ.μ., Dimitris Zacharopoulos (HARICA) via 
Servercert-wg wrote:

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 :)


 that requires it for Client Authentication-only Certificates.
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

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

[Dimitris Zacharopoulos (HARICA) via Servercert-wg]

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 
*
*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@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

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

[Pedro FUENTES via Servercert-wg]

Sorry, small correction… 

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”

P

> On 16 May 2024, at 11:20, Pedro FUENTES via Servercert-wg 
>  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
> Mobile: + 41 (0) 791 274 790
> Address: Avenue Louis-Casaï 58 | 1216 Cointrin | Switzerland
> Stay connected with WISeKey 
> 
> 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@cabforum.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cabforum.org_mailman_listinfo_servercert-2Dwg&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY&m=FoiL3YKgLoj4pSwEwQdSP6wZzGRgoPtagCFxqp-vMieN_TeL8CXf_lT-0BeNrYpH&s=2CiAgBrT9g5pxby_GDhFV1zWp5FIYZw7eXRDRSOnP8k&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 

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.



smime.p7s
Description: S/MIME cryptogra

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

[Pedro FUENTES via Servercert-wg]

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
Mobile: + 41 (0) 791 274 790
Address: Avenue Louis-Casaï 58 | 1216 Cointrin | Switzerland
Stay connected with WISeKey 

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.



smime.p7s
Description: S/MIME cryptographic signature
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

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

[Dimitris Zacharopoulos (HARICA) via Servercert-wg]

On 15/5/2024 11:07 μ.μ., Clint Wilson wrote:

Hi Dimitris,

I guess I’m confused about how this is relevant to the scope of the 
CA/BF as it seems quite orthogonal to the questions you posed 
initially. Regardless of how clients check certificates, the question 
is about the issuance of a certificate.
As a side-note, the question that comes to mind for me is what would 
be the reason to allow issuance of clientAuth-only certificates by a 
subCA that also issues TBR-compliant TLS certificates? Why is such a 
thing necessary or valuable?


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.


The good practice here is for the CA to create a TC non-TLS SubCA that 
includes the /id-kp-clientAuth/ EKU and issue single-purpose client 
authentication certificates off of that TC SubCA. However, some CAs 
might have used a TLS SubCA, that also includes the /id-kp-clientAuth 
/EKU, to issue those single-purpose client authentication certificates. 
This was allowed before SC-62.


Regardless of the conclusion to the questions you posed, I’m failing 
to see why we would want any other outcome than to have subCAs which 
issue TBR-compliant TLS certificate always and only issue 
TBR-compliant TLS certificates. Perhaps if you could help me 
understand the motivations behind seeking clarity on this, I would be 
better able to understand how/why these questions have been posed 
(even if those motivations are simple idle curiosity, that would still 
help).


I don't object to the change of the goal from "we don't really care so 
much about non-TLS server leaf certificates" to "we only want server 
TLS-capable CAs to issue server TLS leaf certificates". There's a 
difference. I'm trying to establish if the prohibition of single-purpose 
clientAuth certs was intended in SC-62 or not. To the best of my 
recollection, we didn't intend to enforce that, "only server TLS leaf 
certificates are to be issued from server TLS-capable Issuing CAs".


This is why I insisted in establishing the past motivation before the 
group decides where to go. Based on this outcome , we can add more 
clarity in the BRs. To put this very clearly, if we didn't intend to 
enforce that only server TLS leaf certs should be issued from server 
TLS-capable CAs, then the current language that prohibits issuance of 
single-purpose client authentication certificates from server 
TLS-capable CAs, is an unintended prohibition that we should fix it. If 
no CA is interested to lift this prohibition, then we should just add 
clarification language that every certificate issued from a server 
TLS-capable Issuing CA is in scope of the TLS BRs and it MUST be a leaf 
server-TLS Certificate which MAY have additional EKUs (as described in 
the corresponding table in the BRs). If the group decides to lift this 
unintended prohibition, we could add rules around the policy OIDs (e.g. 
that the TLS BR OIDs must not be used in no-TLS server certificates).




However, leaving aside that there’s likely some level of ignorance on 
my part, to the extent I understand it, the question at hand is 
essentially:


Is it compliant for a CA, that wants to be considered compliant
with the TBRs, to issue a certificate which asserts compliance
with the TBRs — by way of including an OID under the CA/BF OID arc
defined to represent a certificate’s compliance with the Policy
document associated with that OID — where the issued certificate
does not match one of the profiles defined in Section 7.1 of the TBRs?


Breaking this apart, there are several aspects to consider.

First, does the CA want to be considered compliant with the TBRs? If 
not, then it doesn’t matter which TBR OIDs they assert because they’re 
not intending to be considered compliant. If the CA doesn’t have a 
relying party they’re expecting to rely on their assertions in 
general, then the rest of the question is relatively moot; on the 
other hand, if the CA’s assertions are intended to be accurate and 
treated as such, then it’s a pretty important foundational point I 
think. For the purposes of this discussion, I’m assuming the CA does 
want to be considered compliant with the TBRs because if that’s not 
the case then the conclusions to the rest of this don’t really matter.


Correct. Single-purpose Client Authentication Certificates (and 
simil