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

Received changes through RFC Editor sync (created alias RFC 9116, changed abstract to 'When security vulnerabilities are discovered by researchers, proper reporting channels are often lacking.  As a result, vulnerabilities may be left unreported.  This document defines a machine-parsable format ("security.txt") to help organizations describe their vulnerability disclosure practices to make it easier for researchers to report vulnerabilities.', changed pages to 21, changed standardization level to Informational, changed state to RFC, added RFC published event at 2022-04-27, changed IESG state to RFC Published)

[Ballot discuss]
(Updated for -11)

** Section 3.5.2. Per “The purpose of this field is to allow a digital signature to be applied to the locations of the "security.txt" file”, if a security.txt file is retrieved over https via “URL-A”, and the Canonical field does not contain URL-A, should this file be trusted?

[Ballot comment]
(Updated for -11)
Thank you to Tero Kivinen for the SECDIR review.

Thank you for addressing some of the DISCUSS and COMMENT feedback.

====

** Section 6.1.  Per “Security researchers should triage  the "security.txt" file including verifying the digital signature and checking any available historical  records before using the information contained in the file”

-- what historical records are being suggested here?  Is it older versions of the security.txt file?

** Section 6.3.  Per “Organizations must use …”, should this be a normative MUST?

** Section 6.4.  Per “Implementors … may choose not to parse files larger …”, should this be a normative MAY?  Should this be restated to say that the MTI is supporting files of 32KBs and smaller?

[Ballot discuss]
Taking over Alissa's discuss, because I see no changes in -11 related to it:

> 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.

[Ballot comment]
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.

[Ballot discuss]
Sorry to pile on, but I'm really not clear on the whole filesystem portion of this.

  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.

I take this to mean if I want to report a vulnerability related to the filesystem or something in it (a vulnerable binary, perhaps, or a writable password file), I should look for "security.txt" in the directory of interest and use that one; if it's missing, I walk upwards until I find one, and use the first one I found.  (If that's not correct, then this needs to be clarified, or given the other DISCUSSes, it may need to be clarified anyway.)

What if I want to report something unrelated to the filesystem?  Suppose I somehow acquire a root shell on a machine I shouldn't be able to access, and that process has no current working directory.  I look around and find "security.txt" files in several directories.  Which one do I use?  Sitting at a shell prompt doesn't automatically map to a place in the filesystem tree where I should start looking.

[Ballot comment]
I support Alissa and Barry's DISCUSS positions.

Some additional feedback:

Section 4.1:

  Web-based services MUST place the security.txt file under the
  "/.well-known/" path; e.g. https://example.com/.well-known/
  security.txt as per [RFC8615].

It's not really the web server putting it there, right?  It's some human, and the web server just makes it available at that path.  I suggest:

  Web-based services MUST make the security.txt file available at the
  "/.well-known/" path; e.g. https://example.com/.well-known/
  security.txt, as per [RFC8615].

Similarly:

  File systems SHOULD place the "security.txt" file under the root
  directory; e.g., "/security.txt", "C:\security.txt".

I suggest:

  The "security.txt" file SHOULD be placed in the root
  directory; e.g., "/security.txt", "C:\security.txt".

Also, why is this a SHOULD?  Why might someone put it elsewhere, and what implications does doing so have?

Section 4.3 talks about extension fields in the content, but that's part of Section 4 which talks about location of the file.  I think 4.3 belongs at 5.1 instead.

[Ballot discuss]
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.

[Ballot comment]
I support Barry's DISCUSS.

== Section 3 ==

OLD
On HTTP servers, the file MUST be accessed via HTTP 1.0 or a higher
  version and the "https" scheme (as per [RFC1945] and section 2.7.2 of
  [RFC7230]).

NEW
On HTTP servers, the file MUST be accessed via HTTP 1.0 or a higher
  version and the file access MUST use the "https" scheme (as per [RFC1945] and section 2.7.2 of [RFC7230]).
 
'A "field" MUST always consist of a name and a value' --> why is "field" in quotes? (It is not in quotes in the prior paragraph.)

s/It is important to note that each field MUST appear on its own line./Each field MUST appear on its own line./

== Section 3.2 and 3.3 ==

