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]

Hi Pedro,

All CAs in the Apple Root Program are required to complete an audit based on 
either WebTrust Principles and Criteria for Certification Authorities or ETSI 
EN 319 411-1 LCP, NCP, or NCP+ per Section 1.1.1 of the ARP Policy. For 
clientAuth-only CAs, these are currently the only audit criteria.

I appreciate the comment regarding TLS CAs; I’ll look at improving this 
language, but this specifically is referencing CAs capable of asserting the 
serverAuth EKU as clientAuth is not required for TLS. That is, the serverAuth 
EKU is required at a protocol level to establish a secure TLS connection, while 
the clientAuth EKU is only used in specific contexts, such as mTLS — which is 
almost always a use-case better (or perhaps more ideally) solved by Enterprise 
or Private PKIs.

Thanks!
-Clint

> On May 17, 2024, at 2:32 AM, Pedro FUENTES  wrote:
> 
> I also oversaw that…
> 
> Anyhow… @Clint, what are the audit requirements for these clientAuth CAs?
> In your program you mention WTBR as a requirement for "TLS CAs”, but there’s 
> no distinction between clientAuth or serverAuth… while both are used to 
> secure TLS handshakes.
> 
>> On 17 May 2024, at 11:22, Dimitris Zacharopoulos (HARICA) 
>>  wrote:
>> 
>> 
>> 
>> On 16/5/2024 10:29 μ.μ., Clint Wilson wrote:
 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).
>>> 
>> 
>> Thanks for the correction Clint. I had the impression that you shipped only 
>> Apple Roots for clientAuth. My bad.
>> 
>> Dimitris.
>> 
>> 
>> 
> 
> 
> 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

[Pedro FUENTES via Servercert-wg]

I also oversaw that…

Anyhow… @Clint, what are the audit requirements for these clientAuth CAs?
In your program you mention WTBR as a requirement for "TLS CAs”, but there’s no 
distinction between clientAuth or serverAuth… while both are used to secure TLS 
handshakes.

> On 17 May 2024, at 11:22, Dimitris Zacharopoulos (HARICA) 
>  wrote:
> 
> 
> 
> On 16/5/2024 10:29 μ.μ., Clint Wilson wrote:
>>> 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).
>> 
> 
> Thanks for the correction Clint. I had the impression that you shipped only 
> Apple Roots for clientAuth. My bad.
> 
> Dimitris.
> 
> 
> 


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 16/5/2024 10:29 μ.μ., Clint Wilson wrote:

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



Thanks for the correction Clint. I had the impression that you shipped 
only Apple Roots for clientAuth. My bad.


Dimitris.



___
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 10:20 μ.μ., Clint Wilson wrote:



On May 16, 2024, at 1:19 AM, Dimitris Zacharopoulos (HARICA) 
 wrote:




[...]


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


Exactly. I don't object as long as we agree on whatever it is that we 
want to go.


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.


I went through a large number of emails related to SC-62 and I couldn't 
find something concrete to support your interpretation, which is why I 
was asking for more feedback by Members that participated in those 
discussions :-)



This was done by ensuring the allowed uses of CA Key material in-scope 
of the TBRs are comprehensively defined as certificate profiles.


My recollection is that we wanted to make sure that in-scope CAs have as 
many profiles defined as possible, that's why we added profiles for OCSP 
responses and TC non-TLS subCAs that did not exist. But I don't recall 
eliminating the single-purpose clientAuth Certificates from server 
TLS-capable CAs, as the clientAuth EKU is still an allowed/supported EKU 
in the TLS BRs, although the resulting certificates are not server TLS 
Certificates and thus out of scope.






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 some circumstances would, ideally, be deprecated at 
some point. Similarly, a goal is, and has been, to move towards an 
outcome where every Root CA which asserts compliance with the TBRs 
issues _only_ serverAuth certificates (through subCAs) — SC-62 was a 
stepping stone towards that, by ensuring that at least every 
Subordinate CA capable of issuing TLS server certificates and which 
asserts compliance with the TBRs issues _only_ serverAuth certificates.


I think this intent is clear from discussions like 
https://github.com/sleevi/cabforum-docs/pull/36#discussion_r653544605


I missed that comment from Doug. I wish such important comments were 
also shared on the public list and in the mailing archives so all 
Members would get a chance to review and comment on. Back in 2021 I 
don't think all members received updates about discussions on GitHub.


