Chunghwa Telecom Co., Ltd. Votes “No” on Ballot 218.
Li-Chun Chen
From: Public[mailto:[email protected]] 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 <[email protected]> on behalf of Tim Hollebeek via
Public <[email protected]>
Reply-To: Tim Hollebeek <[email protected]>, CA/Browser Forum Public
Discussion List <[email protected]>
Date: Monday, 29 January, 2018 at 17:07
To: CA/Browser Forum Public Discussion List <[email protected]>
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
[email protected]
https://cabforum.org/mailman/listinfo/public
_______________________________________________
Public mailing list
[email protected]
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.
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
