[cabf_validation] Draft Ballot to Remove IP "Any Other Method" Validation (SC7)

[Wayne Thayer]

Jacob,

Thanks for the review and suggestions. We discussed them on yesterday's
subcommittee call and consensus was to accept the proposals to make the
ACME methods explicit, but to keep (for now) the reverse-lookup method
despite you concerns being shared by others. The intent of this ballot is
to replace "any other method" with explicit methods that are in use today,
and we believe that the reverse-lookup method is in use. The next step in
the process is to improve or remove vulnerable methods, as is currently
being done for domain validation.

I think this ballot is ready, so I'll be starting the review period shortly.

- Wayne

On Tue, Jan 8, 2019 at 4:58 PM Wayne Thayer <wthayer at mozilla.com> wrote:

> Forwarding this message since Jacob isn't a member of the list, so it was
> discarded by the system.
>
> ---------- Forwarded message ---------
> From: Jacob Hoffman-Andrews <jsha at eff.org>
> Date: Tue, Jan 8, 2019 at 4:52 PM
> Subject: Re: [cabf_validation] Draft Ballot to Remove IP "Any Other
> Method" Validation (SC7)
> To: Wayne Thayer <wthayer at mozilla.com>, CA/Browser Forum Validation WG
> List <validation at cabforum.org>
>
>
> Thanks for drafting this! I'm very supportive of specifying the IP
> validation methods more rigorously.
>
> I've made a couple of comments on the draft:
>
> - The ACME WG has removed the "reverse address lookup" method from the
> IP address validation draft because it was not considered a reliable
> source of information. We shouldn't include it here.
>
> - The "Agreed-Upon Change to Website" section covers the "http-01"
> method in the acme-ip draft
> (https://tools.ietf.org/html/draft-ietf-acme-ip-04#section-4), but I
> think it is better to assign separate numbers to ACME methods because
> they are much narrower and better-defined. For instance, if a future
> requirement or best practice emerges of declaring the validation methods
> used within a certificate extension, this allows CAs to be much more
> specific.
>
> - Along similar lines, we should probably include the other method from
> the acme-ip draft, "tls-alpn-01." This avoids a deadlock where the
> method isn't legal, so there can't be publicly-trusted implementations,
> which makes IETF standardization harder.
>
> The acme-ip draft is not yet an RFC, but is fairly far along. I don't
> expect revisions to the details of the validation methods, and we can
> reference a specific draft version for precision.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20190118/cf16359f/attachment.html>