or even just the description in 
https://github.com/sleevi/cabforum-docs/pull/36 (carried forward to 
https://github.com/cabforum/servercert/pull/373): (emphasis mine)


"Technically Constrained Non-TLS Subordinate CA (7.1.2.3)
This is a new profile meant to 

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 

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 authentication use cases? 
> 

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 

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=DwICAg=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY=FoiL3YKgLoj4pSwEwQdSP6wZzGRgoPtagCFxqp-vMieN_TeL8CXf_lT-0BeNrYpH=2CiAgBrT9g5pxby_GDhFV1zWp5FIYZw7eXRDRSOnP8k=


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 

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 

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]

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

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.

Second, are TBR OIDs defined by their node owner as representing compliance 
with the TLS Baseline Requirements? Based on what’s documented in 
https://cabforum.org/resources/object-registry/, I believe this is clearly the 
case. For example, issuing a certificate with the 2.23.140.1.2.2 OID is a 
representation that the “Certificate [was] issued in compliance with the TLS 
Baseline Requirements – Organization identity asserted”. Maybe this should be 
brought into 7.1.6.1 of the TBRs, but I don’t think that’s necessary to come to 
a conclusion here.

Third, does inclusion of a TBR OID in a certificate issued by such a CA 
constitute that CA asserting that certificate’s compliance with the TBRs? 
Combined with the fact that the OID itself defines this to be the case, my 
reading of Section 4.2.1.4 
 of RFC 5280[1] 
is that if a Policy OID is present in a certificate — or any certificate 
subordinate to a certificate in which it’s present — then the certificate has 
been issued under the Policy document represented by that OID.

