[cabf_validation] Pre-ballot discussion for Method 10 replacement

Ryan Sleevi sleevi at google.com
Tue Jan 29 13:05:12 MST 2019


I thought that http-01 was being coupled with a proposed sunset of -06?
Have I misunderstood?

Given how close ACME is to RFC status (it's in the RFC Editor queue), it
may be worth deferring. That is, unlike both the IP improvement and this
(which close security gaps and overly broad language), http-01 and dns-01
don't seem as significant a win unless coupled to improvements/deprecation
of 3.2.2.4.6 / .7.

IP address and ALPN are not quite there yet, although they're substantially
matured, hence the desire to use the draft status and update the BRs once
finalized.

On Tue, Jan 29, 2019 at 2:56 PM Wayne Thayer via Validation <
validation at cabforum.org> wrote:

> For consistency with the decision we made to add explicit ACME methods for
> IP address validation, should we also add http-01 and dns-01 from
> https://tools.ietf.org/html/draft-ietf-acme-acme-18 to this ballot?
>
> - Wayne
>
> On Mon, Jan 28, 2019 at 2:01 PM Tim Hollebeek via Validation <
> validation at cabforum.org> wrote:
>
>> I support this strategy and would endorse.
>>
>>
>>
>> -Tim
>>
>>
>>
>> *From:* Validation <validation-bounces at cabforum.org> *On Behalf Of *Doug
>> Beattie via Validation
>> *Sent:* Monday, January 28, 2019 2:33 PM
>> *To:* validation (validation at cabforum.org) <validation at cabforum.org>
>> *Subject:* [cabf_validation] Pre-ballot discussion for Method 10
>> replacement
>>
>>
>>
>> I’ve had a couple of side discussions with various people, so I figured I
>> toss this our for discussion on a Method 10 replacement strategy.   If this
>> is generally agreed to, then I’ll look for 2 endorsers and get a Ballot
>> number.
>>
>>
>>
>>
>>
>>
>>
>> This ballot sets and end date to Method 10 and defines a replacement
>> method based on the IETF TLS ALPN specification.
>>
>>
>>
>> --- MOTION BEGINS ---
>>
>> This ballot modifies the “Baseline Requirements for the Issuance and
>> Management of Publicly-Trusted Certificates” as follows, based on Version
>> 1.6.2:
>>
>>
>>
>> Replace the content of section 3.2.2.4.10 with:
>>
>>
>>
>> This method has been retired and MUST NOT be used for issuance of
>> certificates after May 31, 2019. Prior validations using this method and
>> validation data gathered according to this method SHALL NOT be used to
>> issue certificates after May 31, 2019.
>>
>>
>>
>>
>>
>> Add Section 3.2.2.4.17  TLS ALPN
>>
>> Confirming the Applicant's control over a FQDN by validating domain
>> control of the FQDN using TLS as specified in this specific IETF
>> specification and version:
>> https://tools.ietf.org/html/draft-ietf-acme-tls-alpn-05
>>
>> 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.
>>
>>
>>
>>
>>
>>
>>
>> --- MOTION ENDS ---
>>
>>
>>
>>
>> _______________________________________________
>> Validation mailing list
>> Validation at cabforum.org
>> https://cabforum.org/mailman/listinfo/validation
>>
> _______________________________________________
> Validation mailing list
> Validation at cabforum.org
> https://cabforum.org/mailman/listinfo/validation
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20190129/e8942782/attachment.html>


More information about the Validation mailing list