Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Last call changes #183

Merged
merged 7 commits into from
Jan 30, 2020
Merged

Last call changes #183

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
1435fbb
last call changes
nightwatchcyber Dec 31, 2019
73b7401
last call changes
nightwatchcyber Dec 31, 2019
39a296d
more fixes
nightwatchcyber Jan 1, 2020
bcef5d3
fixes
nightwatchcyber Jan 5, 2020
26a3ea5
more last back fixes
nightwatchcyber Jan 6, 2020
8926a16
more lang fixes
nightwatchcyber Jan 6, 2020
28424b0
additional updates
nightwatchcyber Jan 20, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
29 changes: 15 additions & 14 deletions draft-foudil-securitytxt.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -317,7 +317,7 @@
<link href="#rfc.section.6.7" rel="Chapter" title="6.7 Spam and Spurious Reports">
<link href="#rfc.section.7" rel="Chapter" title="7 IANA Considerations">
<link href="#rfc.section.7.1" rel="Chapter" title="7.1 Well-Known URIs registry">
<link href="#rfc.section.7.2" rel="Chapter" title="7.2 Registry for security.txt Header Fields">
<link href="#rfc.section.7.2" rel="Chapter" title="7.2 Registry for security.txt Fields">
<link href="#rfc.section.8" rel="Chapter" title="8 Contributors">
<link href="#rfc.references" rel="Chapter" title="9 References">
<link href="#rfc.references.1" rel="Chapter" title="9.1 Normative References">
Expand All @@ -341,7 +341,7 @@

<meta name="dct.creator" content="Foudil, E. and Y. Shafranovich" />
<meta name="dct.identifier" content="urn:ietf:id:draft-foudil-securitytxt-09" />
<meta name="dct.issued" scheme="ISO8601" content="2020-01-05" />
<meta name="dct.issued" scheme="ISO8601" content="2020-01-06" />
<meta name="dct.abstract" content="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 (&#8220;security.txt&#8221;) to help organizations describe their vulnerability disclosure practices to make it easier for researchers to report security vulnerabilities." />
<meta name="description" content="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 (&#8220;security.txt&#8221;) to help organizations describe their vulnerability disclosure practices to make it easier for researchers to report security vulnerabilities." />

Expand All @@ -365,12 +365,12 @@
<td class="right">Y. Shafranovich</td>
</tr>
<tr>
<td class="left">Expires: July 8, 2020</td>
<td class="left">Expires: July 9, 2020</td>
<td class="right">Nightwatch Cybersecurity</td>
</tr>
<tr>
<td class="left"></td>
<td class="right">January 05, 2020</td>
<td class="right">January 06, 2020</td>
</tr>


