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

[Dimitris Zacharopoulos (HARICA)]

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.

[Martijn Katerbarg]

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

 

I do agree with the quoted statement. If compliance is asserted by the inclusion of a Policy OID, it would come into scope. If not, then indeed it would seem, it’s not in scope.

 

To me this mainly raises the question: What is a CA allowed to do with a SubCA Private Key. Section 6.1.7 states what a private key corresponding to a Root Certificate may be used for. Do we need something similar for private keys corresponding to Subordinate CAs?

 

Such a requirement could then indicate which type of objects may be signed (such as CRLs, OCSP responses, TLS certs, precerts. Since the requirements are related to TLS Certificates, in my opinion it would be in scope to say that a Subordinate CA capable of issuing TLS Certificates, may or may not issue clientAuth-only certificates, and if so, according to which profile.

 

Regards,

Martijn

 

From: Servercert-wg <servercert...@cabforum.org> on behalf of Dimitris Zacharopoulos (HARICA) via Servercert-wg <server...@cabforum.org>
Date: Tuesday, 14 May 2024 at 11:33
To: CA/B Forum Server Certificate WG Public Discussion List <server...@cabforum.org>
Subject: [Servercert-wg] Discussion about single-purpose client authentication leaf certificates issued from a server TLS Issuing CA

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

[Adriano Santoni]

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

[Aaron Gable]

On Tue, May 14, 2024, 02:33 Dimitris Zacharopoulos (HARICA) via Servercert-wg <server...@cabforum.org> wrote:

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?

Speaking in a personal capacity, it is my opinion that no, such issuance is not acceptable.

I agree that the resulting end-entity client-auth-only certificate is out of scope of the BRs, and is not in and of itself misissued. However, the issuing intermediate itself is still in scope of the BRs, and its behavior can be contained by them. By virtue of issuing the clientAuth cert, the issuing intermediate has violated the BRs requirement that "all certificates that it issues MUST comply with one of the following certificate profiles".

One could even argue that, having issued a certificate which does not comply with a BR profile, the issuing intermediate must be revoked within 7 days, per BRs Section 4.9.1.2 (5): "The Issuing CA SHALL revoke a Subordinate CA Certificate [if...] the Issuing CA is made aware that the... Subordinate CA has not complied with this document".

Aaron

[Dimitris Zacharopoulos (HARICA)]

Thanks Aaron, I tried to first establish the intent of the group before digging in the actual BRs. If we agree that the intent was to place rules only for Server TLS leaf Certificates but not for Client TLS Certificates, then we need to acknowledge that, and work within the document to fix any conflicts.

Dimitris.

[Dimitris Zacharopoulos (HARICA)]

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

[Dimitris Zacharopoulos (HARICA)]

On 14/5/2024 12:53 μ.μ., Martijn Katerbarg wrote:

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

 

I do agree with the quoted statement.

Are you referring to your quoted statement? I had two quotes in my first email of the thread :-)

If compliance is asserted by the inclusion of a Policy OID, it would come into scope. If not, then indeed it would seem, it’s not in scope.

I already answered that in https://lists.cabforum.org/pipermail/servercert-wg/2024-May/004575.html (apologies for starting the responses in reverse order).

 

To me this mainly raises the question: What is a CA allowed to do with a SubCA Private Key. Section 6.1.7 states what a private key corresponding to a Root Certificate may be used for. Do we need something similar for private keys corresponding to Subordinate CAs?

 

