A File Format to Aid in Security Vulnerability Disclosure
draft-foudil-securitytxt-12

I realize this was discussed during IETF last call, but the document still seems unclear on whether the contents of security.txt are meant to be consumed by a human or a machine. In some places the syntax of fields is specified in detail, which would imply machine readability is expected. The ABNF is provided, although it is not normative. The registry policy does not require any formal specification of the format of new fields nor a requirement that field formats even be documented. In short, I can't tell whether security.txt files are meant to be machine-consumable. If they are, then the registry entries need to be more tightly specified and the ABNF should probably be normative. If they're not, I'm not sure why the field definitions are constrained to specific formats beyond saying whether they should be URIs or free text.

I have a few issues I’d like to get resolve before I move to “no objection”.  I think it will be an easy discussion and quick resolution.

— Section 3.1 —

   A "security.txt" file that is found in a file system MUST only apply
   to the folder in which it is located and that folder's subfolders.
   The file does not apply to any of the folder's parent or sibling
   folders.

You don’t say what happens if there are nested security.txt files.  What’s the scope in this situation (which file applies to folder1; which applies to folder1/subfolder)?:

/example/security.txt
/example/folder1/
/example/folder1/security.txt
/example/folder1/subfolder/

I think the document needs to make this clear.

   # This security.txt file applies to IPv4 address of 192.0.2.0.
   https://192.0.2.0/.well-known/security.txt

I’m uncomfortable with trying to restrict the scope depending upon how the file was retrieved.  If www.example.com resolves to 192.0.2.0, then it should not matter whether the file is retrieved via <https://192.0.2.0/.well-known/security.txt> or <https://www.example.com/.well-known/security.txt> (or via the corresponding v6 address).

— Section 3.6 —

Your examples lack the EXPIRES field that you say MUST be present.

— Section 5 —

   The expected file format of the security.txt file is plain text (MIME
   type "text/plain") as defined in section 4.1.3 of [RFC2046] and is
   encoded using UTF-8 [RFC3629] in Net-Unicode form [RFC5198].

In Section 3 you say that for HTTP:

   It MUST have a Content-Type of "text/plain" with the
   default charset parameter set to "utf-8" (as per section 4.1.3 of
   [RFC2046]).

It would be best to have the format requirement be consistent, however it’s retrieved, so “MUST” (rather than “expected”) is right, no?

The ABNF needs some work.  DISCUSS-level issues here, with less important ones below:

  signed           =  sign-header unsigned sign-footer

No, the signed body doesn’t just have a header and footer around the unsigned plain text.  A signed body would have an unsigned body, *followed by* a sign-header, a signature, and a sign-footer.

  unsigned         =  *line (contact-field eol)
                      *line (expires-field eol)
                      *line [lang-field eol] *line
                      ; order of fields within the file is not important

I found this confusing, with “*line” repeated all over the place and with “contact-field” both here and in the “field” construct, but as I worked it out I see that it’s correct (though defnitely confusing).  But while the order of the fields mostly doesn’t matter, the order of the Contact fields, if there are more than one, does matter.  So you’ll have to tweak this a bit.

Give the above, I suggest this:

  unsigned         =  *line
                      (contact-field eol) ; one or more required
                      *line
                      (expires-field eol) ; exactly one required
                      *line
                      [lang-field eol] ; exactly one optional
                      *line
                      ; order of fields within the file is not important
                      ; except that if contact-field appears more than once
                      ; the order of those indicates priority (Section 3.5.3)

  field            =  ; optional fields
                      ack-field /
                      can-field /
                      contact-field / ; optional repeated instances
                      encryption-field /
                      hiring-field /
                      policy-field /
                      ext-field

What do you think?