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

[Dimitris Zacharopoulos (HARICA)]

On 16/5/2024 10:20 μ.μ., Clint Wilson wrote:
>
>
>> On May 16, 2024, at 1:19 AM, Dimitris Zacharopoulos (HARICA) 
>> <dzacharo at 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 
>> thechartering process for the S/MIME WG 
>> <https://github.com/cabforum/forum/blob/main/SMCWG-charter.md>and 
>> similarly for theCSCWG 
>> <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.

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

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

>
> 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/20240517/30d4e5d7/attachment-0001.html>