<div dir="ltr">



















<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif"><b>Validation Subcommittee – Minutes of Thursday, May 5,
2022<span></span></b></p>

<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif"><b>Attendance</b>:<span> 
</span>Ben Wilson, Corey Bonnell, Rebecca Kelley, Hubert Chao, Joanna Fox, Tyler
Myers, Aneta Wojtczak, Wayne Thayer, Janet Hines, Georgy Sebastian, Dustin
Hollenback, Michael Slaughter, Clint Wilson, Doug Beattie, Enrico Entschew, Joe
Ramm, Tobias Josefowitz, Andrea Holland, Stephen Davidson, Martijn Katerbarg<span></span></p>

<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif"><b>Antitrust Statement:</b> Read by Corey Bonnell<span></span></p>

<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif"><b>Previous Minutes:</b> Draft minutes circulated by Aneta
on 5/4/2022.<span>  </span>Dustin asked whether minutes
should be detailed (transcribed) or provided with less detail. Discussion followed that it
depended on who was preparing the minutes and that no protocol has been previously
adopted. One reason for creating detailed minutes is that the IPR Policy deals
with “Contributions” of a member, and detailed minutes help track those. Going
forward, we can use Webex to support transcription, if that’s available. Approval
of the minutes was postponed.<span></span></p>

<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif"><b><u>Profiles Ballot<span></span></u></b></p>

<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Activity has taken place on Github. <span> </span>Last meeting we discussed the commentary
document, which we could discuss again if we have time, or we could discuss the
commits and associated commentary. <span> </span>We
also need to discuss pushing this to a final ballot. Ryan S. said he had several
edge cases that he preferred to discuss rather than items that have already been
pushed in Github.<span>  </span><span></span></p>

<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif"><b>1 – </b>The permitted certificate policies for a<b> </b>non-TLS
sub CA is currently ambiguous.<span>  </span>Does a BR
OID for non-TLS CAs make sense? The group agreed that probably not. <span> </span>A CABF OID doesn’t make sense.<span></span></p>

<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif"><b>2 –</b> In existing BR 7.1.5, name constraints, we reference
the notion of technically constraining CAs with EKU.<span>  </span>The first part says, “For a Subordinate CA
Certificate to be considered Technically Constrained, the certificate MUST
include an Extended Key Usage (EKU) extension specifying all extended key
usages that the Subordinate CA Certificate is authorized to issue certificates
for.”<span>  </span>However, there are CAs that use a precertificate-signing
CA certificate with a special EKU OID specified in RFC 6962 (1.3.6.1.4.1.11129.2.4.4),
similar to how an OCSP responder has a special EKU OID for OCSP signing.<span>  </span>Is that type of CA inside or outside the
scope of the BRs? If we determine that a precertificate-signing CA is
technically constrained, it will weaken requirements on key protection, audits,
etc.<span>  </span>It might also introduce ambiguity
and support an argument by some that the misissuance of a precertificate isn’t a
misissuance under RFC 5280 or the Baseline Requirements. (Even though multiple
root programs will still treat this as a misissuance.)<span>  </span><span></span></p>

