<div dir="ltr"><div>Here are the draft minutes.</div><div><br></div><div>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif"><b>Validation Subcommittee Meeting April 22, 2021<span></span></b></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 Tim<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif"><b>Attendees</b>:<span> </span>Ben
Wilson, Andrea Holland, Clint Wilson, Aneta Wojtczak, Tim Hollebeek, Corey
Bonnell, Bruce Morton, Curt Spann, Enrico Entschew, Doug Beattie, I<span>ñ</span>igo
Barreira, Janet Hines, Johnny Reading, Ryan Sleevi, Michelle Coon, Niko
Carpenter, Paul van Brouwershaven, and Wayne Thayer <span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif"><b>Agenda:</b> Wildcards, CAA and Certificate Profile
Updates<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif"><b>Wildcards & ADNs (SC45):</b> Ryan worked with
Dimitris re: how work relates to appendix B (.onion validation rules) and
whether a host-based control actually demonstrates control over the whole
domain name space.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Sites that use .onion certificates have a Tor daemon on one
server that is doing proxying for different subdomains.<span> </span>Subdomains don’t go over the Tor network, they
are conveyed by the host header if you’re using http. The daemon runs on one
server and inspects the SNI to dispatch to other servers.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Control over one of these destination servers doesn’t mean you
have control over the onion private key or the entire domain namespace. Control
over the destination server doesn’t mean you control the proxy server.<span> </span>Purpose of the ballot is to make it clear
that the validation of a subdomain is not validation of the domain namespace or
of subdomains beneath it.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">The implementation requirement date is being moved from
October 2021 to December 2021.<span> </span><span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Corey – ACME IP address validation discussion at IETF is
making some security assumptions – concerns about passive proxying and whether
use of SNI is sufficient demonstration of control.<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 – for this ballot, we are not making such assumptions -
control over private key doesn’t assume authorization for the namespace.<span> </span>The primary method for demonstrating control
would be the CSR method using the private key. <span> </span>The well-known URI cannot be used to demonstrate
control of the whole namespace.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif"><b>CAA ballot (SC46):</b> Purpose of the ballot is to remove
DNS operator exception from the CAA-checking requirements. You always check CAA.
That ballot is ready to go.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif"><b>Certificate Profiles</b>: Ryan announced items to resolve
or to call out or to pay attention to.<span> </span><span></span></p><span><span><span style="font:7pt "Times New Roman""> </span></span></span><b>Name Constraints and BR section 7.1.2.4.2:</b>
<span> </span>PDFs circulated on the list, there is dif
file you can look at – <a href="https://github.com/sleevi/cabforum-docs/pull/36/files" style="color:rgb(5,99,193);text-decoration:underline">https://github.com/sleevi/cabforum-docs/pull/36/files</a><span></span>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">BRs talk about the three constraints – DNS constraints, IP
address constraints, and Directory Name constraints.<span> </span>The idea is to transition SHOULD NOTs (profiles
phase 1) to MUST NOTs (profiles phase 2). In Mozilla policy, it doesn’t address
<b>RFC 822 and SRV names</b>. You could be exempt from audits, but still
subject to Mozilla’s policy and CCADB disclosure would be required. The
proposed profile would illustrate how to handle constraints for RFC 822 and SRV
names. Under Mozilla Policy, the domain part of the RFC822 name must be validated
per BR <span>§</span>
3.2.2.4. For SRV names, the name portion must be validated. The goal is to
provide guidance for CAs trying to technically constrain intermediate CAs. <span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">If SRV names were supported in browsers, all of these SRV
names would not be technically supported and it would create a security risk.
Clients can introduce support for the new name types, but the security gap
needs to be closed first.<span> </span>There needs to
be a transition as CAs issue newer intermediate CAs. Clients/browsers won’t
support SRV until CAs have technically constrained their intermediate CAs by
SRV names. Ryan will create an issue in the servercert GitHub repository to
track steps and conclusions.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">With regard to <b>non-critical name constraints</b>, Ryan
had a question for Apple.<span> </span>In the profiles
v.1 phase, it was decided to go with non-critical name constraints because of Apple
and OpenSSL098. What about a 2022 sunset for non-critical name constraints
(requiring that they be marked critical)?<span>
</span>This would apply to any new sub CAs.<span>
</span>Dimitris noted that there are relying parties still using old mobile
phones that we need to look at.<span> </span>For
example, it is hard to get relying party data because they are customers of
customers (e.g. Bank Customers). <span> </span>Ryan noted
that there are these issues and he’ll file an issue in the GitHub repository
and kick off a discussion on the validation list.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif"><b>Cross certificates</b>. Ryan noted that in the profiles he
was trying to clarify when you issue a cross-certificate to a sub CA. Now it will
be called a cross-certified subordinate CA certificate. See BR <span>§</span>
7.1.2.6.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Another related issue is that today we don’t consistently
use “subscriber certificates” and “server certificates”.<span> </span>In section 7.1.2.6, the word “server” is
added in parenthesis – (Server) – to clarify that is the end entity certificate
profile because there is a language issue in the BRs today.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Ryan asked whether his current approach in sections 7.1.2.6.1
– 7.1.2.6.5 (IV, DV, OV, EV) was acceptable. <span> </span>Then, there are two other types of end entity
certificates (not to be tackled in the profiles v1 phase) – <b>(a) signed-exchange
certificates</b> with extensions and issues with EKU compatibility and they are
90-day certificates.<span> </span>Intent is that they
authenticate the domain name just like TLS certificates and they want to be
treated like TLS certificates, and <b>(b) delegated credential certificates</b>
– that are server certificates that indicate the server supports delegated
credentials by protecting keys used in Cloudflare and Facebook, and Mozilla has
been supporting these. Neither of these have been finalized yet in IETF (but they
need references and runnable code).<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Ryan has also updated the pull request description for WIP pull
request #36 to explain why things are changing. The next step is to move this to
a CABF pull request.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif"><b>Validity Periods<span></span></b></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">These are TBD in every certificate profile.<span> </span>There has been concern about backdating (pre-dating,
too) server certificates. E.g. strawman proposal is to prohibit back dating
past 30 days and only if the information was valid at that time. Thus, you
would be prohibited from back dating a server certificate if you verified the domain
only today. Also, there would be no pre-dating – you cannot issue a certificate
in the future.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Tim – last time we talked about this, we were not going to
allow backdating more than 7 days, but there was still debate about that because
there was still an unresolved clock-skew issue.<span>
</span>We couldn’t get consistent information. One issue, for example, is that
customers want their certificates as quickly as possible, so certificates are
issued as soon as validation is performed.<span>
</span>So the second part of the requirement (only if the information was validated),
presents a problem because the reason for <span> </span>backdating is to account for clock skew. <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 – what is the right balance? <span> </span><span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Tim – We need two rules- one for short backdating and one
for long backdating.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">I<span>ñ</span>igo – what about CAs trying to avoid requirements?<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Ryan – yes, we need to make sure that the BR addresses this,
and validity periods would still need to be observed. <span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif"><b>Backdating CAs</b> – the effect on optimal path-building
necessitates some degree of backdating. The rules for CAs needs to be more
permissive, but with a caveat. Let’s say you have an existing CA with a given
SPKI, and you are trying to replace it.<span> </span>If
you are transitioning to a new certificate from an existing certificate,
backdating is fine. <span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Curt: Does there need to be a tie to the audit window?<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: Look at section 7.1.2.2.1 of the document. I think
your question relates to the replacement of a CA with a cross certificate. Thus,
if the certificate was audited according to the then-existing requirements, and
everything was good, then you can still backdate. In other words, if you have all
of the audits, then you can backdate to that period. But if you created the
root or sub CA and it was not audited for a period of time, then you cannot
backdate.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Adjourned.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif"><span> </span></p>
</div></div>