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 <[email protected]> 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 > > ........................................................................ > > [email protected] > > http://www.logius.nl > > > > > > > > Van: Public [mailto:[email protected]] Namens Dimitris > Zacharopoulos via Public > Verzonden: donderdag 1 februari 2018 15:35 > Aan: [email protected] > 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 > > [email protected] > > 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 > [email protected] > https://cabforum.org/mailman/listinfo/public >
-- Josh Aas Executive Director Internet Security Research Group Let's Encrypt: A Free, Automated, and Open CA _______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