<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">The current profiles work has revealed this ambiguity and potential
gap in the BRs. We need to close this potential loophole. Ben asked whether the
precertificate-signing CA certificate would have the serverAuth EKU in addition
to the special EKU.<span>  </span>Ryan said that it
isn’t prohibited by RFC 6962. <span> </span>Looking at
proposed section 7.1.2.4.2 (see <a href="https://github.com/sleevi/cabforum-docs/pull/36" style="color:rgb(5,99,193);text-decoration:underline">https://github.com/sleevi/cabforum-docs/pull/36</a>),
there is a line that says “NOT RECOMMENDED” for any other EKUs. <span> </span>Should that be a “MUST NOT”? <span> </span>Additionally, the title of section 7.1.2.4
could remove the words “Technically Constrained”.<span>  </span>Both of those proposals seemed to have
support from the group.<span>  </span>Otherwise, if
the precertificate-signing CA were to be considered “technically constrained”,
that might exempt that precertificate-signing CA from audits.<span>  </span>Whereas, if we say, “If a CA certificate
conforms to this profile, it is NOT considered Technically Constrained,” then
it would be within the scope of the audit. Also, WebTrust and ETSI could update
their audit criteria to include precertificate-signing CAs in audits to ensure
that they only issue precertificates. <span></span></p>

<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Corey said that if we want to encompass the signing material,
we should evaluate the security benefits of bringing the precertificate-signing
CA in scope. Ryan responded that there a key security policy implication is misissuance
because a precertificate is considered by browsers to be the binding intent to
issue a real certificate. There don’t appear to be downsides to keeping these
CAs in scope. <span></span></p>

<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Ryan <span> </span>– <span> </span>With the profiles, every certificate should be
able to be overlayed on these profiles and must meet the corresponding
requirements for that type of certificate.<span></span></p>

<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Corey – If the intent is to capture the non-TLS profiles, I
think one further challenge of trying to specify the non-TLS profiles is that the
validation requirements are different for other types of certificates, e.g. S/MIME,
etc.<span></span></p>

<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Ryan reviewed the base profile of “Technically Constrained
Non-TLS Subordinate CA (7.1.2.3)” in <a href="https://github.com/sleevi/cabforum-docs/pull/36" style="color:rgb(5,99,193);text-decoration:underline">https://github.com/sleevi/cabforum-docs/pull/36</a>
and focused on “serialNumber” (i.e. must be 64 bits of output from a CSPRNG), “validity”
(i.e. may be backdated up to 1 day), etc. <span> </span>The issue being how those should be handled in
light of other certificate types, like S/MIME.<span></span></p>

<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Under the “Extensions” section of the profile commentary, Ryan
focused on the crlDistributionPoints subsection and noted that it is a property
of the issuer, not of the subject, and so it makes complete sense that it be
included in the profile for Technically Constrained Non-TLS Subordinate CAs. Similarly,
the EKU specification (“BRs 7.1.2.2 (g) already contains rules for non-TLS
subordinate CAs, such as prohibiting id-kp-serverAuth”) is necessary in the profile
to define that it is a non-TLS CA.<span> 
</span>Well-formedness for name constraints is a necessary part of the profile.
<span> </span><span></span></p>

<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">So there are places that impose requirements on non-TLS CAs,
above and beyond RFC 5280 or the existing BRs (although some of them may be
implied by the current BRs), which we can discuss further.<span></span></p>

<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif"><b>3 –</b> See section 7.1.2.5.1 (commentary in <a href="https://github.com/sleevi/cabforum-docs/pull/36" style="color:rgb(5,99,193);text-decoration:underline">https://github.com/sleevi/cabforum-docs/pull/36</a>
) and BR section 7.1.2.2.g.<span>  </span>– we have
requirements on EKUs – “For Subordinate CA Certificates that will be used to
issue TLS certificates, the value id-kp-serverAuth [RFC5280] MUST be present.
The value id-kp-clientAuth [RFC5280] MAY be present. The values id-kp-emailProtection
[RFC5280], id-kp-codeSigning [RFC5280], id-kp-timeStamping [RFC5280], and
anyExtendedKeyUsage [RFC5280] MUST NOT be present. Other values SHOULD NOT be
present.”<span>  </span>But for end entity TLS server certificates,
the BRs currently allow the emailProtection EKU to be present – so there is
some incongruity. <span> </span>Bottom line - in profiles,
under name constraints, can we just delete the RFC 822 name constraint requirement
in the certificate profile because it doesn’t make sense?<span>  </span><span></span></p>

<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Currently, we say, “(New) rules for rfc822Name are
introduced. This is to account for the fact that a Technically Constrained
Non-TLS Sub-CA is still within scope of the BRs, if it is issued by an in-scope
Issuing CA. In order for that non-TLS Sub-CA to also be seen as technically
constrained for its purpose (e.g. technically constrained for email), it's
necessary to be explicit that rfc822Name is permitted. The existing rules from
7.1.2.4 would apply to any rfc822Name constraint, and this attempts to derive
the functional requirements for this field, also in line with the existing
requirements of 3.2.2.4 / 3.2.2.5. Although not intended to be seen as a ‘new’
requirement, as these are reflected through the combination of existing
requirements and clauses, it may be seen as such.” This would be deleted.<span></span></p>

