[cabfpub] Voting begins: Ballot 218 version 2

Dimitris Zacharopoulos jimmy at it.auth.gr
Thu Feb 1 14:34:39 UTC 2018


All currently approved Domain Validation methods provide some level of
assurance which is not easily quantifiable without calculating the risks
(vulnerabilities, threats) of each method. If we had a methodology to
quantify the assurance level of each method, we would be able to compare
them.

The discussion around methods 3.2.2.4.1 (1 and 2)  and 3.2.2.4.5
demonstrated that these methods have lower assurance levels than the
other methods, without providing conclusive evidence to support ultimate
failure of #1 and #5. If we had that, probably all validations performed
with methods #1 and #5 would have to be invalidated and re-done using
other methods. This means that the forum considered these methods
"acceptable" so far which means they provided a "reasonable" assurance
level. The bar has been raised, but not in a measurable way.
Intuitively, these methods were proved to be the "weakest" among the
other methods, even though there are known vulnerabilities for almost
all of them (including DNS/routes hijacking, etc). The validation
working group should discuss more about the threats of each method (and
how to formalize the level of assurance) in case a similar discussion
about the other methods is brought forward.

HARICA votes "abstain" to ballot 218.


Dimitris.


On 29/1/2018 11:51 μμ, Tim Hollebeek via Public wrote:
>
>  
>
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20180201/61c8bcb4/attachment.html>


More information about the Public mailing list