Such a requirement could then indicate which type of objects may be signed (such as CRLs, OCSP responses, TLS certs, precerts. Since the requirements are related to TLS Certificates, in my opinion it would be in scope to say that a Subordinate CA capable of issuing TLS Certificates, may or may not issue clientAuth-only certificates, and if so, according to which profile.

This is an interesting idea, I wouldn't object to it as long as we reach consensus about the intent related to client authentication -and other non-server-TLS, non-codeSigning, non-timeStamping, non-emailProtection- leaf certificates.


Thanks,
Dimitris.

[Aaron Gable]

That makes sense. I guess I'm saying that the intent of "Intermediates which are part of the WebPKI must not issue certificates which are not part of the WebPKI" makes sense to me.

Imagine that a publicly trusted Subordinate CA issues a "certificate" which is so badly malformed that it does not match any of the profiles allowed by the BRs, and it's even difficult to tell which profile it may have been intended to match before things went wrong. This feels to me like it should be treated as a misissuance: it should not have been possible for a CA to sign such an artifact, and the fact that it is possible merits an investigation and incident report.

But the difference between such a malformed certificate and a certificate which asserts clientAuth but not serverAuth is only one of degree, not one of kind. They are both certificates which are issued by a publicly-trusted Subordinate CA, but which do not conform to a BRs profile. If issuing a clientAuth-only cert should be okay, but issuing a badly malformed cert should not be, where and how does one draw the line between them?

Aaron

[Roman Fischer]

Dear Aaron,

 

Interesting line of argumentation. Wouldn’t that conclude that -every- mis-issuance of a leaf certificate would be a violation of "all certificates that it issues MUST comply with one of the following certificate profiles" and thus would require the ICA to be revoked? That can’t be the intent of the regulation, right?

 

Rgds
Roman

[Dimitris Zacharopoulos (HARICA)]

On 14/5/2024 7:52 μ.μ., Aaron Gable wrote:

That makes sense. I guess I'm saying that the intent of "Intermediates which are part of the WebPKI must not issue certificates which are not part of the WebPKI" makes sense to me.

While I agree that this sounds reasonable to clarify and ensure it is applicable unambiguously, to the best of my recollection, the intent of this group when drafting the profiles ballot was not what you describe. I'd be happy to be shown otherwise. I do recall Tim Hollebeek strongly objecting to adding requirements for non-TLS Certificates.

The current BRs do not require strict server TLS hierarchies, that was never the intent. If that was the case, it would not be allowed to create TC non-TLS Intermediates from a Root that is in-scope of the TLS BRs.

Imagine that a publicly trusted Subordinate CA issues a "certificate" which is so badly malformed that it does not match any of the profiles allowed by the BRs, and it's even difficult to tell which profile it may have been intended to match before things went wrong. This feels to me like it should be treated as a misissuance: it should not have been possible for a CA to sign such an artifact, and the fact that it is possible merits an investigation and incident report.

But the difference between such a malformed certificate and a certificate which asserts clientAuth but not serverAuth is only one of degree, not one of kind. They are both certificates which are issued by a publicly-trusted Subordinate CA, but which do not conform to a BRs profile. If issuing a clientAuth-only cert should be okay, but issuing a badly malformed cert should not be, where and how does one draw the line between them?

The badly formed cert issue should definitely be addressed, just like it has been addressed for the TC non-TLS subCA profile. At a minimum it must conform to RFC 5280. But just as we had multi-purpose hierarchies, and we support non-TLS subCAs, maybe we should add similar language to cover the case of non-TLS leaf certificates.

However, if the group wants to proceed with "clarifying"* that CA Certificates technically capable of issuing server TLS Certificates SHALL NOT issue end-entity Certificates that do not include the serverAuth EKU, I'm all for it. I still don't see the harm in doing so from a RP security perspective but I won't object to clear and unambiguous rules that all CAs and auditors interpret the same way.

I'm not sure if this issue deserves some dedicated time for discussion at the upcoming F2F but Inigo could add it as an agenda item. At the very least we should capture the group's preference and proceed accordingly.

Dimitris.


* "Clarifying" has been used before as a way of adding new requirements.

[Dimitris Zacharopoulos (HARICA)]

On 15/5/2024 7:35 π.μ., Roman Fischer via Servercert-wg wrote:

Dear Aaron,

 

Interesting line of argumentation. Wouldn’t that conclude that -every- mis-issuance of a leaf certificate would be a violation of "all certificates that it issues MUST comply with one of the following certificate profiles" and thus would require the ICA to be revoked? That can’t be the intent of the regulation, right?

 

Roman,

TC non-TLS subCAs already have a defined certificate profile described in the BRs so there is no need to revoke such an ICA. I think you might be referring to non-TLS Subscriber Certificates issued by those TC non-TLS SubCAs?


Dimitris.

Rgds
Roman

 

From: Servercert-wg <servercert...@cabforum.org> On Behalf Of Aaron Gable via Servercert-wg
Sent: Dienstag, 14. Mai 2024 16:59
To: Dimitris Zacharopoulos (HARICA) <dzac...@harica.gr>; CA/B Forum Server Certificate WG Public Discussion List <server...@cabforum.org>
Subject: Re: [Servercert-wg] Discussion about single-purpose client authentication leaf certificates issued from a server TLS Issuing CA

 

On Tue, May 14, 2024, 02:33 Dimitris Zacharopoulos (HARICA) via Servercert-wg <server...@cabforum.org> wrote:

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?

 

Speaking in a personal capacity, it is my opinion that no, such issuance is not acceptable.

 

I agree that the resulting end-entity client-auth-only certificate is out of scope of the BRs, and is not in and of itself misissued. However, the issuing intermediate itself is still in scope of the BRs, and its behavior can be contained by them. By virtue of issuing the clientAuth cert, the issuing intermediate has violated the BRs requirement that "all certificates that it issues MUST comply with one of the following certificate profiles".

 

One could even argue that, having issued a certificate which does not comply with a BR profile, the issuing intermediate must be revoked within 7 days, per BRs Section 4.9.1.2 (5): "The Issuing CA SHALL revoke a Subordinate CA Certificate [if...] the Issuing CA is made aware that the... Subordinate CA has not complied with this document".

 

Aaron

[Roman Fischer]

Hi Dimitris,

 

I was thinking more along the line: What if we had TLS leaf certificates with e.g. the country field missing. Such a cert would not comply to the TLS BR and since the ICA signed such a non-complying cert, it would need to be revoked too… Which IMHO makes no sense at all. 😊

 

Rgds
Roman

[Dimitris Zacharopoulos (HARICA)]

On 15/5/2024 9:21 π.μ., Roman Fischer wrote:

Hi Dimitris,

 

I was thinking more along the line: What if we had TLS leaf certificates with e.g. the country field missing. Such a cert would not comply to the TLS BR and since the ICA signed such a non-complying cert, it would need to be revoked too… Which IMHO makes no sense at all. 😊

Indeed, it doesn't :)

[Inigo Barreira]

> I'm not sure if this issue deserves some dedicated time for discussion at the upcoming F2F but Inigo could add it as an agenda item. At the very least we should capture the group's preference and proceed accordingly.

Dimitris, if you want this to be discussed at the F2F SCWG, just drop me an email with the content (just for the introduction) and an estimated discussion time and I´ll add it to the agenda. Not a problem.

 

De: Servercert-wg <servercert...@cabforum.org> En nombre de Dimitris Zacharopoulos (HARICA) via Servercert-wg
Enviado el: miércoles, 15 de mayo de 2024 7:16
Para: Aaron Gable <aa...@letsencrypt.org>
CC: CA/B Forum Server Certificate WG Public Discussion List <server...@cabforum.org>
Asunto: Re: [Servercert-wg] Discussion about single-purpose client authentication leaf certificates issued from a server TLS Issuing CA

 

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

 

 

On 14/5/2024 7:52 μ.μ., Aaron Gable wrote:

That makes sense. I guess I'm saying that the intent of "Intermediates which are part of the WebPKI must not issue certificates which are not part of the WebPKI" makes sense to me.

While I agree that this sounds reasonable to clarify and ensure it is applicable unambiguously, to the best of my recollection, the intent of this group when drafting the profiles ballot was not what you describe. I'd be happy to be shown otherwise. I do recall Tim Hollebeek strongly objecting to adding requirements for non-TLS Certificates.

The current BRs do not require strict server TLS hierarchies, that was never the intent. If that was the case, it would not be allowed to create TC non-TLS Intermediates from a Root that is in-scope of the TLS BRs.

 

Imagine that a publicly trusted Subordinate CA issues a "certificate" which is so badly malformed that it does not match any of the profiles allowed by the BRs, and it's even difficult to tell which profile it may have been intended to match before things went wrong. This feels to me like it should be treated as a misissuance: it should not have been possible for a CA to sign such an artifact, and the fact that it is possible merits an investigation and incident report.

 

But the difference between such a malformed certificate and a certificate which asserts clientAuth but not serverAuth is only one of degree, not one of kind. They are both certificates which are issued by a publicly-trusted Subordinate CA, but which do not conform to a BRs profile. If issuing a clientAuth-only cert should be okay, but issuing a badly malformed cert should not be, where and how does one draw the line between them?

The badly formed cert issue should definitely be addressed, just like it has been addressed for the TC non-TLS subCA profile. At a minimum it must conform to RFC 5280. But just as we had multi-purpose hierarchies, and we support non-TLS subCAs, maybe we should add similar language to cover the case of non-TLS leaf certificates.

However, if the group wants to proceed with "clarifying"* that CA Certificates technically capable of issuing server TLS Certificates SHALL NOT issue end-entity Certificates that do not include the serverAuth EKU, I'm all for it. I still don't see the harm in doing so from a RP security perspective but I won't object to clear and unambiguous rules that all CAs and auditors interpret the same way.

I'm not sure if this issue deserves some dedicated time for discussion at the upcoming F2F but Inigo could add it as an agenda item. At the very least we should capture the group's preference and proceed accordingly.

Dimitris.


* "Clarifying" has been used before as a way of adding new requirements.

 

Aaron

[Martijn Katerbarg]

> Are you referring to your quoted statement? I had two quotes in my first email of the thread :-)

