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

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

>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20240516/29bb1e11/attachment-0001.html>