<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p class="MsoNormal">These are the Final Minutes of the
Teleconference described in the subject of this message, prepared
by Dimitris Zacharopoulos (HARICA).<br>
</p>
<h1 id="minutes-validation-subcommittee-2023-03-09"
style="page-break-inside: avoid;">Minutes validation subcommittee
2023-03-09</h1>
<h2 id="roll-call" style="page-break-inside: avoid;">Roll call</h2>
<p style="page-break-inside: avoid;">Aaron Poulsen - (Amazon),
Andrea Holland - (VikingCloud), Aneta Wojtczak-Iwanicka -
(Microsoft), Ben Wilson - (Mozilla), Bruce Morton - (Entrust),
Chris Clements - (Google), Clint Wilson - (Apple), Corey Bonnell -
(DigiCert), Daryn Wright - (GoDaddy), Dimitris Zacharopoulos -
(HARICA), Doug Beattie - (GlobalSign), Dustin Hollenback -
(Microsoft), Enrico Entschew - (D-TRUST), Inigo Barreira -
(Sectigo), Janet Hines - (VikingCloud), Johnny Reading -
(GoDaddy), Joseph Ramm - (OATI), Kiran Tummala - (Microsoft),
Martijn Katerbarg - (Sectigo), Michael Slaughter - (Amazon),
Michelle Coon - (OATI), Nargis Mannan - (VikingCloud), Paul van
Brouwershaven - (Entrust), Pekka Lahtiharju - (Telia Company),
Rebecca Kelley - (Apple), Rollin Yu - (TrustAsia Technologies,
Inc.), Ryan Dickson - (Google), Tobias Josefowitz - (Opera
Software AS), Wayne Thayer - (Fastly), Wendy Brown - (US Federal
PKI Management Authority).</p>
<h2 id="approval-of-minutes" style="page-break-inside: avoid;">Approval
of minutes</h2>
<p style="page-break-inside: avoid;">No minutes to approve from
previous Teleconference</p>
<h2 id="review-of-agenda" style="page-break-inside: avoid;">Review
of Agenda</h2>
<p style="page-break-inside: avoid;">Approved</p>
<ul style="page-break-inside: avoid;">
<li style="page-break-inside: avoid;">Multi-perspective Domain
Validation</li>
<li style="page-break-inside: avoid;">Resuming the discussion
about Applicant, Applicant Representative</li>
<li style="page-break-inside: avoid;">Certificate issuance flows
<ul style="page-break-inside: avoid;">
<li style="page-break-inside: avoid;">Traditional hosting
providers</li>
<li style="page-break-inside: avoid;">CDN</li>
</ul>
</li>
</ul>
<h2
id="update-from-ryan-on-multi-perspective-domain-validation-if-needed"
style="page-break-inside: avoid;">Update from Ryan on
multi-perspective domain validation</h2>
<p style="page-break-inside: avoid;">Ryan gave a quick summary.</p>
<p style="page-break-inside: avoid;">At the last F2F, a guest
speaker from Princeton University investigating vulnerabilities
with DNS and Internet routing, gave a nice presentation and a live
demo via an ethical BGP hijack and forced mis-issuance of a
Certificate. The researcher explained some possible mitigations we
can do collectively to prevent this issue.</p>
<p style="page-break-inside: avoid;">Multi-perspective domain
validation is one such mitigation. Chrome team is leading this
effort and gathered a team of members from Princeton and other
interested parties to work on some draft requirements that we
might be able to add to the baseline requirements. The goal is not
to sunset or deprecate the existing validation methods that cannot
take advantage of the multi-perspective DV. Email and other Domain
Validation methods will continue to work. The focus is on
strengthening the methods that can benefit from the MPDV approach.</p>
<p style="page-break-inside: avoid;">Corey asked if we could have an
outstanding agenda item for a progress report on this topic and
Ryan agreed.</p>
<p style="page-break-inside: avoid;">Dimitris asked if this is a
closed group or something that we could potentially bring into the
Forum, like inviting Princeton researchers and other folks to
participate as Interested Parties. We would be able to publish
minutes and all the good provisions we already have in the CA/B
Forum.</p>
<p style="page-break-inside: avoid;">Ryan replied that the current
approach is that this is just a group of individual organizations
that are interested in a common initiative. They are keeping
everything open so there is a call for interested parties to
volunteer for the work team. An email group will be created and a
draft project plan and a kick-off sometime next week.</p>
<p style="page-break-inside: avoid;">Detailed minutes will be taken
so there is a clear history because it is important to be
transparent. It's also important to capture history as to why did
the group come to these conclusions. Ryan wants to make sure the
experts are capable of participating and that was his only
concern. He's fine either way as long as the Princeton team is
able to participate.</p>
<p style="page-break-inside: avoid;">There was some discussion about
possible IP concerns and how an external group developing
requirements would introduce those to a Forum WG. Ryan said this
will be discussed at the 1st kick off meeting, he hadn't
considered IP at this point. It needs to be solved one way or
another.</p>
<p style="page-break-inside: avoid;">Tobi said that perhaps since
this will be introduced to the Forum, it's not much of an issue
from an IP perspective but we need to explore some more. The
primary researchers would need to sign the IPR, we'll ask them and
report at next meeting.</p>
<h2 id="discussion-on-certificate-issuance-flows"
style="page-break-inside: avoid;">Discussion on certificate
issuance flows</h2>
<p style="page-break-inside: avoid;">The following flows have been
drafted:</p>
<ol style="page-break-inside: avoid;">
<li style="page-break-inside: avoid;">Traditional Hosting
Provider, written by Corey</li>
<li style="page-break-inside: avoid;">CDN, written by Wayne</li>
<li style="page-break-inside: avoid;">ACME flow, written by Corey</li>
</ol>
<p style="page-break-inside: avoid;">Doug offered to write up at
least one other flow in the next couple of weeks.</p>
<p style="page-break-inside: avoid;">We will spend the rest of this
meeting on the first one.</p>
<h3 id="traditional-hosting-provider-flow" style="page-break-inside:
avoid;">Traditional Hosting Provider flow</h3>
<p style="page-break-inside: avoid;">This model describes how the
"generally house certificates" were issued at the time the 1st BRs
were written, 10+ years ago. The model is using a "shared hosting
provider".</p>
<ul style="page-break-inside: avoid;">
<li style="page-break-inside: avoid;"><a
href="https://docs.google.com/document/d/1uX8jJ0u9p8mNjUeLl31N8YbmhIuuC2jfs2mZW6Bj-Hk/edit#"
class="moz-txt-link-freetext" moz-do-not-send="true">https://docs.google.com/document/d/1uX8jJ0u9p8mNjUeLl31N8YbmhIuuC2jfs2mZW6Bj-Hk/edit#</a></li>
<li style="page-break-inside: avoid;">16 descrete steps</li>
</ul>
<p style="page-break-inside: avoid;">Corey went through the steps
and explained actions on each step.</p>
<p style="page-break-inside: avoid;">Ben said that the reason we
wanted to explore this flow is because we felt that the BRs do not
describe modern/current models. Exploring this path would show us
how to change the BRs to accommodate these models or make them
more clear, especially when it comes to the certificate
application, Applicant/Applicant Representative issues and where
the Subscriber Agreement kicks in.</p>
<p style="page-break-inside: avoid;">Corey agreed that that is one
aspect of the effort. Another one is about the validation parts,
whether or not the Applicant has to manually place the token at a
given location, or that location could be delegated to another
party, the subscriber key generation, etc. It's kind of a holistic
reexamination of the processes to see how they map to current
practices.</p>
<p style="page-break-inside: avoid;">Ben disagreed with the idea of
having a the holistic approach because we might get stuck.</p>
<p style="page-break-inside: avoid;">Corey: take a step back and see
what exactly we are looking for</p>
<p style="page-break-inside: avoid;">Corey did a high level
description of the steps to get a certificate that we need to
address:</p>
<ol style="page-break-inside: avoid;">
<li style="page-break-inside: avoid;">Signing of the Subscriber
Agreement</li>
<li style="page-break-inside: avoid;">Generation of the private
key</li>
<li style="page-break-inside: avoid;">What elements are required
for a certificate request?</li>
<li style="page-break-inside: avoid;">Domain Validation (does the
Applicant need to manually place the Random Value?)</li>
</ol>
<p style="page-break-inside: avoid;">Wayne mentioned that we might
need to add a definition of roles as a 5th element.</p>
<ol style="page-break-inside: avoid;" type="a">
<li style="page-break-inside: avoid;">Who is the Applicant?</li>
<li style="page-break-inside: avoid;">In the case of third
parties, how do they map to the BR definitions (if at all)?</li>
</ol>
<p style="page-break-inside: avoid;">Text added to the main
description of the Traditional Hosting Provider flow.</p>
<p style="page-break-inside: avoid;">Private Key can be generated by
the hosting provider on behalf of the Applicant. This seems to be
allowed per section 6.1.2 but some Members thought it might be a
good idea for this part to be clarified. No disagreements with
that plan.</p>
<p style="page-break-inside: avoid;">Dimitris mentioned that there
might be a need for some kind of explicit Certificate acceptance
action per BRs 9.6.3 "Acceptance of Certificate".</p>
<p style="page-break-inside: avoid;">Ben said that in some cases
when you send something out, without expecting an acknowledgment
may be considered acceptance.</p>
<p style="page-break-inside: avoid;">Corey brought up section 6.9.3
sub-item 3 of the BRs and understood the issue. Agreed to take a
note in the minutes to revisit and clarify this part of the
process.</p>
<p style="page-break-inside: avoid;">Michael Slaughter. There is an
implicit nature of acceptance. You implicitly authorize a hosting
provider to generate keys on behalf of. Similarly, acceptance of
the certificate is implicit by the Subscriber using the
certificate. How much do we want to go into switching from
implicit approvals to explicit? Or, explicitly calling out that
these are implicit approvals/acceptances?</p>
<p style="page-break-inside: avoid;">Wayne. An interesting area is
when a Subscriber Agreement is accepted via an API call, like, set
a flag in the API and that means you have accepted the agreement.
Seems like a common practice. We should argue that this is
acceptable, or if we do not consider this acceptable, it would
mean a lot of changes.</p>
<p style="page-break-inside: avoid;">Corey clarified that in the
beginning of section 9.6.3, there is clear language that allows
"click-through" agreements to be implemented, and such agreements
are legally enforceable.</p>
<p style="page-break-inside: avoid;">Wayne would still like this
part to be a bit more explicit, although he agrees that this
language probably allows this practice. Wayne argued that if we
hard code acceptance of agreement to "true", and noting that "He
Is Not A Lawyer", it doesn't seem viable. He believes that if
that's the case, we should remove the requirement for the
automated acceptance of the Subscriber Agreement in a way that you
have to do something to demonstrate acceptance.</p>
<p style="page-break-inside: avoid;">Doug noted that this is how
ACME clients work today, where the user configures the client to
accept the subscriber agreement.</p>
<p style="page-break-inside: avoid;">Ryan: With ACME, when you
register the account, you either needs to send the command that
you accept the Subscriber Agreement or interactively accept it,
one time. However, there are some cases where the user
automatically accepts those agreements when, for example, they
download some software that contains the ACME client tools. It's
not always transparent to the user.</p>
<p style="page-break-inside: avoid;">He then questioned, are they
used? Are they legally binding and enforceable? Perhaps we should
not require them as Wayne mentioned. He was not a great fan of
Subscriber Agreements. That is more of a personal opinion, not the
opinion of the Chrome Root Program. He believes there is something
worth pursuing.</p>
<p style="page-break-inside: avoid;">Wayne continued on this topic
asking about the case where a web server is configured to
automatically request a certificate. Who is the Subscriber in that
case?</p>
<p style="page-break-inside: avoid;">Ben mentioned some opinion
about the "Digital Signature Guidelines" from the American Bar
Association regarding the acceptance, and in particular the
implied acceptance.</p>
<ul style="page-break-inside: avoid;">
<li style="page-break-inside: avoid;">Implied acceptance can be
done in the absence of express manifestation of approval by the
Subscriber.</li>
</ul>
<p style="page-break-inside: avoid;">Corey asked if that
interpretation could be applied for both the Certificate
Acceptance and the acceptance of the Subscriber Agreement. Ben
replied that it would not apply to the acceptance of the
Subscriber Agreement.</p>
<p style="page-break-inside: avoid;">Dimitris mentioned that
subscriber agreements must be affirmatively accepted and legally
enforceable. It is key on enforcing policies described in the BRs
like revocation requirements, all the warranties and
representations, to Certificate Subscribers. With that in mind, he
believes we should clarify but not make the requirements weaker so
he would not support removing the need for an Applicant to accept
the Subscriber Agreement.</p>
<p style="page-break-inside: avoid;">Corey restated that the
applicant's acceptance of the Subscriber Agreement means that they
are going to fulfill all these obligations.</p>
<p style="page-break-inside: avoid;">Dimitris relied to Wayne's
previous point about who is the Subscriber when a Web Server
requests a certificate, and the answer is that there is always
some human configuring these things, at least in 2023.</p>
<p style="page-break-inside: avoid;">Wayne still questions whether
that's legally enforceable. If the person configured something and
then that caused some other action to later accept this legal
agreement, it doesn't seem to be very strongly enforceable. He is
not against a mechanisms where a subscriber can affirmatively
accept it but he is against this "subscriber agreement theater"
for which people have found ways to make so automatic that it
doesn't add any value.</p>
<p style="page-break-inside: avoid;">Dustin asked Wayne if he is
only referring to the initial onboarding, like having a new
customer, as with ACME's example that Ryan mentioned earlier, that
you accept the agreement once and you don't have to accept any
more. Wayne replied that he was referring to both.</p>
<p style="page-break-inside: avoid;">Dimitris asked what happens
when the Subscriber Agreement changes? The Applicant/Subscriber
would need to be alerted about that. He thinks that ACME support
it.</p>
<p style="page-break-inside: avoid;">Ryan was thinking of all these
cases and believes that if we put our minds together and find a a
better way of getting the acknowledgment from the subscriber, and
accept that over time, it would promote more agility in the
ecosystem. People familiar with ACME and ARI (ACME Renewal
Information) which can "signal some messages" from the CA to the
Subscriber. That would give them the way to switch to another
provider in an automated way. That would be very useful for
mis-issuances (e.g. 63 bits of entropy in the serial number) or
some other "doomsday" scenario.</p>
<p style="page-break-inside: avoid;">We could consider a concept of
pre-accepting agreements without getting certificates yet,
something of that sort.</p>
<p style="page-break-inside: avoid;">Perhaps refining this language
for more automation, pre-agreements .</p>
<p style="page-break-inside: avoid;">Dimitris highlighted that
"pre-agreements" or things of that sort will be very challenging
because of the different jurisdictions. That's why the language in
section 9.6.3 contains the statement "provided that the CA has
determined that such agreements are legally enforceable".</p>
<p style="page-break-inside: avoid;">Ryan wondered if there is a
world where the subscriber agreement becomes optional, and the CA
determines that this is a risk they are willing to accept.</p>
<p style="page-break-inside: avoid;">Ben replied that he didn't
think we should go down that path.</p>
<p style="page-break-inside: avoid;">Dimitris mentioned that a CA
can find different ways to obligate an applicant to follow some
rules but historically we wanted all Applicants, all Subscribers
to have a minimum set of responsibilities, warranties and
obligations especially towards revocation of certificates. Also,
for the need to contact the CA when the domain name changes, or
the key is compromised. Without an agreement, this minimum set of
expectations goes away for the ecosystem not for the CA.</p>
<p style="page-break-inside: avoid;">Ben mentioned that from a legal
perspective, there needs to be some kind of affirmative act at
some point. There are situations where computers can enter into
legal agreements if they have been empowered by their creators
(developers, system administrators, etc) or the companies that
have set it up. There are cases where computers have been allowed
to take over the contracting process. Perhaps we're not talking
about that same thing here.</p>
<p style="page-break-inside: avoid;">Ben continued explaining that
there is a concept of Affirmative act. The acceptance of the
agreement doesn't need to be actually a click, we need to consider
what that would look like "Accepting an agreement" without
clicking something. He gave an example of a "shrinkwrap license" (<a
href="https://en.wikipedia.org/wiki/Shrinkwrap_(contract_law)"
class="moz-txt-link-freetext" moz-do-not-send="true">https://en.wikipedia.org/wiki/Shrinkwrap_(contract_law)</a>).
These software licenses didn't really want users to accept
anything but it said that by using or keeping something open, they
agreed to it. The acceptance of the agreement doesn't have to be
so specific as clicking on something, it can be something else. We
should think broadly in terms of what would the affirmative act
be, that somebody does at some point to put in motion this idea of
accepting this subscriber agreement.</p>
<p style="page-break-inside: avoid;">Michael doesn't fundamentally
have a problem with a subscriber agreement being actively accepted
but he raised a concern that we should not add any additional
friction or require manual action in order to give that
affirmative response.</p>
<p style="page-break-inside: avoid;">Ryan: An act like "requesting a
certificate", would that constitute acceptance of the agreement?</p>
<p style="page-break-inside: avoid;">Martijn: completing the domain
validation could potentially be considered a possible acceptance
of the SA?</p>
<p style="page-break-inside: avoid;">Corey summarized that we should
modify this language about the electronically click-through
agreement and expand upon that point. No objections were raised.
He asked for volunteers to draft some concrete language and Ben
volunteered to take that on.</p>
<p style="page-break-inside: avoid;">Dustin will also contact Ben
offline to assist. He mentioned that we should not limit this only
to specific options but use them as examples. It can be something
generic like "some affirmative act by the subscriber provided that
the CA has determined that such process creates a legally
enforceable subscriber agreement".</p>
<p style="page-break-inside: avoid;">Wendy: An act like installing
& using the cert could also be used.</p>
<p style="page-break-inside: avoid;">Ben will work on some language
proposals.</p>
<p style="page-break-inside: avoid;">Step 9, registered their
domain, they have an A record pointing to the hosting machine. Not
delegating to the hosting provider, no CNAME</p>
<p style="page-break-inside: avoid;">Wayne mentioned that he covered
the CNAME delegation in the CDN model so it might be a good place
to talk about it.</p>
<p style="page-break-inside: avoid;">Dimitris noticed that the model
uses the DNS challenge and not the agreed-upon change to website
and was wondering if this was a deliberate choice considering that
a hosting provider would have access to the server to place a
random value in a file and complete the transaction. Corey thinks
both DNS and agreed-upon change to website would be similar in
this model because there is no integration between a CA and a
hosting provider. This is another assumption that should be
stated. These are mostly manual steps.</p>
<p style="page-break-inside: avoid;">Wayne highlighted that this is
a model before CAs started integrating with hosting providers and
automating some of these model. He has considered these
integrations that Dimitris was talking about in the CDN model.</p>
<p style="page-break-inside: avoid;">Martijn mentioned that we
should at some point consider the reseller model too. It seems
like a hybrid of the hosting provider being the reseller in which
case they would probably perform that.</p>
<p style="page-break-inside: avoid;">Assumption that the Applicant
and the hosting provider are different entities and there is no
integration between hosting provider and CA. This is the "2010"
model where the "webmaster" is doing most of the steps.</p>
<p style="page-break-inside: avoid;">Dimitris asked Corey if it
would be useful to document those assumptions (that there is no
DNS delegation, or CNAME, or...) to the beginning of the workflow
which will make the steps make more sense. Corey agreed to add
those assumptions.</p>
<p style="page-break-inside: avoid;">The group agreed to pick up
where we left off at step 12.</p>
<p style="page-break-inside: avoid;">Clint asked to time-box the
discussion so we have time for at least another model.</p>
<p style="page-break-inside: avoid;"><br>
</p>
<p style="page-break-inside: avoid;">Adj<br>
</p>
<style type="text/css">td, h1, h2, h3, h4, h5, p, ul, ol, li { page-break-inside: avoid; }</style>
</body>
</html>