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

Wed May 15 07:12:18 UTC 2024

> 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-wg-bounces at 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 <aaron at letsencrypt.org>
CC: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at 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

On Tue, May 14, 2024 at 8:49 AM Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr <mailto:dzacharo at harica.gr> > wrote:

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

On Tue, May 14, 2024, 02:33 Dimitris Zacharopoulos (HARICA) via Servercert-wg <servercert-wg at cabforum.org <mailto:servercert-wg at 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

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20240515/2f9b4034/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6630 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20240515/2f9b4034/attachment-0001.p7s>