[cabf_validation] Replacement for Domain Validation Method 6

[Doug Beattie]

Ryan,

 

Thanks for the comments and especially for the proposed re-wording that would be acceptable, that saves a lot of time.  I agree with all of your comments and will incorporate them except for the comment about the location of the file.  

 

The intent of this change was to remove “or another path registered with IANA for the purpose of Domain Validation” and to specifically define the 2 places where the validation could be done.  Is it an important security related recommendation to specify ACME MUST use only '.well-known/acme-challenge/ and that all other  implementing of this method MUST use /.well-known/pki-validation (if that is what you were recommending)?  Since multiple random Numbers may be in the same file, I don’t think this will cause interoperability issues, but I wasn’t sure what motived your recommendation. 

 

 

From: Validation <validation-bounces at cabforum.org> On Behalf Of Ryan Sleevi via Validation
Sent: Friday, November 1, 2019 7:02 PM
To: Doug Beattie via Validation <validation at cabforum.org>
Subject: Re: [cabf_validation] Replacement for Domain Validation Method 6

 

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 <mailto: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/20191104/88808bbc/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5701 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20191104/88808bbc/attachment-0001.p7s>