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." />
335
335
<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." />
336
336
@@ -354,12 +354,12 @@
354
354
<tdclass="right">Y. Shafranovich</td>
355
355
</tr>
356
356
<tr>
357
-
<tdclass="left">Expires: July 15, 2019</td>
357
+
<tdclass="left">Expires: July 16, 2019</td>
358
358
<tdclass="right">Nightwatch Cybersecurity</td>
359
359
</tr>
360
360
<tr>
361
361
<tdclass="left"></td>
362
-
<tdclass="right">January 11, 2019</td>
362
+
<tdclass="right">January 12, 2019</td>
363
363
</tr>
364
364
365
365
@@ -375,7 +375,7 @@ <h1 id="rfc.status"><a href="#rfc.status">Status of This Memo</a></h1>
375
375
<p>This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.</p>
376
376
<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>
377
377
<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>
378
-
<p>This Internet-Draft will expire on July 15, 2019.</p>
378
+
<p>This Internet-Draft will expire on July 16, 2019.</p>
<p>Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
381
381
<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>
@@ -498,7 +498,8 @@ <h1 id="rfc.section.3">
498
498
</h1>
499
499
<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>
500
500
<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 fall back option. For web-based services, the file MUST be accessible via the Hypertext Transfer Protocol <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 is RECOMMENDED that this file 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>
501
-
<pid="rfc.section.3.p.3">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:”). 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”). 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 and everything MUST be in a separate field. Unless otherwise indicated in a definition of a particular field, any directive MAY appear multiple times.</p>
501
+
<pid="rfc.section.3.p.3">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>
502
+
<pid="rfc.section.3.p.4">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 and everything MUST be in a separate field. Unless otherwise indicated in a definition of a particular field, any directive MAY appear multiple times.</p>
<pid="rfc.section.3.5.3.p.1">This directive allows you to provide an address that researchers SHOULD use for reporting security vulnerabilities. The value MAY be an email address, a phone number and/or a web page with contact information. The “Contact:” directive MUST always be present in a security.txt file. If this directive indicates a web URL, then it RECOMMENDED that it begins with “https://” (as per section 2.7.2 of <ahref="#RFC7230" class="xref">[RFC7230]</a>). Security email addresses SHOULD use the conventions defined in section 4 of <ahref="#RFC2142" class="xref">[RFC2142]</a>.</p>
573
-
<pid="rfc.section.3.5.3.p.2">The value MUST follow the general syntax described in <ahref="#RFC3986" class="xref">[RFC3986]</a>. This means that “mailto” and “tel” URI schemes MUST be used when specifying email addresses and telephone numbers.</p>
574
+
<pid="rfc.section.3.5.3.p.2">The value MUST follow the URI syntax described in <ahref="#RFC3986" class="xref">[RFC3986]</a>. This means that “mailto” and “tel” URI schemes MUST be used when specifying email addresses and telephone numbers, as defined in <ahref="#RFC6068" class="xref">[RFC6068]</a> and <ahref="#RFC3966" class="xref">[RFC3966]</a>.</p>
574
575
<pid="rfc.section.3.5.3.p.3">The precedence SHOULD be in listed order. The first field is the preferred method of contact. In the example below, the e-mail address is the preferred method of contact.</p>
<pid="rfc.section.5.p.1">The expected file format of the security.txt file is plain text (MIME type “text/plain”) as defined in section 4.1.3 of <ahref="#RFC2046" class="xref">[RFC2046]</a> and is encoded using UTF-8 <ahref="#RFC3629" class="xref">[RFC3629]</a> in Net-Unicode form <ahref="#RFC5198" class="xref">[RFC5198]</a>.</p>
719
720
<pid="rfc.section.5.p.2">The following is an ABNF definition of the security.txt format, using the conventions defined in <ahref="#RFC5234" class="xref">[RFC5234]</a>.</p>
720
721
<pre>
721
-
body = signed / unsigned
722
+
body = signed / unsigned
722
723
723
-
signed = sign-header unsigned sign-footer
724
+
signed = sign-header unsigned sign-footer
724
725
725
-
sign-header = <OpenPGP headers and empty line as per section 7 of {{RFC4880}}>
726
+
sign-header = <headers and line from section 7 of [RFC4880]>
726
727
727
-
sign-footer = <OpenPGP ASCII armored signature as per section 7 of {{RFC4880}}>
728
+
sign-footer = <OpenPGP signature from section 7 of [RFC4880]>
field-name= <imported from section 3.6.8 of [RFC5322]>
769
770
770
-
field-name = <as per section 3.6.8 of {{RFC5322}}>
771
-
772
-
unstructured = <as per section 3.2.5 of {{RFC5322}}>
771
+
unstructured = <imported from section 3.2.5 of [RFC5322]>
773
772
</pre>
774
773
<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>
775
774
<h1id="rfc.section.6">
@@ -821,7 +820,7 @@ <h1 id="rfc.section.7.2">
821
820
Status: current
822
821
823
822
Field Name: Contact
824
-
Description: contact information to use for reporting security vulnerabilities
823
+
Description: contact information to use for reporting vulnerabilities
825
824
Multiple Appearances: Yes
826
825
Published in: this document
827
826
Status: current
@@ -931,6 +930,11 @@ <h1 id="rfc.references.1">
931
930
<a>Nottingham, M.</a> and <a>E. Hammer-Lahav</a>, "<ahref="https://tools.ietf.org/html/rfc5785">Defining Well-Known Uniform Resource Identifiers (URIs)</a>", RFC 5785, DOI 10.17487/RFC5785, April 2010.</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>
<a>Fielding, R.</a> and <a>J. Reschke</a>, "<ahref="https://tools.ietf.org/html/rfc7230">Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</a>", RFC 7230, DOI 10.17487/RFC7230, June 2014.</td>
0 commit comments