[cabfpub] [Ext] .well-known and re-directs

[Jacob Hoffman-Andrews]

I disagree with Paul's interpretation. At Let's Encrypt we have always
followed HTTP redirects, and consider it an important part of validating by
HTTP. Consider, for instance, a web site that redirects all "http:" URLs to
"https:" URLs. If that site were required to inhibit redirects for
validation requests, that would be harmful to the site's security.

My interpretation is that RFC 5785 (Well-Known URIs) doesn't need to
specifically mention redirects, any more than it needs to mention Host
headers, status codes, or any of the other implementation details of HTTP.
According to RFC 7231 <https://tools.ietf.org/html/rfc7231#section-6.4> (HTTP
Semantics and Content):

> The 3xx (Redirection) class of status code indicates that further
> action needs to be taken by the user agent in order to fulfill the
> request.  If a Location header field (Section 7.1.2 <https://tools.ietf.org/html/rfc7231#section-7.1.2>) is provided, the
> user agent MAY automatically redirect its request to the URI
> referenced by the Location field value, even if the specific status
> code is not understood.


If it was the intent of RFC 5785 or the Baseline Requirements to rule out
certain HTTP semantics, that would need to be made explicit. And I think an
amendment ruling out redirects would be a mistake. For reference, here's
the relevant BR text:
3.2.2.4.6 Agreed-Upon Change to Website

Confirming the Applicant’s control over the requested FQDN by confirming
one of the following under the “/.well-known/pki-validation” directory, or
another path registered with IANA for the purpose of Domain Validation, on
the Authorization Domain Name that is accessible by the CA via HTTP/HTTPS
over an Authorized Port:

   1. The presence of Required Website Content contained in the content of
   a file or on a web page in the form of a meta tag. The entire Required
   Website Content MUST NOT appear in the request used to retrieve the file or
   web page, or
   2. The presence of the Request Token or Request Value contained in the
   content of a file or on a webpage in the form of a meta tag where the
   Request Token or Random Value MUST NOT appear in the request.

If a Random Value is used, the CA or Delegated Third Party SHALL provide a
Random Value unique to the certificate request and 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 3.3.1 of these
Guidelines or Section 11.14.3 of the EV Guidelines).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20170719/eb2c5105/attachment.html>