Fourth, does a certificate which meets the above conditions (i.e. wants to be 
considered compliant, includes a TBR OID), need to match one of the profiles in 
the TBRs? Section 7.1 announces quite clearly that "the CA SHALL issue 
Certificates in accordance with the profile specified in these Requirements” 
and further reinforces in Section 7.1.2 that (emphasis mine) "If the CA asserts 
compliance with these Baseline Requirements, all certificates that it issues 
MUST comply with one of the following certificate profiles”. There are possible 
problematic interpretations of this, but I find it difficult to grasp a truly 
good-faith reading of this as meaning anything other than “Yes, a certificate 
which includes a TBR OID is asserting compliance with the TBRs and thus, the 
certificate itself must comply with one of the certificate profiles defined in 
the TBRs.” That doesn’t mean there’s not room to improve the language, 
especially in 7.1.2 (which I’ve highlighted before in Issue 495 
(https://github.com/cabforum/servercert/issues/495)). 
I personally also think the statements in 7.1 and 7.1.2 go quite a bit further 
than just this constrained example of a certificate which explicitly indicates 
its own compliance with the TBRs, but to keep the discussion focused I’m only 
opining on that specific scenario.

Fifth, does the certificate match one of the profiles defined in Section 7.1 of 
the TBRs? Here we have to look at the certificate in question, with a couple 
components quickly narrowing our search within Section 7.1. In your first 
email, you indicated the question is about a leaf 

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 7:27 μ.μ., Clint Wilson wrote:
Apologies if I’m replying to the wrong thread, but I wanted to comment 
on one point here.


On May 14, 2024, at 8:54 AM, Dimitris Zacharopoulos (HARICA) via 
Servercert-wg  wrote:




On 14/5/2024 1:27 μ.μ., Adriano Santoni via Servercert-wg wrote:


I would agree to consider out-of-scope (of the BRs) a leaf 
certificate with EKU=clientAuth issued by a SubCA that has 
EKU={server,client}, provided of course the leaf certificate does 
not assert a BR TLS policy OID because this would be contradictory.


Besides, at least one widely used linter considers a certificate 
in-scope if it contains EKU=serverAuth and/or it contains a BR 
policy OID, which seems quite logical to me.


Adriano




I think the policy OID is effectively completely ignored (along with 
anything in the subject of the certificate or other extensions) 
because the certificate is by design "incompatible for server TLS", 
so it is discarded by server TLS consumers which are conformant with 
RFC 5280.


I don’t think it’s entirely germane whether or not the policy OID is 
discarded by an application; the inclusion of the policy OID itself is 
a violation of RFC 5280 by the CA (if it’s included in a certificate 
or certificate chain where the leaf certificate being validated 
doesn’t comply with the policy referenced by the OID).


According to section 4.2.1.12 
of RFC 
5280, a conforming implementation must use the certificate if one of the 
indicated purposes of the EKU is used. In my understanding, a Browser 
implementation that expects the /id-kp-serverAuth/ EKU MUST NOT trust a 
certificate that does not include that EKU or the /anyExtendedKeyUsage/.


AFAIK there no similar strong requirement for the policy tree. For many 
years, CAs used custom Policy OIDs to indicate conformance with a 
certain standard and it was very difficult for Certificate Consumers to 
work with that information to make restrictions.


I guess my point is that the EKU is checked first, and the policy OID 
check comes later. Both must be ok for the certificate to be trusted.


Does that make sense?



Thanks!
-Clint



It is misleading, but it is very difficult to add requirements around 
what a Certificate MUST NOT include (e.g. an existing TLS BR policy 
OID). I'd prefer to clarify that these are out-of-scope of the BRs as 
long as they are structured according to RFC 5280, and do not contain 
EKU=serverAuth, just like we did for the TC non-TLS subCA Profile.


Dimitris.



Il 14/05/2024 11:33, Dimitris Zacharopoulos (HARICA) via 
Servercert-wg ha scritto:
NOTICE: Pay attention - external email - Sender is 
0100018f76738e97-739d5cad-6797-4977-b997-150e338d5740-000...@amazonses.com 





Dear Members,

Following-up on an interesting public incident 
 , I 
would like to have a discussion about the scope of the TLS BRs as 
specified in the SCWG Charter and in the actual TLS BRs, especially 
when it comes to single-purpose "client authentication" 
certificates (i.e. leaf certificates that include the 
/id-kp-clientAuth/ and DO NOT include the /id-kp-serverAuth/ 
KeyPurposeId in their extKeyUsage extension).


The TLS BRs describe the profiles of Subordinate CA Certificates 
issued from a Root that is in-scope for server TLS authentication, 
even for the case of Technically-Constrained non-TLS CA 
Certificates. There was a lot of discussion about whether this is 
permitted based on the SCWG Charter and there was consensus that 
Browsers want to make sure that there are some minimum expectations 
about the structure of such non-TLS CA certificates, especially the 
adherence to RFC 5280. I recall that there was also consensus that 
whatever is issued off of these TC non-TLS CAs is not in scope of 
the TLS BRs.


_Does this seem like a fair statement about intent of the group on 
the expectations of TC non-TLS CAs and their leaf certificates?_


Technically Constrained non-TLS Issuing CAs have a defined profile 
in the TLS BRs but IMO it cannot, and should not mandate the 
profile of non-TLS leaf certificates based on the CA/Browser Forum 
Server Certificate Working Group Charter 
 which states 
(emphasis mine):


/(a) To specify Baseline Requirements, Extended Validation 
Guidelines, and other acceptable practices for the issuance and 
management of *TLS server certificates used for authenticating 
servers accessible through the Internet*/


It gets more interesting when an Issuing CA that is technically 
capable of issuing server authentication TLS Certificates (by 
including the /id-kp-serverAuth/ KeyPurposeId in its extKeyUsage 
extension), also includes the /id-kp-clientAuth/ KeyPurposeId, thus 
being technically capable of issuing client authentication TLS 
Certificates.


Please recall that a few years back multi-purpose Issuing CAs 
existed, 

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]

Apologies if I’m replying to the wrong thread, but I wanted to comment on one 
point here.

> On May 14, 2024, at 8:54 AM, Dimitris Zacharopoulos (HARICA) via 
> Servercert-wg  wrote:
> 
> 
> 
> On 14/5/2024 1:27 μ.μ., Adriano Santoni via Servercert-wg wrote:
>> I would agree to consider out-of-scope (of the BRs) a leaf certificate with 
>> EKU=clientAuth issued by a SubCA that has EKU={server,client}, provided of 
>> course the leaf certificate does not assert a BR TLS policy OID because this 
>> would be contradictory. 
>> 
>> Besides, at least one widely used linter considers a certificate in-scope if 
>> it contains EKU=serverAuth and/or it contains a BR policy OID, which seems 
>> quite logical to me.
>> 
>> Adriano
>> 
>> 
>> 
> 
> I think the policy OID is effectively completely ignored (along with anything 
> in the subject of the certificate or other extensions) because the 
> certificate is by design "incompatible for server TLS", so it is discarded by 
> server TLS consumers which are conformant with RFC 5280.

I don’t think it’s entirely germane whether or not the policy OID is discarded 
by an application; the inclusion of the policy OID itself is a violation of RFC 
5280 by the CA (if it’s included in a certificate or certificate chain where 
the leaf certificate being validated doesn’t comply with the policy referenced 
by the OID).

Thanks!
-Clint

> 
> It is misleading, but it is very difficult to add requirements around what a 
> Certificate MUST NOT include (e.g. an existing TLS BR policy OID). I'd prefer 
> to clarify that these are out-of-scope of the BRs as long as they are 
> structured according to RFC 5280, and do not contain EKU=serverAuth, just 
> like we did for the TC non-TLS subCA Profile.
> 
> Dimitris.
> 
>> 
>> Il 14/05/2024 11:33, Dimitris Zacharopoulos (HARICA) via Servercert-wg ha 
>> scritto:
>>> 
>>> NOTICE: Pay attention - external email - Sender is 
>>> 0100018f76738e97-739d5cad-6797-4977-b997-150e338d5740-000...@amazonses.com 
>>> 
>>> 
>>> Dear Members, 
>>> 
>>> Following-up on an interesting public incident 
>>>  , I would like 
>>> to have a discussion about the scope of the TLS BRs as specified in the 
>>> SCWG Charter and in the actual TLS BRs, especially when it comes to 
>>> single-purpose "client authentication" certificates (i.e. leaf certificates 
>>> that include the id-kp-clientAuth and DO NOT include the id-kp-serverAuth 
>>> KeyPurposeId in their extKeyUsage extension).
>>> The TLS BRs describe the profiles of Subordinate CA Certificates issued 
>>> from a Root that is in-scope for server TLS authentication, even for the 
>>> case of Technically-Constrained non-TLS CA Certificates. There was a lot of 
>>> discussion about whether this is permitted based on the SCWG Charter and 
>>> there was consensus that Browsers want to make sure that there are some 
>>> minimum expectations about the structure of such non-TLS CA certificates, 
>>> especially the adherence to RFC 5280. I recall that there was also 
>>> consensus that whatever is issued off of these TC non-TLS CAs is not in 
>>> scope of the TLS BRs.
>>> 
>>> Does this seem like a fair statement about intent of the group on the 
>>> expectations of TC non-TLS CAs and their leaf certificates?
>>> 
>>> Technically Constrained non-TLS Issuing CAs have a defined profile in the 
>>> TLS BRs but IMO it cannot, and should not mandate the profile of non-TLS 
>>> leaf certificates based on the CA/Browser Forum Server Certificate Working 
>>> Group Charter  which 
>>> states (emphasis mine):
>>> 
 (a) To specify Baseline Requirements, Extended Validation Guidelines, and 
 other acceptable practices for the issuance and management of TLS server 
 certificates used for authenticating servers accessible through the 
 Internet
>>> It gets more interesting when an Issuing CA that is technically capable of 
>>> issuing server authentication TLS Certificates (by including the 
>>> id-kp-serverAuth KeyPurposeId in its extKeyUsage extension), also includes 
>>> the id-kp-clientAuth KeyPurposeId, thus being technically capable of 
>>> issuing client authentication TLS Certificates.
>>> 
>>> Please recall that a few years back multi-purpose Issuing CAs existed, 
>>> where the EKU was not present, and even if it was, it allowed the inclusion 
>>> of various KeyPurposeIds.
>>> 
>>> Is it ok for such an Issuing CA to create a single-purpose client 
>>> authentication TLS Certificate, one that is structured according to RFC 
>>> 5280 (thus can be successfully parsed by Relying Party RFC 5280-conformant 
>>> software), contains an extKeyUsage extension which contains the 
>>> id-kp-clientAuth and DOES NOT include the id-kp-serverAuth KeyPurposeId?
>>> 
>>> My understanding is that these particular leaf certificates 

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 14/5/2024 1:27 μ.μ., Adriano Santoni via Servercert-wg wrote:


I would agree to consider out-of-scope (of the BRs) a leaf certificate 
with EKU=clientAuth issued by a SubCA that has EKU={server,client}, 
provided of course the leaf certificate does not assert a BR TLS 
policy OID because this would be contradictory.


Besides, at least one widely used linter considers a certificate 
in-scope if it contains EKU=serverAuth and/or it contains a BR policy 
OID, which seems quite logical to me.


Adriano




I think the policy OID is effectively completely ignored (along with 
anything in the subject of the certificate or other extensions) because 
the certificate is by design "incompatible for server TLS", so it is 
discarded by server TLS consumers which are conformant with RFC 5280.


It is misleading, but it is very difficult to add requirements around 
what a Certificate MUST NOT include (e.g. an existing TLS BR policy 
OID). I'd prefer to clarify that these are out-of-scope of the BRs as 
long as they are structured according to RFC 5280, and do not contain 
EKU=serverAuth, just like we did for the TC non-TLS subCA Profile.


Dimitris.

Il 14/05/2024 11:33, Dimitris Zacharopoulos (HARICA) via Servercert-wg 
ha scritto:
NOTICE: Pay attention - external email - Sender is 
0100018f76738e97-739d5cad-6797-4977-b997-150e338d5740-000...@amazonses.com 





Dear Members,

Following-up on an interesting public incident 
 , I would 
like to have a discussion about the scope of the TLS BRs as specified 
in the SCWG Charter and in the actual TLS BRs, especially when it 
comes to single-purpose "client authentication" certificates (i.e. 
leaf certificates that include the /id-kp-clientAuth/ and DO NOT 
include the /id-kp-serverAuth/ KeyPurposeId in their extKeyUsage 
extension).


The TLS BRs describe the profiles of Subordinate CA Certificates 
issued from a Root that is in-scope for server TLS authentication, 
even for the case of Technically-Constrained non-TLS CA Certificates. 
There was a lot of discussion about whether this is permitted based 
on the SCWG Charter and there was consensus that Browsers want to 
make sure that there are some minimum expectations about the 
structure of such non-TLS CA certificates, especially the adherence 
to RFC 5280. I recall that there was also consensus that whatever is 
issued off of these TC non-TLS CAs is not in scope of the TLS BRs.


_Does this seem like a fair statement about intent of the group on 
the expectations of TC non-TLS CAs and their leaf certificates?_


Technically Constrained non-TLS Issuing CAs have a defined profile in 
the TLS BRs but IMO it cannot, and should not mandate the profile of 
non-TLS leaf certificates based on the CA/Browser Forum Server 
Certificate Working Group Charter 
 which states 
(emphasis mine):


/(a) To specify Baseline Requirements, Extended Validation 
Guidelines, and other acceptable practices for the issuance and 
management of *TLS server certificates used for authenticating 
servers accessible through the Internet*/


It gets more interesting when an Issuing CA that is technically 
capable of issuing server authentication TLS Certificates (by 
including the /id-kp-serverAuth/ KeyPurposeId in its extKeyUsage 
extension), also includes the /id-kp-clientAuth/ KeyPurposeId, thus 
being technically capable of issuing client authentication TLS 
Certificates.


Please recall that a few years back multi-purpose Issuing CAs 
existed, where the EKU was not present, and even if it was, it 
allowed the inclusion of various KeyPurposeIds.


Is it ok for such an Issuing CA to create a single-purpose client 
authentication TLS Certificate, one that is structured according to 
RFC 5280 (thus can be successfully parsed by Relying Party RFC 
5280-conformant software), contains an extKeyUsage extension which 
contains the /id-kp-clientAuth/ and DOES NOT include the 
/id-kp-serverAuth/ KeyPurposeId?


My understanding is that these particular leaf certificates are 
allowed to be issued by a server TLS capable CA and they are 
considered out-of-scope of the BRs, in the sense that *they are not 
TLS Server Certificates*. The SCWG has accepted this "risk" with the 
client authentication certificates by allowing the co-existence of 
/id-kp-clientAuth/ and /id-kp-serverAuth/ KeyPurposeIds and the 
explicit dis-allowance of /id-kp-emailProtection, id-kp-codeSigning, 
id-kp-timeStamping, anyExtendedKeyUsage/ in the CA Certificate profiles.


The first paragraph of the TLS BRs (section 1.1) states:

/.for the issuance and management of Publicly-Trusted TLS Server 
Certificates;/
Provided these certificates follow RFC 5280 and can be properly 
parsed, Browsers should never consider such certificates server TLS 
certificates. They are by design "technically constrained".


Thoughts? Disagreements? I know that Apple has already publicly 

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

[Adriano Santoni via Servercert-wg]

I would agree to consider out-of-scope (of the BRs) a leaf certificate 
with EKU=clientAuth issued by a SubCA that has EKU={server,client}, 
provided of course the leaf certificate does not assert a BR TLS policy 
OID because this would be contradictory.


Besides, at least one widely used linter considers a certificate 
in-scope if it contains EKU=serverAuth and/or it contains a BR policy 
OID, which seems quite logical to me.


Adriano


Il 14/05/2024 11:33, Dimitris Zacharopoulos (HARICA) via Servercert-wg 
ha scritto:
NOTICE: Pay attention - external email - Sender is 
0100018f76738e97-739d5cad-6797-4977-b997-150e338d5740-000...@amazonses.com 





Dear Members,

Following-up on an interesting public incident 
 , I would 
like to have a discussion about the scope of the TLS BRs as specified 
in the SCWG Charter and in the actual TLS BRs, especially when it 
comes to single-purpose "client authentication" certificates (i.e. 
leaf certificates that include the /id-kp-clientAuth/ and DO NOT 
include the /id-kp-serverAuth/ KeyPurposeId in their extKeyUsage 
extension).


The TLS BRs describe the profiles of Subordinate CA Certificates 
issued from a Root that is in-scope for server TLS authentication, 
even for the case of Technically-Constrained non-TLS CA Certificates. 
There was a lot of discussion about whether this is permitted based on 
the SCWG Charter and there was consensus that Browsers want to make 
sure that there are some minimum expectations about the structure of 
such non-TLS CA certificates, especially the adherence to RFC 5280. I 
recall that there was also consensus that whatever is issued off of 
these TC non-TLS CAs is not in scope of the TLS BRs.


_Does this seem like a fair statement about intent of the group on the 
expectations of TC non-TLS CAs and their leaf certificates?_


Technically Constrained non-TLS Issuing CAs have a defined profile in 
the TLS BRs but IMO it cannot, and should not mandate the profile of 
non-TLS leaf certificates based on the CA/Browser Forum Server 
Certificate Working Group Charter 
 which states 
(emphasis mine):


/(a) To specify Baseline Requirements, Extended Validation 
Guidelines, and other acceptable practices for the issuance and 
management of *TLS server certificates used for authenticating 
servers accessible through the Internet*/


It gets more interesting when an Issuing CA that is technically 
capable of issuing server authentication TLS Certificates (by 
including the /id-kp-serverAuth/ KeyPurposeId in its extKeyUsage 
extension), also includes the /id-kp-clientAuth/ KeyPurposeId, thus 
being technically capable of issuing client authentication TLS 
Certificates.


Please recall that a few years back multi-purpose Issuing CAs existed, 
where the EKU was not present, and even if it was, it allowed the 
inclusion of various KeyPurposeIds.


Is it ok for such an Issuing CA to create a single-purpose client 
authentication TLS Certificate, one that is structured according to 
RFC 5280 (thus can be successfully parsed by Relying Party RFC 
5280-conformant software), contains an extKeyUsage extension which 
contains the /id-kp-clientAuth/ and DOES NOT include the 
/id-kp-serverAuth/ KeyPurposeId?


My understanding is that these particular leaf certificates are 
allowed to be issued by a server TLS capable CA and they are 
considered out-of-scope of the BRs, in the sense that *they are not 
TLS Server Certificates*. The SCWG has accepted this "risk" with the 
client authentication certificates by allowing the co-existence of 
/id-kp-clientAuth/ and /id-kp-serverAuth/ KeyPurposeIds and the 
explicit dis-allowance of /id-kp-emailProtection, id-kp-codeSigning, 
id-kp-timeStamping, anyExtendedKeyUsage/ in the CA Certificate profiles.


The first paragraph of the TLS BRs (section 1.1) states:

/.for the issuance and management of Publicly-Trusted TLS Server 
Certificates;/
Provided these certificates follow RFC 5280 and can be properly 
parsed, Browsers should never consider such certificates server TLS 
certificates. They are by design "technically constrained".


Thoughts? Disagreements? I know that Apple has already publicly shared 
an opinion  
on this matter so I'm hoping to get more feedback from Members here :)



Thanks,
Dimitris.



___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg


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