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