<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<br>
<div class="moz-cite-prefix">On 16/5/2024 10:20 μ.μ., Clint Wilson
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:23BEDB68-9865-4BDE-9447-744202DA4224@apple.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<br id="lineBreakAtBeginningOfMessage">
<div><br>
<blockquote type="cite">
<div>On May 16, 2024, at 1:19 AM, Dimitris Zacharopoulos
(HARICA) <a class="moz-txt-link-rfc2396E" href="mailto:dzacharo@harica.gr"><dzacharo@harica.gr></a> wrote:</div>
<br class="Apple-interchange-newline">
<div>
<meta charset="UTF-8">
<br>
</div>
</blockquote>
</div>
</blockquote>
[...]<br>
<blockquote type="cite"
cite="mid:23BEDB68-9865-4BDE-9447-744202DA4224@apple.com">
<div>
<blockquote type="cite">
<div><br
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
<blockquote type="cite"
cite="mid:D8FB366F-7DDE-4869-A1B7-3584B13E353D@apple.com"
style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
<div>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).</div>
</blockquote>
<br
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
<span
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;">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".</span><br
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
</div>
</blockquote>
<div><br>
</div>
<div>(Just to confirm, you <b>don’t</b> object to this change?)</div>
</div>
</blockquote>
<br>
Exactly. I don't object as long as we agree on whatever it is that
we want to go.<br>
<br>
<blockquote type="cite"
cite="mid:23BEDB68-9865-4BDE-9447-744202DA4224@apple.com">
<div>
<div>Ah, this is quite interesting (genuinely) as my
understanding is that one of, if not the, <i>primary</i>
goals of SC-62 was to ensure only TLS leaf certificates could
be issued from server TLS-capable CAs. </div>
</div>
</blockquote>
<br>
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 :-)<br>
<br>
<br>
<blockquote type="cite"
cite="mid:23BEDB68-9865-4BDE-9447-744202DA4224@apple.com">
<div>
<div>This was done by ensuring the allowed uses of CA Key
material in-scope of the TBRs are comprehensively defined as
certificate profiles.</div>
</div>
</blockquote>
<br>
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.<br>
<br>
<blockquote type="cite"
cite="mid:23BEDB68-9865-4BDE-9447-744202DA4224@apple.com">
<div><br>
<blockquote type="cite">
<div><br
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
<span
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;">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).</span><br
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
</div>
</blockquote>
<div><br>
</div>
<div>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. </div>
<div>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.</div>
<div><br>
</div>
<div>I think this intent is clear from discussions like <a
href="https://github.com/sleevi/cabforum-docs/pull/36#discussion_r653544605"
moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/sleevi/cabforum-docs/pull/36#discussion_r653544605</a> </div>
</div>
</blockquote>
<br>
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.<br>
<br>
<blockquote type="cite"
cite="mid:23BEDB68-9865-4BDE-9447-744202DA4224@apple.com">
<div>
<div>or even just the description in <a
href="https://github.com/sleevi/cabforum-docs/pull/36"
moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/sleevi/cabforum-docs/pull/36</a> (carried
forward to <a
href="https://github.com/cabforum/servercert/pull/373"
moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/cabforum/servercert/pull/373</a>):
(emphasis mine)</div>
</div>
<blockquote
style="margin: 0 0 0 40px; border: none; padding: 0px;">
<div>
<div>"Technically Constrained Non-TLS Subordinate CA (7.1.2.3)</div>
<div>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 <b>issuance is still
subject to the BRs</b>, 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.”</div>
</div>
</blockquote>
</blockquote>
<br>
So unless I hear otherwise, the change from the pre-SC62 BRs
stating:<br>
<br>
7.1.2.3 (f). extKeyUsage (required)<br>
<i>"Either the value id-kp-serverAuth [RFC5280] <b>or</b>
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."</i><br>
<br>
was purposely effectively changed to something along the lines of:<br>
<br>
"the value id-kp-serverAuth [RFC5280]<b> </b>MUST always be
present. id-kp-serverAuth [RFC5280] MAY also be present<b>. </b>other
explicit EKUs (codeSigning, timeStamping, etc) MUST not be present
and other values are NOT RECOMMENDED".<i><br>
<br>
</i>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.<br>
<br>
<blockquote type="cite"
cite="mid:23BEDB68-9865-4BDE-9447-744202DA4224@apple.com">
<div><br>
</div>
<div>
<blockquote type="cite">
<div><br
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
<blockquote type="cite"
cite="mid:D8FB366F-7DDE-4869-A1B7-3584B13E353D@apple.com"
style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
<div>
<div><br>
<div>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: </div>
</div>
<blockquote
style="margin: 0px 0px 0px 40px; border: medium; padding: 0px;">
<div>
<div>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?</div>
</div>
</blockquote>
<div>
<div><br>
<div>Breaking this apart, there are several aspects
to consider.</div>
<div><br>
</div>
<div>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.</div>
</div>
</div>
</div>
</blockquote>
<br
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
<span
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;">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.</span><br
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
<br
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
<span
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;">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<span class="Apple-converted-space"> </span></span><i
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">some<span
class="Apple-converted-space"> </span></i><span
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;">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</span><i
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><span
class="Apple-converted-space"> </span>"of TLS server
certificates used for authenticating servers accessible
through the Internet"</i><span
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;">,
i.e. certificates that include the<span
class="Apple-converted-space"> </span></span><i
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">id-kp-serverAuth</i><span
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;"><span
class="Apple-converted-space"> </span>EKU. This has been
discussed in the past during the<span
class="Apple-converted-space"> </span></span><a
href="https://github.com/cabforum/forum/blob/main/SMCWG-charter.md"
style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"
moz-do-not-send="true">chartering process for the S/MIME
WG</a><span
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;"><span
class="Apple-converted-space"> </span>and similarly for
the<span class="Apple-converted-space"> </span></span><a
href="https://github.com/cabforum/forum/blob/main/CSCWG-charter.md"
style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"
moz-do-not-send="true">CSCWG</a><span
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;"><span
class="Apple-converted-space"> </span>which made it
unambiguously clear that the separation of policy scope is
based on the EKU, not the policy OIDs. </span></div>
</blockquote>
<div><br>
</div>
<div>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.</div>
</div>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
<blockquote type="cite"
cite="mid:23BEDB68-9865-4BDE-9447-744202DA4224@apple.com">
<div><br>
<blockquote type="cite">
<div><span
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;">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.</span><br
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
<br
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
<blockquote type="cite"
cite="mid:D8FB366F-7DDE-4869-A1B7-3584B13E353D@apple.com"
style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
<div>
<div>
<div>
<div><br>
</div>
<div><font><span style="caret-color: rgb(0, 0, 0);">Second,
are TBR OIDs defined by their node owner as
representing compliance with the TLS Baseline
Requirements? Based on what’s documented in </span></font><a
href="https://cabforum.org/resources/object-registry/"
moz-do-not-send="true"
class="moz-txt-link-freetext">https://cabforum.org/resources/object-registry/</a>,
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.</div>
</div>
</div>
</div>
</blockquote>
<br
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
<span
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;">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<span class="Apple-converted-space"> </span></span><i
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">"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"</i><span
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;"><span
class="Apple-converted-space"> </span>and these would
not fit that description.</span><br
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
</div>
</blockquote>
<div><br>
</div>
<div>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.</div>
</div>
</blockquote>
<br>
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?<br>
<br>
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).<br>
<br>
<blockquote type="cite"
cite="mid:23BEDB68-9865-4BDE-9447-744202DA4224@apple.com">
<div><br>
<blockquote type="cite">
<div><br
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
<span
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;">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<span class="Apple-converted-space"> </span></span><i
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">"TLS
Server Certificates",</i><span
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;"><span
class="Apple-converted-space"> </span>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.</span><br
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
</div>
</blockquote>
<div><br>
</div>
<div>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).</div>
<div>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.</div>
<div>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.</div>
<br>
<blockquote type="cite">
<div><br
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
<blockquote type="cite"
cite="mid:D8FB366F-7DDE-4869-A1B7-3584B13E353D@apple.com"
style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
<div>
<div>
<div>
<div><br>
</div>
<div>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 <a
href="https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.4"
moz-do-not-send="true">Section 4.2.1.4</a> 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.</div>
</div>
</div>
</div>
</blockquote>
<br
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
<span
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;">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.</span><br
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
</div>
</blockquote>
<div><br>
</div>
<div>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.</div>
<br>
</div>
</blockquote>
<br>
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.<br>
<br>
<br>
<blockquote type="cite"
cite="mid:23BEDB68-9865-4BDE-9447-744202DA4224@apple.com">
<div>
<blockquote type="cite">
<div><br
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
<blockquote type="cite"
cite="mid:D8FB366F-7DDE-4869-A1B7-3584B13E353D@apple.com"
style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
<div>
<div>
<div>
<div><br>
</div>
<div>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,<span class="Apple-converted-space"> </span><b>all
certificates that it issues</b><span
class="Apple-converted-space"> </span>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
(<a
href="https://github.com/cabforum/servercert/issues/495"
moz-do-not-send="true"
class="moz-txt-link-freetext">https://github.com/cabforum/servercert/issues/495</a>)). </div>
<div>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<span
class="Apple-converted-space"> </span><i>explicitly</i> indicates
its own compliance with the TBRs, but to keep the
discussion focused I’m only opining on that
specific scenario.</div>
</div>
</div>
</div>
</blockquote>
<br
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
<span
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;">That's
exactly where original intent needs to be established. We
can decide on the improved language in either direction
very easily.<span class="Apple-converted-space"> </span></span><br
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
<br
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
<blockquote type="cite"
cite="mid:D8FB366F-7DDE-4869-A1B7-3584B13E353D@apple.com"
style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
<div>
<div>
<div>
<div><br>
</div>
<div>Fifth, <font><span
style="caret-color: rgb(0, 0, 0);">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.</span></font></div>
</div>
</div>
</div>
</blockquote>
<br
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
<span
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;">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.</span><br
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
</div>
</blockquote>
<div><br>
</div>
<div>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.</div>
<br>
</div>
</blockquote>
<br>
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.<br>
<br>
<br>
<blockquote type="cite"
cite="mid:23BEDB68-9865-4BDE-9447-744202DA4224@apple.com">
<div>
<blockquote type="cite">
<div><br
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
<blockquote type="cite"
cite="mid:D8FB366F-7DDE-4869-A1B7-3584B13E353D@apple.com"
style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
<div>
<div>
<div>
<div><font><span style="caret-color: rgb(0, 0, 0);"><br>
</span></font></div>
<div><font>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.<span
class="Apple-converted-space"> </span><br>
</font></div>
</div>
</div>
</div>
</blockquote>
<br
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
<span
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;">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.</span><br
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
</div>
</blockquote>
<div><br>
</div>
<div>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)<i>
</i>identify the outcomes which readers perceive of ballots in
the Forum, but that’s perhaps a topic for another day :D</div>
</div>
</blockquote>
<br>
Likewise, it was a good discussion and revealed how different
perspectives can lead to improvements that help those implementing
the TLS BRs :)<br>
<br>
<blockquote type="cite"
cite="mid:23BEDB68-9865-4BDE-9447-744202DA4224@apple.com">
<div>
<div><br>
</div>
<div>Cheers!</div>
<div>-Clint</div>
<br>
<blockquote type="cite">
<div><br
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
<span
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;">Thanks
to all for reading these long emails :-)</span><br
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
<br
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
<br
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
<span
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;">Dimitris.</span></div>
</blockquote>
</div>
<br>
</blockquote>
<br>
</body>
</html>