Buypass votes NO. There are use cases and scenarios where an improved version of method #1 for proving ownership of a domain would be appropriate. Method #1 is only to be used for OV/EV and as such the authorization to issue the certificate must be given by an authoritative representative of the applicant. If we can prove that the applicant is equal to the domain owner in a proper way, we consider this to be sufficient to issue the certificate. The validation and issuance of OV/EV must be based on both verifying the Applicant's identity and domain ownership (with or without the technical demonstration of domain control).
BR 3.2.2.4 says 'defines the permitted processes and procedures for validating the Applicant's ownership or control of the domain'. The concept of validating an Applicant's ownership is most important for OV/EV as this is a scenario where the Applicant always must be verified. Then it is possible to verify domain ownership based on a properly verified identity and address of the Applicant. All other methods focus on domain control and we can't see that the concept of domain ownership is well covered by any of these methods. We understand that domain control is considered to be very important, but we would like to emphasize that we consider the concept of 'domain control' and 'domain ownership' to be two different concepts - at least seen in relation to the issuance of OV/EV. If we really mean to include both concepts in the domain validation methods, this should be made more explicit. We are concerned that a switch of focus towards domain control also for OV/EV might result in less focus on domain ownership and thus giving any actor who controls the domain a possibility to get an OV/EV for that domain. I would hate to see e.g. the DNS provider of Buypass AS being able to get an EV certificate with the identity of the DNS provider and the domain buypass.no based on domain control only. It is difficult to evaluate the quality of method #1 on itself without at the same time evaluate the parts of BR (and EVG) relevant for using the method - for OV (BR 3.2.2.1 and 3.2.5) and similar in EVG for EV. We are not convinced that all the other methods based on domain control in all cases necessarily provides a higher level of assurance than an improved method #1 for OV/EV certificates. We agree with Dimitris that it is important to get a better understanding of the vulnerabilities and threats for each of the domain validation methods and this should be analyzed independently for DV and OV/EV. Regards Mads From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Tim Hollebeek via Public Sent: mandag 29. januar 2018 22:52 To: CA/Browser Forum Public Discussion List <public@cabforum.org> Subject: [cabfpub] Voting begins: Ballot 218 version 2 I'm highly skeptical that discussing this for another month will change anybody's minds. It has already been discussed for over a month, including at three validation working group meetings and once on the management call, with extensive discussion on this list as well. There have been a number of clever attempts to distract from the matter at hand. Everybody seems to agree that methods #1 and #5 as currently written are insufficient to validate certificates, and efforts to improve method #1 have all either been shown to be similarly weak, or have turned the validation method into one of the other existing validation methods. In fact, this demonstrates an obvious transition path for CAs currently using method #1: use method #2 or method #3. Since methods #1 and #5 do not sufficiently validate certificates, they should not be used, and six months should be more than enough time to cease using them. Here is the final version of the ballot, with voting times. A redlined document is attached (I encourage other proposers to post ballot redlines, even if it isn't required). -Tim ----- Ballot 218 version 2: Remove validation methods #1 and #5 ----- Purpose of Ballot: Section 3.2.2.4 says that it "defines the permitted processes and procedures for validating the Applicant's ownership or control of the domain." Most of the validation methods actually do validate ownership and control, but two do not, and can be completed solely based on an applicant's own assertions. Since these two validation methods do not meet the objectives of section 3.2.2.4, and are actively being used to avoid validating domain control or ownership, they should be removed, and the other methods that do validate domain control or ownership should be used. The following motion has been proposed by Tim Hollebeek of DigiCert and endorsed by Ryan Sleevi of Google and Rich Smith of Comodo. -- MOTION BEGINS - This ballot modifies the "Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates" as follows, based upon Version 1.5.4: In Section 1.6.1, in the definition of "Domain Contact", after "in a DNS SOA record", add ", or as obtained through direct contact with the Domain Name Registrar" In Section 3.2.2.4.1, add text at the end: "For certificates issued on or after August 1, 2018, this method SHALL NOT be used for validation, and completed validations using this method SHALL NOT be used for the issuance of certificates." In Section 3.2.2.4.5, add text at the end: "For certificates issued on or after August 1, 2018, this method SHALL NOT be used for validation, and completed validations using this method SHALL NOT be used for the issuance of certificates." After Section 3.2.2.4.10, add following two new subsections: "3.2.2.4.11 Any Other Method This method has been retired and MUST NOT be used. 3.2.2.4.12 Validating Applicant as a Domain Contact Confirming the Applicant's control over the FQDN by validating the Applicant is the Domain Contact. This method may only be used if the CA is also the Domain Name Registrar, or an Affiliate of the Registrar, of the Base Domain Name. Note: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names." In Section 4.2.1, after the paragraph that begins "After the change to any validation method", add the following paragraph: "Validations completed using methods specified in Section 3.2.2.4.1 or Section 3.2.2.4.5 SHALL NOT be re-used on or after August 1, 2018." -- MOTION ENDS - For the purposes of section 4.2.1, the new text added to 4.2.1 from this ballot is "specifically provided in a [this] ballot." The procedure for approval of this ballot is as follows: Discussion (7+ days) Start Time: 2017-01-22 21:30:00 UTC End Time: 2017-01-29 21:50:00 UTC Vote for approval (7 days) Start Time: 2017-01-29 21:50:00 UTC End Time: 2017-02-05 21:50 UTC
_______________________________________________ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
