Subject: Re: [Last-Call] Last Call: <draft-foudil-securitytxt-08.txt> (A Method for Web Security Policies) to Informational RFC

From: Mark Nottingham <[email-masked]>
Date: Mon, 6 Jan 2020 16:27:43 +1100

Hello,

In general I support this document. However, I noticed a few things that I think need to be addressed before publication.

* In Section 3:

~~~
 The file is named "security.txt", and this file SHOULD be placed
   under the /.well-known/ path ("/.well-known/security.txt") [RFC8615]
   of a domain name or IP address for web properties.  For legacy
   compatibility, a security.txt file might be placed at the top level
   path (see Section 4.1).

   For web-based services, the file MUST be accessible via the Hypertext
   Transfer Protocol (HTTP) [RFC1945] as a resource of Internet Media
   Type "text/plain" with the default charset parameter set to "utf-8"
   per section 4.1.3 of [RFC2046], and it MUST be served with "https"
   (as per section 2.7.2 of [RFC7230]).  For file systems and version
   control repositories a "security.txt" file SHOULD be placed in the
   root directory of a particular file system or source code project.
~~~

The language here is a bit confused and imprecise. I think you mean something like:

~~~
By convention, the file is named "security.txt". 

When made available on HTTP servers, it SHOULD be placed under the /.well-known/ path (as "/.well-known/security.txt") [RFC8615], MUST be accessed with the "https" scheme, and MUST have a Content-Type of "text/plain". For legacy compatibility, a security.txt file might also be placed at the top level path; see Section 4.1.

When made available in file systems, version control repositories, and similar circumstance, it SHOULD be placed in the root directory.
~~~

* Section 3.1 can be read to allow security.txt to appear on HTTP servers in arbitrary locations. Is that the intent?

* Section 4.1 talks about redirect handling for the top-level path, but doesn't define it for the .well-known location.

* Section 4.1's langage around redirect handling is confusing:

~~~
the implementors MUST NOT follow that redirect if it leads to another domain or subdomain but SHOULD follow that redirect within the same domain name (but not different subdomain on the same domain)
~~~

I think it'd be simpler to just say that redirects MUST NOT be followed if they have a different origin [RFC6454].

* Section 7.2 establishes the "security.txt Header Fields" registry, whereas elsewhere in the document they're called "directives" and "fields". I think it'd be less confusing if this were the "security.txt Directives" registry, since "header fields" is likely to confuse people.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 6 Jan 2020 17:36:00 -0500

> When made available in file systems, version control repositories, and similar circumstance, it SHOULD be placed in the root directory.

We are re-wording this

> * Section 3.1 can be read to allow security.txt to appear on HTTP servers in arbitrary locations. Is that the intent?

Are you referring to the ability to place the file within file systems?

Thanks

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 7 Jan 2020 10:21:27 +1100

> On 7 Jan 2020, at 9:36 am, Yakov Shafranovich <[email-masked]> wrote:
> 

I'm referring to:

>    # This file applies to the /example/folder1 directory and subfolders.
>    /example/folder1/security.txt

A casual reader might interpret that as applying to URIs.

Cheers,

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 6 Jan 2020 18:53:30 -0500

We will clarify the language. Thanks