No, more specifically: ”If the CA asserts compliance with these Baseline Requirements, all certificates that it issues MUST comply with one of the following certificate profiles....”

 

> This is an interesting idea, I wouldn't object to it as long as we reach consensus about the intent related to client authentication -and other non-server-TLS, non-codeSigning, non-timeStamping, non-emailProtection- leaf certificates.

How about expanding section 6.1.7, with:

 

Private Keys corresponding to Subordinate CA Certificates containing the id-kp-serverAuth EKU MUST NOT be used to sign Certificates except in the following cases:

1. Certificates for Subordinate CAs and Cross-Certified Subordinate CA Certificates, including Technically-Constrained Subordinate CAs;
2. OCSP Responder Certificates;
3. Precertificates containing at least the id-kp-serverAuth EKU; and
4. Subscriber Certificates containing at least the id-kp-serverAuth EKU;

 

Quick draft, so I may have missed a use case. However this would not pose any requirements on clientAuth-only certificates, but it would prevent TLS SubCAs from issuing them, which in my mind is perfectly aligned with that the BRs are in scope for.

Regards,

Martijn

[Clint Wilson]

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

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

[Dimitris Zacharopoulos (HARICA)]

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 <server...@cabforum.org> 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?

[Clint Wilson]

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 certificate, so all the profiles where basicConstraints:cA=TRUE can be discarded (7.1.2.1 - 7.1.2.6). Next you indicated that the certificate in question does not include the serverAuth EKU, so we can discard all profiles where the extendedKeyUsage extension requires inclusion of the serverAuth value (7.1.2.7 and 7.1.2.9). Finally, you indicated that the certificate in question does include the clientAuth EKU, so we can discard any remaining profile that doesn’t allow the clientAuth EKU (7.1.2.8). This brings us to the end of the list of 9 certificate profiles defined in the TBRs today without finding any that match the certificate described.

