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

[Jeremy Rowley]

The BR language states the well-known directory must be “on the Authorization Domain Name”.  Whether a re-direct is “on the Authorization Domain Name” is questionable.  If following redirects is permitted, the language should be updated accordingly. 

 

Jeremy

 

 

From: Jacob Hoffman-Andrews [mailto:jsha at letsencrypt.org] 
Sent: Wednesday, July 19, 2017 2:54 PM
To: Paul Hoffman <paul.hoffman at icann.org>; CA/Browser Forum Public Discussion List <public at cabforum.org>
Cc: Jeremy Rowley <jeremy.rowley at digicert.com>
Subject: Re: [cabfpub] [Ext] .well-known and re-directs

 

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://lists.cabforum.org/pipermail/public/attachments/20170720/ec12e942/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4964 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170720/ec12e942/attachment-0003.p7s>