This reflects my ignorance, but do we not have a documented best practice recommendation for character set usage for free-form text, akin to RFC 5198?

== Section 3.5.6 ==

This field does not seem to belong in the security.txt specification.

[Ballot discuss]
Hi,

Thank you for this document.  I like that it provides a fairly simple solution to providing vulnerability reporting information, although I also have some sympathy with the observation that if the server is compromised then security.txt could also be compromised.

However, I have a concern about the document both being machine readable and also including an expiry date.  This would seem to offer an easy mechanism to probe websites for those that have out of date security.txt files and hence may have more lax security practices, or potentially help provide indirect information about what software versions a website might be using.  Alternatively, this will end up as Barry has suggested, with lots of old expiry dates.

Arguably, the best alternative might be just to not provide a date at all, and rely on the humans to check the provenance of the information, and treat it with suitable caution.  An alternative possibility could be just to define a field for when the information was last updated.  This doesn't go out of date, but helps provide some clue as to whether the information might be stale or not.

Regards,
Rob

[Ballot comment]
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.

[Ballot discuss]
Sorry to pile on, but I'm really not clear on the whole filesystem portion of this.

  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.

I take this to mean if I want to report a vulnerability related to the filesystem or something in it (a vulnerable binary, perhaps, or a writable password file, I should look for "security.txt" in the directory of interest and use that one; if it's missing, I walk upwards until I find one, and use the first one I found.  (If that's not correct, then this needs to be clarified, or given the other DISCUSSes, it may need to be clarified anyway.)

What if I want to report something unrelated to the filesystem?  Suppose I somehow acquire a root shell on a machine I shouldn't be able to access, and that process has no current working directory.  I look around and find "security.txt" files in several directories.  Which one do I use?  Sitting at a shell prompt doesn't automatically map to a place in the filesystem tree where I should start looking.

[Ballot comment]
I support Barry's DISCUSS.  Some additional feedback:

Section 4.1:

  Web-based services MUST place the security.txt file under the
  "/.well-known/" path; e.g. https://example.com/.well-known/
  security.txt as per [RFC8615].

It's not really the web server putting it there, right?  It's some human, and the web server just makes it available at that path.  I suggest:

  Web-based services MUST make the security.txt file available at the
  "/.well-known/" path; e.g. https://example.com/.well-known/
  security.txt, as per [RFC8615].

Similarly:

  File systems SHOULD place the "security.txt" file under the root
  directory; e.g., "/security.txt", "C:\security.txt".

I suggest:

  The "security.txt" file SHOULD be placed in the root
  directory; e.g., "/security.txt", "C:\security.txt".

Also, why is this a SHOULD?  Why might someone put it elsewhere, and what implications does doing so have?

Section 4.3 talks about extension fields in the content, but that's part of Section 4 which talks about location of the file.  I think 4.3 belongs at 5.1 instead.

[Ballot discuss]
(Updated)
** The concept of operations for the file-based approach seems under-specified in a few ways:

(After reviewing the other ballot positions of my peers, I believe this first item is the same issue as raise by Barry)
-- Section 3.1 says: 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.

Unless I missed it, a “use the most specific directory rule” doesn’t appear to be explicitly stated and there didn’t seem to be a restriction on the number of security.txt files in a filesystem.  That is, multiple security.txt seem like they could apply.  Assume:

(1) /opt/foo/security.txt
(2) /opt/foo/bar/security.txt

Does security.txt (1) and (2) apply to /opt/foo/bar? How is one intended merge the contents of two files?

-- Is the thinking that software publisher going to package a security.txt and put it in some install directory on an end-point (like a SWID)? Or is it more likely to go into a source tar ball or seen only when you “git clone” a repo (like a README.md)?

-- If it will be in a package, is there an intent to relate any integrity protection of the overall package with the recommend openpgp practices described in this document?  If one is signature is invalid does that say anything about the other?

-- If it will be in a package, then is the guidance in Section 4.2 appropriate (File systems SHOULD place the "security.txt" file under the root directory; e.g., "/security.txt", "C:\security.txt") unless we’re assuming some container/chroot-like strategy?

-- If an end-point maintainer wants to implement a different policy, is that maintainer supposed to modify/replace the file or put another instance of that file in an alternate directory?

** Section 3.5.2. Per “The purpose of this field is to allow a digital signature to be applied to the locations of the "security.txt" file”, if a security.txt file is retrieved over https via “URL-A”, and the Canonical field does not contain URL-A, should this file be trusted?  Same with a file system directory.

[Ballot discuss]
** The concept of operations for the file-based approach seems under-specified in a few ways:

-- Section 3.1 says: 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.

Unless I missed it, a “use the most specific directory rule” doesn’t appear to be explicitly stated and there didn’t seem to be a restriction on the number of security.txt files in a filesystem.  That is, multiple security.txt seem like they could apply.  Assume:

(1) /opt/foo/security.txt
(2) /opt/foo/bar/security.txt

Does security.txt (1) and (2) apply to /opt/foo/bar? How is one intended merge the contents of two files?

-- Is the thinking that software publisher going to package a security.txt and put it in some install directory on an end-point (like a SWID)? Or is it more likely to go into a source tar ball or seen only when you “git clone” a repo (like a README.md)?

-- If it will be in a package, is there an intent to relate any integrity protection of the overall package with the recommend openpgp practices described in this document?  If one is signature is invalid does that say anything about the other?

-- If it will be in a package, then is the guidance in Section 4.2 appropriate (File systems SHOULD place the "security.txt" file under the root directory; e.g., "/security.txt", "C:\security.txt") unless we’re assuming some container/chroot-like strategy?

-- If an end-point maintainer wants to implement a different policy, is that maintainer supposed to modify/replace the file or put another instance of that file in an alternate directory?

** Section 3.5.2. Per “The purpose of this field is to allow a digital signature to be applied to the locations of the "security.txt" file”, if a security.txt file is retrieved over https via “URL-A”, and the Canonical field does not contain URL-A, should this file be trusted?  Same with a file system directory.

[Ballot comment]
Thank you to Tero Kivinen for the SECDIR review.

** Terminology.  Section 1.1 cites [ISO.29147.2018] and [CERT.CVD] as the background documents for vulnerability management.  Those documents define a workflow and name the actors in the corresponding processes as “finders”, “reporters” and “vendors”.  This document uses the term “security researchers”, “implementers” and “organizations”.  Why use a new lexicon?  If not reuse of this lexicon, minimally, it would be helpful to explicitly map the terms used in those references to the terms used here.

** Section 3.1.  Per "security.txt" file MAY also apply to products and services provided by the organization publishing the file”, this statement confused me because this seems like the definition of the kinds of product vulnerability information described in Section 1.1.  Here it used a normative MAY too.

** Section 3.  Per “The file may also contain blank lines …”, why not a normative MAY?

** Section 3.5.*.  It would be helpful to explicitly say that unless otherwise noted, all fields are optional.  Certainly fields are explicitly noted as being mandatory, but for other the cardinality is left unsaid and implicitly assumed to be optional.

** Section 4.3.  Per “To encourage extensibility and interoperability, implementors MUST ignore any fields they do not explicitly support”, I recommend being clearer by saying it is the consumers (or reporters if you want to be consistent with the references or researchers to be consistent with the current terms) who can ignore any unrecognized fields.

** Section 6.1.  Per “Security researchers should triage  the "security.txt" file including verifying the digital signature and checking any available historical  records before using the information contained in the file”

-- I don’t follow what is being ‘triaged’ which would suggest that there is a choice to make among options?

-- what historical records are being suggested here?  Is it older versions of the security.txt file?

** Section 6.3.  Per “Organizations must use …”, should this be a normative MUST?

** Section 6.4.  Per “Implementors … may choose not to parse files larger …”, should this be a normative MAY?  Should this be restated to say that the MTI is supporting files of 32KBs and smaller?

** Section 6.5
-- Per “The presence of a security.txt file might be interpreted by researchers as providing permission to do security testing against that asset.”, the framing of security.txt as referencing an asset could be seen as an expansion of scope.  Recommend using  language consistent with what was said in Section 1 or 3 (i.e., “product” or “service”).

