Skip to main content

A File Format to Aid in Security Vulnerability Disclosure
RFC 9116

Revision differences

Document history

Date Rev. By Action
2022-05-06
12 (System) Received changes through RFC Editor sync (added Errata tag, added Verified Errata tag)
2022-04-28
12 (System) IANA registries were updated to include RFC9116
2022-04-27
12 (System)
Received changes through RFC Editor sync (created alias RFC 9116, changed abstract to 'When security vulnerabilities are discovered by researchers, proper reporting channels are …
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)
2022-04-27
12 (System) RFC published
2022-04-25
12 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2021-08-10
12 (System) RFC Editor state changed to AUTH48
2021-07-29
12 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2021-07-14
12 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2021-07-13
12 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2021-07-13
12 (System) IANA Action state changed to In Progress from Waiting on Authors
2021-07-13
12 (System) IANA Action state changed to Waiting on Authors from In Progress
2021-07-13
12 (System) IANA Action state changed to In Progress from Waiting on Authors
2021-07-13
12 (System) IANA Action state changed to Waiting on Authors from In Progress
2021-07-09
12 (System) RFC Editor state changed to EDIT
2021-07-09
12 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2021-07-09
12 (System) Announcement was received by RFC Editor
2021-07-09
12 (System) IANA Action state changed to In Progress
2021-07-09
12 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2021-07-09
12 Amy Vezza IESG has approved the document
2021-07-09
12 Amy Vezza Closed "Approve" ballot
2021-07-09
12 Amy Vezza Ballot approval text was generated
2021-07-08
12 Benjamin Kaduk IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2021-05-24
12 Lars Eggert [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss
2021-05-24
12 Roman Danyliw [Ballot Position Update] Position for Roman Danyliw has been changed to Yes from No Objection
2021-05-24
12 Roman Danyliw [Ballot comment]
(Updated for -12)
Thank you to Tero Kivinen for the SECDIR review.

Thank you for addressing some of the DISCUSS and COMMENT feedback.
2021-05-24
12 Roman Danyliw [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss
2021-05-24
12 Yakov Shafranovich New version available: draft-foudil-securitytxt-12.txt
2021-05-24
12 (System) New version approved
2021-05-24
12 (System) Request for posting confirmation emailed to previous authors: Edwin Foudil , Yakov Shafranovich
2021-05-24
12 Yakov Shafranovich Uploaded new revision
2021-05-13
11 Roman Danyliw
[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 …
[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?
2021-05-13
11 Roman Danyliw
[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. …
[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?
2021-05-13
11 Roman Danyliw Ballot comment and discuss text updated for Roman Danyliw
2021-04-22
11 Lars Eggert
[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 …
[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.
2021-04-22
11 Lars Eggert [Ballot Position Update] New position, Discuss, has been recorded for Lars Eggert
2021-04-22
11 Robert Wilton [Ballot Position Update] Position for Robert Wilton has been changed to No Objection from Discuss
2021-03-31
11 Murray Kucherawy
[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 …
[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.
2021-03-31
11 Murray Kucherawy [Ballot Position Update] Position for Murray Kucherawy has been changed to No Objection from Discuss
2021-03-11
11 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-03-11
11 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2021-03-11
11 Yakov Shafranovich New version available: draft-foudil-securitytxt-11.txt
2021-03-11
11 (System) New version approved
2021-03-11
11 (System) Request for posting confirmation emailed to previous authors: Edwin Foudil , Yakov Shafranovich
2021-03-11
11 Yakov Shafranovich Uploaded new revision
2021-01-24
10 Tero Kivinen Closed request for Telechat review by SECDIR with state 'Overtaken by Events'
2021-01-24
10 Tero Kivinen Assignment of request for Telechat review by SECDIR to Tero Kivinen was marked no-response
2021-01-22
10 Murray Kucherawy
[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 …
[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.
2021-01-22
10 Murray Kucherawy Ballot discuss text updated for Murray Kucherawy
2021-01-21
10 Murray Kucherawy
[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
  …
[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.
2021-01-21
10 Murray Kucherawy Ballot comment text updated for Murray Kucherawy
2021-01-21
10 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2021-01-21
10 Cindy Morgan Changed consensus to Yes from Unknown
2021-01-21
10 Alissa Cooper
[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 …
[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.
2021-01-21
10 Alissa Cooper
[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 …
[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.
2021-01-21
10 Alissa Cooper [Ballot Position Update] New position, Discuss, has been recorded for Alissa Cooper
2021-01-21
10 Robert Wilton
[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 …
[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
2021-01-21
10 Robert Wilton
[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 …
[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.
2021-01-21
10 Robert Wilton [Ballot Position Update] New position, Discuss, has been recorded for Robert Wilton
2021-01-20
10 Murray Kucherawy
[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 …
[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.
2021-01-20
10 Murray Kucherawy
[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. …
[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.
2021-01-20
10 Murray Kucherawy [Ballot Position Update] New position, Discuss, has been recorded for Murray Kucherawy
2021-01-20
10 Martin Duke [Ballot comment]
I support Roman's DISCUSS.
2021-01-20
10 Martin Duke [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke
2021-01-20
10 Roman Danyliw
[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 …
[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.
2021-01-20
10 Roman Danyliw Ballot discuss text updated for Roman Danyliw
2021-01-20
10 Roman Danyliw
[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 …
[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.
2021-01-20
10 Roman Danyliw
[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 …
[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.
2021-01-20
10 Roman Danyliw [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw
2021-01-20
10 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2021-01-20
10 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2021-01-20
10 Éric Vyncke
[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 …
[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 ;-)
2021-01-20
10 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2021-01-19
10 Barry Leiba
[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 …
[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?
2021-01-19
10 Barry Leiba
[Ballot comment]
— Section 3.3 —

  Every line MUST end either with a carriage return and line feed
  characters (CRLF / %x0D %x0A) …
[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).
2021-01-19
10 Barry Leiba [Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba
2021-01-16
10 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2021-01-15
10 Tero Kivinen Request for Telechat review by SECDIR is assigned to Tero Kivinen
2021-01-15
10 Tero Kivinen Request for Telechat review by SECDIR is assigned to Tero Kivinen
2021-01-14
10 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2021-01-13
10 Amy Vezza Placed on agenda for telechat - 2021-01-21
2021-01-12
10 Benjamin Kaduk
[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 …
[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.
2021-01-12
10 Benjamin Kaduk Ballot comment text updated for Benjamin Kaduk
2021-01-12
10 Benjamin Kaduk Ballot has been issued
2021-01-12
10 Benjamin Kaduk [Ballot Position Update] New position, Yes, has been recorded for Benjamin Kaduk
2021-01-12
10 Benjamin Kaduk Created "Approve" ballot
2021-01-12
10 Benjamin Kaduk IESG state changed to IESG Evaluation from Waiting for Writeup::AD Followup
2021-01-12
10 Benjamin Kaduk Ballot writeup was changed
2020-08-23
10 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-08-23
10 Yakov Shafranovich New version available: draft-foudil-securitytxt-10.txt
2020-08-23
10 (System) New version approved
2020-08-23
10 (System) Request for posting confirmation emailed to previous authors: Edwin Foudil , Yakov Shafranovich
2020-08-23
10 Yakov Shafranovich Uploaded new revision
2020-06-30
09 Benjamin Kaduk IESG state changed to Waiting for Writeup::Revised I-D Needed from Waiting for Writeup
2020-02-25
09 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2020-02-25
09 Yakov Shafranovich New version available: draft-foudil-securitytxt-09.txt
2020-02-25
09 (System) New version approved
2020-02-25
09 (System) Request for posting confirmation emailed to previous authors: Edwin Foudil , Yakov Shafranovich
2020-02-25
09 Yakov Shafranovich Uploaded new revision
2020-02-03
08 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'Overtaken by Events'
2020-01-19
08 Gunter Van de Velde Assignment of request for Last Call review by OPSDIR to Nagendra Kumar was marked no-response
2020-01-06
08 Amanda Baber IANA Experts State changed to Expert Reviews OK
2020-01-06
08 (System) IESG state changed to Waiting for Writeup from In Last Call
2019-12-24
08 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2019-12-24
08 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2019-12-24
08 Amanda Baber
(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 …
(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
2019-12-24
08 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Tero Kivinen. Sent review to list.
2019-12-17
08 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Nagendra Kumar
2019-12-17
08 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Nagendra Kumar
2019-12-16
08 Roni Even Request for Last Call review by GENART Completed: Ready. Reviewer: Roni Even. Sent review to list.
2019-12-12
08 Jean Mahoney Request for Last Call review by GENART is assigned to Roni Even
2019-12-12
08 Jean Mahoney Request for Last Call review by GENART is assigned to Roni Even
2019-12-12
08 Tero Kivinen Request for Last Call review by SECDIR is assigned to Tero Kivinen
2019-12-12
08 Tero Kivinen Request for Last Call review by SECDIR is assigned to Tero Kivinen
2019-12-09
08 Cindy Morgan IANA Review state changed to IANA - Review Needed
2019-12-09
08 Cindy Morgan
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: …
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.




2019-12-09
08 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2019-12-09
08 Benjamin Kaduk Last call was requested
2019-12-09
08 Benjamin Kaduk Last call announcement was generated
2019-12-09
08 Benjamin Kaduk Ballot approval text was generated
2019-12-09
08 Benjamin Kaduk Ballot writeup was generated
2019-12-09
08 Benjamin Kaduk IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2019-12-09
08 Kathleen Moriarty
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 …
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.

2019-11-19
08 (System) Sub state has been changed to AD Followup from Revised ID Needed
2019-11-19
08 Yakov Shafranovich New version available: draft-foudil-securitytxt-08.txt
2019-11-19
08 (System) New version approved
2019-11-19
08 (System) Request for posting confirmation emailed to previous authors: Edwin Foudil , Yakov Shafranovich
2019-11-19
08 Yakov Shafranovich Uploaded new revision
2019-09-27
07 Benjamin Kaduk IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2019-09-26
07 Benjamin Kaduk IESG state changed to AD Evaluation from Publication Requested
2019-09-26
07 Benjamin Kaduk Assigned to Security Area
2019-09-26
07 Benjamin Kaduk IESG process started in state Publication Requested
2019-09-22
07 Kathleen Moriarty Notification list changed to Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>, draft-foudil-securitytxt-all@tools.ietf.org from Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>
2019-09-22
07 Kathleen Moriarty
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 …
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.

2019-08-26
07 Kathleen Moriarty
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 …
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.

2019-07-21
07 Yakov Shafranovich New version available: draft-foudil-securitytxt-07.txt
2019-07-21
07 (System) New version approved
2019-07-21
07 (System) Request for posting confirmation emailed to previous authors: Edwin Foudil , Yakov Shafranovich
2019-07-21
07 Yakov Shafranovich Uploaded new revision
2019-04-08
06 Yakov Shafranovich New version available: draft-foudil-securitytxt-06.txt
2019-04-08
06 (System) New version approved
2019-04-08
06 (System) Request for posting confirmation emailed to previous authors: Edwin Foudil , Yakov Shafranovich
2019-04-08
06 Yakov Shafranovich Uploaded new revision
2019-01-12
05 Yakov Shafranovich New version available: draft-foudil-securitytxt-05.txt
2019-01-12
05 (System) New version approved
2019-01-12
05 (System) Request for posting confirmation emailed to previous authors: Edwin Foudil , Yakov Shafranovich
2019-01-12
05 Yakov Shafranovich Uploaded new revision
2018-08-23
04 Kathleen Moriarty Changed document writeup
2018-07-16
04 Edwin Foudil New version available: draft-foudil-securitytxt-04.txt
2018-07-16
04 (System) New version approved
2018-07-16
04 (System) Request for posting confirmation emailed to previous authors: Edwin Foudil , Yakov Shafranovich
2018-07-16
04 Edwin Foudil Uploaded new revision
2018-06-21
03 Benjamin Kaduk Shepherding AD changed to Benjamin Kaduk
2018-06-21
03 Benjamin Kaduk Notification list changed to Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>
2018-06-21
03 Benjamin Kaduk Document shepherd changed to Kathleen Moriarty
2018-06-21
03 Benjamin Kaduk Stream changed to IETF from None
2018-03-09
03 Roman Danyliw Added to session: IETF-101: secdispatch  Tue-0930
2018-02-09
03 Edwin Foudil New version available: draft-foudil-securitytxt-03.txt
2018-02-09
03 (System) New version approved
2018-02-09
03 (System) Request for posting confirmation emailed to previous authors: Edwin Foudil , Yakov Shafranovich
2018-02-09
03 Edwin Foudil Uploaded new revision
2017-12-27
02 Edwin Foudil New version available: draft-foudil-securitytxt-02.txt
2017-12-27
02 (System) New version approved
2017-12-27
02 (System) Request for posting confirmation emailed to previous authors: Edwin Foudil
2017-12-27
02 Edwin Foudil Uploaded new revision
2017-12-03
01 Edwin Foudil New version available: draft-foudil-securitytxt-01.txt
2017-12-03
01 (System) New version approved
2017-12-03
01 (System) Request for posting confirmation emailed to previous authors: Edwin Foudil
2017-12-03
01 Edwin Foudil Uploaded new revision
2017-09-19
00 Nevil Brownlee Stream changed to None from ISE
2017-09-13
00 Nevil Brownlee Intended Status changed to Informational from None
2017-09-13
00 Nevil Brownlee Stream changed to ISE from None
2017-09-10
00 Edwin Foudil New version available: draft-foudil-securitytxt-00.txt
2017-09-10
00 (System) New version approved
2017-09-10
00 Edwin Foudil Request for posting confirmation emailed  to submitter and authors: Edwin Foudil
2017-09-10
00 Edwin Foudil Uploaded new revision