[cabf_validation] Replacement for Domain Validation Method 6

[Ryan Sleevi]

High Level: We've been inconsistent with SHALL/SHALL NOT vs MUST/MUST NOT
overall. MUST/MUST NOT is the more common/modern expression, and may be
clearer to understand.

On Fri, Nov 1, 2019 at 1:59 PM Doug Beattie via Validation <
validation at cabforum.org> wrote:

> 3.2.2.4.17 Agreed-Upon Change to Website v2
>
> Confirming the Applicant's control over the FQDN by verifying that the
> Request Token or Random Value is contained in the contents of a file.
>
> A.      The entire Request Token or Random Value MUST NOT appear in the
> request used to retrieve the file, and
> B.      the CA MUST receive a successful HTTP response from the request
> (meaning a 2xx HTTP return code must be received).
>
>
>
> The file containing the Request Token or Random Number SHALL:
>
> 1.      be located on an Authorization Domain Name, and
>

I don't think this is the right wording, but I appreciate that you're
trying to mirror the (bugged) 3.2.2.4.6

Short answer: change "an" to "the" :)

Long answer: (because of course) We've had some discussions in the past
about the language here, and it seems this construct might cause some
confusion

 In the past, the discussion was about the singular/proper ("the"
Authorization Domain Name) versus plural/any-of ("an" Authorization Domain
Name). The question then, which I think is relevant now, is whether the ADN
is an Input into the validation algorithm - i.e. the CA selects it before
hand, then applies the validation method - or if it's an Output - i.e. the
CA provides an FQDN, and the validation method can enumerate through ADNs.

3.2.2.4.2 reads that it's an input.
3.2.2.4.2 reads that it's an input or an output
3.2.2.4.6 reads that it's an input
3.2.2.4.7 reads that it's an output
3.2.2.4.10 reads that it's an input
3.2.2.4.13 reads that it's an input
3.2.2.4.14 read that it's an input

We last discussed this with SC13 (e.g.
https://cabforum.org/pipermail/servercert-wg/2018-November/000416.html and
following), and before that SC3, which is why all of the subsequent methods
have treated it as an input ("the" Authorization Domain Name). 3.2.2.4.6
was one we said we'd clean up when we cleaned up 3.2.2.4.6, so I think this
is where/when we want to clean up.

2.      be located under the "/.well-known/pki-validation" or
> ".well-known/acme-challenge/" directory, and
>

I thought the intent was to explicitly sunset anything other than the ACME
method? If that's not the intent of this Ballot, perhaps we should split
this into two parts - one related to explicitly referencing RFC 8555 and
the 'http-01' challenge, and the other normatively describing an
ACME-alternative (which would stay on pki-validation).

Part of this is intentional to avoid situations where
'.well-known/acme-challenge/' is used with non-ACME validation methods,
which would just make things less interoperable and more confusing.


> 3.      be accessed via HTTP or HTTPS, and
>

Implicit in this, but which is worth specifying, is what does "accessed
over HTTPS" mean? Can a CA perform a TLS handshake disabling all
certificate validation? Can they use a legacy version of SSL/TLS that is
known-insecure (e.g. SSL3)?

Implicitly, since we're allowing HTTP, it seems we're presuming there are
zero confidentiality, integrity, or authenticity requirements here for the
request or the response, which isn't an unreasonable assumption (since
we're also assuming the out-of-band knowledge of the magic value). However,
we may want to try to clarify some of this while we're revising.

- MUST be retrieved via either the "http" or "https" scheme.


> 4.      be accessed over an Authorized Port.
>
> If the CA follows redirects, then the CA SHALL:
>
> a.      follow only server side (3xx) redirects, and
>

It's unclear why the number shifting, and this certainly would be somewhat
uncharacteristic with how we approach other sections (and, admittedly,
slightly unfortunate for markdown as we could not do prettier lists here).

That said, the term "server side (3xx)" is a bit ambiguous. It sounds like
what you're trying to capture is:
- Redirects MUST be initiated at the HTTP protocol layer (e.g. using a 3xx
status code)

Of course, if we want to further restrict it (e.g. to exclude HTTP/2
framing or future stuff)
- Redirects MUST be the result of an HTTP status code result within the 3xx
Redirection class of status codes, as defined in RFC 7231, Section 6.4


> b.      follow 10 or fewer redirects, and
> c.      follow only HTTP and HTTPS redirects, and
>

- Redirects MUST be to resource URLs with either via the "http" or "https"
scheme


> d.      follow redirects only to Authorized Ports.
>

- Redirects MUST be to resource URLs accessed via Authorized Ports.


> If a Random Value is used, then:
>
> i.      the CA SHALL provide a Random Value unique to the certificate
> request and
> ii.     the CA SHALL NOT use the Random Value after the longer of (i) 30
> days or (ii) if the Applicant submitted the Certificate request, the
> timeframe permitted for reuse of validated information relevant to the
> Certificate (such as in Section 4.2.1 of these Guidelines or Section
> 11.14.3 of the EV Guidelines).
>

Using (i) and (ii) nested in an (i) seems... very undesirable. You've
exhausted the iterative number lists. It's also clear why this isn't broken
into a subsetted list, which I think is one of the pieces of feedback we've
been regularly hearing.

However, there's an even easier fix here. In the past, we've had discussion
that it's unclear why subclause (ii) exists, and there is compelling reason
why it SHOULD NOT exist. That is, compare with our other methods (e.g.
3.2.2.4.2), and 30 days is the absolute upper bound for the reuse of that
Random Value, and the CA's CP/CPS MAY specify shorter.

As a practical matter, CAs can already reuse a previously completed
validation to be valid (for the ADN or for the FQDN), so this doesn't
change the overall ability to reuse. However, it's patently dangerous to
allow this random value to sit out there and be able to be used to
authorize subsequent (different) requests, and worse, it allows an overall
extension for the reuse by allowing

T=0 - initial random value created; certificate issued
T=824 days - a *new* validation is performed using that *old* random number.

This permits the CA to issue a new certificate at T=824 for 825 days, *and*
permits them to issue *another* 825-day level certificate at T=1649 (!!!),
by reusing the previous ADN validation.

That is, the validation method itself should not try to match the reuse
limitations in 4.2.1/11.14.3, because that doesn't "match" the reuse, it
significantly *extends* the reuse, insecurely.

I can understand that (i) is supposed to prohibit this, but I'm fully
confident that some CA would be willing to argue they were confused,
because they reused the same initial CSR, so it was fine to reuse that same
Random Value.

So let's just say what we do in 3.2.2.4.2

> The Random Value SHALL remain valid for use in a confirming response for
no more than 30 days from its
> creation. The CPS MAY specify a shorter validity period for Random
Values, in which case the CA MUST follow
> its CPS.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20191101/6c2a6479/attachment.html>