From Corey.Bonnell at digicert.com Tue Mar 7 16:56:06 2023 From: Corey.Bonnell at digicert.com (Corey Bonnell) Date: Tue, 7 Mar 2023 16:56:06 +0000 Subject: [cabf_validation] 2023-03-09 Agenda Message-ID: Hello, Hope everyone who attended the F2F in person last week had a safe and uneventful trip home. Agenda for this Thursday's meeting: 1. Update from Ryan on multi-perspective domain validation (if needed) 2. Discussion on certificate issuance flows a. Traditional Hosting Provider flow b. CDN flow c. ACME flow d. Others Scheduled minute-taker: Dimitris If you have any items to add, please reply to this email. Thanks, Corey -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4990 bytes Desc: not available URL: From Corey.Bonnell at digicert.com Mon Mar 20 17:29:14 2023 From: Corey.Bonnell at digicert.com (Corey Bonnell) Date: Mon, 20 Mar 2023 17:29:14 +0000 Subject: [cabf_validation] 2023-03-23 Agenda Message-ID: Hello, I won't be on the call Thursday, so Wayne will lead the discussion. Agenda for this Thursday's meeting: 1. Progress report from Ryan on Multi-perspective domain validation. 2. Analysis and discussion of Wayne's write-up for the CDN certificate issuance flow (link available on the Validation Sub-committee page on the Wiki). We didn't quite finish discussing the "Traditional Hosting Provider" flow on the last call, so we'll resume discussion in a subsequent meeting when I can attend. Scheduled minute-taker: Doug As always, if you have any topics that you'd like to discuss, please reply to this email. Thanks, Corey -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4990 bytes Desc: not available URL: From dzacharo at harica.gr Thu Mar 23 15:09:07 2023 From: dzacharo at harica.gr (Dimitris Zacharopoulos (HARICA)) Date: Thu, 23 Mar 2023 17:09:07 +0200 Subject: [cabf_validation] Final Minutes for the SCWG Validation Subcommittee Teleconference - March 9, 2023 Message-ID: <96213c21-fc97-e8eb-0e84-346e19f0525f@harica.gr> 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: