Skip to main content

A File Format to Aid in Security Vulnerability Disclosure



No Objection

Erik Kline
Lars Eggert
(Alvaro Retana)
(Deborah Brungard)

Note: This ballot was opened for revision 10 and is now closed.

Roman Danyliw
(was No Objection, Discuss) Yes
Comment (2021-05-24)
(Updated for -12)
Thank you to Tero Kivinen for the SECDIR review.

Thank you for addressing some of the DISCUSS and COMMENT feedback.
Erik Kline
No Objection
Lars Eggert
(was Discuss) No Objection
Martin Duke
No Objection
Comment (2021-01-20 for -10)
I support Roman's DISCUSS.
Murray Kucherawy
(was Discuss) No Objection
Comment (2021-03-31 for -11)
Thanks for addressing my DISCUSS issues and comments.  I also checked Barry's original DISCUSS and it looks like all of that got covered as well.  So I'll get out of your way here.
Robert Wilton
(was Discuss) No Objection
Comment (2021-01-21 for -11)
And one non blocking comment:

I wasn't quite sure whether the intention is that this file is read and acted on by security researchers, or by scripts?  Having a prescriptive format feels like it is optimized for scripts, but then the text states in various places that security researchers need to check the provenance of the information contained in the file.  I guess that it wasn't really clear to me why a precise format, ABNF and registry needs to be defined at all, and why it wouldn't just be sufficient to say that it is a text file which should contain x, y & z and just leave it at that.
Éric Vyncke
No Objection
Comment (2021-01-20 for -10)
Thank you for the work put into this document. 

I strongly second Barry's DISCUSS point on section 3.1.

Please find below some non-blocking COMMENT points (but replies would be appreciated).

I hope that this helps to improve the document,




I am always uneasy when seeing BCP14 in an informational document...

-- Section 3.1 --
I find weird that a HTTP-retrieved security.txt applies to the whole web site while in a file system it can be applied to a sub-tree.

-- Section 3.5.4 --
Should the encryption algorithm be specified ? OpenPGP is only recommended and not specified as the only one.

-- Section 3.5.6 --
What is the motivation of the "Hiring" field ?

-- Section 3.5.7 --
Is there any recommendation for the language for the policy? Could there be multiple language fields for the policy each with one language ?

-- Section 3.5.8 --
What was the reason of not having a priority order in the list of languages ?
-- Section 4 --
It seems that section 4 repeats the content of section 3.1

-- Section 4.3 --
Why is this section (extensibility) a sub-section of section 4 (location of security.txt) ? Probably a XML mystery ;-)
Alissa Cooper Former IESG member
Discuss [Treat as non-blocking comment] (2021-01-21 for -10)
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.
Barry Leiba Former IESG member
Discuss [Treat as non-blocking comment] (2021-01-19 for -10)
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

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)?:


I think the document needs to make this clear.

   # This security.txt file applies to IPv4 address of

I’m uncomfortable with trying to restrict the scope depending upon how the file was retrieved.  If resolves to, then it should not matter whether the file is retrieved via <> or <> (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

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
                      (expires-field eol) ; exactly one required
                      [lang-field eol] ; exactly one optional
                      ; 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 /

What do you think?
Benjamin Kaduk Former IESG member
Yes (2021-01-12 for -10)
Section 3.5.2

We now allow for multiple Canonical directives to be present.  I think we
should clarify that this directive is used to indicate that a file retrieved
from a given URL is intended to apply to that URL; it is not a direct
indication that a single file, retrieved from whatever location, applies to
all listed locations.  Some additional authority, such as a trusted PGP
signature or the ambient authority granted from retriving the file from the
listed location, is needed in order to know that the claimed canonical 
location applies.

Section 3.5.3

We should s/email address is the preferred/email address 
is the preferred/ (since we now have two email addresses listed)

Section 6

Since we make heavy use of URIs pointing to remote content, we should probably 
explicitly reference the URI security considerations from RFC 3986, especially
with respect to reliability and consistency

Section 6.1

I think we should s/DNS-based/DNSSEC-based/, since we want there to be a
cryptographic mechanism involved in out-of-band verification of the data.

Section 7.2

We should update the initial registration for Canonical to allow multiple
appearances, as the body text now does.
Alvaro Retana Former IESG member
No Objection
No Objection (for -10)

Deborah Brungard Former IESG member
No Objection
No Objection (for -10)