On 16/5/2024 10:20 μ.μ., Clint Wilson wrote:
On May 16, 2024, at 1:19 AM, Dimitris Zacharopoulos (HARICA)
<[email protected]> 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.
_______________________________________________
Servercert-wg mailing list
[email protected]
https://lists.cabforum.org/mailman/listinfo/servercert-wg