Expand All @@ -386,7 +386,7 @@ <h1 id="rfc.status"><a href="#rfc.status">Status of This Memo</a></h1>
<p>This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.</p>
<p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.</p>
<p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."</p>
<p>This Internet-Draft will expire on July 8, 2020.</p>
<p>This Internet-Draft will expire on July 9, 2020.</p>
<h1 id="rfc.copyrightnotice"><a href="#rfc.copyrightnotice">Copyright Notice</a></h1>
<p>Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
<p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.</p>
Expand Down Expand Up @@ -466,7 +466,7 @@ <h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1>
</li>
<ul><li>7.1. <a href="#rfc.section.7.1">Well-Known URIs registry</a>
</li>
<li>7.2. <a href="#rfc.section.7.2">Registry for security.txt Header Fields</a>
<li>7.2. <a href="#rfc.section.7.2">Registry for security.txt Fields</a>
</li>
</ul><li>8. <a href="#rfc.section.8">Contributors</a>
</li>
Expand Down Expand Up @@ -530,15 +530,16 @@ <h1 id="rfc.section.3">
<a href="#rfc.section.3">3.</a> <a href="#the-specification" id="the-specification">The Specification</a>
</h1>
<p id="rfc.section.3.p.1">This document defines a text file to be placed in a known location that provides information about the vulnerability disclosure practices of a particular organization. This is intended to help security researchers when disclosing security vulnerabilities.</p>
<p id="rfc.section.3.p.2">The file is named &#8220;security.txt&#8221;, and this file MUST be placed under the /.well-known/ path (&#8220;/.well-known/security.txt&#8221;) <a href="#RFC8615" class="xref">[RFC8615]</a> of a domain name or IP address for web properties. For legacy compatibility, a security.txt file might be placed at the top level path (see <a href="#weblocation" class="xref">Section 4.1</a>).</p>
<p id="rfc.section.3.p.3">For web-based services, the file MUST be accessible via the Hypertext Transfer Protocol (HTTP) 1.0 <a href="#RFC1945" class="xref">[RFC1945]</a> or higher version, as a resource of Internet Media Type &#8220;text/plain&#8221; with the default charset parameter set to &#8220;utf-8&#8221; per section 4.1.3 of <a href="#RFC2046" class="xref">[RFC2046]</a>, and it MUST be served with &#8220;https&#8221; (as per section 2.7.2 of <a href="#RFC7230" class="xref">[RFC7230]</a>). For file systems a &#8220;security.txt&#8221; file SHOULD be placed in the root directory of a particular file system.</p>
<p id="rfc.section.3.p.4">This text file contains multiple fields with different values. A field contains a &#8220;name&#8221; which is the first part of a field all the way up to the colon (&#8220;Contact:&#8221;) and follows the syntax defined for &#8220;field-name&#8221; in section 3.6.8 of <a href="#RFC5322" class="xref">[RFC5322]</a>. Fields are case-insensitive (as per section 2.3 of <a href="#RFC5234" class="xref">[RFC5234]</a>). The &#8220;value&#8221; comes after the field name (&#8220;https://example.com/security&#8221;) and follows the syntax defined for &#8220;unstructured&#8221; in section 3.2.5 of <a href="#RFC5322" class="xref">[RFC5322]</a>.</p>
<p id="rfc.section.3.p.5">A &#8220;field&#8221; MUST always consist of a name and a value (&#8220;Contact: https://example.com/security&#8221;). A security.txt file can have an unlimited number of fields. It is important to note that each field MUST appear on its own line. Unless specified otherwise by the field definition, multiple values MUST NOT be chained together for a single field. Unless otherwise indicated in a definition of a particular field, any field MAY appear multiple times.</p>
<p id="rfc.section.3.p.6">Implementors should be aware that some of the fields may contain URIs using percent-encoding (as per section 2.1 of <a href="#RFC3986" class="xref">[RFC3986]</a>).</p>
<p id="rfc.section.3.p.2">By convention, the file is named &#8220;security.txt&#8221;.</p>
<p id="rfc.section.3.p.3">When made available on HTTP servers, it MUST be placed under the /.well-known/ path (as &#8220;/.well-known/security.txt&#8221;) <a href="#RFC8615" class="xref">[RFC8615]</a> of a domain name or IP address. For legacy compatibility, a security.txt file might be placed at the top level path (see <a href="#weblocation" class="xref">Section 4.1</a>). For file systems a &#8220;security.txt&#8221; file SHOULD be placed in the root directory of a particular file system.</p>
<p id="rfc.section.3.p.4">On HTTP servers, the file MUST be accessed via the Hypertext Transfer Protocol (HTTP) 1.0 <a href="#RFC1945" class="xref">[RFC1945]</a> or higher version and the &#8220;https&#8221; scheme (as per section 2.7.2 of <a href="#RFC7230" class="xref">[RFC7230]</a>). It MUST have a Content-Type of &#8220;text/plain&#8221; with the default charset parameter set to &#8220;utf-8&#8221; (as per section 4.1.3 of <a href="#RFC2046" class="xref">[RFC2046]</a>).</p>
<p id="rfc.section.3.p.5">This text file contains multiple fields with different values. A field contains a &#8220;name&#8221; which is the first part of a field all the way up to the colon (&#8220;Contact:&#8221;) and follows the syntax defined for &#8220;field-name&#8221; in section 3.6.8 of <a href="#RFC5322" class="xref">[RFC5322]</a>. Fields are case-insensitive (as per section 2.3 of <a href="#RFC5234" class="xref">[RFC5234]</a>). The &#8220;value&#8221; comes after the field name (&#8220;https://example.com/security&#8221;) and follows the syntax defined for &#8220;unstructured&#8221; in section 3.2.5 of <a href="#RFC5322" class="xref">[RFC5322]</a>.</p>
<p id="rfc.section.3.p.6">A &#8220;field&#8221; MUST always consist of a name and a value (&#8220;Contact: https://example.com/security&#8221;). A security.txt file can have an unlimited number of fields. It is important to note that each field MUST appear on its own line. Unless specified otherwise by the field definition, multiple values MUST NOT be chained together for a single field. Unless otherwise indicated in a definition of a particular field, any field MAY appear multiple times.</p>
<p id="rfc.section.3.p.7">Implementors should be aware that some of the fields may contain URIs using percent-encoding (as per section 2.1 of <a href="#RFC3986" class="xref">[RFC3986]</a>).</p>
<h1 id="rfc.section.3.1">
<a href="#rfc.section.3.1">3.1.</a> <a href="#scope-of-the-file" id="scope-of-the-file">Scope of the File</a>
</h1>
<p id="rfc.section.3.1.p.1">A &#8220;security.txt&#8221; file MUST only apply to the domain or IP address in the URI used to retrieve it, not to any of its subdomains or parent domains. A &#8220;security.txt&#8221; file that is found in a file system MUST only apply to the folder or repository in which it is located, and not to any of its parent or sibling folders, or repositories. However, it will apply to all subfolders.</p>
<p id="rfc.section.3.1.p.1">A &#8220;security.txt&#8221; file MUST only apply to the domain or IP address in the URI used to retrieve it, not to any of its subdomains or parent domains. A &#8220;security.txt&#8221; file that is found in a file system MUST only apply to the folder in which it is located, and not to any of its parent or sibling folders. However, it will apply to all subfolders.</p>
<p id="rfc.section.3.1.p.2">Some examples appear below:</p>
<pre>
# The following only applies to example.com.
Expand Down Expand Up @@ -862,9 +863,9 @@ <h1 id="rfc.section.7.1">
<p id="rfc.section.7.1.p.4">Specification document(s): this document</p>
<p id="rfc.section.7.1.p.5">Status: permanent</p>
<h1 id="rfc.section.7.2">
<a href="#rfc.section.7.2">7.2.</a> <a href="#registry" id="registry">Registry for security.txt Header Fields</a>
<a href="#rfc.section.7.2">7.2.</a> <a href="#registry" id="registry">Registry for security.txt Fields</a>
</h1>
<p id="rfc.section.7.2.p.1">IANA is requested to create the &#8220;security.txt Header Fields&#8221; registry in accordance with <a href="#RFC8126" class="xref">[RFC8126]</a>. This registry will contain header fields for use in security.txt files, defined by this specification.</p>
<p id="rfc.section.7.2.p.1">IANA is requested to create the &#8220;security.txt Fields&#8221; registry in accordance with <a href="#RFC8126" class="xref">[RFC8126]</a>. This registry will contain fields for use in security.txt files, defined by this specification.</p>
<p id="rfc.section.7.2.p.2">New registrations or updates MUST be published in accordance with the &#8220;Expert Review&#8221; guidelines as described in sections 4.5 and 5 of <a href="#RFC8126" class="xref">[RFC8126]</a>. Any new field thus registered is considered optional by this specification unless a new version of this specification is published.</p>
<p id="rfc.section.7.2.p.3">Designated Experts are expected to check whether a proposed registration or update makes sense in the context of industry accepted vulnerability disclosure processes such as <a href="#ISO.29147.2018" class="xref">[ISO.29147.2018]</a> and <a href="#CERT.CVD" class="xref">[CERT.CVD]</a>, and provides value to organizations and researchers using this format.</p>
<p id="rfc.section.7.2.p.4">New registrations and updates MUST contain the following information:</p>
Expand Down
23 changes: 14 additions & 9 deletions draft-foudil-securitytxt.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -94,11 +94,16 @@ This document defines a text file to be placed in a known location
that provides information about the vulnerability disclosure practices of a particular organization.
This is intended to help security researchers when disclosing security vulnerabilities.

The file is named "security.txt", and this file MUST be placed under the
/.well-known/ path ("/.well-known/security.txt") {{!RFC8615}} of a domain name or IP address for web
properties. For legacy compatibility, a security.txt file might be placed at the top level path (see {{weblocation}}).
By convention, the file is named "security.txt".

For web-based services, the file MUST be accessible via the Hypertext Transfer Protocol (HTTP) 1.0 {{!RFC1945}} or higher version, as a resource of Internet Media Type "text/plain" with the default charset parameter set to "utf-8" per section 4.1.3 of {{!RFC2046}}, and it MUST be served with "https" (as per section 2.7.2 of {{!RFC7230}}). For file systems a "security.txt" file SHOULD be placed in the root directory of a particular file system.
When made available on HTTP servers, it MUST be placed under the
/.well-known/ path (as "/.well-known/security.txt") {{!RFC8615}} of a domain name or IP address.
For legacy compatibility, a security.txt file might be placed at the top level path (see {{weblocation}}).
For file systems a "security.txt" file SHOULD be placed in the root directory of a particular file system.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
For file systems a "security.txt" file SHOULD be placed in the root directory of a particular file system.
For file systems a "security.txt" file SHOULD be placed in the root directory of the file system.

I do not think "particular" is needed here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done


On HTTP servers, the file MUST be accessed via the Hypertext Transfer Protocol (HTTP) 1.0 {{!RFC1945}} or higher version
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
On HTTP servers, the file MUST be accessed via the Hypertext Transfer Protocol (HTTP) 1.0 {{!RFC1945}} or higher version
On HTTP servers, the file MUST be accessed via the Hypertext Transfer Protocol (HTTP) 1.0 {{!RFC1945}} or a higher version

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

and the "https" scheme (as per section 2.7.2 of {{!RFC7230}}). It MUST have a Content-Type of "text/plain"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On HTTP servers, the file MUST be accessed via the Hypertext Transfer Protocol 1.0 or a higher version and the "https" scheme.

This sentence is quite difficult to follow. Especially with all the inline references. Might need rephrasing.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

reworded

with the default charset parameter set to "utf-8" (as per section 4.1.3 of {{!RFC2046}}).

This text file contains multiple fields with different values. A field contains a "name" which is the first part of a field all the way up
to the colon ("Contact:") and follows the syntax defined for "field-name" in section 3.6.8
Expand All @@ -122,8 +127,8 @@ contain URIs using percent-encoding (as per section 2.1 of {{!RFC3986}}).
A "security.txt" file MUST only apply to the domain or IP address in the URI used to retrieve it,
not to any of its subdomains or parent domains. A "security.txt" file that is found
in a file system MUST only apply to the folder
or repository in which it is located, and not to any of its parent or sibling folders,
or repositories. However, it will apply to all subfolders.
in which it is located, and not to any of its parent or sibling folders.
However, it will apply to all subfolders.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would reword this as follows:

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done


Some examples appear below:

Expand Down Expand Up @@ -631,10 +636,10 @@ Specification document(s): this document

Status: permanent

## Registry for security.txt Header Fields {#registry}
## Registry for security.txt Fields {#registry}

IANA is requested to create the "security.txt Header Fields" registry in
accordance with {{?RFC8126}}. This registry will contain header fields for
IANA is requested to create the "security.txt Fields" registry in
accordance with {{?RFC8126}}. This registry will contain fields for
use in security.txt files, defined by this specification.

New registrations or updates MUST be published in accordance with the
Expand Down