[cabfpub] Ballot 218 version 2: Remove validation methods #1 and #5
Ryan Sleevi
sleevi at google.com
Mon Jan 29 15:20:39 UTC 2018
Bruce,
To date, Entrust has not provided any of the requested details about its
use of 3.2.2.4.1, the prevalence, and the potential impact. Given the lack
of responsiveness to the issues, which were raised over a month ago, and
have made no substantial progress to addressing or understanding the
security considerations, it does not seem like another two months of
discussion will be productive, particularly given the user-security risk.
Given the lack of information and responsiveness to the issues, it is
difficult to believe this is a good faith request, and not simply yet
another attempt to stall conversation in the Forum. We are certainly
sensitive to the potential impact, based on available data - but CAs, such
as Entrust's, unwillingness to contribute effectively to that conversation,
or ability to demonstrate an awareness of and sensitivity to the security
risks presented to the ecosystem by the current practices, leads to the
unavoidable conclusion that there is not much productive progress.
We value the Forum for its excellent opportunities to discuss proposals,
share information, and assess the impact to the security of users about
various proposals - including the potential challenges faced by site
operators. Yet that does not preclude taking necessary steps to protect the
safety and security of users, to accurately report to users the level of
assurance provided by a given certificate, and to take steps to reduce the
risk from CAs whose validation practices are insufficient for the needs of
the Web PKI.
Thus, we do not believe further delays, given the direct lack of
responsiveness to the matters, is either warranted or wise.
On Mon, Jan 29, 2018 at 10:01 AM, Bruce Morton via Public <
public at cabforum.org> wrote:
> On the CA/Browser Teleconference last Thursday, the members discussed
> pending Ballot 218, which would eliminate domain validation method 1 (WhoIs
> lookup, BR 3.2.2.4.1) as of August, 2018. Google indicated it was not
> satisfied with an August 2018 implementation date, and might impose a March
> 2018 date on its own (through the Google root program) ending the ability
> to use Method 1 for domain validation as of that date.
>
>
>
> We would like to ask Forum members, including Google, for a little more
> time to discuss this issue, including possible amendments to Ballot 218
> that might satisfy everyone’s concerns. Some possible ideas for amending
> Method 1 (which we can develop further in our next meeting) could include
> the following:
>
>
>
> - Strengthen Method 1 by adding more details match the Applicant and
> the domain Registrant using name and a unique identifier.
> - Require the CA also to send a notice of domain validation to the
> Registrant, allowing the Registrant to have the certificate revoked if the
> validation is not authorized.
> - Eliminating Method 1 for DV and OV domain validation, but allowing
> Method 1 to be used for EV validation. The EV validation process already
> includes two steps to confirm the authority of the Applicant Representative
> to order the certificate – including a call to a second person at the
> organization to confirm that the Applicant Representative has authority to
> request the certificate. (EVGL 11.8)
> - Ballot 218 will require revalidation of 100% of domains previously
> validated using Method 1 for issuance starting 1 August 2018 (if Google
> acts unilaterally to prohibit use of Method 1 by March, this revalidation
> deadline could be March 2018). We suggest Ballot 218 should allow reuse of
> domain validation data for the normal period allowed by BR 4.2.1, as is the
> Forum’s standard practice. This will allow CAs to change processes,
> implement/extend automation and train customers on alternative validation
> methods.
> - Finally, the elimination of Method 1 will have a significant impact
> not only on CAs (some of whom are Forum members, but many of whom are not
> and are unaware of this discussion), but more importantly on major
> certificate users including enterprises and governments who often prefer
> Method 1 for validation of their domains. Therefore, we ask for more time
> for both discussion and implementation so both CAs and website owners can
> have a more graceful transition to whatever new rules we ultimately adopt.
>
>
>
> The Forum will be meeting in approximately 5 weeks at our Face to Face
> meeting in Herndon – this is a complex topic which would benefit from a
> thorough discussion at that meeting to try to reach a sensible solution.
> We should continue discussion on this list, but let’s wait until the F2F
> meeting occurs to reach a final conclusion that can be implemented without
> unnecessary disruption to the security ecosystem.
>
>
>
> Thanks,
>
>
>
> Bruce.
>
>
>
> *From:* Public [mailto:public-bounces at cabforum.org] * On Behalf Of *Tim
> Hollebeek via Public
> *Sent:* January 22, 2018 4:31 PM
> *To:* CA/Browser Forum Public Discussion List <public at cabforum.org>
> *Subject:* [EXTERNAL][cabfpub] Ballot 218 version 2: Remove validation
> methods #1 and #5
>
>
>
>
>
> 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: Not Before 2017-01-29 21:30:00 UTC
>
>
>
> Vote for approval (7 days)
>
> Start Time: TBD
>
> End Time: TBD
>
>
>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20180129/d5aeec15/attachment-0003.html>
More information about the Public
mailing list