This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
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/.
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."
-This Internet-Draft will expire on September 25, 2019.
+This Internet-Draft will expire on October 9, 2019.
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
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.
@@ -520,10 +521,10 @@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.
-The file is named “security.txt”, and this file SHOULD be placed under the /.well-known/ path (“/.well-known/security.txt”) [RFC5785] 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 section Section 4.1).
-For web-based services, the file MUST be accessible via the Hypertext Transfer Protocol [RFC1945] 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 and version control repositories a “security.txt” file SHOULD be placed in the root directory of a particular file system or source code project.
+The file is named “security.txt”, and this file SHOULD be placed under the /.well-known/ path (“/.well-known/security.txt”) [RFC5785] 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 Section 4.1).
+For web-based services, the file MUST be accessible via the Hypertext Transfer Protocol (HTTP) [RFC1945] 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 and version control repositories a “security.txt” file SHOULD be placed in the root directory of a particular file system or source code project.
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 [RFC5322]. Directives MUST be case-insensitive (as per section 2.3 of [RFC5234]). The “value” comes after the directive (“https://example.com/security”) and follows the syntax defined for “unstructured” in section 3.2.5 of [RFC5322].
-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.
+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.
A separate line is REQUIRED for every new value and field. You MUST NOT chain everything into a single 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).
+A separate line is REQUIRED for every new value and 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).
It is RECOMMENDED that a security.txt file be digitally signed using an OpenPGP cleartext signature as described in section 7 of [RFC4880]. When digital signatures are used, it is also RECOMMENDED that implementors use the “Canonical” directive as per Section 3.5.2, thus allowing the digital signature to authenticate the location of the file.
+It is RECOMMENDED that a security.txt file be digitally signed using an OpenPGP cleartext signature as described in section 7 of [RFC4880]. When digital signatures are used, it is also RECOMMENDED that implementors use the “Canonical” directive (as per Section 3.5.2), thus allowing the digital signature to authenticate the location of the file.
When it comes to verifying the key used to generate the signature, it is always the security researcher’s responsibility to make sure the key being used is indeed one they trust.
This directive indicates the canonical URI where the security.txt file is located, which is usually something like “https://example.com/.well-known/security.txt”. If this directive indicates a web URL, then it MUST begin with “https://” (as per section 2.7.2 of [RFC7230]).
+This directive indicates the canonical URI where the security.txt file is located, which is usually something like “https://example.com/.well-known/security.txt”. If this directive indicates a web URL, then it MUST begin with “https://” (as per section 2.7.2 of [RFC7230]). The purpose of this directive is to allow a digital signature to be applied to the location of the “security.txt” file.
This directive MUST NOT appear more than once.
Canonical: https://example.com/.well-known/security.txt @@ -641,7 +642,7 @@
This directive can be used to indicate a set of natural languages that are preferred when submitting security reports. This set MAY list multiple values, separated by commas. If this directive is included then at least one value MUST be listed. The values within this set are language tags (as defined in [RFC5646]). If this directive is absent, security researchers MAY assume that English is the default language to be used (as per section 4.5 of [RFC2277]).
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 directive MUST NOT appear more than once.
-Example:
+Example (English, Spanish and French):
Preferred-Languages: en, es, fr@@ -696,7 +697,7 @@
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 [RFC5785]. A security.txt file located under the top-level path SHOULD either redirect (as per section 6.4 of [RFC7231]) to the security.txt file under the /.well-known/ path or be used as a fallback if the “.well-known” path cannot be used.
If retrieval of a “security.txt” file results in a redirect (as per section 6.4 of [RFC7231]), the implementors MUST NOT follow redirects that lead to another domain or subdomain but SHOULD follow redirects within the same domain name (but not different subdomain on the same domain).
-This does not apply to resource locations that appear within the file.
+The guidance regarding redirects SHOULD NOT apply to the resource locations that appear within the file.
4.2. Filesystems
diff --git a/draft-foudil-securitytxt.md b/draft-foudil-securitytxt.md index 15443a7..f956db8 100644 --- a/draft-foudil-securitytxt.md +++ b/draft-foudil-securitytxt.md @@ -85,9 +85,9 @@ in disclosing security vulnerabilities. The file is named "security.txt", and this file SHOULD be placed under the /.well-known/ path ("/.well-known/security.txt") {{!RFC5785}} 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 section {{weblocation}}). +of a given web domain or IP address ("/security.txt") as a fallback option (see {{weblocation}}). -For web-based services, the file MUST be accessible via the Hypertext Transfer Protocol {{!RFC1945}} 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 and version control repositories a "security.txt" file SHOULD be placed in the root directory of a particular file system or source code project. +For web-based services, the file MUST be accessible via the Hypertext Transfer Protocol (HTTP) {{!RFC1945}} 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 and version control repositories a "security.txt" file SHOULD be placed in the root directory of a particular file system or source code project. This text file contains multiple directives with different values. The "directive" is the first part of a field all the way up @@ -100,7 +100,7 @@ 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 +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. @@ -127,7 +127,7 @@ https://192.0.2.0/.well-known/security.txt # This security.txt file applies to IPv6 address of 2001:db8:8:4::2. https://[2001:db8:8:4::2]/.well-known/security.txt -# This security.txt file applies to the /example/folder1 directory. +# This security.txt file applies to the /example/folder1 directory and subfolders. /example/folder1/security.txt ~~~~~~~~~~ @@ -150,7 +150,7 @@ respective field. ## Separate Fields A separate line is REQUIRED for every new value and field. You MUST -NOT chain everything into a single field. Every line MUST end either +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). @@ -159,7 +159,7 @@ a line feed character (LF / %x0A). It is RECOMMENDED that a security.txt file be digitally signed using an OpenPGP cleartext signature as described in section 7 of {{!RFC4880}}. When digital signatures are used, it is also -RECOMMENDED that implementors use the "Canonical" directive as per {{canonical}}, +RECOMMENDED that implementors use the "Canonical" directive (as per {{canonical}}), thus allowing the digital signature to authenticate the location of the file. When it comes to verifying the key used to generate the signature, it is always @@ -202,7 +202,8 @@ We would like to thank the following researchers: This directive indicates the canonical URI where the security.txt file is located, which is usually something like "https://example.com/.well-known/security.txt". If this directive indicates a web URL, then it MUST begin with "https://" -(as per section 2.7.2 of {{!RFC7230}}). +(as per section 2.7.2 of {{!RFC7230}}). The purpose of this directive is to allow +a digital signature to be applied to the location of the "security.txt" file. This directive MUST NOT appear more than once. @@ -308,7 +309,7 @@ priority - rather these MUST BE interpreted as all being of equal priority. This directive MUST NOT appear more than once. -Example: +Example (English, Spanish and French): ~~~~~~~~~~ Preferred-Languages: en, es, fr @@ -371,7 +372,7 @@ redirects that lead to another domain or subdomain but SHOULD follow redirects within the same domain name (but not different subdomain on the same domain). -This does not apply to resource locations that appear within the file. +The guidance regarding redirects SHOULD NOT apply to the resource locations that appear within the file. ## Filesystems diff --git a/draft-foudil-securitytxt.txt b/draft-foudil-securitytxt.txt index 5ac61ba..f2732b1 100644 --- a/draft-foudil-securitytxt.txt +++ b/draft-foudil-securitytxt.txt @@ -5,8 +5,8 @@ Network Working Group E. Foudil Internet-Draft Intended status: Informational Y. Shafranovich -Expires: September 25, 2019 Nightwatch Cybersecurity - March 24, 2019 +Expires: October 9, 2019 Nightwatch Cybersecurity + April 07, 2019 A Method for Web Security Policies @@ -36,7 +36,7 @@ Status of This Memo time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on September 25, 2019. + This Internet-Draft will expire on October 9, 2019. Copyright Notice @@ -53,9 +53,9 @@ Copyright Notice -Foudil & Shafranovich Expires September 25, 2019 [Page 1] +Foudil & Shafranovich Expires October 9, 2019 [Page 1] -Internet-Draft A Method for Web Security Policies March 2019 +Internet-Draft A Method for Web Security Policies April 2019 the Trust Legal Provisions and are provided without warranty as @@ -109,9 +109,9 @@ Table of Contents -Foudil & Shafranovich Expires September 25, 2019 [Page 2] +Foudil & Shafranovich Expires October 9, 2019 [Page 2] -Internet-Draft A Method for Web Security Policies March 2019 +Internet-Draft A Method for Web Security Policies April 2019 B.2. Since draft-foudil-securitytxt-01 . . . . . . . . . . . . 20 @@ -165,9 +165,9 @@ Internet-Draft A Method for Web Security Policies March 2019 -Foudil & Shafranovich Expires September 25, 2019 [Page 3] +Foudil & Shafranovich Expires October 9, 2019 [Page 3] -Internet-Draft A Method for Web Security Policies March 2019 +Internet-Draft A Method for Web Security Policies April 2019 1.2. Terminology @@ -198,13 +198,13 @@ Internet-Draft A Method for Web Security Policies March 2019 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 section Section 4.1). + fallback option (see Section 4.1). For web-based services, the file MUST be accessible via the Hypertext - Transfer Protocol [RFC1945] 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 and version + Transfer Protocol (HTTP) [RFC1945] 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 and version control repositories a "security.txt" file SHOULD be placed in the root directory of a particular file system or source code project. @@ -221,16 +221,16 @@ Internet-Draft A Method for Web Security Policies March 2019 -Foudil & Shafranovich Expires September 25, 2019 [Page 4] +Foudil & Shafranovich Expires October 9, 2019 [Page 4] -Internet-Draft A Method for Web Security Policies March 2019 +Internet-Draft A Method for Web Security Policies April 2019 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. + 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. 3.1. Scope @@ -243,20 +243,20 @@ Internet-Draft A Method for Web Security Policies March 2019 Some examples appear below: - # The following only applies to example.com. - https://example.com/.well-known/security.txt +# The following only applies to example.com. +https://example.com/.well-known/security.txt - # This only applies to subdomain.example.com. - https://subdomain.example.com/.well-known/security.txt +# This only applies to subdomain.example.com. +https://subdomain.example.com/.well-known/security.txt - # This security.txt file applies to IPv4 address of 192.0.2.0. - https://192.0.2.0/.well-known/security.txt +# This security.txt file applies to IPv4 address of 192.0.2.0. +https://192.0.2.0/.well-known/security.txt - # This security.txt file applies to IPv6 address of 2001:db8:8:4::2. - https://[2001:db8:8:4::2]/.well-known/security.txt +# This security.txt file applies to IPv6 address of 2001:db8:8:4::2. +https://[2001:db8:8:4::2]/.well-known/security.txt - # This security.txt file applies to the /example/folder1 directory. - /example/folder1/security.txt +# This security.txt file applies to the /example/folder1 directory and subfolders. +/example/folder1/security.txt 3.2. Comments @@ -277,26 +277,27 @@ Internet-Draft A Method for Web Security Policies March 2019 -Foudil & Shafranovich Expires September 25, 2019 [Page 5] +Foudil & Shafranovich Expires October 9, 2019 [Page 5] -Internet-Draft A Method for Web Security Policies March 2019 +Internet-Draft A Method for Web Security Policies April 2019 3.3. Separate Fields A separate line is REQUIRED for every new value and field. You MUST - NOT chain everything into a single 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). + 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). 3.4. Digital signature It is RECOMMENDED that a security.txt file be digitally signed using an OpenPGP cleartext signature as described in section 7 of [RFC4880]. When digital signatures are used, it is also RECOMMENDED - that implementors use the "Canonical" directive as per Section 3.5.2, - thus allowing the digital signature to authenticate the location of - the file. + that implementors use the "Canonical" directive (as per + Section 3.5.2), thus allowing the digital signature to authenticate + the location of the file. When it comes to verifying the key used to generate the signature, it is always the security researcher's responsibility to make sure the @@ -332,10 +333,9 @@ Internet-Draft A Method for Web Security Policies March 2019 - -Foudil & Shafranovich Expires September 25, 2019 [Page 6] +Foudil & Shafranovich Expires October 9, 2019 [Page 6] -Internet-Draft A Method for Web Security Policies March 2019 +Internet-Draft A Method for Web Security Policies April 2019 3.5.2. Canonical @@ -344,7 +344,9 @@ Internet-Draft A Method for Web Security Policies March 2019 file is located, which is usually something like "https://example.com/.well-known/security.txt". If this directive indicates a web URL, then it MUST begin with "https://" (as per - section 2.7.2 of [RFC7230]). + section 2.7.2 of [RFC7230]). The purpose of this directive is to + allow a digital signature to be applied to the location of the + "security.txt" file. This directive MUST NOT appear more than once. @@ -387,11 +389,9 @@ Internet-Draft A Method for Web Security Policies March 2019 - - -Foudil & Shafranovich Expires September 25, 2019 [Page 7] +Foudil & Shafranovich Expires October 9, 2019 [Page 7] -Internet-Draft A Method for Web Security Policies March 2019 +Internet-Draft A Method for Web Security Policies April 2019 When it comes to verifying the authenticity of the key, it is always @@ -445,9 +445,9 @@ Encryption: dns:5d2d37ab76d47d36._openpgpkey.example.com?type=OPENPGPKEY -Foudil & Shafranovich Expires September 25, 2019 [Page 8] +Foudil & Shafranovich Expires October 9, 2019 [Page 8] -Internet-Draft A Method for Web Security Policies March 2019 +Internet-Draft A Method for Web Security Policies April 2019 The order in which they appear MUST NOT be interpreted as an @@ -456,7 +456,7 @@ Internet-Draft A Method for Web Security Policies March 2019 This directive MUST NOT appear more than once. - Example: + Example (English, Spanish and French): Preferred-Languages: en, es, fr @@ -501,9 +501,9 @@ Internet-Draft A Method for Web Security Policies March 2019 -Foudil & Shafranovich Expires September 25, 2019 [Page 9] +Foudil & Shafranovich Expires October 9, 2019 [Page 9] -Internet-Draft A Method for Web Security Policies March 2019 +Internet-Draft A Method for Web Security Policies April 2019 4. Location of the security.txt file @@ -523,8 +523,8 @@ Internet-Draft A Method for Web Security Policies March 2019 within the same domain name (but not different subdomain on the same domain). - This does not apply to resource locations that appear within the - file. + The guidance regarding redirects SHOULD NOT apply to the resource + locations that appear within the file. 4.2. Filesystems @@ -557,9 +557,9 @@ Internet-Draft A Method for Web Security Policies March 2019 -Foudil & Shafranovich Expires September 25, 2019 [Page 10] +Foudil & Shafranovich Expires October 9, 2019 [Page 10] -Internet-Draft A Method for Web Security Policies March 2019 +Internet-Draft A Method for Web Security Policies April 2019 In general, implementors SHOULD "be conservative in what you do, be @@ -613,9 +613,9 @@ Internet-Draft A Method for Web Security Policies March 2019 -Foudil & Shafranovich Expires September 25, 2019 [Page 11] +Foudil & Shafranovich Expires October 9, 2019 [Page 11] -Internet-Draft A Method for Web Security Policies March 2019 +Internet-Draft A Method for Web Security Policies April 2019 hiring-field = "Hiring" fs SP uri @@ -669,9 +669,9 @@ Internet-Draft A Method for Web Security Policies March 2019 -Foudil & Shafranovich Expires September 25, 2019 [Page 12] +Foudil & Shafranovich Expires October 9, 2019 [Page 12] -Internet-Draft A Method for Web Security Policies March 2019 +Internet-Draft A Method for Web Security Policies April 2019 Organizations SHOULD ensure that information in this file and any @@ -725,9 +725,9 @@ Internet-Draft A Method for Web Security Policies March 2019 -Foudil & Shafranovich Expires September 25, 2019 [Page 13] +Foudil & Shafranovich Expires October 9, 2019 [Page 13] -Internet-Draft A Method for Web Security Policies March 2019 +Internet-Draft A Method for Web Security Policies April 2019 6.6. Protecting Data in Transit @@ -781,9 +781,9 @@ Internet-Draft A Method for Web Security Policies March 2019 -Foudil & Shafranovich Expires September 25, 2019 [Page 14] +Foudil & Shafranovich Expires October 9, 2019 [Page 14] -Internet-Draft A Method for Web Security Policies March 2019 +Internet-Draft A Method for Web Security Policies April 2019 URI suffix: security.txt @@ -837,9 +837,9 @@ Internet-Draft A Method for Web Security Policies March 2019 -Foudil & Shafranovich Expires September 25, 2019 [Page 15] +Foudil & Shafranovich Expires October 9, 2019 [Page 15] -Internet-Draft A Method for Web Security Policies March 2019 +Internet-Draft A Method for Web Security Policies April 2019 Field Name: Acknowledgments @@ -893,9 +893,9 @@ Internet-Draft A Method for Web Security Policies March 2019 -Foudil & Shafranovich Expires September 25, 2019 [Page 16] +Foudil & Shafranovich Expires October 9, 2019 [Page 16] -Internet-Draft A Method for Web Security Policies March 2019 +Internet-Draft A Method for Web Security Policies April 2019 The authors would also like to acknowledge the feedback provided by @@ -949,9 +949,9 @@ Internet-Draft A Method for Web Security Policies March 2019 -Foudil & Shafranovich Expires September 25, 2019 [Page 17] +Foudil & Shafranovich Expires October 9, 2019 [Page 17] -Internet-Draft A Method for Web Security Policies March 2019 +Internet-Draft A Method for Web Security Policies April 2019 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network @@ -1005,9 +1005,9 @@ Internet-Draft A Method for Web Security Policies March 2019 -Foudil & Shafranovich Expires September 25, 2019 [Page 18] +Foudil & Shafranovich Expires October 9, 2019 [Page 18] -Internet-Draft A Method for Web Security Policies March 2019 +Internet-Draft A Method for Web Security Policies April 2019 9.2. Informative References @@ -1061,9 +1061,9 @@ Appendix A. Note to Readers -Foudil & Shafranovich Expires September 25, 2019 [Page 19] +Foudil & Shafranovich Expires October 9, 2019 [Page 19] -Internet-Draft A Method for Web Security Policies March 2019 +Internet-Draft A Method for Web Security Policies April 2019 Appendix B. Document History @@ -1117,9 +1117,9 @@ B.2. Since draft-foudil-securitytxt-01 -Foudil & Shafranovich Expires September 25, 2019 [Page 20] +Foudil & Shafranovich Expires October 9, 2019 [Page 20] -Internet-Draft A Method for Web Security Policies March 2019 +Internet-Draft A Method for Web Security Policies April 2019 B.3. Since draft-foudil-securitytxt-02 @@ -1173,9 +1173,9 @@ B.5. Since draft-foudil-securitytxt-04 -Foudil & Shafranovich Expires September 25, 2019 [Page 21] +Foudil & Shafranovich Expires October 9, 2019 [Page 21] -Internet-Draft A Method for Web Security Policies March 2019 +Internet-Draft A Method for Web Security Policies April 2019 o Removed permission directive (#30) @@ -1229,4 +1229,4 @@ Authors' Addresses -Foudil & Shafranovich Expires September 25, 2019 [Page 22] +Foudil & Shafranovich Expires October 9, 2019 [Page 22]