You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<metaname="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 (“security.txt”) to help organizations describe the process for security researchers to follow in order to report security vulnerabilities." />
344
344
<metaname="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 (“security.txt”) to help organizations describe the process for security researchers to follow in order to report security vulnerabilities." />
345
345
@@ -363,12 +363,12 @@
363
363
<tdclass="right">Y. Shafranovich</td>
364
364
</tr>
365
365
<tr>
366
-
<tdclass="left">Expires: December 18, 2019</td>
366
+
<tdclass="left">Expires: January 17, 2020</td>
367
367
<tdclass="right">Nightwatch Cybersecurity</td>
368
368
</tr>
369
369
<tr>
370
370
<tdclass="left"></td>
371
-
<tdclass="right">June 16, 2019</td>
371
+
<tdclass="right">July 16, 2019</td>
372
372
</tr>
373
373
374
374
@@ -384,7 +384,7 @@ <h1 id="rfc.status"><a href="#rfc.status">Status of This Memo</a></h1>
384
384
<p>This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.</p>
385
385
<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>
386
386
<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>
387
-
<p>This Internet-Draft will expire on December 18, 2019.</p>
387
+
<p>This Internet-Draft will expire on January 17, 2020.</p>
<p>Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
390
390
<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>
<pid="rfc.section.3.p.1">This document defines a text file to be placed in a known location that provides information for security researchers to assist in disclosing security vulnerabilities.</p>
527
-
<pid="rfc.section.3.p.2">The file is named “security.txt”, and this file SHOULD be placed under the /.well-known/ path (“/.well-known/security.txt”) <ahref="#RFC5785" class="xref">[RFC5785]</a> of a domain name or IP address for web properties. If it is not possible to place the security.txt file in the /.well-known/ path or setup a redirect, web-based services MAY place the file in the top-level path of a given web domain or IP address (“/security.txt”) as a fallback option (see <ahref="#weblocation" class="xref">Section 4.1</a>).</p>
527
+
<pid="rfc.section.3.p.2">The file is named “security.txt”, and this file SHOULD be placed under the /.well-known/ path (“/.well-known/security.txt”) <ahref="#RFC8615" class="xref">[RFC8615]</a> of a domain name or IP address for web properties. If it is not possible to place the security.txt file in the /.well-known/ path or setup a redirect, web-based services MAY place the file in the top-level path of a given web domain or IP address (“/security.txt”) as a fallback option (see <ahref="#weblocation" class="xref">Section 4.1</a>).</p>
528
528
<pid="rfc.section.3.p.3">For web-based services, the file MUST be accessible via the Hypertext Transfer Protocol (HTTP) <ahref="#RFC1945" class="xref">[RFC1945]</a> as a resource of Internet Media Type “text/plain” with the default charset parameter set to “utf-8” per section 4.1.3 of <ahref="#RFC2046" class="xref">[RFC2046]</a>, and it MUST be served with “https” (as per section 2.7.2 of <ahref="#RFC7230" class="xref">[RFC7230]</a>). For file systems and version control repositories a “security.txt” file SHOULD be placed in the root directory of a particular file system or source code project.</p>
529
529
<pid="rfc.section.3.p.4">This text file contains multiple directives with different values. The “directive” 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 of <ahref="#RFC5322" class="xref">[RFC5322]</a>. Directives MUST be case-insensitive (as per section 2.3 of <ahref="#RFC5234" class="xref">[RFC5234]</a>). The “value” comes after the directive (“https://example.com/security”) and follows the syntax defined for “unstructured” in section 3.2.5 of <ahref="#RFC5322" class="xref">[RFC5322]</a>.</p>
530
530
<pid="rfc.section.3.p.5">A “field” MUST always consist of a directive and a value (“Contact: https://example.com/security”). A security.txt file can have an unlimited number of fields. It is important to note that you MUST have a separate line for every field. One MUST NOT chain multiple values for a single directive unless it is explicitly defined by that particular field. Unless otherwise indicated in a definition of a particular field, any directive MAY appear multiple times.</p>
@@ -546,7 +546,7 @@ <h1 id="rfc.section.3.1">
546
546
# This security.txt file applies to IPv6 address of 2001:db8:8:4::2.
# This security.txt file applies to the /example/folder1 directory and subfolders.
549
+
# This file applies to the /example/folder1 directory and subfolders.
550
550
/example/folder1/security.txt
551
551
</pre>
552
552
<h1id="rfc.section.3.2">
@@ -557,11 +557,11 @@ <h1 id="rfc.section.3.2">
557
557
<pre>
558
558
# This is a comment.
559
559
</pre>
560
-
<pid="rfc.section.3.2.p.3">You MAY use one or more comments as descriptive text immediately before the field. Parsers SHOULD associate the comments with the respective field.</p>
560
+
<pid="rfc.section.3.2.p.3">You MAY use one or more comments as descriptive text immediately before the field. Parsers SHOULD associate the comments with the respective field. Only the line most immediately preceding a field SHOULD be associated with that field.</p>
<pid="rfc.section.3.3.p.1">A separate line is REQUIRED for every field. You MUST NOT chain everything into a single field unless defined by that field. Every line MUST end either with a carriage return and line feed characters (CRLF / %x0D %x0A) or just a line feed character (LF / %x0A).</p>
564
+
<pid="rfc.section.3.3.p.1">A separate line is REQUIRED for every new field. You MUST NOT chain everything into a single field unless defined by that field. Every line MUST end either with a carriage return and line feed characters (CRLF / %x0D %x0A) or just a line feed character (LF / %x0A).</p>
<pid="rfc.section.4.1.p.1">Web-based services SHOULD place the security.txt file under the /.well-known/ path; e.g. https://example.com/.well-known/security.txt as per <ahref="#RFC5785" class="xref">[RFC5785]</a>. A security.txt file located under the top-level path SHOULD either redirect (as per section 6.4 of <ahref="#RFC7231" class="xref">[RFC7231]</a>) to the security.txt file under the /.well-known/ path or be used as a fallback if the “.well-known” path cannot be used.</p>
701
+
<pid="rfc.section.4.1.p.1">Web-based services SHOULD place the security.txt file under the /.well-known/ path; e.g. https://example.com/.well-known/security.txt as per <ahref="#RFC8615" class="xref">[RFC8615]</a>. A security.txt file located under the top-level path SHOULD either redirect (as per section 6.4 of <ahref="#RFC7231" class="xref">[RFC7231]</a>) to the security.txt file under the /.well-known/ path or be used as a fallback if the “.well-known” path cannot be used.</p>
702
702
<pid="rfc.section.4.1.p.2">If retrieval of a “security.txt” file from the top-level path results in a redirect (as per section 6.4 of <ahref="#RFC7231" class="xref">[RFC7231]</a>), the implementors MUST NOT follow that redirect if it leads to another domain or subdomain but SHOULD follow that redirect within the same domain name (but not different subdomain on the same domain).</p>
703
703
<pid="rfc.section.4.1.p.3">The guidance regarding redirects SHOULD NOT apply to the resource locations that appear within the file.</p>
704
704
<h1id="rfc.section.4.2">
@@ -732,9 +732,9 @@ <h1 id="rfc.section.5">
732
732
733
733
signed = sign-header unsigned sign-footer
734
734
735
-
sign-header = <headers and line from section 7 of [RFC4880]>
735
+
sign-header = <headers and line from section 7 of [RFC4880]>
736
736
737
-
sign-footer = <OpenPGP signature from section 7 of [RFC4880]>
737
+
sign-footer = <OpenPGP signature from section 7 of [RFC4880]>
lang-tag = <Language-Tag from section 2.1 of [RFC5646]>
763
+
lang-tag = <Language-Tag from section 2.1 of [RFC5646]>
764
764
765
-
uri = <URI as per [RFC3986]>
765
+
uri = <URI as per [RFC3986]>
766
766
767
767
encryption-field = "Encryption" fs SP uri
768
768
@@ -776,14 +776,15 @@ <h1 id="rfc.section.5">
776
776
777
777
ext-field = field-name fs SP unstructured
778
778
779
-
field-name = <imported from section 3.6.8 of [RFC5322]>
779
+
field-name = <imported from section 3.6.8 of [RFC5322]>
780
780
781
-
unstructured = <imported from section 3.2.5 of [RFC5322]>
781
+
unstructured = <imported from section 3.2.5 of [RFC5322]>
782
782
</pre>
783
783
<pid="rfc.section.5.p.3">“ext-field” refers to extension fields, which are discussed in <ahref="#extensibility" class="xref">Section 4.4</a></p>
<pid="rfc.section.6.p.1">Implementors SHOULD review this section as well as the security considerations section of <ahref="#RFC8615" class="xref">[RFC8615]</a>.</p>
787
788
<h1id="rfc.section.6.1">
788
789
<ahref="#rfc.section.6.1">6.1.</a><ahref="#compromised-files-and-redirects" id="compromised-files-and-redirects">Compromised Files and Redirects</a>
<pid="rfc.section.7.1.p.1">The “Well-Known URIs” registry should be updated with the following additional values (using the template from <ahref="#RFC5785" class="xref">[RFC5785]</a>):</p>
834
+
<pid="rfc.section.7.1.p.1">The “Well-Known URIs” registry should be updated with the following additional values (using the template from <ahref="#RFC8615" class="xref">[RFC8615]</a>):</p>
<pid="rfc.section.7.1.p.4">Specification document(s): this document</p>
838
+
<pid="rfc.section.7.1.p.5">Status: permanent</p>
837
839
<h1id="rfc.section.7.2">
838
840
<ahref="#rfc.section.7.2">7.2.</a><ahref="#registry" id="registry">Registry for security.txt Header Fields</a>
839
841
</h1>
@@ -970,11 +972,6 @@ <h1 id="rfc.references.1">
970
972
<a>Phillips, A.</a> and <a>M. Davis</a>, "<ahref="https://tools.ietf.org/html/rfc5646">Tags for Identifying Languages</a>", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009.</td>
<a>Duerst, M.</a>, <a>Masinter, L.</a> and <a>J. Zawinski</a>, "<ahref="https://tools.ietf.org/html/rfc6068">The 'mailto' URI Scheme</a>", RFC 6068, DOI 10.17487/RFC6068, October 2010.</td>
@@ -999,6 +996,11 @@ <h1 id="rfc.references.1">
999
996
<tdclass="top">
1000
997
<a>Leiba, B.</a>, "<ahref="https://tools.ietf.org/html/rfc8174">Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</a>", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.</td>
Copy file name to clipboardExpand all lines: draft-foudil-securitytxt.md
+21-12Lines changed: 21 additions & 12 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -83,7 +83,7 @@ that provides information for security researchers to assist
83
83
in disclosing security vulnerabilities.
84
84
85
85
The file is named "security.txt", and this file SHOULD be placed under the
86
-
/.well-known/ path ("/.well-known/security.txt") {{!RFC5785}} of a domain name or IP address for web
86
+
/.well-known/ path ("/.well-known/security.txt") {{!RFC8615}} of a domain name or IP address for web
87
87
properties. If it is not possible to place the security.txt file in the /.well-known/ path or setup a redirect, web-based services MAY place the file in the top-level path
88
88
of a given web domain or IP address ("/security.txt") as a fallback option (see {{weblocation}}).
0 commit comments