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/
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
