<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 Meeting of Thursday, December 16,
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>Roll Call:</b> <span> </span>Ben
Wilson, Corey Bonnell, Tim Hollebeek, Wayne Thayer, Ryan Dickson, Paul van
Brouwershaven, Andrea Holland, Aneta Wojtczak, Brittany Randall, Bruce Morton,
Clint Wilson, Dimitris Zacharopoulos, Janet Hines, Joanna Fox, Jose Guzman,
Kati Davids, Kidd Freeman (OATI), Michael Slaughter, Martijn Katerbarg, Natalia
Kotliarsky, Pekka Lahtiharju, Rebecca Kelley, Tobias Josefowitz, Trev
Ponds-White, Tyler Myers, and I<span>ñ</span>igo Barreira <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 Tim.<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> was reviewed.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif"><b>Next Call:</b> <span> </span>Call
of December 30, 2021, is cancelled.<span> </span>Next
call is January 13, 2022. <span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif"><b>Vulnerabilities of Distributed Domain Validation<span></span></b></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">We discussed the recent research paper (<a href="https://dl.acm.org/doi/pdf/10.1145/3460120.3484815" style="color:blue;text-decoration:underline" target="_blank">https://dl.acm.org/doi/pdf/10.1145/3460120.3484815</a>)
introduced by Wayne Thayer to the mailing list on multi-perspective DNS
validation to prevent certificate misissuance due to DNS hijacking. Let’s
Encrypt has implemented multi-perspective domain validation. We might want to
invite the authors of this recent paper to present to us. <span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Wayne explained that the researchers performed downgrade
attacks. A CA queries DNS from multiple points, but the attacker eliminates
some to where the system is forced down into only using one. The attacks
degrade DNS responses on the other points and then you attack just the one that
is remaining with cache poisoning, route hijacking, etc. <span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Wayne asked whether the Validation Subcommittee was the
right group to tackle this issue with requirements aimed at closing down some
of the vulnerabilities. He noted that the research paper hints at ways that the
attacks could be mitigated to some extent.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Paul said it might be something for the NetSec group to
address because a couple of the recommendations were RPKI and DNSSEC. Many DNS servers
automatically select the best performing authoritative DNS server. By attacking
by overloading DNS servers with queries, it could result that the attacker’s
DNS server becomes the best performing DNS server. One of the strategies is to
randomly select DNS servers so that even poorly performing ones are queried. Paul
said that NetSec might more appropriate because things like RPKI are a best
practice for anyone operating a network. Cloudflare and others have had success
in implementing RPKI to prevent these kinds of things from happening. It would
help if CAs were required to run their own infrastructure behind a network that
is protected by RPKI. For random selection for DNS lookup, that might be a
NetSec issue, too.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Tim noted that these methods may not be specific to CAs
only, and that it could just be considered good practice. Tim said that NetSec
is traditionally focused on protecting CA systems from external attacks, but
technical details of validation would be better addressed in the Validation
Subcommittee, and that is why we previously discussed multi-perspective
validation. Paul agreed that it would still be within the Validation
Subcommittee’s purview, and we could come forth with technical requirements. <span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Tim noted that when we discussed multi-perspective
validation previously, and as he recalled without looking at the discussions, there
may have been hesitation due to issues with practice and scale that caused
people to not move forward with it as a requirement.<span> </span><span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Dimitris recalled that we discussed requiring RPKI, which
basically accepts only signed route objects, and whether the CA needs to have
its own infrastructure for this and must follow this method, or whether upstream
service providers could be required by the CA to implement this. A CA that does
one or the other has a better chance of mitigating these types of attacks.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Paul said it depends, because if you use an upstream ISP, the
ISP should use RPKI not just for you as the CA, but because it is an ISP, but
some ISPs might say that they don’t have that capability. The other challenge
is that you can do it as an authoritative source (someone cannot fake to be
you), intercepting and proxying response codes. But it is really about the
subscriber target you are checking, if they are not doing RPKI as well, then
the attack could still happen on their side. It might be good to make these
things long-term requirements. If it were a requirement for ISPs of CAs, then it
could help add pressure on the ISPs to implement it because if you are not
going to do this, then we need to go somewhere else. Tim stated that it would
be good to find out who is doing it and that the CA market might not be big
enough to push ISPs in any significant way.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Paul – You can use RIPE Stat (<a href="https://stat.ripe.net/" style="color:blue;text-decoration:underline" target="_blank">https://stat.ripe.net/</a>) you can enter your IP
address to see if it is announcing an RPKI record. So, it’s really easy to see
if your network is protected.<span> </span>More and
more RPKI is becoming a required practice. <span> </span><span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Tobias asked how would RPKI mitigate these attacks?<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Paul responded that the research paper describes how the
attacker would capture packets, re-encode them, proxies them, etc. <span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Tobias said but everybody needs to use it.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Paul said yes, but the attack was also implemented on the CA
side as well.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Tobias said that if RPKI were deployed, then we wouldn’t
need multi-perspective validation to begin with.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Paul said the challenge would be how to get subscribers to
implement RPKI, but CAs need to step up and <span> </span>begin implementing it themselves, like
Cloudflare has done. <span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Dimitris said it’s partially mitigated unless everybody implements
RPKI.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Wayne noted that we should not focus just on RPKI because it
is only one of the mitigations, and multi-perspective validation is better than
validation being done by CAs today. There are things we could do here, such as
improving authoritative name server selection. There are things that can be
done here or in NetSec to improve from single-point validation to multi-point
validation. It is a matter of resources and time as to the progress we can make
on addressing these issues.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Tim said that looking at this in depth will be more helpful
than just having various people saying that CAs should be doing various things.
Tim will see if we can speak with the authors. Paul agreed that it would useful
and that we should also be looking to see what solutions are easier for CAs to
implement in the short term. We should look at the effort needed for CAs to
take in order to get us where we want to be (e.g. an analysis of the costs,
burdens and benefits). <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>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif"><b>Ballot SC-52 - Time Intervals for CRLs<span></span></b></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">See discussion at <a href="https://lists.cabforum.org/pipermail/validation/2021-November/001724.html" style="color:blue;text-decoration:underline" target="_blank">https://lists.cabforum.org/pipermail/validation/2021-November/001724.html</a>.
<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">We discussed whether we should put time frames in terms of seconds
in the Baseline Requirements. <span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Dimitris said he wanted a few more days to consult with his
team before we started a vote. Tim said that would be fine.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Wayne asked when the ballot discussion period would expire
and whether we needed to refresh the ballot or start voting now because we
don’t want to be voting during the holidays. <span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Tim said he would work on a refresh it and put it out on January
3, 2022, for voting.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif"><b>CNAME delegation to the CA<span></span></b></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Discussions about CNAME delegation have previously occurred.<span> </span>See <a href="https://lists.cabforum.org/pipermail/validation/2021-December/001734.html" style="color:blue;text-decoration:underline" target="_blank">https://lists.cabforum.org/pipermail/validation/2021-December/001734.html</a>.
<span> </span>Discussions have revolved around the
purpose of the CA going through the effort of retrieving a token that they put
there and whether that tests that the customer still has the delegation in
place at the time of issuance.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Wayne said he liked Tim’s proposal, but his concern is that
it changes the requirement for the applicant to demonstrate control of time at
time of issuance to require once at time of initial issuance and to leave it in
place until they revoke it. His concerns are about renewals where a CNAME has
been delegated to a CA, the CA is going to check it to make sure that the CNAME
is there, but the applicant is no longer involved. That differs from the other
methods where we require the applicant’s involvement.<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 agreed that it is qualitatively different and that we should
discuss whether it is good and if there are concerns. <span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Wayne said that it makes automation of certificate issuance
easier, as long as it’s secure. <span> </span>A random
value is only value for 30 days, and why can this be different.<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 said, “If there are problems with the method, the fact
that the CA is involved, … if there is anything going wrong, then there may be
problems with some of the CDN providers ... “ Do we need to revisit that, and if
so, what security analysis do we need to do?<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Wayne said that the distinction, from the CA’s perspective,
is that if the CDN is requesting the certificate, they are the applicant, legal
issues aside. <span> </span>From a CA’s perspective,
the applicant is demonstrating control, but when the CA is doing it, that is
not the applicant demonstrating control.<span>
</span>But what about Google, Apple, etc. getting certificates from themselves?<span> </span>What if the organization is both the CA and
the Applicant? <span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Tim that is a known problem with the BRs today, similar to whether
a CA can generate the keys if it is also the applicant.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Wayne said the problem is the argument that if you are the
CA, then you can’t also be the applicant.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Tim said we should fix these inconsistencies.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Corey noted that the requirement that the CA provide test websites
with certificates raises a similar question. <span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Wayne asked, in the case where the CA is not allowed to do
something, because it is validation, can the CA claim an exception because it
is doing it as the applicant?<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Tim said the requirements contradict themselves on what to
do when the CA is the applicant.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Wayne asked whether this is a “fail-closed” situation?<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Tim wondered whether CAs would have to revoke the
certificates on their test websites, and Wayne said it depends on what
validation methods were used.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Ben said that if we go too far down with the analysis it
gets to the point of absurdum.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Tim said we should amend the requirements to address, “when
the CA is the Applicant” and specify that when it is doing CA things, it follows
CA requirements and when it is doing applicant tasks, it follows applicant
requirements, and when there is a contradiction, resolve it to say that the CA
needs to do nothing special from what they were otherwise doing. <span> </span><span> </span><span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Wayne said that would solve the problem here, for the most
part. Clarification works that any of these validation methods have to be tied
to a particular customer account.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Tim said it would clarify and one could argue that the “MAY”
language is useful because it indicates that it is allowed behavior by the CA. It
clears up the ambiguity of whether the customer is allowed to delegate to the
CA or not.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Dimitris asked how would this account-focusing part work
with ACME? <span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Tim said he thought this would work better with ACME because
you already have the account separation.<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 the applicant would create a one-time CNAME
for the ACME challenge subdomain for the CA. If you’re using a particular ACME
client, Certbot, then it can do the DNS, you could set up the DNS challenge on
your behalf. You could have the client skip that part and have it delegated to
the CA, and it publishes the challenge. There is limited benefit, I guess.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Tim – The ACME protocol could be upgraded to handle this
better. Because if the ACME protocol allowed you to specify that the CNAME
delegation was already in place, then people could use that instead of the new
URL. Certbot would need to be updated to be aware of this method of validation.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Wayne suggested that the ballot be circulated for discussion.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Tim will propose a ballot. Ben and Clint will look at the
draft ballot and let Tim know whether they’ll be able to endorse.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif"><b>Certificate Profile Suggestions<span></span></b></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">See Corey’s email - <a href="https://lists.cabforum.org/pipermail/validation/2021-December/001738.html" style="color:blue;text-decoration:underline" target="_blank">https://lists.cabforum.org/pipermail/validation/2021-December/001738.html</a>.
<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Ryan Dickson said that he had argued previously to keep the
requirement for an AKI in self-signed root certificates. As he understands it,
Windows, MacOS, and maybe Adobe use AKI and SKI as part of path building. Chrome
is looking to move away from platform verifiers, so the concern for Chrome is
not particularly long-lived, and others have not voiced interest in keeping the
requirement. <span> </span>So I’m fine with going
ahead and removing it from the draft ballot as Corey had suggested. <span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Ryan D. said that a second issue is cross-certificates
requiring EKUs. What is being changed?<span>
</span>Isn’t this more of a dis-ambiguation?<span>
</span>BR section 7.1.2.2 says the EKU MAY be present for what we are re-phrasing
as affiliated cross certificates. “EKU may be present” is equivalent to either presence
or absence of the EKU. <span> </span>We need to be
mindful of affiliated cross certificates and non-affiliated cross certificates.
For affiliated cross certificates, the proposed language is a “SHOULD.” Functionally,
I don’t see it as different.<span> </span>Only change
is that affiliated CAs we’re going from “May” to “Should”. For unaffiliated
cross certificates, the current language says, “For all other Subordinate CA
Certificates, including Technically Constrained Subordinate CA Certificates:<span> </span>This extension MUST be present”, etc. Functionally,
I do not see a difference. How do other people interpret this?<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Tim said that the European regulators and auditors follow
DigiCert’s approach to “shoulds” and require explanations for departures.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Clint said that CAs should justify departures from any “shoulds”,
but it’s still different from a “must”.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Tim acknowledged that the transition from a “may” to a “should”
is a small change.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Ryan D. said we’re trying to jam a lot into these profiles. The
more we can simplify, the better.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Tim said that on the next call we should be prepared to discuss
what items we can just ship because there aren’t any issues, and which are the
ones that need more discussion. <span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Dimitris said he I thought that we had previously agreed to
post the profiles ballot without any normative changes and then have a version
2. It is much easier to evaluate these kinds of changes in two steps. Some
auditors read RFC 2119 a little more strictly.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Trev agreed with Dimitris that we had previously discussed
the transition from “mays” to “shoulds” and that “shoulds” were considered best
practices and could eventually become “musts” and we should treat “shoulds”
this way.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Ryan D asked whether we should remove the “shoulds”?<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 said that some people in some standards groups take that
approach. It would be great if we could modify RFC 2119 to explain in greater
detail what “should” means. <span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Trev suggested that next year we look at the “shoulds”.<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>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Meeting adjourned.</p>
</div>