-- Per “Therefore, implementors shouldn't assume that presence or absence of a "security.txt" file grants or denies permission for security testing.  Any such permission may be indicated in the company's vulnerability disclosure policy (as per Section 3.5.7) or a new field (as per Section 4.3)”, if we are talking about “products”, as in packaged software, it seems uncommon to turn to vul disclosure policies (rather than EULAs) to understand what kind of testing/reverse engineering is permitted.

[Ballot comment]
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,

Regards,

-éric

== COMMENTS ==

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 ;-)

[Ballot discuss]
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  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
  [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?

[Ballot comment]
— Section 3.3 —

  Every line MUST end either with a carriage return and line feed
  characters (CRLF / %x0D %x0A) or just a line feed character (LF /
  %x0A).

Why are we still allowing multiple ways to do this, these days, though it’s been shown to be problematic?  Most protocols have settles on CRLF definitively.  Why not here also?

— Section 3.5.1 —

  If this field indicates a web URL

“URI”, please, and throughout the document (I see 9 instances).

Also, you might consider just factoring that bit out to avoid repeating it, and putting into Section 3.5 something like:

  If any field indicates a web URI, that URI MUST begin with "https://"
  (as per section 2.7.2 of [RFC7230]).

— Section 3.5.5 —

Is there really value in *requiring* a sell-by date on this, and in recommending that the domain owner update this file annually or more often?  I can see that in most cases, this information would reasonably have a lifetime of years (if I’m not using fields such as “Hiring”).  I guess it’s not really a problem, as I could just ignore the RECOMMENDED and specify 31 Dec 2525, or some such [https://en.wikipedia.org/wiki/In_the_Year_2525].

— Section 3.5.8 —

  The order in which they appear MUST NOT be interpreted as an
  indication of priority - rather these MUST be interpreted as all
  being of equal priority.

This seems like an oddly heavy use of “MUST”, as there’s no interoperability issue here.  I suggest phrasing this without BCP 14 key words, as:

  The order in which they appear is not an indication of priority;
  the listed languages are intended to have equal priority.

— Section 4.1 —

  Researchers should perform additional triage

“Triage” refers to sorting into priority groups, and doesn’t seem to be the right word here.  I think “analysis” works better.

— Section 4.2 —

I can see many use cases where other mechanisms are preferable, and it might be best to talk about that.  For instance, one might prefer something like this:

/users/
/users/admin/
/users/admin/security.txt
/users/alice/
/users/carol/

Or for file systems containing product code:

/products/vendor1/
/products/vendor1/product1/
/products/vendor1/product1/security.txt
/products/vendor1/product2/
/products/vendor1/product2/security.txt
/products/company2/
/products/company2/security.txt
/products/company2/productA/
/products/company2/productB/

I’m not suggesting a lot of text here, but just something to show that the SHOULD is talking about typical situations, and that there are other valid deployments.

I’ll also note that the example in Section 3.1 violates this recommendation.

— Section 5 —

  lang-values      =  lang-tag *(*WSP "," *WSP lang-tag)

Is there really a reason to allow WSP throughout the lang-tag entries?  Why not just have them packed together, as:

  lang-values      =  lang-tag *(“,”lang-tag)

…so you have << Preferred-Languages: en,es,fr >> ?  That just seems simpler, unless there’s real value in allowing the WSP.

  uri              =  < URI as per [RFC3986] >

3986 is big; I suggest “URI imported from Section 3 of [RFC3986]” to make it easier on the reader and to be consistent with the other definitions here.

— Section 6.1 —

  Security researchers should triage the "security.txt" file including
  verifying the digital signature and checking any available historical
  records before using the information contained in the file.

As above, “triage” is not the right word.  I think “validate” works here.

— Section 6.7 —

  To protect a "security.txt" file from being tampered with in transit,
  implementors should use HTTPS (as per [RFC2818]) when serving the
  file itself

Well, this is actually a MUST (rather than “should”) earlier in the draft.  It needs to be changed to “MUST” here in order to be consistent.

  invalid certificate, additional human triage is recommended since the
  contents may have been modified while in transit.

Again, “triage” is wrong: “validation” or “analysis” here.

— Section 6.8 —

  In addition, there is an increased likelihood of
  reports being sent in an automated fashion and/or as result of
  automated scans without human triage.

Again, “triage” is wrong: “analysis” here, I think.

  Organizations need to weigh the advantages of publishing this file
  versus the possible disadvantages and increased resources required to
  triage security reports.

“analyze”

— Section 7 —

At least the first two paragraphs are unnecessary (and I’m not sure the third is useful either, but it might have some value).

— Section 7.2 —

      *  deprecated: The field is in current use, but its use is
          discouraged

I suggest, “The field has been in use, but new usage is discouraged”

Please change all “change controller” instances to “IETF”, rather than “IESG”, as that’s the IESG’s preference for declaration of change control (the IESG is an agent of the IETF community).

[Ballot comment]
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 security@example.com
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
(https://tools.ietf.org/html/rfc3986#section-7.1).

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.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-foudil-securitytxt-08. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that upon approval of this document, there are two actions to be completed.

First, in the Well-Known URIs registry located at

https://www.iana.org/assignments/well-known-uris/

a single registration is to be made as follows:

URI Suffix: security.txt
Change Controller: IETF
Reference: [ RFC-to-be ]
Status: permanent
Related Information:
Date Registered: [ TBD-at-Registration ]
Date Modified:

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we have initiated the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Second, a new registry called "security.txt Header Fields" will be created.

IANA Question --> Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols?

IANA understands that the new registry will be managed via Expert Review as defined by [ RFC 8126 ].

There are initial registrations in the new registry:

Field Multiple Change
Name Description Appearances Status Reference Controller
-------------------+-------------------------------+------------+-----------+--------------+-----------
Acknowledgments link to page where security Yes current [ RFC-to-be ] IESG
researchers are recognized
Canonical canonical URL for this file No current [ RFC-to-be ] IESG
Contact contact information to use Yes current [ RFC-to-be ] IESG
for reporting vulnerabilities
Encryption link to a key to be used for Yes current [ RFC-to-be ] IESG
encrypted communication
Hiring link to the vendor's Yes current [ RFC-to-be ] IESG
security-related job positions
Policy link to security policy page Yes current [ RFC-to-be ] IESG
Preferred-Languages list of preferred languages No current [ RFC-to-be ] IESG
for security reports

The IANA Functions Operator understands that these are the only actions required upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Amanda Baber
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-01-06):

From: The IESG
To: IETF-Announce
CC: Kathleen.Moriarty.ietf@gmail.com, draft-foudil-securitytxt@ietf.org, kaduk@mit.edu
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (A Method for Web Security Policies) to Informational RFC


The IESG has received a request from an individual submitter to consider the
following document: - 'A Method for Web Security Policies'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-01-06. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  When security vulnerabilities are discovered by independent security
  researchers, they often lack the channels to report them properly.
  As a result, security vulnerabilities may be left unreported.  This
  document defines a format ("security.txt") to help organizations
  describe the process for security researchers to follow in order to
  report security vulnerabilities.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-foudil-securitytxt/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-foudil-securitytxt/ballot/


No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

An AD sponsored, informational RFC is requested and is noted in the title page header.  This is a process document and as such is an appropriate choice, although it does specify a protocol and could be experimental or standards track.  The process aspect using existing standards, while defining the format for a text file, lends this more towards informational.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  When security risks are discovered by independent security
  researchers, they often lack the channels to disclose them properly.
  As a result, security issues may be left unreported.  This document
  defines a standard ("security.txt") to help organizations describe
  the process for security researchers to follow in order to disclose
  security vulnerabilities securely.

Working Group Summary

  Was the document considered in any WG, and if so, why was
  it not adopted as a work item there? Was there controversy
  about particular points that caused the WG to not adopt the
  document?

  This is an AD sponsored draft and was discussed on the SAAG mailing list.  This draft was also presented at IETF 101 in the SecDispatch session, resulting in the consensus decision that this document go forward as an AD sponsored document.  There was quite a bit of discussion on the SAAG list and all technical comments seem to have been addressed.  There was one suggestion that RDAP might be better suited, saying that if the system were to be compromised , there would be no way of noticing if the security.txt had been modified (assuming new signature is placed on the file).  Otherwise, there was agreement to publish and there was active experiments to test this process early in the draft's history.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

There are active implementations of the security.txt file that were noted by reviewers of the draft on list in addition to the UK NCSC mentioned off-list. Contributors are mentioned by way of reference to the SAAG list.  There are a few that could merit being called out specifically as they did influence some positive updates to the draft.

Personnel

  Kathleen Moriarty is the Document Shepherd.  Benjamin Kaduk is the Responsible Area
  Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The shepherd provided a published technical review of the draft to the SAAG list.  Once that was addressed, the shepherd checked with authors/editors on knowledge of IPR finding xxxxx.  Next the shepherd reviewed all list communication on the draft to find that all actionable comments had been addressed.  The shepherd also reached out to Paul Woulters who was in opposition to this approach to solve the problem and found he remains not in favor. https://mailarchive.ietf.org/arch/msg/saag/WoVRqcqmWdbE4mZo42XHBCKb9vg

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No, it describes a text file.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the interested community has
discussed those issues and has indicated that it still wishes to advance
the document, detail those concerns here.

See above comments from Paul Woulters.  I do not see this as a reason to block publication as he prefers a different approach to solve the problem.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes, both authors have confirmed they are not aware of existing IPR.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any discussion and conclusion regarding the IPR
disclosures.

(9) How solid is the consensus of the interested community behind this
document? Does it represent the strong concurrence of a few individuals,
with others being silent, or does the interested community as a whole
understand and agree with it?

There is consensus to progress this informational document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

One error was found, a line was too long and the editors were asked to correct this issue.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No reviews necessary.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs
is discussed. If this information is not in the document, explain why
the interested community considers it unnecessary.

No. This document does not update any existing document.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

IANA is requested to create the "security.txt Header Fields" registry.  Additional entries require expert review.  Changes to the list of required entires requires an update to this document. There are no references to existing IANA registries.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

IANA is requested to create the "security.txt Header Fields" registry.  Additional entries require expert review.  Changes to the list of required entires requires an update to this document.

(19) Describe reviews and automated checks performed by to validate
sections of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, etc.

None.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

An AD sponsored, informational RFC is requested and is noted in the title page header.  This is a process document and as such is an appropriate choice, although it does specify a protocol and could be experimental or standards track.  The process aspect using existing standards, while defining the format for a text file, lends this more towards informational.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  When security risks are discovered by independent security
  researchers, they often lack the channels to disclose them properly.
  As a result, security issues may be left unreported.  This document
  defines a standard ("security.txt") to help organizations describe
  the process for security researchers to follow in order to disclose
  security vulnerabilities securely.

Working Group Summary

  Was the document considered in any WG, and if so, why was
  it not adopted as a work item there? Was there controversy
  about particular points that caused the WG to not adopt the
  document?

  This is an AD sponsored draft and was discussed on the SAAG mailing list.  This draft was also presented at IETF 101 in the SecDispatch session, resulting in the consensus decision that this document go forward as an AD sponsored document.  There was quite a bit of discussion on the SAAG list and all technical comments seem to have been addressed.  There was one suggestion that RDAP might be better suited, saying that if the system were to be compromised , there would be no way of noticing if the security.txt had been modified (assuming new signature is placed on the file).  Otherwise, there was agreement to publish and there was active experiments to test this process early in the draft's history.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

There are active implementations of the security.txt file that were noted by reviewers of the draft on list. Contributors are mentioned by way of reference to the SAAG list.  There are a few that could merit being called out specifically as they did influence some positive updates to the draft.

Personnel

  Kathleen Moriarty is the Document Shepherd.  Benjamin Kaduk is the Responsible Area
  Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The shepherd provided a published technical review of the draft to the SAAG list.  Once that was addressed, the shepherd checked with authors/editors on knowledge of IPR finding xxxxx.  Next the shepherd reviewed all list communication on the draft to find that all actionable comments had been addressed.  The shepherd also reached out to Paul Woulters who was in opposition to this approach to solve the problem and found he remains not in favor. https://mailarchive.ietf.org/arch/msg/saag/WoVRqcqmWdbE4mZo42XHBCKb9vg

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No, it describes a text file.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the interested community has
discussed those issues and has indicated that it still wishes to advance
the document, detail those concerns here.

See above comments from Paul Woulters.  I do not see this as a reason to block publication as he prefers a different approach to solve the problem.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes, both authors have confirmed they are not aware of existing IPR.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any discussion and conclusion regarding the IPR
disclosures.

(9) How solid is the consensus of the interested community behind this
document? Does it represent the strong concurrence of a few individuals,
with others being silent, or does the interested community as a whole
understand and agree with it?

There is consensus to progress this informational document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

One error was found, a line was too long and the editors were asked to correct this issue.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No reviews necessary.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs
is discussed. If this information is not in the document, explain why
the interested community considers it unnecessary.

No. This document does not update any existing document.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

IANA is requested to create the "security.txt Header Fields" registry.  Additional entries require expert review.  Changes to the list of required entires requires an update to this document. There are no references to existing IANA registries.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

IANA is requested to create the "security.txt Header Fields" registry.  Additional entries require expert review.  Changes to the list of required entires requires an update to this document.

(19) Describe reviews and automated checks performed by to validate
sections of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, etc.

None.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

An AD sponsored, informational RFC is requested and is noted in the title page header.  This is a process document and as such is an appropriate choice, although it does specify a protocol and could be experimental or standards track.  The process aspect using existing standards, while defining the format for a text file, lends this more towards informational.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  When security risks are discovered by independent security
  researchers, they often lack the channels to disclose them properly.
  As a result, security issues may be left unreported.  This document
  defines a standard ("security.txt") to help organizations describe
  the process for security researchers to follow in order to disclose
  security vulnerabilities securely.

Working Group Summary

  Was the document considered in any WG, and if so, why was
  it not adopted as a work item there? Was there controversy
  about particular points that caused the WG to not adopt the
  document?

  This is an AD sponsored draft and was discussed on the SAAG mailing list.  This draft was also presented at IETF 101 in the SecDispatch session, resulting in the consensus decision that this document go forward as an AD sponsored document.  There was quite a bit of discussion on the SAAG list and all technical comments seem to have been addressed.  There was one suggestion that RDAP might be better suited, saying that if the system were to be compromised , there would be no way of noticing if the security.txt had been modified (assuming new signature is placed on the file).  Otherwise, there was agreement to publish and there was active experiments to test this process early in the draft's history.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

There are active implementations of the security.txt file that were noted by reviewers of the draft on list. Contributors are mentioned by way of reference to the SAAG list.  There are a few that could merit being called out specifically as they did influence some positive updates to the draft.

Personnel

  Kathleen Moriarty is the Document Shepherd.  Benjamin Kaduk is the Responsible Area
  Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The shepherd provided a published technical review of the draft to the SAAG list.  Once that was addressed, the shepherd checked with authors/editors on knowledge of IPR finding xxxxx.  Next the shepherd reviewed all list communication on the draft to find that all actionable comments had been addressed.  The shepherd also reached out to Paul Woulters who was in opposition to this approach to solve the problem and found he remains not in favor. https://mailarchive.ietf.org/arch/msg/saag/WoVRqcqmWdbE4mZo42XHBCKb9vg

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No, it describes a text file.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the interested community has
discussed those issues and has indicated that it still wishes to advance
the document, detail those concerns here.

See above comments from Paul Woulters.  I do not see this as a reason to block publication as he prefers a different approach to solve the problem.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

xxxx

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any discussion and conclusion regarding the IPR
disclosures.

(9) How solid is the consensus of the interested community behind this
document? Does it represent the strong concurrence of a few individuals,
with others being silent, or does the interested community as a whole
understand and agree with it?

There is consensus to progress this informational document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

One error was found, a line was too long and the editors were asked to correct this issue.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No reviews necessary.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs
is discussed. If this information is not in the document, explain why
the interested community considers it unnecessary.

No. This document does not update any existing document.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

IANA is requested to create the "security.txt Header Fields" registry.  Additional entries require expert review.  Changes to the list of required entires requires an update to this document. There are no references to existing IANA registries.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

IANA is requested to create the "security.txt Header Fields" registry.  Additional entries require expert review.  Changes to the list of required entires requires an update to this document.

(19) Describe reviews and automated checks performed by to validate
sections of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, etc.

None.