[cabf_validation] Final Minutes for the SCWG Validation Subcommittee Teleconference - March 9, 2023

[Dimitris Zacharopoulos (HARICA)]

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


    Roll call

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

Approved

  * Multi-perspective Domain Validation
  * Resuming the discussion about Applicant, Applicant Representative
  * Certificate issuance flows
      o Traditional hosting providers
      o CDN


    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 
CA/B Forum.

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 
weeks.

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".

  * https://docs.google.com/document/d/1uX8jJ0u9p8mNjUeLl31N8YbmhIuuC2jfs2mZW6Bj-Hk/edit#
  * 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 
practices.

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
    Random Value?)

Wayne mentioned that we might need to add a definition of roles as a 5th 
element.

 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 
demonstrate acceptance.

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 
Agreement.

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.

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 
accept.

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" 
(https://en.wikipedia.org/wiki/Shrinkwrap_(contract_law)). 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.

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.

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 
model.

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 
another model.


Adj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20230323/b5459446/attachment-0001.html>