Based on this sequence of assessment, I’m personally led to the conclusion that such a certificate is indeed not compliant. Please let me know where I’ve misunderstood your question or arrived at incorrect conclusions so I can better understand the model you’re describing. 

Thanks very much!

-Clint

[1] - The specific text of 5280 is:

In an end entity certificate, these policy information terms indicate the policy under which the certificate has been issued and the purposes for which the certificate may be used.  

In a CA certificate, these policy information terms limit the set of policies for certification paths that include this certificate.

[Dimitris Zacharopoulos (HARICA)]

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 similarly in the past, single-purpose S/MIME, Code Signing Certificates), were considered out-of-scope of the TLS BRs due to the EKU restriction which is the #1 factor for scoping the usage of a certificate.

I can't fully analyze why a CA would assert the CA/B Forum server TLS OID in a non-server TLS OID. Maybe the CA has applied some of the TLS BRs but not the profiles section? I don't know but that's besides the point. Based on the SCWG Charter, this group should only focus on use cases "of TLS server certificates used for authenticating servers accessible through the Internet", i.e. certificates that include the id-kp-serverAuth EKU. This has been discussed in the past during the chartering process for the S/MIME WG and similarly for the CSCWG which made it unambiguously clear that the separation of policy scope is based on the EKU, not the policy OIDs. I was hoping to align the charters of all WGs taking good elements from all and apply them to the rest but I haven't had the time to look into it yet.

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.

By extension, if a CA creates a separate hierarchy that is not trusted in the public Internet, what happens if it issues certificates that include a TLS BR policy OID? Such a hierarchy should be totally out-of-scope of the TLS BRs even if it asserted policy OIDs of the TLS BRs because the BRs are scoped to "the issuance and management of Publicly-Trusted TLS Server Certificates; Certificates that are trusted by virtue of the fact that their corresponding Root Certificate is distributed in widely-available application software" and these would not fit that description.

Similarly, single-purpose client authentication, code signing, time-stamping, document signing, and other non-TLS server certificates, are out of scope of the TLS BRs because they are not "TLS Server Certificates", regardless if they chain to a corresponding Root Certificate distributed in widely-available application software. Please let me know if you agree or disagree with this interpretation.

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.

As explained earlier, this implies that test hierarchies would be in violation of the TLS BRs but.... they are implicitly excluded from scope because they are not publicly-trusted, just as the non-TLS server Certificates are excluded for not being server TLS Certificates.

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.

That's exactly where original intent needs to be established. We can decide on the improved language in either direction very easily.

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 certificate, so all the profiles where basicConstraints:cA=TRUE can be discarded (7.1.2.1 - 7.1.2.6). Next you indicated that the certificate in question does not include the serverAuth EKU, so we can discard all profiles where the extendedKeyUsage extension requires inclusion of the serverAuth value (7.1.2.7 and 7.1.2.9). Finally, you indicated that the certificate in question does include the clientAuth EKU, so we can discard any remaining profile that doesn’t allow the clientAuth EKU (7.1.2.8). This brings us to the end of the list of 9 certificate profiles defined in the TBRs today without finding any that match the certificate described.

This argument assumes that single-purpose non-TLS Server Certificates ARE in scope of the TLS BRs, therefore one of the leaf certificate profiles must be followed. My point is that these are out of scope of the BRs and restricting their issuance from a server TLS-capable CA was unintended in SC-62.

Based on this sequence of assessment, I’m personally led to the conclusion that such a certificate is indeed not compliant. Please let me know where I’ve misunderstood your question or arrived at incorrect conclusions so I can better understand the model you’re describing.

I hope I provided more clarity of my view and some additional context. Let me repeat that I'm not against restricting server TLS-capable CAs issuing only TLS server certificates but this needs to be confirmed and clarified in the BRs because, to the best of my knowledge, that was not intended nor discussed explicitly during SC-62.

Thanks to all for reading these long emails :-)


Dimitris.

[Pedro FUENTES]

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.

[Pedro FUENTES]

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

_______________________________________________
Servercert-wg mailing list
Server...@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=

[Dimitris Zacharopoulos (HARICA)]

On 16/5/2024 12:20 μ.μ., Pedro FUENTES wrote:

Hello Dimitris,

I’m following closely this as I find very important.

About…

This is easy to answer. Some use cases need single-purpose client authentication certificates. There are numerous use cases where client authentication certificates are used for strong authentication, I'm sure you are aware of such use cases. While client authentication use cases can ALL be supported by non-public CAs, there are some regulatory requirements that demand such certificates be issued from an audited and publicly-trusted CA. In fact, HARICA has participated in public tenders where client authentication certificates need to be issued from a CA that chains to Apple, Microsoft and Mozilla Root Stores. Client authentication certificates are asked in addition to server TLS certificates.

I don’t know if you didn’t mention Chrome for a particular reason,

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

but actually that’s the Root program that makes me scratch my head while reading these discussions… because AFAIK they only include Roots for TLS serverAuth purposes, and not for clientAuth. So (again AFAIK, I may be wrong) you can’t propose clientAuth-only certs that work in Chrome unless these come from a Root that is included for TLS serverAuth.

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

Apart of that, just to say that my current understanding is that the BR as they are today don’t allow the issuance of these certificates,

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

so maybe it’s more pragmatic to assume the status-quo, and focus the discussion if the BR should be modified to implicitly or explicitly allow this.

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

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


Dimitris.

[Dimitris Zacharopoulos (HARICA)]

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.

[Ryan Dickson]

Hi Pedro,

Sharing our perspective below:

> I don’t know if you didn’t mention Chrome for a particular reason, but actually that’s the Root program that makes me scratch my head while reading these discussions… because AFAIK they only include Roots for TLS serverAuth purposes, and not for clientAuth. So (again AFAIK, I may be wrong) you can’t propose clientAuth-only certs that work in Chrome unless these come from a Root that is included for TLS serverAuth.

For applicants to the Chrome Root Store, your description above is correct. Specifically, our current expectations for applicant hierarchies are described in Section 4 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 <server...@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
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.

[Pedro FUENTES]

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

[Clint Wilson]

On May 16, 2024, at 1:19 AM, Dimitris Zacharopoulos (HARICA) <dzac...@harica.gr> 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 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 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 capture a "not used for TLS" intermediate. When issued from a TLS-capable CA (e.g. one with no EKU restrictions), the issuance is still subject to the BRs, but any operation - such as private key protection, auditing, logging, issuance beneath - are seen as out of scope. The purpose of this profile is to ensure that such issuance aligns with RFC 5280 and the BRs, such that it can be seen as reduced risk.”

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 similarly in the past, single-purpose S/MIME, Code Signing Certificates), were considered out-of-scope of the TLS BRs due to the EKU restriction which is the #1 factor for scoping the usage of a certificate.

I can't fully analyze why a CA would assert the CA/B Forum server TLS OID in a non-server TLS OID. Maybe the CA has applied some of the TLS BRs but not the profiles section? I don't know but that's besides the point. Based on the SCWG Charter, this group should only focus on use cases "of TLS server certificates used for authenticating servers accessible through the Internet", i.e. certificates that include the id-kp-serverAuth EKU. This has been discussed in the past during the chartering process for the S/MIME WG and similarly for the CSCWG which made it unambiguously clear that the separation of policy scope is based on the EKU, not the policy OIDs.

Part of what I was trying to highlight is that the Policy OID is defined at the Forum level; regardless of the SCWG charter, the inclusion of the OID by a CA in a certificate very fundamentally brings that certificate into scope of the policy associated with that OID. Whether anyone cares that a CA has brought an issued certificate into scope of the TBRs in turn depends on whether there exists a Relying Party which expects the CA to comply with the TBRs — and in the context of publicly trusted CAs, I think there are many Relying Parties (not just application software suppliers) which expect the TBRs to be followed for certificates which assert compliance with the TBRs.

I was hoping to align the charters of all WGs taking good elements from all and apply them to the rest but I haven't had the time to look into it yet.

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.

By extension, if a CA creates a separate hierarchy that is not trusted in the public Internet, what happens if it issues certificates that include a TLS BR policy OID? Such a hierarchy should be totally out-of-scope of the TLS BRs even if it asserted policy OIDs of the TLS BRs because the BRs are scoped to "the issuance and management of Publicly-Trusted TLS Server Certificates; Certificates that are trusted by virtue of the fact that their corresponding Root Certificate is distributed in widely-available application software" and these would not fit that description.

This entirely depends on my first point, which is whether this separate hierarchy is intended to be considered compliant with the TBRs. Is there a Relying Party for this hierarchy that expects its CAs to comply with the TBRs? If there isn’t, which based on your description is the case, then absolutely it’s totally out-of-scope of the TBRs.

Similarly, single-purpose client authentication, code signing, time-stamping, document signing, and other non-TLS server certificates, are out of scope of the TLS BRs because they are not "TLS Server Certificates", regardless if they chain to a corresponding Root Certificate distributed in widely-available application software. Please let me know if you agree or disagree with this interpretation.

