On Mon, Jan 6, 2020 at 12:27 AM Mark Nottingham <mnot@xxxxxxxx> wrote:
>
> 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.
> ~~~
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
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
