idnits 2.17.1 draft-foudil-securitytxt-09.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 (February 25, 2020) is 1515 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 2818 (Obsoleted by RFC 9110) ** 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: 4 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: August 28, 2020 Nightwatch Cybersecurity 6 February 25, 2020 8 A File Format to Aid in Security Vulnerability Disclosure 9 draft-foudil-securitytxt-09 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 August 28, 2020. 37 Copyright Notice 39 Copyright (c) 2020 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 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Motivation, Prior Work and Scope . . . . . . . . . . . . 3 56 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Note to Readers . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. The Specification . . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. Scope of the File . . . . . . . . . . . . . . . . . . . . 5 60 3.2. Comments . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.3. Line Separator . . . . . . . . . . . . . . . . . . . . . 6 62 3.4. Digital signature . . . . . . . . . . . . . . . . . . . . 6 63 3.5. Field Definitions . . . . . . . . . . . . . . . . . . . . 6 64 3.5.1. Acknowledgments . . . . . . . . . . . . . . . . . . . 6 65 3.5.2. Canonical . . . . . . . . . . . . . . . . . . . . . . 7 66 3.5.3. Contact . . . . . . . . . . . . . . . . . . . . . . . 7 67 3.5.4. Encryption . . . . . . . . . . . . . . . . . . . . . 7 68 3.5.5. Expires . . . . . . . . . . . . . . . . . . . . . . . 8 69 3.5.6. Hiring . . . . . . . . . . . . . . . . . . . . . . . 8 70 3.5.7. Policy . . . . . . . . . . . . . . . . . . . . . . . 8 71 3.5.8. Preferred-Languages . . . . . . . . . . . . . . . . . 9 72 3.6. Example of an unsigned "security.txt" file . . . . . . . 9 73 3.7. Example of a signed "security.txt" file . . . . . . . . . 9 74 4. Location of the security.txt file . . . . . . . . . . . . . . 10 75 4.1. Web-based services . . . . . . . . . . . . . . . . . . . 10 76 4.2. Filesystems . . . . . . . . . . . . . . . . . . . . . . . 10 77 4.3. Extensibility . . . . . . . . . . . . . . . . . . . . . . 11 78 5. File Format Description and ABNF Grammar . . . . . . . . . . 11 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 80 6.1. Compromised Files and Redirects . . . . . . . . . . . . . 13 81 6.2. Incorrect or Stale Information . . . . . . . . . . . . . 13 82 6.3. Intentionally Malformed Files, Resources and Reports . . 13 83 6.4. No Implied Permission for Testing . . . . . . . . . . . . 14 84 6.5. Multi-user Environments . . . . . . . . . . . . . . . . . 14 85 6.6. Protecting Data in Transit . . . . . . . . . . . . . . . 14 86 6.7. Spam and Spurious Reports . . . . . . . . . . . . . . . . 15 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 88 7.1. Well-Known URIs registry . . . . . . . . . . . . . . . . 16 89 7.2. Registry for security.txt Fields . . . . . . . . . . . . 16 90 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 92 9.1. Normative References . . . . . . . . . . . . . . . . . . 18 93 9.2. Informative References . . . . . . . . . . . . . . . . . 20 94 Appendix A. Note to Readers . . . . . . . . . . . . . . . . . . 21 95 Appendix B. Document History . . . . . . . . . . . . . . . . . . 22 96 B.1. Since draft-foudil-securitytxt-00 . . . . . . . . . . . . 22 97 B.2. Since draft-foudil-securitytxt-01 . . . . . . . . . . . . 22 98 B.3. Since draft-foudil-securitytxt-02 . . . . . . . . . . . . 23 99 B.4. Since draft-foudil-securitytxt-03 . . . . . . . . . . . . 23 100 B.5. Since draft-foudil-securitytxt-04 . . . . . . . . . . . . 23 101 B.6. Since draft-foudil-securitytxt-05 . . . . . . . . . . . . 24 102 B.7. Since draft-foudil-securitytxt-06 . . . . . . . . . . . . 24 103 B.8. Since draft-foudil-securitytxt-07 . . . . . . . . . . . . 24 104 B.9. Since draft-foudil-securitytxt-08 . . . . . . . . . . . . 25 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 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 vulnerabilities. That convention provides only a 120 single, email-based channel of communication for security 121 vulnerabilities per domain, and does not provide a way for domain 122 owners to publish information about their security disclosure 123 practices. 125 There are also contact conventions prescribed for Internet Service 126 Providers (ISPs) in section 2 of [RFC3013], for Computer Security 127 Incident Response Teams (CSIRTs) in section 3.2 of [RFC2350] and for 128 site operators in section 5.2 of [RFC2196]. As per [RFC7485], there 129 is also contact information provided by Regional Internet Registries 130 (RIRs) and domain registries for owners of IP addresses, autonomous 131 system numbers (ASNs), and domain names. However, none of these 132 address the issue of how security researchers can locate contact 133 information and vulnerability disclosure practices for organizations 134 in order to report vulnerabilities. 136 In this document, we define a richer and more extensible way for 137 organizations to communicate information about their security 138 disclosure practices and ways to contact them. Other details of 139 vulnerability disclosure are outside the scope of this document. 140 Readers are encouraged to consult other documents such as 141 [ISO.29147.2018] or [CERT.CVD]. 143 1.2. Terminology 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 147 "OPTIONAL" in this document are to be interpreted as described in BCP 148 14 [RFC2119] [RFC8174] when, and only when, they appear in all 149 capitals, as shown here. 151 2. Note to Readers 153 *Note to the RFC Editor:* Please remove this section prior to 154 publication. 156 Development of this draft takes place on Github at: 157 https://github.com/securitytxt/security-txt 159 3. The Specification 161 This document defines a text file to be placed in a known location 162 that provides information about the vulnerability disclosure 163 practices of a particular organization. This is intended to help 164 security researchers when disclosing security vulnerabilities. 166 By convention, the file is named "security.txt". 168 When made available on HTTP servers, it MUST be placed under the 169 /.well-known/ path (as "/.well-known/security.txt") [RFC8615] of a 170 domain name or IP address. For legacy compatibility, a security.txt 171 file might be placed at the top level path (see Section 4.1). For 172 file systems a "security.txt" file SHOULD be placed in the root 173 directory of the file system. 175 On HTTP servers, the file MUST be accessed via HTTP 1.0 or a higher 176 version and the "https" scheme (as per [RFC1945] and section 2.7.2 of 177 [RFC7230]). It MUST have a Content-Type of "text/plain" with the 178 default charset parameter set to "utf-8" (as per section 4.1.3 of 179 [RFC2046]). 181 This text file contains multiple fields with different values. A 182 field contains a "name" which is the first part of a field all the 183 way up to the colon ("Contact:") and follows the syntax defined for 184 "field-name" in section 3.6.8 of [RFC5322]. Fields are case- 185 insensitive (as per section 2.3 of [RFC5234]). The "value" comes 186 after the field name ("https://example.com/security") and follows the 187 syntax defined for "unstructured" in section 3.2.5 of [RFC5322]. 189 A "field" MUST always consist of a name and a value ("Contact: 190 https://example.com/security"). A security.txt file can have an 191 unlimited number of fields. It is important to note that each field 192 MUST appear on its own line. Unless specified otherwise by the field 193 definition, multiple values MUST NOT be chained together for a single 194 field. Unless otherwise indicated in a definition of a particular 195 field, any field MAY appear multiple times. 197 Implementors should be aware that some of the fields may contain URIs 198 using percent-encoding (as per section 2.1 of [RFC3986]). 200 3.1. Scope of the File 202 For HTTP servers, a "security.txt" file MUST only apply to the domain 203 or IP address in the URI used to retrieve it, not to any of its 204 subdomains or parent domains. 206 A "security.txt" file that is found in a file system MUST only apply 207 to the folder in which it is located and that folder's subfolders. 208 The file does not apply to any of the folder's parent or sibling 209 folders. 211 Some examples appear below: 213 # The following only applies to example.com. 214 https://example.com/.well-known/security.txt 216 # This only applies to subdomain.example.com. 217 https://subdomain.example.com/.well-known/security.txt 219 # This security.txt file applies to IPv4 address of 192.0.2.0. 220 https://192.0.2.0/.well-known/security.txt 222 # This security.txt file applies to IPv6 address of 2001:db8:8:4::2. 223 https://[2001:db8:8:4::2]/.well-known/security.txt 225 # This file applies to the /example/folder1 directory and subfolders. 226 /example/folder1/security.txt 228 3.2. Comments 230 Any line beginning with the "#" (%x30) symbol MUST be interpreted as 231 a comment. The content of the comment may contain any ASCII or 232 Unicode characters in the %x21-7E and %x80-FFFFF ranges plus the tab 233 (%x09) and space (%x20) characters. 235 Example: 237 # This is a comment. 239 3.3. Line Separator 241 Every line MUST end either with a carriage return and line feed 242 characters (CRLF / %x0D %x0A) or just a line feed character (LF / 243 %x0A). 245 3.4. Digital signature 247 It is RECOMMENDED that a security.txt file be digitally signed using 248 an OpenPGP cleartext signature as described in section 7 of 249 [RFC4880]. When digital signatures are used, it is also RECOMMENDED 250 that implementors use the "Canonical" field (as per Section 3.5.2), 251 thus allowing the digital signature to authenticate the location of 252 the file. 254 When it comes to verifying the key used to generate the signature, it 255 is always the security researcher's responsibility to make sure the 256 key being used is indeed one they trust. 258 3.5. Field Definitions 260 3.5.1. Acknowledgments 262 This field indicates a link to a page where security researchers are 263 recognized for their reports. The page being referenced should list 264 individuals or organizations that reported security vulnerabilities 265 and collaborated to remediate them. Organizations should be careful 266 to limit the vulnerability information being published in order to 267 prevent future attacks. 269 If this field indicates a web URL, then it MUST begin with "https://" 270 (as per section 2.7.2 of [RFC7230]). 272 Example: 274 Acknowledgments: https://example.com/hall-of-fame.html 276 Example security acknowledgments page: 278 We would like to thank the following researchers: 280 (2017-04-15) Frank Denis - Reflected cross-site scripting 281 (2017-01-02) Alice Quinn - SQL injection 282 (2016-12-24) John Buchner - Stored cross-site scripting 283 (2016-06-10) Anna Richmond - A server configuration issue 285 3.5.2. Canonical 287 This field indicates the canonical URIs where the security.txt file 288 is located, which is usually something like 289 "https://example.com/.well-known/security.txt". If this field 290 indicates a web URL, then it MUST begin with "https://" (as per 291 section 2.7.2 of [RFC7230]). The purpose of this field is to allow a 292 digital signature to be applied to the locations of the 293 "security.txt" file. 295 Canonical: https://www.example.com/.well-known/security.txt 296 Canonical: https://someserver.example.com/.well-known/security.txt 298 3.5.3. Contact 300 This field indicates an address that researchers should use for 301 reporting security vulnerabilities such as an email address, a phone 302 number and/or a web page with contact information. The "Contact" 303 field MUST always be present in a security.txt file. If this field 304 indicates a web URL, then it MUST begin with "https://" (as per 305 section 2.7.2 of [RFC7230]). Security email addresses should use the 306 conventions defined in section 4 of [RFC2142]. 308 The value MUST follow the URI syntax described in [RFC3986]. This 309 means that "mailto" and "tel" URI schemes must be used when 310 specifying email addresses and telephone numbers, as defined in 311 [RFC6068] and [RFC3966]. When the value of this field is an email 312 address, it is RECOMMENDED that encryption be used (as per 313 Section 3.5.4). 315 The precedence SHOULD be in listed order. The first field is the 316 preferred method of contact. In the example below, the email address 317 is the preferred method of contact. 319 Contact: mailto:security@example.com 320 Contact: mailto:security%2Buri%2Bencoded@example.com 321 Contact: tel:+1-201-555-0123 322 Contact: https://example.com/security-contact.html 324 3.5.4. Encryption 326 This field indicates an encryption key that security researchers 327 should use for encrypted communication. Keys MUST NOT appear in this 328 field - instead the value of this field MUST be a URI pointing to a 329 location where the key can be retrieved. If this field indicates a 330 web URL, then it MUST begin with "https://" (as per section 2.7.2 of 331 [RFC7230]). 333 When it comes to verifying the authenticity of the key, it is always 334 the security researcher's responsibility to make sure the key being 335 specified is indeed one they trust. Researchers must not assume that 336 this key is used to generate the digital signature referenced in 337 Section 3.4. 339 Example of an OpenPGP key available from a web server: 341 Encryption: https://example.com/pgp-key.txt 343 Example of an OpenPGP key available from an OPENPGPKEY DNS record: 345 Encryption: dns:5d2d37ab76d47d36._openpgpkey.example.com?type=OPENPGPKEY 347 Example of an OpenPGP key being referenced by its fingerprint: 349 Encryption: openpgp4fpr:5f2de5521c63a801ab59ccb603d49de44b29100f 351 3.5.5. Expires 353 This field indicates the date and time after which the data contained 354 in the "security.txt" file is considered stale and should not be used 355 (as per Section 6.2). The value of this field follows the format 356 defined in section 3.3 of [RFC5322]. 358 This field MUST NOT appear more than once. 360 Expires: Thu, 31 Dec 2020 18:37:07 -0800 362 3.5.6. Hiring 364 The "Hiring" field is used for linking to the vendor's security- 365 related job positions. If this field indicates a web URL, then it 366 MUST begin with "https://" (as per section 2.7.2 of [RFC7230]). 368 Hiring: https://example.com/jobs.html 370 3.5.7. Policy 372 This field indicates a link to where the vulnerability disclosure 373 policy is located. This can help security researchers understand the 374 organization's vulnerability reporting practices. If this field 375 indicates a web URL, then it MUST begin with "https://" (as per 376 section 2.7.2 of [RFC7230]). 378 Example: 380 Policy: https://example.com/disclosure-policy.html 382 3.5.8. Preferred-Languages 384 This field can be used to indicate a set of natural languages that 385 are preferred when submitting security reports. This set MAY list 386 multiple values, separated by commas. If this field is included then 387 at least one value MUST be listed. The values within this set are 388 language tags (as defined in [RFC5646]). If this field is absent, 389 security researchers may assume that English is the language to be 390 used (as per section 4.5 of [RFC2277]). 392 The order in which they appear MUST NOT be interpreted as an 393 indication of priority - rather these MUST be interpreted as all 394 being of equal priority. 396 This field MUST NOT appear more than once. 398 Example (English, Spanish and French): 400 Preferred-Languages: en, es, fr 402 3.6. Example of an unsigned "security.txt" file 404 # Our security address 405 Contact: mailto:security@example.com 407 # Our OpenPGP key 408 Encryption: https://example.com/pgp-key.txt 410 # Our security policy 411 Policy: https://example.com/security-policy.html 413 # Our security acknowledgments page 414 Acknowledgments: https://example.com/hall-of-fame.html 416 3.7. Example of a signed "security.txt" file 417 ----BEGIN PGP SIGNED MESSAGE----- 418 Hash: SHA256 420 # Canonical URL 421 Canonical: https://example.com/.well-known/security.txt 423 # Our security address 424 Contact: mailto:security@example.com 426 # Our OpenPGP key 427 Encryption: https://example.com/pgp-key.txt 429 # Our security policy 430 Policy: https://example.com/security-policy.html 432 # Our security acknowledgments page 433 Acknowledgments: https://example.com/hall-of-fame.html 434 -----BEGIN PGP SIGNATURE----- 435 Version: GnuPG v2.2 437 [signature] 438 -----END PGP SIGNATURE----- 440 4. Location of the security.txt file 442 4.1. Web-based services 444 Web-based services MUST place the security.txt file under the 445 "/.well-known/" path; e.g. https://example.com/.well-known/ 446 security.txt as per [RFC8615]. For legacy compatibility, a 447 security.txt file might be placed at the top-level path or redirect 448 (as per section 6.4 of [RFC7231]) to the security.txt file under the 449 "/.well-known/" path. If a "security.txt" file is present in both 450 locations, the one in the "/.well-known/" path MUST be used. 452 Retrieval of "security.txt" files and resources indicated within such 453 files may result in a redirect (as per section 6.4 of [RFC7231]). 454 Researchers should perform additional triage (as per Section 6.1) to 455 make sure these redirects are not malicious or point to resources 456 controlled by an attacker. 458 4.2. Filesystems 460 File systems SHOULD place the "security.txt" file under the root 461 directory; e.g., "/security.txt", "C:\security.txt". 463 Example file system: 465 /example-directory-1/ 466 /example-directory-2/ 467 /example-directory-3/ 468 /example-file 469 /security.txt 471 4.3. Extensibility 473 Like many other formats and protocols, this format may need to be 474 extended over time to fit the ever-changing landscape of the 475 Internet. Therefore, extensibility is provided via an IANA registry 476 for fields as defined in Section 7.2. Any fields registered via that 477 process MUST be considered optional. To encourage extensibility and 478 interoperability, implementors MUST ignore any fields they do not 479 explicitly support. 481 In general, implementors should "be conservative in what you do, be 482 liberal in what you accept from others" (as per [RFC0793]). 484 5. File Format Description and ABNF Grammar 486 The expected file format of the security.txt file is plain text (MIME 487 type "text/plain") as defined in section 4.1.3 of [RFC2046] and is 488 encoded using UTF-8 [RFC3629] in Net-Unicode form [RFC5198]. 490 The following is an ABNF definition of the security.txt format, using 491 the conventions defined in [RFC5234]. 493 body = signed / unsigned 495 signed = sign-header unsigned sign-footer 497 sign-header = < headers and line from section 7 of [RFC4880] > 499 sign-footer = < OpenPGP signature from section 7 of [RFC4880] > 501 unsigned = *line (contact-field eol) 502 *line [expires-field eol] 503 *line [lang-field eol] *line 504 ; order of fields within the file is not important 506 line = (field / comment) eol 508 eol = *WSP [CR] LF 510 field = ack-field / 511 can-field / 512 contact-field / 513 encryption-field / 514 hiring-field / 515 policy-field / 516 ext-field 518 fs = ":" 520 comment = "#" *(WSP / VCHAR / %x80-FFFFF) 522 ack-field = "Acknowledgments" fs SP uri 524 can-field = "Canonical" fs SP uri 526 contact-field = "Contact" fs SP uri 528 expires-field = "Expires" fs SP date-time 530 encryption-field = "Encryption" fs SP uri 532 hiring-field = "Hiring" fs SP uri 534 lang-field = "Preferred-Languages" fs SP lang-values 536 policy-field = "Policy" fs SP uri 538 date-time = < imported from section 3.3 of [RFC5322] > 540 lang-tag = < Language-Tag from section 2.1 of [RFC5646] > 542 lang-values = lang-tag *(*WSP "," *WSP lang-tag) 544 uri = < URI as per [RFC3986] > 546 ext-field = field-name fs SP unstructured 548 field-name = < imported from section 3.6.8 of [RFC5322] > 550 unstructured = < imported from section 3.2.5 of [RFC5322] > 552 "ext-field" refers to extension fields, which are discussed in 553 Section 4.3 555 6. Security Considerations 557 In addition to the security considerations of [RFC8615], the 558 following considerations apply. 560 6.1. Compromised Files and Redirects 562 An attacker that has compromised a website is able to compromise the 563 "security.txt" file as well or setup a redirect to their own site. 564 This can result in security reports not being received by the 565 organization or sent to the attacker. 567 To protect against this, organizations should use the "Canonical" 568 field to indicate the locations of the file (as per Section 3.5.2), 569 digitally sign their "security.txt" files (as per Section 3.4), and 570 regularly monitor the file and the referenced resources to detect 571 tampering. 573 Security researchers should triage the "security.txt" file including 574 verifying the digital signature and checking any available historical 575 records before using the information contained in the file. If the 576 "security.txt" file looks suspicious or compromised, it should not be 577 used. 579 When retrieving the file and any resources referenced in the file, 580 researchers should record any redirects since they can lead to a 581 different domain or IP address controlled by an attacker. Further 582 inspections of such redirects is recommended before using the 583 information contained within the file. 585 6.2. Incorrect or Stale Information 587 If information and resources referenced in a "security.txt" file are 588 incorrect or not kept up to date, this can result in security reports 589 not being received by the organization or sent to incorrect contacts, 590 thus exposing possible security issues to third parties. Not having 591 a security.txt file may be preferable to having stale information in 592 this file. Organizations are also encouraged to use the "Expires" 593 field (see Section 3.5.5) to indicate to researchers when the data in 594 the file is no longer valid. 596 Organizations should ensure that information in this file and any 597 referenced resources such as web pages, email addresses, and 598 telephone numbers are kept current, are accessible, controlled by the 599 organization, and are kept secure. 601 6.3. Intentionally Malformed Files, Resources and Reports 603 It is possible for compromised or malicious sites to create files 604 that are extraordinarily large or otherwise malformed in an attempt 605 to discover or exploit weaknesses in parsing code. Implementors 606 should make sure that any such code is robust against large or 607 malformed files and fields and may choose not to parse files larger 608 than 32 KBs, having fields longer than 2,048 characters or containing 609 more than 1,000 lines. The ABNF grammar (as defined in Section 5) 610 can also be used as a way to verify these files. 612 The same concerns apply to any other resources referenced within 613 security.txt files, as well as any security reports received as a 614 result of publishing this file. Such resources and reports may be 615 hostile, malformed or malicious. 617 6.4. No Implied Permission for Testing 619 The presence of a security.txt file might be interpreted by 620 researchers as providing permission to do security testing against 621 that asset. This might result in increased testing against an 622 organization by researchers. On the other hand, a decision not to 623 publish a security.txt file might be interpreted by the organization 624 operating that website to be a way to signal to researchers that 625 permission to test that particular site or project is denied. This 626 might result in pushback against researchers reporting security 627 issues to that organization. 629 Therefore, implementors shouldn't assume that presence or absence of 630 a "security.txt" file grants or denies permission for security 631 testing. Any such permission may be indicated in the company's 632 vulnerability disclosure policy (as per Section 3.5.7) or a new field 633 (as per Section 4.3). 635 6.5. Multi-user Environments 637 In multi-user / multi-tenant environments, it may possible for a user 638 to take over the location of the "security.txt" file. Organizations 639 should reserve the "security.txt" namespace at the root to ensure no 640 third-party can create a page with the "security.txt" AND "/.well- 641 known/security.txt" names. 643 6.6. Protecting Data in Transit 645 To protect a "security.txt" file from being tampered with in transit, 646 implementors should use HTTPS (as per [RFC2818]) when serving the 647 file itself and for retrieval of any web URLs referenced in it 648 (except when otherwise noted in this specification). As part of the 649 TLS handshake, implementors should validate the provided X.509 650 certificate in accordance with [RFC6125] and the following 651 considerations: 653 o Matching is performed only against the DNS-ID identifiers. 655 o DNS domain names in server certificates MAY contain the wildcard 656 character '*' as the complete left-most label within the 657 identifier. 659 The certificate may also be checked for revocation via the Online 660 Certificate Status Protocol (OCSP) [RFC6960], certificate revocation 661 lists (CRLs), or similar mechanisms. 663 In cases where the "security.txt" file cannot be served via HTTPS or 664 is being served with an invalid certificate, additional human triage 665 is recommended since the contents may have been modified while in 666 transit. 668 As an additional layer of protection, it is also recommended that 669 organizations digitally sign their "security.txt" file with OpenPGP 670 (as per Section 3.4). Also, to protect security reports from being 671 tampered with or observed while in transit, organizations should 672 specify encryption keys (as per Section 3.5.4) unless HTTPS is being 673 used. 675 However, the determination of validity of such keys is out of scope 676 for this specification. Security researchers need to establish other 677 secure means to verify them. 679 6.7. Spam and Spurious Reports 681 Similar to concerns in [RFC2142], denial of service attacks via spam 682 reports would become easier once a "security.txt" file is published 683 by an organization. In addition, there is an increased likelihood of 684 reports being sent in an automated fashion and/or as result of 685 automated scans without human triage. Attackers can also use this 686 file as a way to spam unrelated third parties by listing their 687 resources and/or contact information. 689 Organizations need to weigh the advantages of publishing this file 690 versus the possible disadvantages and increased resources required to 691 triage security reports. 693 Security researchers should review all information within the 694 "security.txt" file before submitting reports in an automated fashion 695 or as resulting from automated scans. 697 7. IANA Considerations 699 example.com is used in this document following the uses indicated in 700 [RFC2606]. 702 192.0.2.0 and 2001:db8:8:4::2 are used in this document following the 703 uses indicated in [RFC6890]. 705 7.1. Well-Known URIs registry 707 The "Well-Known URIs" registry should be updated with the following 708 additional values (using the template from [RFC8615]): 710 URI suffix: security.txt 712 Change controller: IETF 714 Specification document(s): this document 716 Status: permanent 718 7.2. Registry for security.txt Fields 720 IANA is requested to create the "security.txt Fields" registry in 721 accordance with [RFC8126]. This registry will contain fields for use 722 in security.txt files, defined by this specification. 724 New registrations or updates MUST be published in accordance with the 725 "Expert Review" guidelines as described in sections 4.5 and 5 of 726 [RFC8126]. Any new field thus registered is considered optional by 727 this specification unless a new version of this specification is 728 published. 730 Designated Experts are expected to check whether a proposed 731 registration or update makes sense in the context of industry 732 accepted vulnerability disclosure processes such as [ISO.29147.2018] 733 and [CERT.CVD], and provides value to organizations and researchers 734 using this format. 736 New registrations and updates MUST contain the following information: 738 1. Name of the field being registered or updated 740 2. Short description of the field 742 3. Whether the field can appear more than once 744 4. The document in which the specification of the field is published 745 (if available) 747 5. New or updated status, which MUST be one of: 749 * current: The field is in current use 750 * deprecated: The field is in current use, but its use is 751 discouraged 753 * historic: The field is no longer in current use 755 6. Change controller 757 An update may make a notation on an existing registration indicating 758 that a registered field is historical or deprecated if appropriate. 760 The initial registry contains these values: 762 Field Name: Acknowledgments 763 Description: link to page where security researchers are recognized 764 Multiple Appearances: Yes 765 Published in: this document 766 Status: current 767 Change controller: IESG 769 Field Name: Canonical 770 Description: canonical URL for this file 771 Multiple Appearances: No 772 Published in: this document 773 Status: current 774 Change controller: IESG 776 Field Name: Contact 777 Description: contact information to use for reporting vulnerabilities 778 Multiple Appearances: Yes 779 Published in: this document 780 Status: current 781 Change controller: IESG 783 Field Name: Expires 784 Description: date and time after which this file is considered stale 785 Multiple Appearances: No 786 Published in: this document 787 Status: current 788 Change controller: IESG 790 Field Name: Encryption 791 Description: link to a key to be used for encrypted communication 792 Multiple Appearances: Yes 793 Published in: this document 794 Status: current 795 Change controller: IESG 797 Field Name: Hiring 798 Description: link to the vendor's security-related job positions 799 Multiple Appearances: Yes 800 Published in: this document 801 Status: current 802 Change controller: IESG 804 Field Name: Policy 805 Description: link to security policy page 806 Multiple Appearances: Yes 807 Published in: this document 808 Status: current 809 Change controller: IESG 811 Field Name: Preferred-Languages 812 Description: list of preferred languages for security reports 813 Multiple Appearances: No 814 Published in: this document 815 Status: current 816 Change controller: IESG 818 8. Contributors 820 The authors would like to acknowledge the help provided during the 821 development of this document by Tom Hudson, Jobert Abma, Gerben 822 Janssen van Doorn, Austin Heap, Stephane Bortzmeyer, Max Smith, 823 Eduardo Vela, and Krzysztof Kotowicz. 825 The authors would also like to acknowledge the feedback provided by 826 multiple members of IETF's LAST CALL, SAAG, and SECDISPATCH lists. 828 Yakov would like to also thank L.T.S. (for everything). 830 9. References 832 9.1. Normative References 834 [RFC1945] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext 835 Transfer Protocol -- HTTP/1.0", RFC 1945, 836 DOI 10.17487/RFC1945, May 1996, 837 . 839 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 840 Extensions (MIME) Part Two: Media Types", RFC 2046, 841 DOI 10.17487/RFC2046, November 1996, 842 . 844 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 845 Requirement Levels", BCP 14, RFC 2119, 846 DOI 10.17487/RFC2119, March 1997, 847 . 849 [RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and 850 Functions", RFC 2142, DOI 10.17487/RFC2142, May 1997, 851 . 853 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 854 Languages", BCP 18, RFC 2277, DOI 10.17487/RFC2277, 855 January 1998, . 857 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 858 DOI 10.17487/RFC2818, May 2000, 859 . 861 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 862 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 863 2003, . 865 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 866 RFC 3966, DOI 10.17487/RFC3966, December 2004, 867 . 869 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 870 Resource Identifier (URI): Generic Syntax", STD 66, 871 RFC 3986, DOI 10.17487/RFC3986, January 2005, 872 . 874 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 875 Thayer, "OpenPGP Message Format", RFC 4880, 876 DOI 10.17487/RFC4880, November 2007, 877 . 879 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 880 Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, 881 . 883 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 884 Specifications: ABNF", STD 68, RFC 5234, 885 DOI 10.17487/RFC5234, January 2008, 886 . 888 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 889 DOI 10.17487/RFC5322, October 2008, 890 . 892 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 893 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 894 September 2009, . 896 [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' 897 URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010, 898 . 900 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 901 Verification of Domain-Based Application Service Identity 902 within Internet Public Key Infrastructure Using X.509 903 (PKIX) Certificates in the Context of Transport Layer 904 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 905 2011, . 907 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 908 Galperin, S., and C. Adams, "X.509 Internet Public Key 909 Infrastructure Online Certificate Status Protocol - OCSP", 910 RFC 6960, DOI 10.17487/RFC6960, June 2013, 911 . 913 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 914 Protocol (HTTP/1.1): Message Syntax and Routing", 915 RFC 7230, DOI 10.17487/RFC7230, June 2014, 916 . 918 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 919 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 920 DOI 10.17487/RFC7231, June 2014, 921 . 923 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 924 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 925 May 2017, . 927 [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers 928 (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, 929 . 931 9.2. Informative References 933 [CERT.CVD] 934 Software Engineering Institute, Carnegie Mellon 935 University, "The CERT Guide to Coordinated Vulnerability 936 Disclosure (CMU/SEI-2017-SR-022)", 2017. 938 [ISO.29147.2018] 939 International Organization for Standardization (ISO), 940 "ISO/IEC 29147:2018, Information technology -- Security 941 techniques -- Vulnerability disclosure", 2018. 943 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 944 RFC 793, DOI 10.17487/RFC0793, September 1981, 945 . 947 [RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, 948 DOI 10.17487/RFC2196, September 1997, 949 . 951 [RFC2350] Brownlee, N. and E. Guttman, "Expectations for Computer 952 Security Incident Response", BCP 21, RFC 2350, 953 DOI 10.17487/RFC2350, June 1998, 954 . 956 [RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS 957 Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999, 958 . 960 [RFC3013] Killalea, T., "Recommended Internet Service Provider 961 Security Services and Procedures", BCP 46, RFC 3013, 962 DOI 10.17487/RFC3013, November 2000, 963 . 965 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 966 "Special-Purpose IP Address Registries", BCP 153, 967 RFC 6890, DOI 10.17487/RFC6890, April 2013, 968 . 970 [RFC7485] Zhou, L., Kong, N., Shen, S., Sheng, S., and A. Servin, 971 "Inventory and Analysis of WHOIS Registration Objects", 972 RFC 7485, DOI 10.17487/RFC7485, March 2015, 973 . 975 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 976 Writing an IANA Considerations Section in RFCs", BCP 26, 977 RFC 8126, DOI 10.17487/RFC8126, June 2017, 978 . 980 Appendix A. Note to Readers 982 *Note to the RFC Editor:* Please remove this section prior to 983 publication. 985 Development of this draft takes place on Github at 986 https://github.com/securitytxt/security-txt 988 Appendix B. Document History 990 *Note to the RFC Editor:* Please remove this section prior to 991 publication. 993 B.1. Since draft-foudil-securitytxt-00 995 o Moved to use IETF's markdown tools for draft updates 997 o Added table of contents and a fuller list of references 999 o Moved file to .well-known URI and added IANA registration (#3) 1001 o Added extensibility with an IANA registry for fields (#34) 1003 o Added text explaining relationship to RFC 2142 / security@ email 1004 address (#25) 1006 o Scope expanded to include internal hosts, domains, IP addresses 1007 and file systems 1009 o Support for digital signatures added (#19) 1011 The full list of changes can be viewed via the IETF document tracker: 1012 https://tools.ietf.org/html/draft-foudil-securitytxt-01 1014 B.2. Since draft-foudil-securitytxt-01 1016 o Added appendix with pointer to Github and document history 1018 o Added external signature file to the well known URI registry (#59) 1020 o Added policy field (#53) 1022 o Added diagram explaining the location of the file on public vs. 1023 internal systems 1025 o Added recommendation that external signature files should use 1026 HTTPS (#55) 1028 o Added recommendation that organizations should monitor their 1029 security.txt files (#14) 1031 The full list of changes can be viewed via the IETF document tracker: 1032 https://tools.ietf.org/html/draft-foudil-securitytxt-02 1034 B.3. Since draft-foudil-securitytxt-02 1036 o Use "mailto" and "tel" (#62) 1038 o Fix typo in the "Example" section (#64) 1040 o Clarified that the root directory is a fallback option (#72) 1042 o Defined content-type for the response (#68) 1044 o Clarify the scope of the security.txt file (#69) 1046 o Cleaning up text based on the NITS tools suggestions (#82) 1048 o Added clarification for newline values 1050 o Clarified the encryption field language, added examples of DNS- 1051 stored encryption keys (#28 and #94) 1053 o Added "Hiring" field 1055 B.4. Since draft-foudil-securitytxt-03 1057 o Added "Hiring" field to the registry section 1059 o Added an encryption example using a PGP fingerprint (#107) 1061 o Added reference to the mailing list (#111) 1063 o Added a section referencing related work (#113) 1065 o Fixes for idnits (#82) 1067 o Changing some references to informative instead of normative 1069 o Adding "Permission" field (#30) 1071 o Fixing remaining ABNF issues (#83) 1073 o Additional editorial changes and edits 1075 B.5. Since draft-foudil-securitytxt-04 1077 o Addressing IETF feedback (#118) 1079 o Case sensitivity clarification (#127) 1081 o Syntax fixes (#133, #135 and #136) 1082 o Removed permission field (#30) 1084 o Removed signature field and switched to inline signatures (#93 and 1085 #128) 1087 o Adding canonical field (#100) 1089 o Text and ABNF grammar improvements plus ABNF changes for comments 1090 (#123) 1092 o Changed ".security.txt" to "security.txt" to be consistent 1094 B.6. Since draft-foudil-securitytxt-05 1096 o Changing HTTPS to MUST (#55) 1098 o Adding language recommending encryption for email reports (#134) 1100 o Added language handling redirects (#143) 1102 o Expanded security considerations section and fixed typos (#30, 1103 #73, #103, #112) 1105 B.7. Since draft-foudil-securitytxt-06 1107 o Fixed ABNF grammar for non-chainable fields (#150) 1109 o Clarified ABNF grammar (#152) 1111 o Clarified redirect logic (#143) 1113 o Clarified comments (#158) 1115 o Updated references and template for well-known URI to RFC 8615 1117 o Fixed nits from the IETF validator 1119 B.8. Since draft-foudil-securitytxt-07 1121 o Addressing AD feedback (#165) 1123 o Fix for ABNF grammar in lang-values (#164) 1125 o Fixing idnits warnings 1127 o Adding guidance for designated experts 1129 B.9. Since draft-foudil-securitytxt-08 1131 o Added language and example regarding URI encoding (#176) 1133 o Add "Expires" field (#181) 1135 o Changed language from "directive" to "field" (#182) 1137 o Addressing last call feedback (#179, #180 and #183) 1139 o Clarifying order of fields (#174) 1141 o Revert comment/field association (#158) 1143 Full list of changes can be viewed via the IETF document tracker: 1144 https://tools.ietf.org/html/draft-foudil-securitytxt 1146 Authors' Addresses 1148 Edwin Foudil 1150 Email: contact@edoverflow.com 1152 Yakov Shafranovich 1153 Nightwatch Cybersecurity 1155 Email: yakov+ietf@nightwatchcybersecurity.com