[cabfpub] Voting begins: Ballot 218 version 2

Josh Aas josh at letsencrypt.org
Mon Feb 5 21:36:00 UTC 2018


Let's Encrypt votes YES on ballot 218

On Mon, Feb 5, 2018 at 2:09 PM, Berge, J. van den (Jochem) - Logius
via Public <public at cabforum.org> wrote:
> PKIoverheid votes YES.
>
>
>
> We’ve been following the discussion as it has unfolded. The definition of
> current methods 3.2.2.4.1 and 3.2.2.4.5, as currently worded in the BR, we
> have to agree,  leaves much room for interpretation. However, we might be
> able to improve these methods, a process that will require time.
>
>
>
> In this discussion there are CAs and browsers on the one side who are
> (possibly) proposing a more radical solution of termination of said
> validation methods per March 1 (enforced through browser program
> requirements), there is ballot 218 which proposes abolition of 3.2.2.4.1 and
> 3.2.2.4.5 per August 1, and there are parties who want to keep current
> methods in place, at least long enough for new and improved versions to be
> developed and deployed. The last option has the danger that a working group
> effort could go on for months and months without much progress, while the
> current methods stay in place. This ballot, with a firm deadline of August
> 1, puts a fixed end date on the current methods .1 and .5. We welcome
> possible working group discussions about a new or improved domain validation
> methods (possibly included in the broader discussion, see Dimitris’ response
> below) and is, in our view, this ballot is the best approach forward. It’s a
> combination of an achievable timeline for CAs to move away from 3.2.2.4.1
> and 3.2.2.4.5 while also including a final date by which CAs must have
> changed to a different method.
>
>
>
> Kind regards,
>
>
>
> Jochem van den Berge
>
>
>
> Logius PKIoverheid
>
> Public Key Infrastructure for the Dutch government
>
> ........................................................................
>
> Logius
>
> Ministry of the Interior and Kingdom Relations (BZK)
>
> Wilhelmina van Pruisenweg 52 | 2595 AN | The Hague
> PO Box 96810 | 2509 JE | The Hague
>
> ........................................................................
>
> jochem.vanden.berge at logius.nl
>
> http://www.logius.nl
>
>
>
>
>
>
>
> Van: Public [mailto:public-bounces at cabforum.org] Namens Dimitris
> Zacharopoulos via Public
> Verzonden: donderdag 1 februari 2018 15:35
> Aan: public at cabforum.org
> Onderwerp: Re: [cabfpub] Voting begins: Ballot 218 version 2
>
>
>
>
> 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
>
>
>
>
> ________________________________
> Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u
> niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden,
> wordt u verzocht dat aan de afzender te melden en het bericht te
> verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van
> welke aard ook, die verband houdt met risico's verbonden aan het
> elektronisch verzenden van berichten.
> This message may contain information that is not intended for you. If you
> are not the addressee or if this message was sent to you by mistake, you are
> requested to inform the sender and delete the message. The State accepts no
> liability for damage of any kind resulting from the risks inherent in the
> electronic transmission of messages.
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>



-- 
Josh Aas
Executive Director
Internet Security Research Group
Let's Encrypt: A Free, Automated, and Open CA



More information about the Public mailing list