This also depends entirely on whether the CA intends such certificates to be considered compliant with the TBRs by a Relying Party. In the context of widely-available application software, this is communicated (from the CA to the Relying Party) in part by whether the CA requests to be enabled for TLS by the application software supplier and communicated (from the Relying Party back to the CA) in part by whether the Root CA is enabled for TLS (i.e. serverAuth EKU).

If such single-purpose non-TLS certificates are issued from a Root CA which is in scope of the TBRs, then the subordinate CA which issues those certificates IS in-scope of the TBRs and the TBRs require such a subordinate CA to be Technically Constrained such that it _cannot_ issue validatable leaf certificates with the serverAuth EKU.

If the subordinate CA is NOT Technically Constrained in this manner (for example by including the serverAuth or anyEKU EKU or no EKU at all), then the certificates issued by that subordinate CA ARE in scope of the TBRs and therefore cannot be single-purpose client authentication, code signing, time-stamping, document signing, or other non-TLS server certificates. That’s not the TBRs overstepping their scope or the SCWG charter because such subordinate CAs are _capable_ of issuing TLS certificates.

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.

As explained earlier, this implies that test hierarchies would be in violation of the TLS BRs but.... they are implicitly excluded from scope because they are not publicly-trusted, just as the non-TLS server Certificates are excluded for not being server TLS Certificates.

I don’t believe it does imply this because of my first point and initial condition for the validity of the remainder of my previous response. That condition is whether the CA intends the hierarchy to be considered compliant with the TBRs and in the case of test hierarchies, presumably the CA does not — and further does not have any Relying Party for such test hierarchies which expects the CA to ensure the test hierarchies comply with the TBRs.

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.

That's exactly where original intent needs to be established. We can decide on the improved language in either direction very easily. 

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 certificate, so all the profiles where basicConstraints:cA=TRUE can be discarded (7.1.2.1 - 7.1.2.6). Next you indicated that the certificate in question does not include the serverAuth EKU, so we can discard all profiles where the extendedKeyUsage extension requires inclusion of the serverAuth value (7.1.2.7 and 7.1.2.9). Finally, you indicated that the certificate in question does include the clientAuth EKU, so we can discard any remaining profile that doesn’t allow the clientAuth EKU (7.1.2.8). This brings us to the end of the list of 9 certificate profiles defined in the TBRs today without finding any that match the certificate described.

This argument assumes that single-purpose non-TLS Server Certificates ARE in scope of the TLS BRs, therefore one of the leaf certificate profiles must be followed. My point is that these are out of scope of the BRs and restricting their issuance from a server TLS-capable CA was unintended in SC-62.

I believe I’ve addressed this above, but to reiterate: single-purpose non-TLS Server Certificates themselves are not directly in scope of the TLS BRs, however their issuing CA may be, specifically when that issuing CA is subordinate to a Root CA which is in scope of the TLS BRs. When such an issuing CA is in scope of the TLS BRs there are conditions which must be met in order for that issuing CA to issue single-purpose non-TLS Server certificates — not because those certificates would be in-scope of the TLS BRs, but because the CA issuing them IS. Such an issuing CA, in-scope of the TLS BRs, must meet the requirements of the Technically Constrained Non-TLS Subordinate CA Certificate profile in order to issue single-purpose non-TLS Server Certificates. If the issuing CA is NOT a Technically Constrained Non-TLS Subordinate CA Certificate, then indeed it must issue certificates which meet the leaf certificate profiles defined in the TBRs.

Based on this sequence of assessment, I’m personally led to the conclusion that such a certificate is indeed not compliant. Please let me know where I’ve misunderstood your question or arrived at incorrect conclusions so I can better understand the model you’re describing. 

I hope I provided more clarity of my view and some additional context. Let me repeat that I'm not against restricting server TLS-capable CAs issuing only TLS server certificates but this needs to be confirmed and clarified in the BRs because, to the best of my knowledge, that was not intended nor discussed explicitly during SC-62.

Yes, and I greatly appreciate your patience in providing that additional clarity and context, Dimitris. Likewise, I hope my responses here help further clarify why I believe this restriction is/was intentional and how I understand the scope of the TLS BRs to apply to different parts of CA hierarchies. I find this discussion very interesting as it highlights seemingly very different views on what SC-62 was intended to accomplish — leading me to once again ponder how we can collectively better 1) convey the intended outcomes and 2) identify the outcomes which readers perceive of ballots in the Forum, but that’s perhaps a topic for another day :D

Cheers!

-Clint

[Clint Wilson]

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

[Dimitris Zacharopoulos (HARICA)]

On 16/5/2024 10:20 μ.μ., Clint Wilson wrote:

On May 16, 2024, at 1:19 AM, Dimitris Zacharopoulos (HARICA) <dzac...@harica.gr> 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 capture a "not used for TLS" intermediate. When issued from a TLS-capable CA (e.g. one with no EKU restrictions), the issuance is still subject to the BRs, but any operation - such as private key protection, auditing, logging, issuance beneath - are seen as out of scope. The purpose of this profile is to ensure that such issuance aligns with RFC 5280 and the BRs, such that it can be seen as reduced risk.”

