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”) [RFC8615] 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].
+
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 are 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 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 directive. Unless otherwise indicated in a definition of a particular field, any directive MAY appear multiple times.
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.
+
One or more comments MAY be used 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.
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).
+
Every line MUST end either with a carriage return and line feed characters (CRLF / %x0D %x0A) or just a line feed character (LF / %x0A).
This directive allows you to link to a page where security researchers are recognized for their reports. The page being linked to SHOULD list individuals or organizations that reported security vulnerabilities and worked with you to remediate the issue. Organizations SHOULD be careful to limit the vulnerability information being published in order to prevent future attacks.
+
This directive indicates a link to a page where security researchers are recognized for their reports. The page being referenced SHOULD list individuals or organizations that reported security vulnerabilities and collaborated to remediate them. Organizations SHOULD be careful to limit the vulnerability information being published in order to prevent future attacks.
If this directive indicates a web URL, then it MUST begin with “https://” (as per section 2.7.2 of [RFC7230]).
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 MUST begin with “https://” (as per section 2.7.2 of [RFC7230]). Security email addresses SHOULD use the conventions defined in section 4 of [RFC2142].
+
This directive indicates 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 MUST begin with “https://” (as per section 2.7.2 of [RFC7230]). Security email addresses SHOULD use the conventions defined in section 4 of [RFC2142].
The value MUST follow the URI syntax described in [RFC3986]. This means that “mailto” and “tel” URI schemes MUST be used when specifying email addresses and telephone numbers, as defined in [RFC6068] and [RFC3966]. When the value of this directive is an email address, it is RECOMMENDED that encryption be used (as per Section 3.5.4).
The precedence SHOULD be in listed order. The first field is the preferred method of contact. In the example below, the email address is the preferred method of contact.
This directive allows you to point to an encryption key that security researchers SHOULD use for encrypted communication. You MUST NOT directly add your key to the field, instead the value of this field MUST be a URI pointing to a location where the key can be retrieved. If this directive indicates a web URL, then it MUST begin with “https://” (as per section 2.7.2 of [RFC7230]).
+
This directive indicates an encryption key that security researchers SHOULD use for encrypted communication. Keys MUST NOT appear in this field - instead the value of this field MUST be a URI pointing to a location where the key can be retrieved. If this directive indicates a web URL, then it MUST begin with “https://” (as per section 2.7.2 of [RFC7230]).
When it comes to verifying the authenticity of the key, it is always the security researcher’s responsibility to make sure the key being specified is indeed one they trust. Researchers MUST NOT assume that this key is used to generate the digital signature referenced in Section 3.4.
Example of an OpenPGP key available from a web server:
This directive allows you to link to where your security policy and/or disclosure policy is located. This can help security researchers understand what you are looking for and how to report security vulnerabilities. If this directive indicates a web URL, then it MUST begin with “https://” (as per section 2.7.2 of [RFC7230]).
+
This directive indicates a link to where the security policy and/or disclosure policy is located. This can help security researchers understand what an organization is looking for and how to report security vulnerabilities. If this directive indicates a web URL, then it MUST begin with “https://” (as per section 2.7.2 of [RFC7230]).
A “security.txt” file SHOULD be placed in the root directory of an internal host.
+
An internal host is “a host served by a NAT gateway, or protected by a firewall” (as per section 3 of [RFC6887]) and might not be accessible directly from the Internet. On such systems, a “security.txt” file SHOULD be placed in the root directory.
If information and resources referenced in a “security.txt” file are incorrect or not kept up to date, this can result in security reports not being received by the organization or sent to incorrect contacts, thus exposing possible security issues to third parties.
+
If information and resources referenced in a “security.txt” file are incorrect or not kept up to date, this can result in security reports not being received by the organization or sent to incorrect contacts, thus exposing possible security issues to third parties. Not having a security.txt file may be preferable to having stale information in this file.
Organizations SHOULD ensure that information in this file and any referenced resources such as web pages, email addresses and telephone numbers are kept current, are accessible, controlled by the organization, and are kept secure.
The presence of a security.txt file might be interpreted by researchers as providing permission to do security testing against that asset. This can lead to increased testing against an organization by researchers. On the other hand, a decision not to publish a security.txt file can be interpreted by the organization operating that website to be a way to signal to researchers that permission to test that particular site or project is denied. This can lead to pushback against researchers reporting security issues to that organization.
+
The presence of a security.txt file might be interpreted by researchers as providing permission to do security testing against that asset. This might result in increased testing against an organization by researchers. On the other hand, a decision not to publish a security.txt file might be interpreted by the organization operating that website to be a way to signal to researchers that permission to test that particular site or project is denied. This might result in pushback against researchers reporting security issues to that organization.
Therefore, implementors MUST NOT assume that presence or absence of a “security.txt” file grants or denies permission for security testing. Any such permission MAY be defined in a security or disclosure policy (as per Section 3.5.6) or a new directive (as per Section 4.4).
In multi-user / multi-tenant environments, it may possible for a user to take over the location of the “security.txt” file. Organizations SHOULD reserve the “security.txt” namespace to ensure no third-party can create a page with the “security.txt” AND “/.well-known/security.txt” names.
+
In multi-user / multi-tenant environments, it may possible for a user to take over the location of the “security.txt” file. Organizations SHOULD reserve the “security.txt” namespace at the root to ensure no third-party can create a page with the “security.txt” AND “/.well-known/security.txt” names.
The document in which the specification of the field is published
+
The document in which the specification of the field is published (if available)
New or updated status, which MUST be one of:
-
current: The field is in current use
-
deprecated: The field is in current use, but its use is discouraged
-
historic: The field is no longer in current use
+
current: The field is in current use
+
deprecated: The field is in current use, but its use is discouraged
+
historic: The field is no longer in current use
+
Change controller
An update may make a notation on an existing registration indicating that a registered field is historical or deprecated if appropriate.
The initial registry contains these values:
@@ -867,42 +868,49 @@
Multiple Appearances: Yes
Published in: this document
Status: current
+ Change controller: IESG
Field Name: Canonical
Description: canonical URL for this file
Multiple Appearances: No
Published in: this document
Status: current
+ Change controller: IESG
Field Name: Contact
Description: contact information to use for reporting vulnerabilities
Multiple Appearances: Yes
Published in: this document
Status: current
+ Change controller: IESG
Field Name: Encryption
Description: link to a key to be used for encrypted communication
Multiple Appearances: Yes
Published in: this document
Status: current
+ Change controller: IESG
Field Name: Hiring
Description: link to the vendor's security-related job positions
Multiple Appearances: Yes
Published in: this document
Status: current
+ Change controller: IESG
Field Name: Policy
Description: link to security policy page
Multiple Appearances: Yes
Published in: this document
Status: current
+ Change controller: IESG
Field Name: Preferred-Languages
Description: list of preferred languages for security reports
Multiple Appearances: No
Published in: this document
Status: current
+ Change controller: IESG
diff --git a/draft-foudil-securitytxt.md b/draft-foudil-securitytxt.md
index c013f60..2ddc685 100644
--- a/draft-foudil-securitytxt.md
+++ b/draft-foudil-securitytxt.md
@@ -92,7 +92,7 @@ For web-based services, the file MUST be accessible via the Hypertext Transfer P
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}}).
+of {{!RFC5322}}. Directives are 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}}.
@@ -143,17 +143,15 @@ Example:
# This is a comment.
~~~~~~~~~~
-You MAY use one or more comments as descriptive text immediately
+One or more comments MAY be used 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.
-## Separate Fields
+## Line Separator
-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).
+Every line MUST end either with a carriage return and line feed
+characters (CRLF / %x0D %x0A) or just a line feed character (LF / %x0A).
## Digital signature {#signature}
@@ -171,10 +169,10 @@ used is indeed one they trust.
### Acknowledgments {#acknowledgments}
-This directive allows you to link to a page where security
-researchers are recognized for their reports. The page being linked to
+This directive indicates a link to a page where security
+researchers are recognized for their reports. The page being referenced
SHOULD list individuals or organizations that reported security vulnerabilities
-and worked with you to remediate the issue. Organizations SHOULD be careful
+and collaborated to remediate them. Organizations SHOULD be careful
to limit the vulnerability information being published in order
to prevent future attacks.
@@ -214,7 +212,7 @@ Canonical: https://example.com/.well-known/security.txt
### Contact {#contact}
-This directive allows you to provide an address that researchers
+This directive indicates 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
@@ -241,9 +239,9 @@ Contact: https://example.com/security-contact.html
### Encryption {#encryption}
-This directive allows you to point to an encryption key that
-security researchers SHOULD use for encrypted communication. You MUST NOT
-directly add your key to the field, instead the value of this field
+This directive indicates an encryption key that
+security researchers SHOULD use for encrypted communication. Keys MUST NOT
+appear in this field - instead the value of this field
MUST be a URI pointing to a location where the key can be retrieved.
If this directive indicates a web URL, then it MUST begin with "https://"
(as per section 2.7.2 of {{!RFC7230}}).
@@ -283,9 +281,9 @@ Hiring: https://example.com/jobs.html
### Policy {#policy}
-This directive allows you to link to where your security policy and/or
+This directive indicates a link to where the security policy and/or
disclosure policy is located. This can help security researchers understand
-what you are looking for and how to report security vulnerabilities.
+what an organization is looking for and how to report security vulnerabilities.
If this directive indicates a web URL, then it MUST begin with "https://"
(as per section 2.7.2 of {{!RFC7230}}).
@@ -353,7 +351,7 @@ Policy: https://example.com/security-policy.html
# Our security acknowledgments page
Acknowledgments: https://example.com/hall-of-fame.html
-----BEGIN PGP SIGNATURE-----
-Version: GnuPG v1
+Version: GnuPG v2.2
[signature]
-----END PGP SIGNATURE-----
@@ -391,7 +389,9 @@ Example file system:
## Internal hosts
-A "security.txt" file SHOULD be placed in the root directory of an internal host.
+An internal host is "a host served by a NAT gateway, or protected by a firewall" (as
+per section 3 of {{!RFC6887}}) and might not be accessible directly from the Internet.
+On such systems, a "security.txt" file SHOULD be placed in the root directory.
## Extensibility {#extensibility}
@@ -500,7 +500,8 @@ domain (as per {{weblocation}}).
If information and resources referenced in a "security.txt" file are incorrect
or not kept up to date, this can result in security reports not being received
by the organization or sent to incorrect contacts, thus exposing possible
-security issues to third parties.
+security issues to third parties. Not having a security.txt file may be preferable
+to having stale information in this file.
Organizations SHOULD ensure that information in this file and any referenced
resources such as web pages, email addresses and telephone numbers
@@ -523,10 +524,10 @@ this file. Such resources and reports may be hostile, malformed or malicious.
The presence of a security.txt file might be interpreted by researchers
as providing permission to do security testing against that asset.
-This can lead to increased testing against an organization by researchers. On the other hand, a decision not
-to publish a security.txt file can be interpreted by the
+This might result in increased testing against an organization by researchers. On the other hand, a decision not
+to publish a security.txt file might be interpreted by the
organization operating that website to be a way to signal to researchers
-that permission to test that particular site or project is denied. This can lead to pushback against
+that permission to test that particular site or project is denied. This might result in pushback against
researchers reporting security issues to that organization.
Therefore, implementors MUST NOT assume that presence or absence of
@@ -538,7 +539,7 @@ Any such permission MAY be defined in a security or disclosure policy
In multi-user / multi-tenant environments, it may possible for a user to take
over the location of the "security.txt" file. Organizations SHOULD reserve
-the "security.txt" namespace to ensure no third-party can create a page with
+the "security.txt" namespace at the root to ensure no third-party can create a page with
the "security.txt" AND "/.well-known/security.txt" names.
## Protecting Data in Transit
@@ -611,11 +612,12 @@ New registrations and updates MUST contain the following information:
1. Name of the field being registered or updated
2. Short description of the field
3. Whether the field can appear more than once
- 4. The document in which the specification of the field is published
+ 4. The document in which the specification of the field is published (if available)
5. New or updated status, which MUST be one of:
- - current: The field is in current use
- - deprecated: The field is in current use, but its use is discouraged
- - historic: The field is no longer in current use
+ - current: The field is in current use
+ - deprecated: The field is in current use, but its use is discouraged
+ - historic: The field is no longer in current use
+ 6. Change controller
An update may make a notation on an existing registration indicating
that a registered field is historical or deprecated if appropriate.
@@ -627,42 +629,49 @@ The initial registry contains these values:
Multiple Appearances: Yes
Published in: this document
Status: current
+ Change controller: IESG
Field Name: Canonical
Description: canonical URL for this file
Multiple Appearances: No
Published in: this document
Status: current
+ Change controller: IESG
Field Name: Contact
Description: contact information to use for reporting vulnerabilities
Multiple Appearances: Yes
Published in: this document
Status: current
+ Change controller: IESG
Field Name: Encryption
Description: link to a key to be used for encrypted communication
Multiple Appearances: Yes
Published in: this document
Status: current
+ Change controller: IESG
Field Name: Hiring
Description: link to the vendor's security-related job positions
Multiple Appearances: Yes
Published in: this document
Status: current
+ Change controller: IESG
Field Name: Policy
Description: link to security policy page
Multiple Appearances: Yes
Published in: this document
Status: current
+ Change controller: IESG
Field Name: Preferred-Languages
Description: list of preferred languages for security reports
Multiple Appearances: No
Published in: this document
Status: current
+ Change controller: IESG
# Contributors
diff --git a/draft-foudil-securitytxt.txt b/draft-foudil-securitytxt.txt
index 2f002a9..0d6ffa3 100644
--- a/draft-foudil-securitytxt.txt
+++ b/draft-foudil-securitytxt.txt
@@ -70,7 +70,7 @@ Table of Contents
3. The Specification . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Comments . . . . . . . . . . . . . . . . . . . . . . . . 5
- 3.3. Separate Fields . . . . . . . . . . . . . . . . . . . . . 6
+ 3.3. Line Separator . . . . . . . . . . . . . . . . . . . . . 6
3.4. Digital signature . . . . . . . . . . . . . . . . . . . . 6
3.5. Field Definitions . . . . . . . . . . . . . . . . . . . . 6
3.5.1. Acknowledgments . . . . . . . . . . . . . . . . . . . 6
@@ -93,19 +93,19 @@ Table of Contents
6.2. Incorrect or Stale Information . . . . . . . . . . . . . 13
6.3. Intentionally Malformed Files, Resources and Reports . . 13
6.4. No Implied Permission for Testing . . . . . . . . . . . . 13
- 6.5. Multi-user Environments . . . . . . . . . . . . . . . . . 13
+ 6.5. Multi-user Environments . . . . . . . . . . . . . . . . . 14
6.6. Protecting Data in Transit . . . . . . . . . . . . . . . 14
6.7. Spam and Spurious Reports . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7.1. Well-Known URIs registry . . . . . . . . . . . . . . . . 15
7.2. Registry for security.txt Header Fields . . . . . . . . . 15
- 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16
- 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
- 9.1. Normative References . . . . . . . . . . . . . . . . . . 17
- 9.2. Informative References . . . . . . . . . . . . . . . . . 19
- Appendix A. Note to Readers . . . . . . . . . . . . . . . . . . 19
- Appendix B. Document History . . . . . . . . . . . . . . . . . . 20
- B.1. Since draft-foudil-securitytxt-00 . . . . . . . . . . . . 20
+ 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18
+ 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
+ 9.1. Normative References . . . . . . . . . . . . . . . . . . 18
+ 9.2. Informative References . . . . . . . . . . . . . . . . . 20
+ Appendix A. Note to Readers . . . . . . . . . . . . . . . . . . 21
+ Appendix B. Document History . . . . . . . . . . . . . . . . . . 21
+ B.1. Since draft-foudil-securitytxt-00 . . . . . . . . . . . . 21
@@ -114,14 +114,14 @@ Foudil & Shafranovich Expires April 8, 2020 [Page 2]
Internet-Draft A Method for Web Security Policies October 2019
- B.2. Since draft-foudil-securitytxt-01 . . . . . . . . . . . . 20
- B.3. Since draft-foudil-securitytxt-02 . . . . . . . . . . . . 21
- B.4. Since draft-foudil-securitytxt-03 . . . . . . . . . . . . 21
- B.5. Since draft-foudil-securitytxt-04 . . . . . . . . . . . . 21
- B.6. Since draft-foudil-securitytxt-05 . . . . . . . . . . . . 22
- B.7. Since draft-foudil-securitytxt-06 . . . . . . . . . . . . 22
- B.8. Since draft-foudil-securitytxt-07 . . . . . . . . . . . . 22
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
+ B.2. Since draft-foudil-securitytxt-01 . . . . . . . . . . . . 21
+ B.3. Since draft-foudil-securitytxt-02 . . . . . . . . . . . . 22
+ B.4. Since draft-foudil-securitytxt-03 . . . . . . . . . . . . 22
+ B.5. Since draft-foudil-securitytxt-04 . . . . . . . . . . . . 23
+ B.6. Since draft-foudil-securitytxt-05 . . . . . . . . . . . . 23
+ B.7. Since draft-foudil-securitytxt-06 . . . . . . . . . . . . 23
+ B.8. Since draft-foudil-securitytxt-07 . . . . . . . . . . . . 24
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction
@@ -211,8 +211,8 @@ Internet-Draft A Method for Web Security Policies October 2019
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
+ section 3.6.8 of [RFC5322]. Directives are 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].
@@ -269,7 +269,7 @@ Internet-Draft A Method for Web Security Policies October 2019
# This is a comment.
- You MAY use one or more comments as descriptive text immediately
+ One or more comments MAY be used 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.
@@ -282,12 +282,11 @@ Foudil & Shafranovich Expires April 8, 2020 [Page 5]
Internet-Draft A Method for Web Security Policies October 2019
-3.3. Separate Fields
+3.3. Line Separator
- 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).
+ 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
@@ -306,12 +305,12 @@ Internet-Draft A Method for Web Security Policies October 2019
3.5.1. Acknowledgments
- This directive allows you to link to a page where security
- researchers are recognized for their reports. The page being linked
- to SHOULD list individuals or organizations that reported security
- vulnerabilities and worked with you to remediate the issue.
- Organizations SHOULD be careful to limit the vulnerability
- information being published in order to prevent future attacks.
+ This directive indicates a link to a page where security researchers
+ are recognized for their reports. The page being referenced SHOULD
+ list individuals or organizations that reported security
+ vulnerabilities and collaborated to remediate them. Organizations
+ SHOULD be careful to limit the vulnerability information being
+ published in order to prevent future attacks.
If this directive indicates a web URL, then it MUST begin with
"https://" (as per section 2.7.2 of [RFC7230]).
@@ -333,6 +332,7 @@ Internet-Draft A Method for Web Security Policies October 2019
+
Foudil & Shafranovich Expires April 8, 2020 [Page 6]
Internet-Draft A Method for Web Security Policies October 2019
@@ -354,14 +354,14 @@ Internet-Draft A Method for Web Security Policies October 2019
3.5.3. Contact
- 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
- MUST begin with "https://" (as per section 2.7.2 of [RFC7230]).
- Security email addresses SHOULD use the conventions defined in
- section 4 of [RFC2142].
+ This directive indicates 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 MUST begin with
+ "https://" (as per section 2.7.2 of [RFC7230]). Security email
+ addresses SHOULD use the conventions defined in section 4 of
+ [RFC2142].
The value MUST follow the URI syntax described in [RFC3986]. This
means that "mailto" and "tel" URI schemes MUST be used when
@@ -380,12 +380,12 @@ Internet-Draft A Method for Web Security Policies October 2019
3.5.4. Encryption
- This directive allows you to point to an encryption key that security
- researchers SHOULD use for encrypted communication. You MUST NOT
- directly add your key to the field, instead the value of this field
- MUST be a URI pointing to a location where the key can be retrieved.
- If this directive indicates a web URL, then it MUST begin with
- "https://" (as per section 2.7.2 of [RFC7230]).
+ This directive indicates an encryption key that security researchers
+ SHOULD use for encrypted communication. Keys MUST NOT appear in this
+ field - instead the value of this field MUST be a URI pointing to a
+ location where the key can be retrieved. If this directive indicates
+ a web URL, then it MUST begin with "https://" (as per section 2.7.2
+ of [RFC7230]).
@@ -422,11 +422,12 @@ Encryption: dns:5d2d37ab76d47d36._openpgpkey.example.com?type=OPENPGPKEY
3.5.6. Policy
- This directive allows you to link to where your security policy and/
- or disclosure policy is located. This can help security researchers
- understand what you are looking for and how to report security
- vulnerabilities. If this directive indicates a web URL, then it MUST
- begin with "https://" (as per section 2.7.2 of [RFC7230]).
+ This directive indicates a link to where the security policy and/or
+ disclosure policy is located. This can help security researchers
+ understand what an organization is looking for and how to report
+ security vulnerabilities. If this directive indicates a web URL,
+ then it MUST begin with "https://" (as per section 2.7.2 of
+ [RFC7230]).
Example:
@@ -444,7 +445,6 @@ Encryption: dns:5d2d37ab76d47d36._openpgpkey.example.com?type=OPENPGPKEY
-
Foudil & Shafranovich Expires April 8, 2020 [Page 8]
Internet-Draft A Method for Web Security Policies October 2019
@@ -494,7 +494,7 @@ Internet-Draft A Method for Web Security Policies October 2019
# Our security acknowledgments page
Acknowledgments: https://example.com/hall-of-fame.html
-----BEGIN PGP SIGNATURE-----
- Version: GnuPG v1
+ Version: GnuPG v2.2
[signature]
-----END PGP SIGNATURE-----
@@ -541,8 +541,10 @@ Internet-Draft A Method for Web Security Policies October 2019
4.3. Internal hosts
- A "security.txt" file SHOULD be placed in the root directory of an
- internal host.
+ An internal host is "a host served by a NAT gateway, or protected by
+ a firewall" (as per section 3 of [RFC6887]) and might not be
+ accessible directly from the Internet. On such systems, a
+ "security.txt" file SHOULD be placed in the root directory.
4.4. Extensibility
@@ -551,8 +553,6 @@ Internet-Draft A Method for Web Security Policies October 2019
Internet. Therefore, extensibility is provided via an IANA registry
for directives as defined in Section 7.2. Any directives registered
via that process MUST be considered optional. To encourage
- extensibility and interoperability, implementors MUST ignore any
- fields they do not explicitly support.
@@ -562,6 +562,9 @@ Foudil & Shafranovich Expires April 8, 2020 [Page 10]
Internet-Draft A Method for Web Security Policies October 2019
+ extensibility and interoperability, implementors MUST ignore any
+ fields they do not explicitly support.
+
In general, implementors SHOULD "be conservative in what you do, be
liberal in what you accept from others" (as per [RFC0793]).
@@ -608,9 +611,6 @@ contact-field = "Contact" fs SP uri
lang-tag = < Language-Tag from section 2.1 of [RFC5646] >
-uri = < URI as per [RFC3986] >
-
-
Foudil & Shafranovich Expires April 8, 2020 [Page 11]
@@ -618,6 +618,8 @@ Foudil & Shafranovich Expires April 8, 2020 [Page 11]
Internet-Draft A Method for Web Security Policies October 2019
+uri = < URI as per [RFC3986] >
+
encryption-field = "Encryption" fs SP uri
hiring-field = "Hiring" fs SP uri
@@ -667,8 +669,6 @@ unstructured = < imported from section 3.2.5 of [RFC5322] >
-
-
Foudil & Shafranovich Expires April 8, 2020 [Page 12]
Internet-Draft A Method for Web Security Policies October 2019
@@ -679,7 +679,9 @@ Internet-Draft A Method for Web Security Policies October 2019
If information and resources referenced in a "security.txt" file are
incorrect or not kept up to date, this can result in security reports
not being received by the organization or sent to incorrect contacts,
- thus exposing possible security issues to third parties.
+ thus exposing possible security issues to third parties. Not having
+ a security.txt file may be preferable to having stale information in
+ this file.
Organizations SHOULD ensure that information in this file and any
referenced resources such as web pages, email addresses and telephone
@@ -704,24 +706,22 @@ Internet-Draft A Method for Web Security Policies October 2019
The presence of a security.txt file might be interpreted by
researchers as providing permission to do security testing against
- that asset. This can lead to increased testing against an
+ that asset. This might result in increased testing against an
organization by researchers. On the other hand, a decision not to
- publish a security.txt file can be interpreted by the organization
+ publish a security.txt file might be interpreted by the organization
operating that website to be a way to signal to researchers that
permission to test that particular site or project is denied. This
- can lead to pushback against researchers reporting security issues to
- that organization.
+ might result in pushback against researchers reporting security
+ issues to that organization.
Therefore, implementors MUST NOT assume that presence or absence of a
"security.txt" file grants or denies permission for security testing.
Any such permission MAY be defined in a security or disclosure policy
(as per Section 3.5.6) or a new directive (as per Section 4.4).
-6.5. Multi-user Environments
- In multi-user / multi-tenant environments, it may possible for a user
- to take over the location of the "security.txt" file. Organizations
- SHOULD reserve the "security.txt" namespace to ensure no third-party
+
+
@@ -730,8 +730,13 @@ Foudil & Shafranovich Expires April 8, 2020 [Page 13]
Internet-Draft A Method for Web Security Policies October 2019
- can create a page with the "security.txt" AND "/.well-known/
- security.txt" names.
+6.5. Multi-user Environments
+
+ In multi-user / multi-tenant environments, it may possible for a user
+ to take over the location of the "security.txt" file. Organizations
+ SHOULD reserve the "security.txt" namespace at the root to ensure no
+ third-party can create a page with the "security.txt" AND "/.well-
+ known/security.txt" names.
6.6. Protecting Data in Transit
@@ -773,11 +778,6 @@ Internet-Draft A Method for Web Security Policies October 2019
example.com is used in this document following the uses indicated in
[RFC2606].
- 192.0.2.0 and 2001:db8:8:4::2 are used in this document following the
- uses indicated in [RFC6890].
-
-
-
@@ -786,6 +786,9 @@ Foudil & Shafranovich Expires April 8, 2020 [Page 14]
Internet-Draft A Method for Web Security Policies October 2019
+ 192.0.2.0 and 2001:db8:8:4::2 are used in this document following the
+ uses indicated in [RFC6890].
+
7.1. Well-Known URIs registry
The "Well-Known URIs" registry should be updated with the following
@@ -820,6 +823,7 @@ Internet-Draft A Method for Web Security Policies October 2019
3. Whether the field can appear more than once
4. The document in which the specification of the field is published
+ (if available)
5. New or updated status, which MUST be one of:
@@ -830,6 +834,16 @@ Internet-Draft A Method for Web Security Policies October 2019
* historic: The field is no longer in current use
+
+
+
+Foudil & Shafranovich Expires April 8, 2020 [Page 15]
+
+Internet-Draft A Method for Web Security Policies October 2019
+
+
+ 6. Change controller
+
An update may make a notation on an existing registration indicating
that a registered field is historical or deprecated if appropriate.
@@ -837,7 +851,49 @@ Internet-Draft A Method for Web Security Policies October 2019
-Foudil & Shafranovich Expires April 8, 2020 [Page 15]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Foudil & Shafranovich Expires April 8, 2020 [Page 16]
Internet-Draft A Method for Web Security Policies October 2019
@@ -847,42 +903,56 @@ Internet-Draft A Method for Web Security Policies October 2019
Multiple Appearances: Yes
Published in: this document
Status: current
+ Change controller: IESG
Field Name: Canonical
Description: canonical URL for this file
Multiple Appearances: No
Published in: this document
Status: current
+ Change controller: IESG
Field Name: Contact
Description: contact information to use for reporting vulnerabilities
Multiple Appearances: Yes
Published in: this document
Status: current
+ Change controller: IESG
Field Name: Encryption
Description: link to a key to be used for encrypted communication
Multiple Appearances: Yes
Published in: this document
Status: current
+ Change controller: IESG
Field Name: Hiring
Description: link to the vendor's security-related job positions
Multiple Appearances: Yes
Published in: this document
Status: current
+ Change controller: IESG
Field Name: Policy
Description: link to security policy page
Multiple Appearances: Yes
Published in: this document
Status: current
+ Change controller: IESG
Field Name: Preferred-Languages
Description: list of preferred languages for security reports
Multiple Appearances: No
Published in: this document
Status: current
+ Change controller: IESG
+
+
+
+Foudil & Shafranovich Expires April 8, 2020 [Page 17]
+
+Internet-Draft A Method for Web Security Policies October 2019
+
8. Contributors
@@ -891,13 +961,6 @@ Internet-Draft A Method for Web Security Policies October 2019
Janssen van Doorn, Austin Heap, Stephane Bortzmeyer, Max Smith,
Eduardo Vela and Krzysztof Kotowicz.
-
-
-Foudil & Shafranovich Expires April 8, 2020 [Page 16]
-
-Internet-Draft A Method for Web Security Policies October 2019
-
-
The authors would also like to acknowledge the feedback provided by
multiple members of IETF's SAAG and SECDISPATCH lists.
@@ -936,6 +999,17 @@ Internet-Draft A Method for Web Security Policies October 2019
RFC 3966, DOI 10.17487/RFC3966, December 2004,
.
+
+
+
+
+
+
+Foudil & Shafranovich Expires April 8, 2020 [Page 18]
+
+Internet-Draft A Method for Web Security Policies October 2019
+
+
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
@@ -946,14 +1020,6 @@ Internet-Draft A Method for Web Security Policies October 2019
DOI 10.17487/RFC4880, November 2007,
.
-
-
-
-Foudil & Shafranovich Expires April 8, 2020 [Page 17]
-
-Internet-Draft A Method for Web Security Policies October 2019
-
-
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network
Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008,
.
@@ -982,11 +1048,24 @@ Internet-Draft A Method for Web Security Policies October 2019
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, .
+ [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and
+ P. Selkirk, "Port Control Protocol (PCP)", RFC 6887,
+ DOI 10.17487/RFC6887, April 2013,
+ .
+
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014,
.
+
+
+
+Foudil & Shafranovich Expires April 8, 2020 [Page 19]
+
+Internet-Draft A Method for Web Security Policies October 2019
+
+
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014,
@@ -1000,16 +1079,6 @@ Internet-Draft A Method for Web Security Policies October 2019
(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
.
-
-
-
-
-
-Foudil & Shafranovich Expires April 8, 2020 [Page 18]
-
-Internet-Draft A Method for Web Security Policies October 2019
-
-
9.2. Informative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
@@ -1044,6 +1113,15 @@ Internet-Draft A Method for Web Security Policies October 2019
RFC 7485, DOI 10.17487/RFC7485, March 2015,
.
+
+
+
+
+Foudil & Shafranovich Expires April 8, 2020 [Page 20]
+
+Internet-Draft A Method for Web Security Policies October 2019
+
+
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
@@ -1057,15 +1135,6 @@ Appendix A. Note to Readers
Development of this draft takes place on Github at
https://github.com/securitytxt/security-txt
-
-
-
-
-Foudil & Shafranovich Expires April 8, 2020 [Page 19]
-
-Internet-Draft A Method for Web Security Policies October 2019
-
-
Appendix B. Document History
*Note to the RFC Editor:* Please remove this section prior to
@@ -1100,6 +1169,15 @@ B.2. Since draft-foudil-securitytxt-01
o Added policy field (#53)
+
+
+
+
+Foudil & Shafranovich Expires April 8, 2020 [Page 21]
+
+Internet-Draft A Method for Web Security Policies October 2019
+
+
o Added diagram explaining the location of the file on public vs.
internal systems
@@ -1112,16 +1190,6 @@ B.2. Since draft-foudil-securitytxt-01
The full list of changes can be viewed via the IETF document tracker:
https://tools.ietf.org/html/draft-foudil-securitytxt-02
-
-
-
-
-
-Foudil & Shafranovich Expires April 8, 2020 [Page 20]
-
-Internet-Draft A Method for Web Security Policies October 2019
-
-
B.3. Since draft-foudil-securitytxt-02
o Use "mailto" and "tel" (#62)
@@ -1159,6 +1227,13 @@ B.4. Since draft-foudil-securitytxt-03
o Adding "Permission" field (#30)
+
+
+Foudil & Shafranovich Expires April 8, 2020 [Page 22]
+
+Internet-Draft A Method for Web Security Policies October 2019
+
+
o Fixing remaining ABNF issues (#83)
o Additional editorial changes and edits
@@ -1171,13 +1246,6 @@ B.5. Since draft-foudil-securitytxt-04
o Syntax fixes (#133, #135 and #136)
-
-
-Foudil & Shafranovich Expires April 8, 2020 [Page 21]
-
-Internet-Draft A Method for Web Security Policies October 2019
-
-
o Removed permission directive (#30)
o Removed signature directive and switched to inline signatures (#93
@@ -1215,6 +1283,13 @@ B.7. Since draft-foudil-securitytxt-06
o Fixed nits from the IETF validator
+
+
+Foudil & Shafranovich Expires April 8, 2020 [Page 23]
+
+Internet-Draft A Method for Web Security Policies October 2019
+
+
B.8. Since draft-foudil-securitytxt-07
o Addressing AD feedback (#165)
@@ -1224,16 +1299,6 @@ B.8. Since draft-foudil-securitytxt-07
Full list of changes can be viewed via the IETF document tracker:
https://tools.ietf.org/html/draft-foudil-securitytxt
-
-
-
-
-
-Foudil & Shafranovich Expires April 8, 2020 [Page 22]
-
-Internet-Draft A Method for Web Security Policies October 2019
-
-
Authors' Addresses
Edwin Foudil
@@ -1276,13 +1341,4 @@ Authors' Addresses
-
-
-
-
-
-
-
-
-
-Foudil & Shafranovich Expires April 8, 2020 [Page 23]
+Foudil & Shafranovich Expires April 8, 2020 [Page 24]