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

Jeremy Rowley jeremy.rowley at digicert.com
Fri Jul 21 08:12:29 MST 2017

Thanks a ton for the reply, Ryan! {Didn't mean to make it sound urgent, but that same question keeps arising during the verification process} 

Your summary is correct, and my thinking aligned with yours - that we want a single request/response for verification.  I was surprised Let's Encyrpt was permitting re-directs.  However, as you pointed, they did not state Let's Encrypt permits redirects to a separate domain (just a port change).  

Jacob - does Let's Encrypt permit redirects to other sites or does the request token/random value need to be on the same authorization domain, just a different port?  

-----Original Message-----
From: Ryan Sleevi [mailto:sleevi at google.com] 
Sent: Friday, July 21, 2017 9:05 AM
To: Jeremy Rowley <jeremy.rowley at digicert.com>; CA/Browser Forum Public Discussion List <public at cabforum.org>
Cc: Jacob Hoffman-Andrews <jsha at letsencrypt.org>; Paul Hoffman <paul.hoffman at icann.org>
Subject: Re: [cabfpub] [Ext] .well-known and re-directs

Hi Jeremy,

Apologies for the delay in responding. Would this be a correct summary of the confusion:

In HTTP, it is a Request/Response protocol. A request is made for a given resource, and a response is provided. Some responses include the resource directly requested (e.g. the 200/2xx series), other responses may indicate the resource has moved (e.g. 304) or is not available (e.g. 404 or 500). These are valid responses, but they indicate they're not the resource requested.

The question is whether or not a CA is expected to perform a single Request/Response in the of retrieving a resource (namely, "the content of a file or on a web page"), or whether it is allowed to adhere to the HTTP semantics that indicate how multiple Requests can be made to ultimately satisfy a resource fetch.

Personally, I'm strongly of the opinion that the Required Website Content should be obtained via a single Request/Response workflow.
This aligns with at least some of the audit reports I've seen, where various auditors (whether security or BR) have interpreted this section as being restrictive to a single Request/Response flow, and appropriately flagged when a CA follows redirects. This suggests that there's at least some agreement on this view.

That said, I can also understand and appreciate a view that, by specifying "content of a file or on a web page", we may have inadvertently allowed for an interpretation that allows for multiple Requests/Responses.

When considering the reasonableness of either approach, it does seem important to consider this: Would we consider it reasonable for a CA to issue Range Requests for the file or a web page? This is where multiple requests can be made that, in their sum totality, encompass the fullness of the file or the web page. Would we allow for partial range requests (e.g. the CA only requesting say, the first 32 bytes).
Would we expect CAs to detect situations of truncation (e.g. the content received does not align with the Content-Length) and either recover from it, reject it, or accept it as valid?

I'm certainly curious others' take, but from an overall security perspective (and aligning with the security audits of CAs that I've seen), there seems to be a general belief that a single Request/Response pair is all that is permitted.

Jacob has taken the view on the rewrite of the scheme, but without modifying the domain. If a server redirected to ftp://, would we still consider that Required Website Content? If it redirected to ldap://, would we still consider that Required Website content?

That said, I haven't heard any arguments that "on the Authorization Domain" encompasses anything other than the domain itself. At best, a modification of scheme (and thus, transitively, a modification of the port used - which needs to be congruent with Authorized Ports) may be worth discussing, but I would not want to see any scoping beyond that.

In these situations, it seems most advisable to take the restrictive approach - to disable redirects. The website authentication mechanism is already substantially less secure than some of our other methods, and the less we can do to increase that attack surface, the better.

On Fri, Jul 21, 2017 at 10:49 AM, Jeremy Rowley via Public <public at cabforum.org> wrote:
> Is the lack of additional response agreement that “on the 
> Authorization Domain” encompasses both the authorization domain names 
> and redirects from an authorization domain name?
> From: Public [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy 
> Rowley via Public
> Sent: Thursday, July 20, 2017 8:37 AM
> To: Jacob Hoffman-Andrews <jsha at letsencrypt.org>; Paul Hoffman 
> <paul.hoffman at icann.org>; CA/Browser Forum Public Discussion List 
> <public at cabforum.org>
> Subject: Re: [cabfpub] [Ext] .well-known and re-directs
> 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 (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) 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:
> 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:
> 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 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).
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4964 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/public/attachments/20170721/ad939bec/attachment-0001.p7s>

More information about the Public mailing list