<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, February
9, 2023<span></span></b></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif"><b>Minute Taker:</b><span>
</span>Ben Wilson<span> </span>(<b>Next Up:</b><span> </span>Andrea Holland)<span></span></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>Aaron
Poulsen - Amazon Trust Services, Andrea Holland - VikingCloud, Aneta Wojtczak –
Microsoft, Bruce Morton – Entrust, Ben Wilson – Mozilla, Chris Clements -
Google Chrome, Clint Wilson – Apple, Corey Bonnell – DigiCert, Doug Beattie –
GlobalSign, Dustin Hollenback – Microsoft, Enrico Entschew - D-Trust, I<span>ñ</span>igo
Barreira – Sectigo, Joe Ramm – OATI, Kiran Tummala – Microsoft, Martijn
Katerbarg – Sectigo, Michelle Coon – OATI, Nargis Mannan – VikingCloud, Paul
van Brouwershaven – Entrust, Pekka Lahtiharju – Telia, Rebecca Kelley – Apple,
Rollin Yu – TrustAsia, Ryan Dickson - Google Chrome, Michael Slaughter –
Amazon, Stephen Davidson – DigiCert, Tobias Josefowitz – Opera, Trevoli
Ponds-White - Amazon Trust Services, Wendy Brown - FPKIMA<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:<span> </span></b>Minutes
of January 26, 2023, prepared by Aneta Wojtczak, unanimously approved. <span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif"><b>Agenda Review:</b><span>
</span>Notably, the certificate profiles topic is no longer on the list,
because that is now up in the Server Certificate Working Group, and the
discussion period has started.<span> </span><span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Face-to-face planning:<span>
</span>The role of the Applicant and Applicant Representatives as defined in
the BRs. We've also had some discussion on LEIs, which is another topic that we
can discuss. <span> </span>What else?<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">There is the OCSP-optional ballot, but maybe that is a
Server Certificate Working Group topic and not a Validation Subcommittee topic.
Ryan Dickson was planning on pursuing that more seriously after the profiles ballot
because of the way that that changes would flow. With regards to business of
the Server Certificate WG, there was also the other OCSP ballot proposed by David
Kluge regarding SLAs, but for these kinds of things we do not seem to find time
during the WG meetings to discuss them. <span> </span>We might use some of the time to discuss
Server Certificate WG items. Still, the problem seems to be that we only have
half an hour every other week because we are with the Forum call, so it’s
something we should think about for the face-to-face meeting.<span> </span>Bruce agreed with looking at the face-to-face
schedule to see what we can address from the Server Certificate WG perspective.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Ryan proposed that we discuss multi-perspective domain
validation, because we will hear from a guest speaker, Henry Briggs-Lee of
Princeton, who specializes in multi-perspective domain validation or multi-vantage
point domain validation, BGP hijacking, and network style attacks. We could
have proactive discussions following the presentation. <span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">It was agreed that we should discuss multi-perspective
validation and the research findings. It will be presented and then we can also
do the Applicant/Applicant’s Representative next-steps discussion as well. <span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Ben mentioned that he would talk about incident report types
and that about 50% of the incidents in Bugzilla have been EV or OV misissuances,
and he’d like to discuss how we can bring that number down.<span> </span>However, he didn’t think he was ready to
address that yet, because he needs to look more carefully at the underlying
causes, and he hasn’t done a full analysis of those.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Bruce suggested that because the EV Guidelines are coming up
on being 17 or 18 years old, maybe it was time to revise them.<span> </span>They are too legal and not techie/not as
technical as the rest of our specs, and maybe EV misissuances will go down with
simpler EV requirements. <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 from his recollection, there is always some
field that got mis-validated, either in OV or EV, and there's certainly more OV
than EV. <span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">We should look to where the requirements can be improved to
mitigate against misissuance, but until we have more root cause analyses, it might
be difficult to have the discussion. <br></p><p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">We have
two potential topics--Applicant Representative next steps and multi-perspective
domain validation. <span> </span>Do we want to split the
time half and half and go 45 minutes with each one?<span> </span>Well if there's no strong opinion, we can go
half and half.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">The third agenda item for today is to look at next steps in our
analysis of the BR's “Applicant” and “Applicant Representative”. <span> </span>The notable items have been divided into 3
buckets, the first of which is “To keep in mind”, the second is “To discuss
further,” and the third is “To do”. <span> </span>Discussion
items might warrant further discussion to come up with actionable next steps in
terms of developing concrete requirements, while to-do items are more straightforward.
<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">First, we have noted that we should try to maintain the
current language in the Subscriber Agreement and Terms of Use requirements to
avoid any messy legal changes. But in BR Section 9.6.3 we have talked about
replacing Subscriber with Applicant/Subscriber, and then also changing the
language to differentiate “initial certificate requests” and “subsequent
requests”. <span> </span>Ben was in favor of making
the changes proposed in BR section 9.6.3. <span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Second, there are five “to discuss further” items that Corey
distilled from the conversations.<span> </span>From
his email of February 6, they were:<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 0in 0.5in;line-height:normal;font-size:11pt;font-family:"Calibri",sans-serif">1. Do we need a term to encompass the
concept of a current Subscriber that has submitted a Certificate Request for a
new Certificate?<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 0in 0.5in;line-height:normal;font-size:11pt;font-family:"Calibri",sans-serif">2. Ben's language for section 1.3.3:
<a href="https://lists.cabforum.org/pipermail/validation/2022-November/001826.html">https://lists.cabforum.org/pipermail/validation/2022-November/001826.html</a><span></span></p>
<p class="MsoNormal" style="margin:0in 0in 0in 0.5in;line-height:normal;font-size:11pt;font-family:"Calibri",sans-serif">a. Does this resolve concerns around CAs
issuing Test Website certificates, etc.?<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 0in 0.5in;line-height:normal;font-size:11pt;font-family:"Calibri",sans-serif">3. More closely examine references to
"hosting providers" in section 9.6.3 and other locations<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 0in 0.5in;line-height:normal;font-size:11pt;font-family:"Calibri",sans-serif">a. This ties very closely into the
extensive discussion in November on "Cloud Providers" issuing
certificates from CAs that are controlled by the "Cloud Provider":
<a href="https://lists.cabforum.org/pipermail/validation/2022-November/001827.html">https://lists.cabforum.org/pipermail/validation/2022-November/001827.html</a><span></span></p>
<p class="MsoNormal" style="margin:0in 0in 0in 0.5in;line-height:normal;font-size:11pt;font-family:"Calibri",sans-serif">4. What exactly is a “certificate
request”? Sections 4.1 and 4.2 need help, as it's not clear what exactly a
"certificate request" is or what exactly a "certificate
request" is comprised of (<a href="https://github.com/cabforum/servercert/issues/400">https://github.com/cabforum/servercert/issues/400</a>)<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 0in 0.5in;line-height:normal;font-size:11pt;font-family:"Calibri",sans-serif">5. What do the Terms of Use accomplish
when the Subscriber is the CA?<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">The first item is that we need a term to encompass the
concept of a current subscriber that has submitted a certificate request for a
new certificate. Ben asked if we could just use the term “current subscriber”?<span> </span>Or there might be some other phrase that says
“the subscriber seeking renewal”. <span> </span>We
looked at BR sections 4.1.2, 4.1.4, and 4.2.1. The concept expressed there is
that one certificate request may suffice for multiple certificates being issued
to the same applicant. <span> </span>One idea was that
if we used Applicant/Subscriber down in section 9.6.3, then we could use Applicant/Subscriber
elsewhere in the BRs, too.<span> </span>However,
would it change the meaning of the section where the certificate may not be
issued yet. So there was concern about introducing the word “Subscriber” and
whether it might cause confusion.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Corey said it would be good to have a term that addresses
the different situations where the applicant is seeking to renew a certificate
or obtain additional certificates.<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 a subscriber can be an applicant, and an
applicant can be a subscriber, and sometimes both at once, and sometimes
separately, but it is unclear where that causes confusion for CAs and where and
how it can be fixed to address any concerns or provide more clarity.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Doug said that we have the definition for Applicant and Applicant
Representative, but we don't have the same for Subscriber, and should we adopt
something for a “Subscriber Representative”? They would be delegated certain
abilities to manage certificates that the subscriber may have allocated to
them, like revocation by a third party or something like that?<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Trev said that we need to address how people want to manage
certificates. They want to obtain a certificate and get another one so that
their service stays up and running. There may be places in the BRs where we
have written the rules in a way that is hostile to automation. Can someone just
say, “for this duration, I am using this other service just to manage my
certificates for me”? <span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Doug asked about delegating responsibilities to a reseller
or partner.<span> </span>Can you delegate revocation
responsibilities to a reseller for all the certificates that they resell? <span> </span>Can the subscriber explicitly say, somewhere
along the way, “that's OK”?<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 it made sense to provide clarity in those
areas, such as a subscriber representative, because there is delegation and shared
responsibility, preserving the idea that ultimately the subscriber is
responsible, but that doesn’t address the question of whether the subscriber can
be an applicant.<span> </span><span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Trev said we need to look at how people want to use certificates.<span> </span>For example, 10-day certificates--some people
might interpret the BRs to mean that every time someone gets a new ten-day certificate
they need to have performed a manual action to agree to a subscriber agreement.<span> </span>That's the opposite of what we want, and what
people want to do with certificates. <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 notion of a subscriber representative,
and also the aspects of automation, touch closely on some of the other
discussion points that we raised and have discussed previously around hosting
providers and cloud providers, which is in Point 3.<span> </span>Maybe if we address that first, then it can
feed into these other issues?<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Ben asked whether we needed someone to write up a use case
or a conceptual model that we can use to compare how these service providers do
automated certificate renewal or issue additional certificates. And then we
could go through the BRs and determine whether the current language works or
not or where we need to make an adjustment to the BRs to accommodate these newer
service models. Whatever that thing is that manages certificates for the users,
and then we identify those rough parts in the BRs.<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 asked whether we should look at different models, like
CDNs, hosting providers, and any other services we can think of, and try to
model those services in terms of the applicant, the subscriber, and the CA, and
their relationships, and then identify misalignment with the BRs in terms of
those models.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">There was general agreement that we should look at how these
things work, or how we want them to work, and then come back to the BRs.<span> </span>It was also suggested that between the
meeting and the upcoming face-to-face meeting that work could be done on each
of these different models so that we could discuss them at the face-to-face
meeting.<span> </span>We could also have people identify
their pain points, because in this respect there may be groups using ACME that
have pain points with the current BRs.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">The group then discussed some of the differences between a
traditional hosting provider and the cloud service provider.<span> </span>In some situations, the Subscriber generates
the key on the hosting provider’s machine, and is given a CSR. The Subscriber
then finds a CA and brings back the certificate chain and then an administrator,
or some automated interface, takes that certificate chain and installs it on
the web server, whereas in the cloud model it is more automated.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">The ACME model was also mentioned. Ryan explained that with ACME,
you first register an account with the CA, and at that point you accept the
terms of service or subscriber agreement. You register an account that
basically creates a local key pair that is then used to sign all subsequent
requests to that service. You're accepting the subscriber agreement once and
then thereafter anytime you make any request either to replace an existing
certificate, renew or revoke. You do not sign a new subscriber agreement. It's
basically accept once, use many.<span> </span>RFC 8555
basically describes two life cycles within the service itself. The first is
registration, and the second is certificate management. So you perform
registration once, and that's where you're creating a specific account with the
ACME server, which we can think of as like the CA. And once that is done, you basically
have a local key pair on your device, that is, that is then used to
authenticate feature requests to the CA.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">The group then discussed spinning up some document sharing
to explore the different service models, and Corey will be sending an email seeking
volunteers.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">The meeting on February 23, 2023, will be cancelled.<span> </span>The next meeting following the face-to-face
will be on March 9, 2023.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Meeting adjourned.<span></span></p>
</div>