<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Corey – This assumes that there is EKU chaining, which there
isn’t in RFC 5280, so we might be in uncharted territory here.<span>  </span>Ryan – but the BRs assume that EKU chaining
is relevant for audit scoping, although Apple has a different approach, requiring
that everything be audited.<span>  </span><span></span></p>

<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Ryan – One option, for consistency with the BRs, is to
assume that there is EKU chaining, and that the RFC 822 name constraints won’t
matter, or we can lean toward RFC 5280 and conservatively keep the requirement
for “defense in depth”.<span></span></p>

<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Wayne – Do you know if there are any certificates that would
not be permitted to exist if we made this change? <span></span></p>

<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Ryan – We don’t know, because emailProtection is not allowed
in these TLS-issuing CAs.<span></span></p>

<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">The proposal on the table is to remove the RFC 822 name
constraint since their purpose is only to issue TLS certificates.<span>  </span>There was a question from GlobalSign a year
or so ago about clientAuth-only certificates (with RFC 822 names) issued from
TLS CAs, without serverAuth – only for clientAuth, but that is no longer an open
question from GlobalSign.<span></span></p>

<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif"><b>4 – </b>BR<b> </b>Section<b> </b>7.1.2.2.a. currently says
for policyIdentifiers – “The following fields MAY be present if the Subordinate
CA is not an Affiliate of the entity that controls the Root CA … [then you can
have a CPS URI].”<span>  </span>(But if you are an
affiliate, you can’t have these?)<span>  </span>There
are a variety of subordinate CAs in the web PKI that may or may not be
affiliates and what does this all mean? <span></span></p>

<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Regarding section 7.1.6.2.1 of the proposed profile (<a href="https://github.com/sleevi/cabforum-docs/pull/36" style="color:rgb(5,99,193);text-decoration:underline">https://github.com/sleevi/cabforum-docs/pull/36</a>),
and for most of our profiles, including non-TLS CA profiles (7.1.2.5.1), they refer
to Affiliated CAs – that’s a bug that needs to be fixed because we have
different requirements when they are affiliated or not affiliated.<span>  </span>Or to simplify it, we could remove this
distinction in BR 7.1.2.2.a entirely and allow all CA certificates to have CPS
URIs. <span> </span>Alternatively, we would create
variations for every instance of CPS URI in the profiles for affiliated vs.
unaffiliated CAs because we have different requirements for EKUs and policy IDs
when you’re affiliated vs. unaffiliated.<span> 
</span>Removing the distinction in the profiles seemed to be the way to go,
where possible, with the exception of the anyPolicy OID, which would have the distinction.<span></span></p>

<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">See also EVG section 9.7 (if you’re issuing an EV,
non-affiliated CA, you have to put the CPS URI qualifier in).<span>  </span>When the issuing CA is controlled by the
entity, the CPS URI can be included, even though it is going to be the same as
the parent CA. <span></span></p>

<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif"><b>5
<b> – </b></b>Ryan will update the commentary in <a href="https://github.com/sleevi/cabforum-docs/pull/36" style="color:rgb(5,99,193);text-decoration:underline">https://github.com/sleevi/cabforum-docs/pull/36</a>
based on today’s discussion.<span>  </span>This is
taking a diff approach.<span>  </span>Currently it’s gone
from v. 1.8.1 to 1.8.4.<span>  </span>When it is done,
it will not only explain where something came from, but also why we made a particular
decision when multiple things were permitted.<span> 
</span>We things ironed out, we could enter the discussion period next week.<b><span></span></b></p><b>

</b><p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif"><b>6 
 – 

</b>One last thing – name uniqueness for OCSP signing certificates.<span>  </span>It’s not a problem when they are the same key,
and we don’t currently require CA uniqueness of names in the currently proposed
profile document. <span></span></p>





</div>