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

[Clint Wilson]

> On May 16, 2024, at 1:19 AM, Dimitris Zacharopoulos (HARICA) <dzacharo at 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 <https://github.com/cabforum/forum/blob/main/SMCWG-charter.md> and similarly for the CSCWG <https://github.com/cabforum/forum/blob/main/CSCWG-charter.md> 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 <https://datatracker.ietf.org/doc/html/rfc5280#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

> 
> Thanks to all for reading these long emails :-)
> 
> 
> Dimitris.

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