idnits 2.17.1 draft-foudil-securitytxt-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (11 March 2021) is 1147 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Foudil 3 Internet-Draft 4 Intended status: Informational Y. Shafranovich 5 Expires: 12 September 2021 Nightwatch Cybersecurity 6 11 March 2021 8 A File Format to Aid in Security Vulnerability Disclosure 9 draft-foudil-securitytxt-11 11 Abstract 13 When security vulnerabilities are discovered by researchers, proper 14 reporting channels are often lacking. As a result, vulnerabilities 15 may be left unreported. This document defines a format 16 ("security.txt") to help organizations describe their vulnerability 17 disclosure practices to make it easier for researchers to report 18 vulnerabilities. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on 12 September 2021. 37 Copyright Notice 39 Copyright (c) 2021 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Simplified BSD License text 48 as described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Motivation, Prior Work and Scope . . . . . . . . . . . . 3 55 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Note to Readers . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. The Specification . . . . . . . . . . . . . . . . . . . . . . 4 58 3.1. Comments . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.2. Line Separator . . . . . . . . . . . . . . . . . . . . . 5 60 3.3. Digital signature . . . . . . . . . . . . . . . . . . . . 6 61 3.4. Extensibility . . . . . . . . . . . . . . . . . . . . . . 6 62 3.5. Field Definitions . . . . . . . . . . . . . . . . . . . . 6 63 3.5.1. Acknowledgments . . . . . . . . . . . . . . . . . . . 6 64 3.5.2. Canonical . . . . . . . . . . . . . . . . . . . . . . 7 65 3.5.3. Contact . . . . . . . . . . . . . . . . . . . . . . . 7 66 3.5.4. Encryption . . . . . . . . . . . . . . . . . . . . . 8 67 3.5.5. Expires . . . . . . . . . . . . . . . . . . . . . . . 8 68 3.5.6. Hiring . . . . . . . . . . . . . . . . . . . . . . . 9 69 3.5.7. Policy . . . . . . . . . . . . . . . . . . . . . . . 9 70 3.5.8. Preferred-Languages . . . . . . . . . . . . . . . . . 9 71 3.6. Example of an unsigned "security.txt" file . . . . . . . 9 72 3.7. Example of a signed "security.txt" file . . . . . . . . . 10 73 4. Location of the security.txt file . . . . . . . . . . . . . . 11 74 4.1. Scope of the File . . . . . . . . . . . . . . . . . . . . 11 75 5. File Format Description and ABNF Grammar . . . . . . . . . . 12 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 77 6.1. Compromised Files and Incident Response . . . . . . . . . 14 78 6.2. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 14 79 6.3. Incorrect or Stale Information . . . . . . . . . . . . . 14 80 6.4. Intentionally Malformed Files, Resources and Reports . . 15 81 6.5. No Implied Permission for Testing . . . . . . . . . . . . 15 82 6.6. Multi-user Environments . . . . . . . . . . . . . . . . . 15 83 6.7. Protecting Data in Transit . . . . . . . . . . . . . . . 16 84 6.8. Spam and Spurious Reports . . . . . . . . . . . . . . . . 16 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 86 7.1. Well-Known URIs registry . . . . . . . . . . . . . . . . 17 87 7.2. Registry for security.txt Fields . . . . . . . . . . . . 17 88 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 89 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 90 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 91 9.2. Informative References . . . . . . . . . . . . . . . . . 21 92 Appendix A. Note to Readers . . . . . . . . . . . . . . . . . . 22 93 Appendix B. Document History . . . . . . . . . . . . . . . . . . 22 94 B.1. Since draft-foudil-securitytxt-00 . . . . . . . . . . . . 22 95 B.2. Since draft-foudil-securitytxt-01 . . . . . . . . . . . . 23 96 B.3. Since draft-foudil-securitytxt-02 . . . . . . . . . . . . 23 97 B.4. Since draft-foudil-securitytxt-03 . . . . . . . . . . . . 24 98 B.5. Since draft-foudil-securitytxt-04 . . . . . . . . . . . . 24 99 B.6. Since draft-foudil-securitytxt-05 . . . . . . . . . . . . 25 100 B.7. Since draft-foudil-securitytxt-06 . . . . . . . . . . . . 25 101 B.8. Since draft-foudil-securitytxt-07 . . . . . . . . . . . . 25 102 B.9. Since draft-foudil-securitytxt-08 . . . . . . . . . . . . 25 103 B.10. Since draft-foudil-securitytxt-09 . . . . . . . . . . . . 26 104 B.11. Since draft-foudil-securitytxt-10 . . . . . . . . . . . . 26 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 107 1. Introduction 109 1.1. Motivation, Prior Work and Scope 111 Many security researchers encounter situations where they are unable 112 to report security vulnerabilities to organizations because there are 113 no reporting channels to contact the owner of a particular resource 114 and no information available about the vulnerability disclosure 115 practices of such owner. 117 As per section 4 of [RFC2142], there is an existing convention of 118 using the email address for communications 119 regarding security issues. That convention provides only a single, 120 email-based channel of communication per domain, and does not provide 121 a way for domain owners to publish information about their security 122 disclosure practices. 124 There are also contact conventions prescribed for Internet Service 125 Providers (ISPs) in section 2 of [RFC3013], for Computer Security 126 Incident Response Teams (CSIRTs) in section 3.2 of [RFC2350] and for 127 site operators in section 5.2 of [RFC2196]. As per [RFC7485], there 128 is also contact information provided by Regional Internet Registries 129 (RIRs) and domain registries for owners of IP addresses, autonomous 130 system numbers (ASNs), and domain names. However, none of these 131 tackle the issue of how security researchers can locate contact 132 information and vulnerability disclosure practices for organizations 133 in order to report vulnerabilities. 135 In this document, we define a richer and more extensible way for 136 organizations to communicate information about their security 137 disclosure practices and ways to contact them. Other details of 138 vulnerability disclosure are outside the scope of this document. 139 Readers are encouraged to consult other documents such as 140 [ISO.29147.2018] or [CERT.CVD]. 142 As per [CERT.CVD], "vulnerability response" refers to reports of 143 product vulnerabilities which is related but distinct from reports of 144 network intrusions and compromised websites ("incident response"). 145 The mechanism defined in this document is intended to be used for the 146 former ("vulnerability response"). If implementors want to utilize 147 this mechanism for incident response, they should be aware of 148 additional security considerations discussed in Section 6.1. 150 The "security.txt" file is intended to be complementary and not as a 151 substitute or replacement for other public resources maintained by 152 organizations regarding their security disclosure practices. 154 1.2. Terminology 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 158 "OPTIONAL" in this document are to be interpreted as described in BCP 159 14 [RFC2119] [RFC8174] when, and only when, they appear in all 160 capitals, as shown here. 162 The term "researcher" corresponds to the terms "finder" and 163 "reporter" in [ISO.29147.2018] and [CERT.CVD]. The term 164 "organization" corresponds to the term "vendor" in [ISO.29147.2018] 165 and [CERT.CVD]. 167 The term "implementors" includes all parties involved in the 168 vulnerability disclosure process. 170 2. Note to Readers 172 *Note to the RFC Editor:* Please remove this section prior to 173 publication. 175 Development of this draft takes place on Github at: 176 https://github.com/securitytxt/security-txt 178 3. The Specification 180 This document defines a text file to be placed in a known location 181 that provides information about vulnerability disclosure practices of 182 a particular organization. This is intended to help security 183 researchers when disclosing security vulnerabilities. 185 By convention, the file is named "security.txt". Location and scope 186 are described in Section 4. 188 This text file contains multiple fields with different values. A 189 field contains a "name" which is the first part of a field all the 190 way up to the colon (for example: "Contact:") and follows the syntax 191 defined for "field-name" in section 3.6.8 of [RFC5322]. Field names 192 are case-insensitive (as per section 2.3 of [RFC5234]). The "value" 193 comes after the field name (for example: 194 "mailto:security@example.com") and follows the syntax defined for 195 "unstructured" in section 3.2.5 of [RFC5322]. The file MAY also 196 contain blank lines. 198 A field MUST always consist of a name and a value (for example: 199 "Contact: mailto:security@example.com"). A security.txt file can 200 have an unlimited number of fields. Each field MUST appear on its 201 own line. Unless specified otherwise by the field definition, 202 multiple values MUST NOT be chained together for a single field. 203 Unless otherwise indicated in a definition of a particular field, a 204 field MAY appear multiple times. 206 Implementors should be aware that some of the fields may contain URIs 207 using percent-encoding (as per section 2.1 of [RFC3986]). 209 3.1. Comments 211 Any line beginning with the "#" (%x23) symbol MUST be interpreted as 212 a comment. The content of the comment may contain any ASCII or 213 Unicode characters in the %x21-7E and %x80-FFFFF ranges plus the tab 214 (%x09) and space (%x20) characters. 216 Example: 218 # This is a comment. 220 3.2. Line Separator 222 Every line MUST end either with a carriage return and line feed 223 characters (CRLF / %x0D %x0A) or just a line feed character (LF / 224 %x0A). 226 3.3. Digital signature 228 It is RECOMMENDED that a security.txt file be digitally signed using 229 an OpenPGP cleartext signature as described in section 7 of 230 [RFC4880]. When digital signatures are used, it is also RECOMMENDED 231 that organizations use the "Canonical" field (as per Section 3.5.2), 232 thus allowing the digital signature to authenticate the location of 233 the file. 235 When it comes to verifying the key used to generate the signature, it 236 is always the security researcher's responsibility to make sure the 237 key being used is indeed one they trust. 239 3.4. Extensibility 241 Like many other formats and protocols, this format may need to be 242 extended over time to fit the ever-changing landscape of the 243 Internet. Therefore, extensibility is provided via an IANA registry 244 for fields as defined in Section 7.2. Any fields registered via that 245 process MUST be considered optional. To encourage extensibility and 246 interoperability, researchers MUST ignore any fields they do not 247 explicitly support. 249 In general, implementors should "be conservative in what you do, be 250 liberal in what you accept from others" (as per [RFC0793]). 252 3.5. Field Definitions 254 Unless otherwise stated, all fields MUST be considered optional. 256 3.5.1. Acknowledgments 258 This field indicates a link to a page where security researchers are 259 recognized for their reports. The page being referenced should list 260 security researchers that reported security vulnerabilities and 261 collaborated to remediate them. Organizations should be careful to 262 limit the vulnerability information being published in order to 263 prevent future attacks. 265 If this field indicates a web URI, then it MUST begin with "https://" 266 (as per section 2.7.2 of [RFC7230]). 268 Example: 270 Acknowledgments: https://example.com/hall-of-fame.html 272 Example security acknowledgments page: 274 We would like to thank the following researchers: 276 (2017-04-15) Frank Denis - Reflected cross-site scripting 277 (2017-01-02) Alice Quinn - SQL injection 278 (2016-12-24) John Buchner - Stored cross-site scripting 279 (2016-06-10) Anna Richmond - A server configuration issue 281 3.5.2. Canonical 283 This field indicates the canonical URIs where the security.txt file 284 is located, which is usually something like 285 "https://example.com/.well-known/security.txt". If this field 286 indicates a web URI, then it MUST begin with "https://" (as per 287 section 2.7.2 of [RFC7230]). 289 While this field indicates that a "security.txt" retrieved from a 290 given URI is intended to apply to that URI, it MUST NOT be 291 interpreted to apply to all canonical URIs listed within the file. 292 Researchers SHOULD use an additional trust mechanism such as a 293 digital signature (as per Section 3.3) to make the determination that 294 a particular canonical URI is applicable. 296 Canonical: https://www.example.com/.well-known/security.txt 297 Canonical: https://someserver.example.com/.well-known/security.txt 299 3.5.3. Contact 301 This field indicates an address that researchers should use for 302 reporting security vulnerabilities such as an email address, a phone 303 number and/or a web page with contact information. The "Contact" 304 field MUST always be present in a security.txt file. If this field 305 indicates a web URI, then it MUST begin with "https://" (as per 306 section 2.7.2 of [RFC7230]). Security email addresses should use the 307 conventions defined in section 4 of [RFC2142]. 309 The value MUST follow the URI syntax described in section 3 of 310 [RFC3986]. This means that "mailto" and "tel" URI schemes must be 311 used when specifying email addresses and telephone numbers, as 312 defined in [RFC6068] and [RFC3966]. When the value of this field is 313 an email address, it is RECOMMENDED that encryption be used (as per 314 Section 3.5.4). 316 The precedence SHOULD be in listed order. The first occurrence is 317 the preferred method of contact. In the example below, the first 318 email address ("security@example.com") is the preferred method of 319 contact. 321 Contact: mailto:security@example.com 322 Contact: mailto:security%2Buri%2Bencoded@example.com 323 Contact: tel:+1-201-555-0123 324 Contact: https://example.com/security-contact.html 326 3.5.4. Encryption 328 This field indicates an encryption key that security researchers 329 should use for encrypted communication. Keys MUST NOT appear in this 330 field - instead the value of this field MUST be a URI pointing to a 331 location where the key can be retrieved. If this field indicates a 332 web URI, then it MUST begin with "https://" (as per section 2.7.2 of 333 [RFC7230]). 335 When it comes to verifying the authenticity of the key, it is always 336 the security researcher's responsibility to make sure the key being 337 specified is indeed one they trust. Researchers must not assume that 338 this key is used to generate the digital signature referenced in 339 Section 3.3. 341 Example of an OpenPGP key available from a web server: 343 Encryption: https://example.com/pgp-key.txt 345 Example of an OpenPGP key available from an OPENPGPKEY DNS record: 347 Encryption: dns:5d2d37ab76d47d36._openpgpkey.example.com?type=OPENPGPKEY 349 Example of an OpenPGP key being referenced by its fingerprint: 351 Encryption: openpgp4fpr:5f2de5521c63a801ab59ccb603d49de44b29100f 353 3.5.5. Expires 355 This field indicates the date and time after which the data contained 356 in the "security.txt" file is considered stale and should not be used 357 (as per Section 6.3). The value of this field follows the format 358 defined in section 3.3 of [RFC5322]. It is RECOMMENDED that the 359 value of this field be less than a year into the future to avoid 360 staleness. 362 This field MUST always be present and MUST NOT appear more than once. 364 Expires: Thu, 31 Dec 2021 18:37:07 -0800 366 3.5.6. Hiring 368 The "Hiring" field is used for linking to the vendor's security- 369 related job positions. If this field indicates a web URI, then it 370 MUST begin with "https://" (as per section 2.7.2 of [RFC7230]). 372 Hiring: https://example.com/jobs.html 374 3.5.7. Policy 376 This field indicates a link to where the vulnerability disclosure 377 policy is located. This can help security researchers understand the 378 organization's vulnerability reporting practices. If this field 379 indicates a web URI, then it MUST begin with "https://" (as per 380 section 2.7.2 of [RFC7230]). 382 Example: 384 Policy: https://example.com/disclosure-policy.html 386 3.5.8. Preferred-Languages 388 This field can be used to indicate a set of natural languages that 389 are preferred when submitting security reports. This set MAY list 390 multiple values, separated by commas. If this field is included then 391 at least one value MUST be listed. The values within this set are 392 language tags (as defined in [RFC5646]). If this field is absent, 393 security researchers may assume that English is the language to be 394 used (as per section 4.5 of [RFC2277]). 396 The order in which they appear is not an indication of priority; the 397 listed languages are intended to have equal priority. 399 This field MUST NOT appear more than once. 401 Example (English, Spanish and French): 403 Preferred-Languages: en, es, fr 405 3.6. Example of an unsigned "security.txt" file 406 # Our security address 407 Contact: mailto:security@example.com 409 # Our OpenPGP key 410 Encryption: https://example.com/pgp-key.txt 412 # Our security policy 413 Policy: https://example.com/security-policy.html 415 # Our security acknowledgments page 416 Acknowledgments: https://example.com/hall-of-fame.html 418 Expires: Thu, 31 Dec 2021 18:37:07 -0800 420 3.7. Example of a signed "security.txt" file 422 ----BEGIN PGP SIGNED MESSAGE----- 423 Hash: SHA256 425 # Canonical URI 426 Canonical: https://example.com/.well-known/security.txt 428 # Our security address 429 Contact: mailto:security@example.com 431 # Our OpenPGP key 432 Encryption: https://example.com/pgp-key.txt 434 # Our security policy 435 Policy: https://example.com/security-policy.html 437 # Our security acknowledgments page 438 Acknowledgments: https://example.com/hall-of-fame.html 440 Expires: Thu, 31 Dec 2021 18:37:07 -0800 441 -----BEGIN PGP SIGNATURE----- 442 Version: GnuPG v2.2 444 [signature] 445 -----END PGP SIGNATURE----- 447 4. Location of the security.txt file 449 For web-based services, organizations MUST place the security.txt 450 file under the "/.well-known/" path; e.g. https://example.com/.well- 451 known/security.txt as per [RFC8615] of a domain name or IP address. 452 For legacy compatibility, a security.txt file might be placed at the 453 top-level path or redirect (as per section 6.4 of [RFC7231]) to the 454 security.txt file under the "/.well-known/" path. If a 455 "security.txt" file is present in both locations, the one in the 456 "/.well-known/" path MUST be used. 458 The file MUST be accessed via HTTP 1.0 or a higher version and the 459 file access MUST use "https" scheme (as per section 2.7.2 of 460 [RFC7230]). It MUST have a Content-Type of "text/plain" with the 461 default charset parameter set to "utf-8" (as per section 4.1.3 of 462 [RFC2046]). 464 Retrieval of "security.txt" files and resources indicated within such 465 files may result in a redirect (as per section 6.4 of [RFC7231]). 466 Researchers should perform additional analysis (as per Section 6.2) 467 to make sure these redirects are not malicious or pointing to 468 resources controlled by an attacker. 470 4.1. Scope of the File 472 A "security.txt" file MUST only apply to the domain or IP address in 473 the URI used to retrieve it, not to any of its subdomains or parent 474 domains. A "security.txt" file MAY also apply to products and 475 services provided by the organization publishing the file. 477 As per Section 1.1, this specification is intended for vulnerability 478 response. If implementors want to use this for incident response, 479 they should be aware of additional security considerations discussed 480 in Section 6.1. 482 Organizations SHOULD use the policy directive (as per Section 3.5.7) 483 to provide additional details regarding scope and details of their 484 vulnerability disclosure process. 486 Some examples appear below: 488 # The following only applies to example.com. 489 https://example.com/.well-known/security.txt 491 # This only applies to subdomain.example.com. 492 https://subdomain.example.com/.well-known/security.txt 494 # This security.txt file applies to IPv4 address of 192.0.2.0. 495 https://192.0.2.0/.well-known/security.txt 497 # This security.txt file applies to IPv6 address of 2001:db8:8:4::2. 498 https://[2001:db8:8:4::2]/.well-known/security.txt 500 5. File Format Description and ABNF Grammar 502 The file format of the security.txt file MUST be plain text (MIME 503 type "text/plain") as defined in section 4.1.3 of [RFC2046] and MUST 504 be encoded using UTF-8 [RFC3629] in Net-Unicode form [RFC5198]. 506 The following is an ABNF definition of the security.txt format, using 507 the conventions defined in [RFC5234]. 509 body = signed / unsigned 511 signed = sign-header unsigned sign-footer 513 sign-header = < headers and line from section 7 of [RFC4880] > 515 sign-footer = < OpenPGP signature from section 7 of [RFC4880] > 517 unsigned = *line (contact-field eol) ; one or more required 518 *line (expires-field eol) ; exactly one required 519 *line [lang-field eol] *line ; exactly one optional 520 ; order of fields within the file is not important 521 ; except that if contact-field appears more 522 ; than once the order of those indicates 523 ; priority (see Section 3.5.3) 525 line = [ (field / comment) ] eol 527 eol = *WSP [CR] LF 529 field = ; optional fields 530 ack-field / 531 can-field / 532 contact-field / ; optional repeated instances 533 encryption-field / 534 hiring-field / 535 policy-field / 536 ext-field 538 fs = ":" 540 comment = "#" *(WSP / VCHAR / %x80-FFFFF) 542 ack-field = "Acknowledgments" fs SP uri 544 can-field = "Canonical" fs SP uri 546 contact-field = "Contact" fs SP uri 548 expires-field = "Expires" fs SP date-time 550 encryption-field = "Encryption" fs SP uri 552 hiring-field = "Hiring" fs SP uri 554 lang-field = "Preferred-Languages" fs SP lang-values 556 policy-field = "Policy" fs SP uri 558 date-time = < imported from section 3.3 of [RFC5322] > 560 lang-tag = < Language-Tag from section 2.1 of [RFC5646] > 562 lang-values = lang-tag *(*WSP "," *WSP lang-tag) 564 uri = < URI as per section 3 of [RFC3986] > 566 ext-field = field-name fs SP unstructured 568 field-name = < imported from section 3.6.8 of [RFC5322] > 570 unstructured = < imported from section 3.2.5 of [RFC5322] > 572 "ext-field" refers to extension fields, which are discussed in 573 Section 3.4 575 6. Security Considerations 577 Because of the use of URIs and well-known resources, security 578 considerations of [RFC3986] and [RFC8615] apply here, in addition to 579 the considerations outlined below. 581 6.1. Compromised Files and Incident Response 583 An attacker that has compromised a website is able to compromise the 584 "security.txt" file as well or setup a redirect to their own site. 585 This can result in security reports not being received by the 586 organization or sent to the attacker. 588 To protect against this, organizations should use the "Canonical" 589 field to indicate the locations of the file (as per Section 3.5.2), 590 digitally sign their "security.txt" files (as per Section 3.3), and 591 regularly monitor the file and the referenced resources to detect 592 tampering. 594 Security researchers should validate the "security.txt" file 595 including verifying the digital signature and checking any available 596 historical records before using the information contained in the 597 file. If the "security.txt" file looks suspicious or compromised, it 598 should not be used. 600 While it is not recommended, implementors may choose to use the 601 information published within a "security.txt" file for incident 602 response. In such cases, extreme caution should be taken before 603 trusting such information, since it may have been compromised by an 604 attacker. Researchers should use additional methods to verify such 605 data including out of band verification of the PGP signature, DNSSEC- 606 based approaches, etc. 608 6.2. Redirects 610 When retrieving the file and any resources referenced in the file, 611 researchers should record any redirects since they can lead to a 612 different domain or IP address controlled by an attacker. Further 613 inspections of such redirects is recommended before using the 614 information contained within the file. 616 6.3. Incorrect or Stale Information 618 If information and resources referenced in a "security.txt" file are 619 incorrect or not kept up to date, this can result in security reports 620 not being received by the organization or sent to incorrect contacts, 621 thus exposing possible security issues to third parties. Not having 622 a security.txt file may be preferable to having stale information in 623 this file. Organizations must use the "Expires" field (see 624 Section 3.5.5) to indicate to researchers when the data in the file 625 is no longer valid. 627 Organizations should ensure that information in this file and any 628 referenced resources such as web pages, email addresses, and 629 telephone numbers are kept current, are accessible, controlled by the 630 organization, and are kept secure. 632 6.4. Intentionally Malformed Files, Resources and Reports 634 It is possible for compromised or malicious sites to create files 635 that are extraordinarily large or otherwise malformed in an attempt 636 to discover or exploit weaknesses in parsing code. Researchers 637 should make sure that any such code is robust against large or 638 malformed files and fields, and may choose not to parse files larger 639 than 32 KBs, having fields longer than 2,048 characters or containing 640 more than 1,000 lines. The ABNF grammar (as defined in Section 5) 641 can also be used as a way to verify these files. 643 The same concerns apply to any other resources referenced within 644 security.txt files, as well as any security reports received as a 645 result of publishing this file. Such resources and reports may be 646 hostile, malformed or malicious. 648 6.5. No Implied Permission for Testing 650 The presence of a security.txt file might be interpreted by 651 researchers as providing permission to do security testing against 652 the domain or IP address where it is published, or products and 653 services provided by the organization publishing the file. This 654 might result in increased testing against an organization by 655 researchers. On the other hand, a decision not to publish a 656 security.txt file might be interpreted by the organization operating 657 that website to be a way to signal to researchers that permission to 658 test that particular site or project is denied. This might result in 659 pushback against researchers reporting security issues to that 660 organization. 662 Therefore, researchers shouldn't assume that presence or absence of a 663 "security.txt" file grants or denies permission for security testing. 664 Any such permission may be indicated in the company's vulnerability 665 disclosure policy (as per Section 3.5.7) or a new field (as per 666 Section 3.4). 668 6.6. Multi-user Environments 670 In multi-user / multi-tenant environments, it may possible for a user 671 to take over the location of the "security.txt" file. Organizations 672 should reserve the "security.txt" namespace at the root to ensure no 673 third-party can create a page with the "security.txt" AND "/.well- 674 known/security.txt" names. 676 6.7. Protecting Data in Transit 678 To protect a "security.txt" file from being tampered with in transit, 679 implementors MUST use HTTPS (as per section 2.7.2 of [RFC7230]) when 680 serving the file itself and for retrieval of any web URIs referenced 681 in it (except when otherwise noted in this specification). As part 682 of the TLS handshake, researchers should validate the provided X.509 683 certificate in accordance with [RFC6125] and the following 684 considerations: 686 * Matching is performed only against the DNS-ID identifiers. 688 * DNS domain names in server certificates MAY contain the wildcard 689 character '*' as the complete left-most label within the 690 identifier. 692 The certificate may also be checked for revocation via the Online 693 Certificate Status Protocol (OCSP) [RFC6960], certificate revocation 694 lists (CRLs), or similar mechanisms. 696 In cases where the "security.txt" file cannot be served via HTTPS 697 (such as localhost) or is being served with an invalid certificate, 698 additional human validation is recommended since the contents may 699 have been modified while in transit. 701 As an additional layer of protection, it is also recommended that 702 organizations digitally sign their "security.txt" file with OpenPGP 703 (as per Section 3.3). Also, to protect security reports from being 704 tampered with or observed while in transit, organizations should 705 specify encryption keys (as per Section 3.5.4) unless HTTPS is being 706 used for report submission. 708 However, the determination of validity of such keys is out of scope 709 for this specification. Security researchers need to establish other 710 secure means to verify them. 712 6.8. Spam and Spurious Reports 714 Similar to concerns in [RFC2142], denial of service attacks via spam 715 reports would become easier once a "security.txt" file is published 716 by an organization. In addition, there is an increased likelihood of 717 reports being sent in an automated fashion and/or as result of 718 automated scans without human analysis. Attackers can also use this 719 file as a way to spam unrelated third parties by listing their 720 resources and/or contact information. 722 Organizations need to weigh the advantages of publishing this file 723 versus the possible disadvantages and increased resources required to 724 analyze security reports. 726 Security researchers should review all information within the 727 "security.txt" file before submitting reports in an automated fashion 728 or as resulting from automated scans. 730 7. IANA Considerations 732 Implementors should be aware that any resources referenced within a 733 security.txt file MUST NOT point to the Well-Known URIs namespace 734 unless they are registered with IANA (as per [RFC8615]). 736 7.1. Well-Known URIs registry 738 The "Well-Known URIs" registry should be updated with the following 739 additional values (using the template from [RFC8615]): 741 URI suffix: security.txt 743 Change controller: IETF 745 Specification document(s): this document 747 Status: permanent 749 7.2. Registry for security.txt Fields 751 IANA is requested to create the "security.txt Fields" registry in 752 accordance with [RFC8126]. This registry will contain fields for use 753 in security.txt files, defined by this specification. 755 New registrations or updates MUST be published in accordance with the 756 "Expert Review" guidelines as described in sections 4.5 and 5 of 757 [RFC8126]. Any new field thus registered is considered optional by 758 this specification unless a new version of this specification is 759 published. 761 Designated Experts are expected to check whether a proposed 762 registration or update makes sense in the context of industry 763 accepted vulnerability disclosure processes such as [ISO.29147.2018] 764 and [CERT.CVD], and provides value to organizations and researchers 765 using this format. 767 New registrations and updates MUST contain the following information: 769 1. Name of the field being registered or updated 770 2. Short description of the field 772 3. Whether the field can appear more than once 774 4. The document in which the specification of the field is published 775 (if available) 777 5. New or updated status, which MUST be one of: 779 * current: The field is in current use 781 * deprecated: The field has been in use, but new usage is 782 discouraged 784 * historic: The field is no longer in current use 786 6. Change controller 788 An update may make a notation on an existing registration indicating 789 that a registered field is historical or deprecated if appropriate. 791 The initial registry contains these values: 793 Field Name: Acknowledgments 794 Description: link to page where security researchers are recognized 795 Multiple Appearances: Yes 796 Published in: this document 797 Status: current 798 Change controller: IETF 800 Field Name: Canonical 801 Description: canonical URI for this file 802 Multiple Appearances: Yes 803 Published in: this document 804 Status: current 805 Change controller: IETF 807 Field Name: Contact 808 Description: contact information to use for reporting vulnerabilities 809 Multiple Appearances: Yes 810 Published in: this document 811 Status: current 812 Change controller: IETF 814 Field Name: Expires 815 Description: date and time after which this file is considered stale 816 Multiple Appearances: No 817 Published in: this document 818 Status: current 819 Change controller: IETF 821 Field Name: Encryption 822 Description: link to a key to be used for encrypted communication 823 Multiple Appearances: Yes 824 Published in: this document 825 Status: current 826 Change controller: IETF 828 Field Name: Hiring 829 Description: link to the vendor's security-related job positions 830 Multiple Appearances: Yes 831 Published in: this document 832 Status: current 833 Change controller: IETF 835 Field Name: Policy 836 Description: link to security policy page 837 Multiple Appearances: Yes 838 Published in: this document 839 Status: current 840 Change controller: IETF 842 Field Name: Preferred-Languages 843 Description: list of preferred languages for security reports 844 Multiple Appearances: No 845 Published in: this document 846 Status: current 847 Change controller: IETF 849 8. Contributors 851 The authors would like to acknowledge the help provided during the 852 development of this document by Tom Hudson, Jobert Abma, Gerben 853 Janssen van Doorn, Austin Heap, Stephane Bortzmeyer, Max Smith, 854 Eduardo Vela, and Krzysztof Kotowicz. 856 The authors would also like to acknowledge the feedback provided by 857 multiple members of IETF's LAST CALL, SAAG, and SECDISPATCH lists. 859 Yakov would like to also thank L.T.S. (for everything). 861 9. References 863 9.1. Normative References 865 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 866 Extensions (MIME) Part Two: Media Types", RFC 2046, 867 DOI 10.17487/RFC2046, November 1996, 868 . 870 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 871 Requirement Levels", BCP 14, RFC 2119, 872 DOI 10.17487/RFC2119, March 1997, 873 . 875 [RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and 876 Functions", RFC 2142, DOI 10.17487/RFC2142, May 1997, 877 . 879 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 880 Languages", BCP 18, RFC 2277, DOI 10.17487/RFC2277, 881 January 1998, . 883 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 884 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 885 2003, . 887 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 888 RFC 3966, DOI 10.17487/RFC3966, December 2004, 889 . 891 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 892 Resource Identifier (URI): Generic Syntax", STD 66, 893 RFC 3986, DOI 10.17487/RFC3986, January 2005, 894 . 896 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 897 Thayer, "OpenPGP Message Format", RFC 4880, 898 DOI 10.17487/RFC4880, November 2007, 899 . 901 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 902 Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, 903 . 905 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 906 Specifications: ABNF", STD 68, RFC 5234, 907 DOI 10.17487/RFC5234, January 2008, 908 . 910 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 911 DOI 10.17487/RFC5322, October 2008, 912 . 914 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 915 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 916 September 2009, . 918 [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' 919 URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010, 920 . 922 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 923 Verification of Domain-Based Application Service Identity 924 within Internet Public Key Infrastructure Using X.509 925 (PKIX) Certificates in the Context of Transport Layer 926 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 927 2011, . 929 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 930 Galperin, S., and C. Adams, "X.509 Internet Public Key 931 Infrastructure Online Certificate Status Protocol - OCSP", 932 RFC 6960, DOI 10.17487/RFC6960, June 2013, 933 . 935 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 936 Protocol (HTTP/1.1): Message Syntax and Routing", 937 RFC 7230, DOI 10.17487/RFC7230, June 2014, 938 . 940 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 941 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 942 DOI 10.17487/RFC7231, June 2014, 943 . 945 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 946 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 947 May 2017, . 949 [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers 950 (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, 951 . 953 9.2. Informative References 955 [CERT.CVD] Software Engineering Institute, Carnegie Mellon 956 University, "The CERT Guide to Coordinated Vulnerability 957 Disclosure (CMU/SEI-2017-SR-022)", 2017. 959 [ISO.29147.2018] 960 International Organization for Standardization (ISO), 961 "ISO/IEC 29147:2018, Information technology - Security 962 techniques - Vulnerability disclosure", 2018. 964 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 965 RFC 793, DOI 10.17487/RFC0793, September 1981, 966 . 968 [RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, 969 DOI 10.17487/RFC2196, September 1997, 970 . 972 [RFC2350] Brownlee, N. and E. Guttman, "Expectations for Computer 973 Security Incident Response", BCP 21, RFC 2350, 974 DOI 10.17487/RFC2350, June 1998, 975 . 977 [RFC3013] Killalea, T., "Recommended Internet Service Provider 978 Security Services and Procedures", BCP 46, RFC 3013, 979 DOI 10.17487/RFC3013, November 2000, 980 . 982 [RFC7485] Zhou, L., Kong, N., Shen, S., Sheng, S., and A. Servin, 983 "Inventory and Analysis of WHOIS Registration Objects", 984 RFC 7485, DOI 10.17487/RFC7485, March 2015, 985 . 987 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 988 Writing an IANA Considerations Section in RFCs", BCP 26, 989 RFC 8126, DOI 10.17487/RFC8126, June 2017, 990 . 992 Appendix A. Note to Readers 994 *Note to the RFC Editor:* Please remove this section prior to 995 publication. 997 Development of this draft takes place on Github at 998 https://github.com/securitytxt/security-txt 1000 Appendix B. Document History 1002 *Note to the RFC Editor:* Please remove this section prior to 1003 publication. 1005 B.1. Since draft-foudil-securitytxt-00 1006 * Moved to use IETF's markdown tools for draft updates 1008 * Added table of contents and a fuller list of references 1010 * Moved file to .well-known URI and added IANA registration (#3) 1012 * Added extensibility with an IANA registry for fields (#34) 1014 * Added text explaining relationship to RFC 2142 / security@ email 1015 address (#25) 1017 * Scope expanded to include internal hosts, domains, IP addresses 1018 and file systems 1020 * Support for digital signatures added (#19) 1022 The full list of changes can be viewed via the IETF document tracker: 1023 https://tools.ietf.org/html/draft-foudil-securitytxt-01 1025 B.2. Since draft-foudil-securitytxt-01 1027 * Added appendix with pointer to Github and document history 1029 * Added external signature file to the well known URI registry (#59) 1031 * Added policy field (#53) 1033 * Added diagram explaining the location of the file on public vs. 1034 internal systems 1036 * Added recommendation that external signature files should use 1037 HTTPS (#55) 1039 * Added recommendation that organizations should monitor their 1040 security.txt files (#14) 1042 The full list of changes can be viewed via the IETF document tracker: 1043 https://tools.ietf.org/html/draft-foudil-securitytxt-02 1045 B.3. Since draft-foudil-securitytxt-02 1047 * Use "mailto" and "tel" (#62) 1049 * Fix typo in the "Example" section (#64) 1051 * Clarified that the root directory is a fallback option (#72) 1053 * Defined content-type for the response (#68) 1054 * Clarify the scope of the security.txt file (#69) 1056 * Cleaning up text based on the NITS tools suggestions (#82) 1058 * Added clarification for newline values 1060 * Clarified the encryption field language, added examples of DNS- 1061 stored encryption keys (#28 and #94) 1063 * Added "Hiring" field 1065 B.4. Since draft-foudil-securitytxt-03 1067 * Added "Hiring" field to the registry section 1069 * Added an encryption example using a PGP fingerprint (#107) 1071 * Added reference to the mailing list (#111) 1073 * Added a section referencing related work (#113) 1075 * Fixes for idnits (#82) 1077 * Changing some references to informative instead of normative 1079 * Adding "Permission" field (#30) 1081 * Fixing remaining ABNF issues (#83) 1083 * Additional editorial changes and edits 1085 B.5. Since draft-foudil-securitytxt-04 1087 * Addressing IETF feedback (#118) 1089 * Case sensitivity clarification (#127) 1091 * Syntax fixes (#133, #135 and #136) 1093 * Removed permission field (#30) 1095 * Removed signature field and switched to inline signatures (#93 and 1096 #128) 1098 * Adding canonical field (#100) 1100 * Text and ABNF grammar improvements plus ABNF changes for comments 1101 (#123) 1103 * Changed ".security.txt" to "security.txt" to be consistent 1105 B.6. Since draft-foudil-securitytxt-05 1107 * Changing HTTPS to MUST (#55) 1109 * Adding language recommending encryption for email reports (#134) 1111 * Added language handling redirects (#143) 1113 * Expanded security considerations section and fixed typos (#30, 1114 #73, #103, #112) 1116 B.7. Since draft-foudil-securitytxt-06 1118 * Fixed ABNF grammar for non-chainable fields (#150) 1120 * Clarified ABNF grammar (#152) 1122 * Clarified redirect logic (#143) 1124 * Clarified comments (#158) 1126 * Updated references and template for well-known URI to RFC 8615 1128 * Fixed nits from the IETF validator 1130 B.8. Since draft-foudil-securitytxt-07 1132 * Addressing AD feedback (#165) 1134 * Fix for ABNF grammar in lang-values (#164) 1136 * Fixing idnits warnings 1138 * Adding guidance for designated experts 1140 B.9. Since draft-foudil-securitytxt-08 1142 * Added language and example regarding URI encoding (#176) 1144 * Add "Expires" field (#181) 1146 * Changed language from "directive" to "field" (#182) 1148 * Addressing last call feedback (#179, #180 and #183) 1150 * Clarifying order of fields (#174) 1151 * Revert comment/field association (#158) 1153 B.10. Since draft-foudil-securitytxt-09 1155 * Adjust ABNF to allow blank lines between directives (#191) 1157 * Make "Expires" field required (#190) 1159 * Adding a warning about the well-known URI namespace (#188) 1161 * Adding scope language around products/services (#185) 1163 * Addressing last call feedback (#189) 1165 B.11. Since draft-foudil-securitytxt-10 1167 * Changes addressing IESG feedback 1169 * Removed language regarding file systems (#201) 1171 * Adding language to explain alignment with the CERT CVD guide 1172 (#202) 1174 Full list of changes can be viewed via the IETF document tracker: 1175 https://tools.ietf.org/html/draft-foudil-securitytxt 1177 Authors' Addresses 1179 Edwin Foudil 1181 Email: contact@edoverflow.com 1183 Yakov Shafranovich 1184 Nightwatch Cybersecurity 1186 Email: yakov+ietf@nightwatchcybersecurity.com