[cabf_validation] Final Minutes for the SCWG Validation Subcommittee Teleconference - March 9, 2023
Dimitris Zacharopoulos (HARICA)
dzacharo at harica.gr
Thu Mar 23 15:09:07 UTC 2023
These are the Final Minutes of the Teleconference described in the
subject of this message, prepared by Dimitris Zacharopoulos (HARICA).
Minutes validation subcommittee 2023-03-09
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).
Approval of minutes
No minutes to approve from previous Teleconference
Review of Agenda
* Multi-perspective Domain Validation
* Resuming the discussion about Applicant, Applicant Representative
* Certificate issuance flows
o Traditional hosting providers
Update from Ryan on multi-perspective domain validation
Ryan gave a quick summary.
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.
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.
Corey asked if we could have an outstanding agenda item for a progress
report on this topic and Ryan agreed.
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
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.
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.
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.
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.
Discussion on certificate issuance flows
The following flows have been drafted:
1. Traditional Hosting Provider, written by Corey
2. CDN, written by Wayne
3. ACME flow, written by Corey
Doug offered to write up at least one other flow in the next couple of
We will spend the rest of this meeting on the first one.
Traditional Hosting Provider flow
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".
* 16 descrete steps
Corey went through the steps and explained actions on each step.
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.
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
Ben disagreed with the idea of having a the holistic approach because we
might get stuck.
Corey: take a step back and see what exactly we are looking for
Corey did a high level description of the steps to get a certificate
that we need to address:
1. Signing of the Subscriber Agreement
2. Generation of the private key
3. What elements are required for a certificate request?
4. Domain Validation (does the Applicant need to manually place the
Wayne mentioned that we might need to add a definition of roles as a 5th
1. Who is the Applicant?
2. In the case of third parties, how do they map to the BR definitions
(if at all)?
Text added to the main description of the Traditional Hosting Provider flow.
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.
Dimitris mentioned that there might be a need for some kind of explicit
Certificate acceptance action per BRs 9.6.3 "Acceptance of Certificate".
Ben said that in some cases when you send something out, without
expecting an acknowledgment may be considered acceptance.
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.
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?
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.
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.
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
Doug noted that this is how ACME clients work today, where the user
configures the client to accept the subscriber agreement.
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.
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.
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?
Ben mentioned some opinion about the "Digital Signature Guidelines" from
the American Bar Association regarding the acceptance, and in particular
the implied acceptance.
* Implied acceptance can be done in the absence of express
manifestation of approval by the Subscriber.
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
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
Corey restated that the applicant's acceptance of the Subscriber
Agreement means that they are going to fulfill all these obligations.
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.
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.
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.
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.
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.
We could consider a concept of pre-accepting agreements without getting
certificates yet, something of that sort.
Perhaps refining this language for more automation, pre-agreements .
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".
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
Ben replied that he didn't think we should go down that path.
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.
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.
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"
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.
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
Ryan: An act like "requesting a certificate", would that constitute
acceptance of the agreement?
Martijn: completing the domain validation could potentially be
considered a possible acceptance of the SA?
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.
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".
Wendy: An act like installing & using the cert could also be used.
Ben will work on some language proposals.
Step 9, registered their domain, they have an A record pointing to the
hosting machine. Not delegating to the hosting provider, no CNAME
Wayne mentioned that he covered the CNAME delegation in the CDN model so
it might be a good place to talk about it.
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.
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
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.
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.
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.
The group agreed to pick up where we left off at step 12.
Clint asked to time-box the discussion so we have time for at least
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Validation