[cabfpub] Voting begins: Ballot 218 version 2

Mon Feb 5 16:13:40 UTC 2018

Chunghwa Telecom Co., Ltd. Votes “No”  on Ballot 218. 

       Li-Chun Chen

From: Public[mailto:public-bounces at cabforum.org] On Behalf Of Mads Egil Henriksveenvia Public
Sent: Friday, February 02, 2018 8:52 PM
To: Tim Hollebeek; CA/Browser Forum Public Discussion List
Subject: [外部郵件]Re: [cabfpub] Voting begins: Ballot 218 version 2

Buypass votes NO.

There are use cases and scenarios where animproved version of method #1 for proving ownership of a domain would beappropriate. Method #1 is only to be used for OV/EV and as such theauthorization to issue the certificate must be given by an authoritativerepresentative of the applicant. If we can prove that the applicant is equal tothe domain owner in a proper way, we consider this to be sufficient to issuethe certificate. The validation and issuance of OV/EV must be based on bothverifying the Applicant’s identity and domain ownership (with or without thetechnical demonstration of domain control). 

BR 3.2.2.4 says ‘defines the permittedprocesses and procedures for validating the Applicant’s ownership or control ofthe domain’. The concept of validating an Applicant’s ownership is mostimportant for OV/EV as this is a scenario where the Applicant always must beverified. Then it is possible to verify domain ownership based on a properlyverified identity and address of the Applicant. All other methods focus ondomain control and we can’t see that the concept of domain ownership is wellcovered by any of these methods. 

We understand that domain control isconsidered to be very important, but we would like to emphasize that weconsider the concept of ‘domain control’ and ‘domainownership’ to be two different concepts - atleast seen in relation to the issuance of OV/EV. If we really mean to includeboth concepts in the domain validation methods, this should be made moreexplicit. 

We are concerned that a switch of focustowards domain control also for OV/EV might result in less focus on domainownership and thus giving any actor who controls the domain a possibility toget an OV/EV for that domain. I would hate to see e.g. the DNS provider ofBuypass AS being able to get an EV certificate with the identity of the DNSprovider and the domain buypass.no based on domain control only. 

It is difficult to evaluate the quality ofmethod #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 inEVG for EV.

We are not convinced that all the othermethods based on domain control in all cases necessarily provides a higherlevel of assurance than an improved method #1 for OV/EV certificates. We agreewith Dimitris that it is important to get a better understanding of thevulnerabilities and threats for each of the domain validation methods and thisshould be analyzed independently for DV and OV/EV.

Regards
Mads

From: Public <public-bounces at cabforum.org> on behalf of Tim Hollebeek via Public <public at cabforum.org>
Reply-To: Tim Hollebeek <tim.hollebeek at digicert.com>, CA/Browser Forum Public Discussion List <public at cabforum.org>
Date: Monday, 29 January, 2018 at 17:07 
To: CA/Browser Forum Public Discussion List <public at 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 at cabforum.org
https://cabforum.org/mailman/listinfo/public

_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public

本信件可能包含中華電信股份有限公司機密資訊,非指定之收件者,請勿蒐集、處理或利用本信件內容,並請銷毀此信件. 如為指定收件者,應確實保護郵件中本公司之營業機密及個人資料,不得任意傳佈或揭露,並應自行確認本郵件之附檔與超連結之安全性,以共同善盡資訊安全與個資保護責任. 
Please be advised that this email message (including any attachments) contains confidential information and may be legally privileged. If you are not the intended recipient, please destroy this message and all attachments from your system and do not further collect, process, or use them. Chunghwa Telecom and all its subsidiaries and associated companies shall not be liable for the improper or incomplete transmission of the information contained in this email nor for any delay in its receipt or damage to your system. If you are the intended recipient, please protect the confidential and/or personal information contained in this email with due care. Any unauthorized use, disclosure or distribution of this message in whole or in part is strictly prohibited. Also, please self-inspect attachments and hyperlinks contained in this email to ensure the information security and to protect personal information.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20180206/5ebeaecf/attachment-0003.html>