So unless I hear otherwise, the change from the pre-SC62 BRs stating:

7.1.2.3 (f). extKeyUsage (required)
"Either the value id-kp-serverAuth [RFC5280] or id-kp-clientAuth [RFC5280] or both values MUST be present. id-kp-emailProtection [RFC5280] MAY be present. Other values SHOULD NOT be present. The value anyExtendedKeyUsage MUST NOT be present."

was purposely effectively changed to something along the lines of:

"the value id-kp-serverAuth [RFC5280] MUST always be present. id-kp-serverAuth [RFC5280] MAY also be present. other explicit EKUs (codeSigning, timeStamping, etc) MUST not be present and other values are NOT RECOMMENDED".

I'm glad I started this discussion because that goal was not part of my expected outcome of SC-62. This feedback is very helpful and adds a lot of clarity on the way CAs and Auditors should see the TLS BRs and their profiles.

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 similarly in the past, single-purpose S/MIME, Code Signing Certificates), were considered out-of-scope of the TLS BRs due to the EKU restriction which is the #1 factor for scoping the usage of a certificate.

I can't fully analyze why a CA would assert the CA/B Forum server TLS OID in a non-server TLS OID. Maybe the CA has applied some of the TLS BRs but not the profiles section? I don't know but that's besides the point. Based on the SCWG Charter, this group should only focus on use cases "of TLS server certificates used for authenticating servers accessible through the Internet", i.e. certificates that include the id-kp-serverAuth EKU. This has been discussed in the past during the chartering process for the S/MIME WG and similarly for the CSCWG which made it unambiguously clear that the separation of policy scope is based on the EKU, not the policy OIDs.

Part of what I was trying to highlight is that the Policy OID is defined at the Forum level; regardless of the SCWG charter, the inclusion of the OID by a CA in a certificate very fundamentally brings that certificate into scope of the policy associated with that OID. Whether anyone cares that a CA has brought an issued certificate into scope of the TBRs in turn depends on whether there exists a Relying Party which expects the CA to comply with the TBRs — and in the context of publicly trusted CAs, I think there are many Relying Parties (not just application software suppliers) which expect the TBRs to be followed for certificates which assert compliance with the TBRs.

That's why I was wondering if the prohibition was done on purpose, because issuing a single-purpose clientAuth Certificate from a multi-purpose (server and client TLS) CA was previously allowed in the BRs.

This TLS BR policy OID assertion in an out of TLS BR scope certificate deserves IMHO some more discussion, possibly at the F2F or in another thread.

I was hoping to align the charters of all WGs taking good elements from all and apply them to the rest but I haven't had the time to look into it yet.

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.

By extension, if a CA creates a separate hierarchy that is not trusted in the public Internet, what happens if it issues certificates that include a TLS BR policy OID? Such a hierarchy should be totally out-of-scope of the TLS BRs even if it asserted policy OIDs of the TLS BRs because the BRs are scoped to "the issuance and management of Publicly-Trusted TLS Server Certificates; Certificates that are trusted by virtue of the fact that their corresponding Root Certificate is distributed in widely-available application software" and these would not fit that description.

This entirely depends on my first point, which is whether this separate hierarchy is intended to be considered compliant with the TBRs. Is there a Relying Party for this hierarchy that expects its CAs to comply with the TBRs? If there isn’t, which based on your description is the case, then absolutely it’s totally out-of-scope of the TBRs.

It would comply if single-purpose clientAuth certificates were allowed, as before. But my understanding is that the EKU is the first line of technically constraining a certificate and putting it out-of-scope of the TLS BRs. It shouldn't matter if it included a CA/B Forum or a HARICA policy OID. What would your interpretation be if a TC non-TLS CA issued -say- a codeSigning Certificate that included the EV TLS policy OID instead of the EV Code Signing OID?

I understand your point though, and it's useful to discuss separately and get the Forum in agreement so there are no misunderstandings about the expectations of asserting certain policy OIDs in server TLS CA and end-entity Certificates issued from either server TLS or non-server TLS CAs).

Similarly, single-purpose client authentication, code signing, time-stamping, document signing, and other non-TLS server certificates, are out of scope of the TLS BRs because they are not "TLS Server Certificates", regardless if they chain to a corresponding Root Certificate distributed in widely-available application software. Please let me know if you agree or disagree with this interpretation.

This also depends entirely on whether the CA intends such certificates to be considered compliant with the TBRs by a Relying Party. In the context of widely-available application software, this is communicated (from the CA to the Relying Party) in part by whether the CA requests to be enabled for TLS by the application software supplier and communicated (from the Relying Party back to the CA) in part by whether the Root CA is enabled for TLS (i.e. serverAuth EKU).

If such single-purpose non-TLS certificates are issued from a Root CA which is in scope of the TBRs, then the subordinate CA which issues those certificates IS in-scope of the TBRs and the TBRs require such a subordinate CA to be Technically Constrained such that it _cannot_ issue validatable leaf certificates with the serverAuth EKU.

If the subordinate CA is NOT Technically Constrained in this manner (for example by including the serverAuth or anyEKU EKU or no EKU at all), then the certificates issued by that subordinate CA ARE in scope of the TBRs and therefore cannot be single-purpose client authentication, code signing, time-stamping, document signing, or other non-TLS server certificates. That’s not the TBRs overstepping their scope or the SCWG charter because such subordinate CAs are _capable_ of issuing TLS certificates.

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.

As explained earlier, this implies that test hierarchies would be in violation of the TLS BRs but.... they are implicitly excluded from scope because they are not publicly-trusted, just as the non-TLS server Certificates are excluded for not being server TLS Certificates.

I don’t believe it does imply this because of my first point and initial condition for the validity of the remainder of my previous response. That condition is whether the CA intends the hierarchy to be considered compliant with the TBRs and in the case of test hierarchies, presumably the CA does not — and further does not have any Relying Party for such test hierarchies which expects the CA to ensure the test hierarchies comply with the TBRs.

Both of these comments are helpful. In some sense, we don't actually say anywhere in the BRs that the certificates issued from non-TLS Subordinate CAs are out-of-scope of the BRs. We assume they are, because the CA Certificate contains an extKeyUsage extention that does not include the id-kp-serverAuth KeyPurposeId, which theoretically restricts RPs from accepting leaf certificates as server TLS certificates.

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.

That's exactly where original intent needs to be established. We can decide on the improved language in either direction very easily. 

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 certificate, so all the profiles where basicConstraints:cA=TRUE can be discarded (7.1.2.1 - 7.1.2.6). Next you indicated that the certificate in question does not include the serverAuth EKU, so we can discard all profiles where the extendedKeyUsage extension requires inclusion of the serverAuth value (7.1.2.7 and 7.1.2.9). Finally, you indicated that the certificate in question does include the clientAuth EKU, so we can discard any remaining profile that doesn’t allow the clientAuth EKU (7.1.2.8). This brings us to the end of the list of 9 certificate profiles defined in the TBRs today without finding any that match the certificate described.

This argument assumes that single-purpose non-TLS Server Certificates ARE in scope of the TLS BRs, therefore one of the leaf certificate profiles must be followed. My point is that these are out of scope of the BRs and restricting their issuance from a server TLS-capable CA was unintended in SC-62.

I believe I’ve addressed this above, but to reiterate: single-purpose non-TLS Server Certificates themselves are not directly in scope of the TLS BRs, however their issuing CA may be, specifically when that issuing CA is subordinate to a Root CA which is in scope of the TLS BRs. When such an issuing CA is in scope of the TLS BRs there are conditions which must be met in order for that issuing CA to issue single-purpose non-TLS Server certificates — not because those certificates would be in-scope of the TLS BRs, but because the CA issuing them IS. Such an issuing CA, in-scope of the TLS BRs, must meet the requirements of the Technically Constrained Non-TLS Subordinate CA Certificate profile in order to issue single-purpose non-TLS Server Certificates. If the issuing CA is NOT a Technically Constrained Non-TLS Subordinate CA Certificate, then indeed it must issue certificates which meet the leaf certificate profiles defined in the TBRs.

If this was the intended outcome for single-purpose client TLS Certificates and not an "accidental" prohibition, and there are no Members suggesting otherwise, I'm happy with the outcome and I'll probably work on some clarification language to be added in a clean-up ballot to make sure this is crystal clear to implementers of the BRs.

Based on this sequence of assessment, I’m personally led to the conclusion that such a certificate is indeed not compliant. Please let me know where I’ve misunderstood your question or arrived at incorrect conclusions so I can better understand the model you’re describing. 

I hope I provided more clarity of my view and some additional context. Let me repeat that I'm not against restricting server TLS-capable CAs issuing only TLS server certificates but this needs to be confirmed and clarified in the BRs because, to the best of my knowledge, that was not intended nor discussed explicitly during SC-62.

Yes, and I greatly appreciate your patience in providing that additional clarity and context, Dimitris. Likewise, I hope my responses here help further clarify why I believe this restriction is/was intentional and how I understand the scope of the TLS BRs to apply to different parts of CA hierarchies. I find this discussion very interesting as it highlights seemingly very different views on what SC-62 was intended to accomplish — leading me to once again ponder how we can collectively better 1) convey the intended outcomes and 2) identify the outcomes which readers perceive of ballots in the Forum, but that’s perhaps a topic for another day :D

Likewise, it was a good discussion and revealed how different perspectives can lead to improvements that help those implementing the TLS BRs :)

[Dimitris Zacharopoulos (HARICA)]

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.

[Pedro FUENTES]

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.

[Clint Wilson]

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