idnits 2.17.1 draft-foudil-securitytxt-07.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 24 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 21, 2019) is 1713 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 ---------------------------------------------------------------------------- == Missing Reference: 'CR' is mentioned on line 504, but not defined == Missing Reference: 'WSP' is mentioned on line 534, but not defined ** 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 (~~), 3 warnings (==), 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: January 22, 2020 Nightwatch Cybersecurity 6 July 21, 2019 8 A Method for Web Security Policies 9 draft-foudil-securitytxt-07 11 Abstract 13 When security vulnerabilities are discovered by independent security 14 researchers, they often lack the channels to report them properly. 15 As a result, security vulnerabilities may be left unreported. This 16 document defines a format ("security.txt") to help organizations 17 describe the process for security researchers to follow in order to 18 report security 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 January 22, 2020. 37 Copyright Notice 39 Copyright (c) 2019 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 and Prior Work . . . . . . . . . . . . . . . . 3 56 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Note to Readers . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. The Specification . . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3.2. Comments . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.3. Separate Fields . . . . . . . . . . . . . . . . . . . . . 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. Hiring . . . . . . . . . . . . . . . . . . . . . . . 8 69 3.5.6. Policy . . . . . . . . . . . . . . . . . . . . . . . 8 70 3.5.7. Preferred-Languages . . . . . . . . . . . . . . . . . 8 71 3.6. Example of an unsigned "security.txt" file . . . . . . . 9 72 3.7. Example of a signed "security.txt" file . . . . . . . . . 9 73 4. Location of the security.txt file . . . . . . . . . . . . . . 10 74 4.1. Web-based services . . . . . . . . . . . . . . . . . . . 10 75 4.2. Filesystems . . . . . . . . . . . . . . . . . . . . . . . 10 76 4.3. Internal hosts . . . . . . . . . . . . . . . . . . . . . 10 77 4.4. Extensibility . . . . . . . . . . . . . . . . . . . . . . 10 78 5. File Format Description and ABNF Grammar . . . . . . . . . . 11 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 80 6.1. Compromised Files and Redirects . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . 13 84 6.5. Multi-user Environments . . . . . . . . . . . . . . . . . 13 85 6.6. Protecting Data in Transit . . . . . . . . . . . . . . . 14 86 6.7. Spam and Spurious Reports . . . . . . . . . . . . . . . . 14 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 88 7.1. Well-Known URIs registry . . . . . . . . . . . . . . . . 15 89 7.2. Registry for security.txt Header Fields . . . . . . . . . 15 90 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 92 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 93 9.2. Informative References . . . . . . . . . . . . . . . . . 19 94 Appendix A. Note to Readers . . . . . . . . . . . . . . . . . . 19 95 Appendix B. Document History . . . . . . . . . . . . . . . . . . 20 96 B.1. Since draft-foudil-securitytxt-00 . . . . . . . . . . . . 20 97 B.2. Since draft-foudil-securitytxt-01 . . . . . . . . . . . . 20 98 B.3. Since draft-foudil-securitytxt-02 . . . . . . . . . . . . 21 99 B.4. Since draft-foudil-securitytxt-03 . . . . . . . . . . . . 21 100 B.5. Since draft-foudil-securitytxt-04 . . . . . . . . . . . . 21 101 B.6. Since draft-foudil-securitytxt-05 . . . . . . . . . . . . 22 102 B.7. Since draft-foudil-securitytxt-06 . . . . . . . . . . . . 22 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 105 1. Introduction 107 1.1. Motivation and Prior Work 109 Many security researchers encounter situations where they are unable 110 to report security vulnerabilities to organizations because there is 111 no course of action laid out or no way indicated to contact the owner 112 of a particular resource. 114 As per section 4 of [RFC2142], there is an existing convention of 115 using the email address for communications 116 regarding security vulnerabilities. That convention provides only a 117 single, email-based channel of communication for security 118 vulnerabilities per domain, and does not provide a way for domain 119 owners to publish information about their security disclosure 120 policies. 122 There are also contact conventions prescribed for Internet Service 123 Providers (ISPs) in section 2 of [RFC3013], for Computer Security 124 Incident Response Teams (CSIRTs) in section 3.2 of [RFC2350] and for 125 site operators in section 5.2 of [RFC2196]. As per [RFC7485], there 126 is also contact information provided by Regional Internet Registries 127 (RIRs) and domain registries for owners of IP addresses, autonomous 128 system numbers (ASNs) and domain names. However, none of these 129 address the issue of how security researchers can locate disclosure 130 policies and contact information for organizations in order to report 131 security vulnerabilities. 133 In this document, we define a richer, machine-parsable and more 134 extensible way for organizations to communicate information about 135 their security disclosure policies, which is not limited to email and 136 also allows for additional features such as encryption. This format 137 is designed to help assist with the security disclosure process by 138 making it easier for organizations to designate the preferred steps 139 for researchers to take when trying to reach out to them with 140 security vulnerabilities. 142 1.2. Terminology 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 146 "OPTIONAL" in this document are to be interpreted as described in BCP 147 14 [RFC2119] [RFC8174] when, and only when, they appear in all 148 capitals, as shown here. 150 2. Note to Readers 152 *Note to the RFC Editor:* Please remove this section prior to 153 publication. 155 Development of this draft takes place on Github at: 156 https://github.com/securitytxt/security-txt 158 3. The Specification 160 This document defines a text file to be placed in a known location 161 that provides information for security researchers to assist in 162 disclosing security vulnerabilities. 164 The file is named "security.txt", and this file SHOULD be placed 165 under the /.well-known/ path ("/.well-known/security.txt") [RFC8615] 166 of a domain name or IP address for web properties. If it is not 167 possible to place the security.txt file in the /.well-known/ path or 168 setup a redirect, web-based services MAY place the file in the top- 169 level path of a given web domain or IP address ("/security.txt") as a 170 fallback option (see Section 4.1). 172 For web-based services, the file MUST be accessible via the Hypertext 173 Transfer Protocol (HTTP) [RFC1945] as a resource of Internet Media 174 Type "text/plain" with the default charset parameter set to "utf-8" 175 per section 4.1.3 of [RFC2046], and it MUST be served with "https" 176 (as per section 2.7.2 of [RFC7230]). For file systems and version 177 control repositories a "security.txt" file SHOULD be placed in the 178 root directory of a particular file system or source code project. 180 This text file contains multiple directives with different values. 181 The "directive" is the first part of a field all the way up to the 182 colon ("Contact:") and follows the syntax defined for "field-name" in 183 section 3.6.8 of [RFC5322]. Directives MUST be case-insensitive (as 184 per section 2.3 of [RFC5234]). The "value" comes after the directive 185 ("https://example.com/security") and follows the syntax defined for 186 "unstructured" in section 3.2.5 of [RFC5322]. 188 A "field" MUST always consist of a directive and a value ("Contact: 189 https://example.com/security"). A security.txt file can have an 190 unlimited number of fields. It is important to note that you MUST 191 have a separate line for every field. One MUST NOT chain multiple 192 values for a single directive unless it is explicitly defined by that 193 particular field. Unless otherwise indicated in a definition of a 194 particular field, any directive MAY appear multiple times. 196 3.1. Scope 198 A "security.txt" file MUST only apply to the domain in the URI used 199 to retrieve it, not to any of its subdomains or parent domains. A 200 "security.txt" file that is found in a file system or version control 201 repository MUST only apply to the folder or repository in which it is 202 located, and not to any of its parent or sibling folders, or 203 repositories. However, it will apply to all subfolders. 205 Some examples appear below: 207 # The following only applies to example.com. 208 https://example.com/.well-known/security.txt 210 # This only applies to subdomain.example.com. 211 https://subdomain.example.com/.well-known/security.txt 213 # This security.txt file applies to IPv4 address of 192.0.2.0. 214 https://192.0.2.0/.well-known/security.txt 216 # This security.txt file applies to IPv6 address of 2001:db8:8:4::2. 217 https://[2001:db8:8:4::2]/.well-known/security.txt 219 # This file applies to the /example/folder1 directory and subfolders. 220 /example/folder1/security.txt 222 3.2. Comments 224 Any line beginning with the "#" (%x30) symbol MUST be interpreted as 225 a comment. The content of the comment may contain any ASCII or 226 Unicode characters in the %x21-7E and %x80-FFFFF ranges plus the tab 227 (%x09) and space (%x20) characters. 229 Example: 231 # This is a comment. 233 You MAY use one or more comments as descriptive text immediately 234 before the field. Parsers SHOULD associate the comments with the 235 respective field. Only the line most immediately preceding a field 236 SHOULD be associated with that field. 238 3.3. Separate Fields 240 A separate line is REQUIRED for every new field. You MUST NOT chain 241 everything into a single field unless defined by that field. Every 242 line MUST end either with a carriage return and line feed characters 243 (CRLF / %x0D %x0A) or just a line feed character (LF / %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" directive (as per 251 Section 3.5.2), thus allowing the digital signature to authenticate 252 the location of 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 directive allows you to link to a page where security 263 researchers are recognized for their reports. The page being linked 264 to SHOULD list individuals or organizations that reported security 265 vulnerabilities and worked with you to remediate the issue. 266 Organizations SHOULD be careful to limit the vulnerability 267 information being published in order to prevent future attacks. 269 If this directive indicates a web URL, then it MUST begin with 270 "https://" (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 directive indicates the canonical URI where the security.txt 288 file is located, which is usually something like 289 "https://example.com/.well-known/security.txt". If this directive 290 indicates a web URL, then it MUST begin with "https://" (as per 291 section 2.7.2 of [RFC7230]). The purpose of this directive is to 292 allow a digital signature to be applied to the location of the 293 "security.txt" file. 295 This directive MUST NOT appear more than once. 297 Canonical: https://example.com/.well-known/security.txt 299 3.5.3. Contact 301 This directive allows you to provide an address that researchers 302 SHOULD use for reporting security vulnerabilities. The value MAY be 303 an email address, a phone number and/or a web page with contact 304 information. The "Contact:" directive MUST always be present in a 305 security.txt file. If this directive indicates a web URL, then it 306 MUST begin with "https://" (as per section 2.7.2 of [RFC7230]). 307 Security email addresses SHOULD use the conventions defined in 308 section 4 of [RFC2142]. 310 The value MUST follow the URI syntax described in [RFC3986]. This 311 means that "mailto" and "tel" URI schemes MUST be used when 312 specifying email addresses and telephone numbers, as defined in 313 [RFC6068] and [RFC3966]. When the value of this directive is an 314 email address, it is RECOMMENDED that encryption be used (as per 315 Section 3.5.4). 317 The precedence SHOULD be in listed order. The first field is the 318 preferred method of contact. In the example below, the email address 319 is the preferred method of contact. 321 Contact: mailto:security@example.com 322 Contact: tel:+1-201-555-0123 323 Contact: https://example.com/security-contact.html 325 3.5.4. Encryption 327 This directive allows you to point to an encryption key that security 328 researchers SHOULD use for encrypted communication. You MUST NOT 329 directly add your key to the field, instead the value of this field 330 MUST be a URI pointing to a location where the key can be retrieved 331 from. If this directive indicates a web URL, then it MUST begin with 332 "https://" (as per section 2.7.2 of [RFC7230]). 334 When it comes to verifying the authenticity of the key, it is always 335 the security researcher's responsibility to make sure the key being 336 specified is indeed one they trust. Researchers MUST NOT assume that 337 this key is used to generate the digital signature referenced in 338 Section 3.4. 340 Example of an OpenPGP key available from a web server: 342 Encryption: https://example.com/pgp-key.txt 344 Example of an OpenPGP key available from an OPENPGPKEY DNS record: 346 Encryption: dns:5d2d37ab76d47d36._openpgpkey.example.com?type=OPENPGPKEY 348 Example of an OpenPGP key being referenced by its fingerprint: 350 Encryption: openpgp4fpr:5f2de5521c63a801ab59ccb603d49de44b29100f 352 3.5.5. Hiring 354 The "Hiring" directive is used for linking to the vendor's security- 355 related job positions. If this directive indicates a web URL, then 356 it MUST begin with "https://" (as per section 2.7.2 of [RFC7230]). 358 Hiring: https://example.com/jobs.html 360 3.5.6. Policy 362 This directive allows you to link to where your security policy and/ 363 or disclosure policy is located. This can help security researchers 364 understand what you are looking for and how to report security 365 vulnerabilities. If this directive indicates a web URL, then it MUST 366 begin with "https://" (as per section 2.7.2 of [RFC7230]). 368 Example: 370 Policy: https://example.com/security-policy.html 372 3.5.7. Preferred-Languages 374 This directive can be used to indicate a set of natural languages 375 that are preferred when submitting security reports. This set MAY 376 list multiple values, separated by commas. If this directive is 377 included then at least one value MUST be listed. The values within 378 this set are language tags (as defined in [RFC5646]). If this 379 directive is absent, security researchers MAY assume that English is 380 the default language to be used (as per section 4.5 of [RFC2277]). 382 The order in which they appear MUST NOT be interpreted as an 383 indication of priority - rather these MUST BE interpreted as all 384 being of equal priority. 386 This directive MUST NOT appear more than once. 388 Example (English, Spanish and French): 390 Preferred-Languages: en, es, fr 392 3.6. Example of an unsigned "security.txt" file 394 # Our security address 395 Contact: mailto:security@example.com 397 # Our OpenPGP key 398 Encryption: https://example.com/pgp-key.txt 400 # Our security policy 401 Policy: https://example.com/security-policy.html 403 # Our security acknowledgments page 404 Acknowledgments: https://example.com/hall-of-fame.html 406 3.7. Example of a signed "security.txt" file 408 ----BEGIN PGP SIGNED MESSAGE----- 409 Hash: SHA256 411 # Canonical URL 412 Canonical: https://example.com/.well-known/security.txt 414 # Our security address 415 Contact: mailto:security@example.com 417 # Our OpenPGP key 418 Encryption: https://example.com/pgp-key.txt 420 # Our security policy 421 Policy: https://example.com/security-policy.html 423 # Our security acknowledgments page 424 Acknowledgments: https://example.com/hall-of-fame.html 425 -----BEGIN PGP SIGNATURE----- 426 Version: GnuPG v1 428 [signature] 429 -----END PGP SIGNATURE----- 431 4. Location of the security.txt file 433 4.1. Web-based services 435 Web-based services SHOULD place the security.txt file under the 436 /.well-known/ path; e.g. https://example.com/.well-known/security.txt 437 as per [RFC8615]. A security.txt file located under the top-level 438 path SHOULD either redirect (as per section 6.4 of [RFC7231]) to the 439 security.txt file under the /.well-known/ path or be used as a 440 fallback if the ".well-known" path cannot be used. 442 If retrieval of a "security.txt" file from the top-level path results 443 in a redirect (as per section 6.4 of [RFC7231]), the implementors 444 MUST NOT follow that redirect if it leads to another domain or 445 subdomain but SHOULD follow that redirect within the same domain name 446 (but not different subdomain on the same domain). 448 The guidance regarding redirects SHOULD NOT apply to the resource 449 locations that appear within the file. 451 4.2. Filesystems 453 File systems SHOULD place the "security.txt" file under the root 454 directory; e.g., "/security.txt", "C:\security.txt". 456 Example file system: 458 /example-directory-1/ 459 /example-directory-2/ 460 /example-directory-3/ 461 /example-file 462 /security.txt 464 4.3. Internal hosts 466 A "security.txt" file SHOULD be placed in the root directory of an 467 internal host. 469 4.4. Extensibility 471 Like many other formats and protocols, this format may need to be 472 extended over time to fit the ever-changing landscape of the 473 Internet. Therefore, extensibility is provided via an IANA registry 474 for directives as defined in Section 7.2. Any directives registered 475 via that process MUST be considered optional. To encourage 476 extensibility and interoperability, implementors MUST ignore any 477 fields they do not explicitly support. 479 In general, implementors SHOULD "be conservative in what you do, be 480 liberal in what you accept from others" (as per [RFC0793]). 482 5. File Format Description and ABNF Grammar 484 The expected file format of the security.txt file is plain text (MIME 485 type "text/plain") as defined in section 4.1.3 of [RFC2046] and is 486 encoded using UTF-8 [RFC3629] in Net-Unicode form [RFC5198]. 488 The following is an ABNF definition of the security.txt format, using 489 the conventions defined in [RFC5234]. 491 body = signed / unsigned 493 signed = sign-header unsigned sign-footer 495 sign-header = < headers and line from section 7 of [RFC4880] > 497 sign-footer = < OpenPGP signature from section 7 of [RFC4880] > 499 unsigned = *line [can-field eol] *line (contact-field eol) *line [lang-field eol] *line 500 ; the order of elements is not important 502 line = (field / comment) eol 504 eol = *WSP [CR] LF 506 field = ack-field / 507 contact-field / 508 encryption-field / 509 hiring-field / 510 policy-field / 511 ext-field 513 fs = ":" 515 comment = "#" *(WSP / VCHAR / %x80-FFFFF) 517 ack-field = "Acknowledgments" fs SP uri 519 can-field = "Canonical" fs SP uri 521 contact-field = "Contact" fs SP uri 523 lang-tag = < Language-Tag from section 2.1 of [RFC5646] > 525 uri = < URI as per [RFC3986] > 526 encryption-field = "Encryption" fs SP uri 528 hiring-field = "Hiring" fs SP uri 530 policy-field = "Policy" fs SP uri 532 lang-field = "Preferred-Languages" fs SP lang-values 534 lang-values = lang-tag *("," [WSP] lang-tag) 536 ext-field = field-name fs SP unstructured 538 field-name = < imported from section 3.6.8 of [RFC5322] > 540 unstructured = < imported from section 3.2.5 of [RFC5322] > 542 "ext-field" refers to extension fields, which are discussed in 543 Section 4.4 545 6. Security Considerations 547 Implementors SHOULD review this section as well as the security 548 considerations section of [RFC8615]. 550 6.1. Compromised Files and Redirects 552 An attacker that has compromised a website is able to compromise the 553 "security.txt" file as well or setup a redirect to their own site. 554 This can result in security reports not being received by the 555 organization or sent to the attacker. 557 To protect against this, organizations SHOULD digitally sign their 558 "security.txt" files (as per Section 3.4), use the canonical 559 directive to sign the location of the file (as per Section 3.5.2), 560 and regularly monitor the file and the referenced resources to detect 561 tampering. 563 Security researchers SHOULD check the "security.txt" file including 564 verifying the digital signature and checking any available historical 565 records before using the information contained in the file. If 566 "security.txt" file looks suspicious or compromised, it SHOULD NOT be 567 used. 569 To avoid redirect attacks, redirects for these files MUST NOT be 570 followed when the file is placed in the top level path if they lead 571 to a different domain (as per Section 4.1). 573 6.2. Incorrect or Stale Information 575 If information and resources referenced in a "security.txt" file are 576 incorrect or not kept up to date, this can result in security reports 577 not being received by the organization or sent to incorrect contacts, 578 thus exposing possible security issues to third parties. 580 Organizations SHOULD ensure that information in this file and any 581 referenced resources such as web pages, email addresses and telephone 582 numbers are kept current, are accessible, controlled by the 583 organization, and are kept secure. 585 6.3. Intentionally Malformed Files, Resources and Reports 587 It is possible for attackers to generate files that are 588 extraordinarily large or otherwise malformed in an attempt to 589 discover or exploit weaknesses in parsing code. Implementors SHOULD 590 make sure that any such code is robust against large and malformed 591 files. ABNF grammar (as defined in Section 5) SHOULD be used as a 592 way to verify these files. 594 Same concerns apply to any other resources referenced within 595 security.txt files, as well as any security reports received as a 596 result of publishing this file. Such resources and reports may be 597 hostile, malformed or malicious. 599 6.4. No Implied Permission for Testing 601 The presence of a security.txt file can be interpreted by researchers 602 as providing permission to do security testing against that asset. 603 This can lead to increased testing against an organization by 604 researchers. On the other hand, a decision not to publish a 605 security.txt file can be interpreted by the organization operating 606 that website to be a way to signal to researchers that permission to 607 test that particular site or project is denied. This can lead to 608 pushback against researchers reporting security issues to that 609 organization. 611 Therefore, implementors MUST NOT assume that presence or absence of a 612 "security.txt" file grants or denies permission for security testing. 613 Any such permission MAY be defined in a security or disclosure policy 614 (as per Section 3.5.6) or a new directive (as per Section 4.4). 616 6.5. Multi-user Environments 618 In multi-user / multi-tenant environments, it may possible for a user 619 to take over the location of the "security.txt" file. Organizations 620 SHOULD reserve the "security.txt" namespace to ensure no third-party 621 can create a page with the "security.txt" AND "/.well-known/ 622 security.txt" names. 624 6.6. Protecting Data in Transit 626 To protect a "security.txt" file from being tampered with in transit, 627 implementors MUST use HTTPS when serving the file itself and any web 628 URLs referenced in it (except as noted in this specification). 629 Implementors MUST also perform the correct TLS verification (as per 630 [RFC6125]). 632 As an additional layer of protection, it is also RECOMMENDED that 633 organizations digitally sign their "security.txt" file with OpenPGP 634 (as per Section 3.4). Also, to protect security reports from being 635 tampered with or observed while in transit, organizations SHOULD 636 specify encryption keys (as per Section 3.5.4) unless HTTPS is being 637 used. 639 However, the determination of validity of keys being used is out of 640 scope for this specification. Implementors MUST establish other 641 secure means to verify these keys. 643 6.7. Spam and Spurious Reports 645 Similar to concerns in [RFC2142], denial of service attacks via spam 646 reports would become easier once a "security.txt" file is published 647 by an organization. In addition, there is an increased likelihood of 648 reports being sent in an automated fashion and/or as result of 649 automated scans without human triage. 651 Organizations SHOULD weigh the advantages of publishing this file 652 versus the possible disadvantages and increased resources required to 653 triage security reports. 655 Security researchers SHOULD consult the organization's policy, if 656 available, before submitting reports in an automated fashion or as 657 resulting from automated scans. 659 7. IANA Considerations 661 example.com is used in this document following the uses indicated in 662 [RFC2606]. 664 192.0.2.0 and 2001:db8:8:4::2 are used in this document following the 665 uses indicated in [RFC6890]. 667 7.1. Well-Known URIs registry 669 The "Well-Known URIs" registry should be updated with the following 670 additional values (using the template from [RFC8615]): 672 URI suffix: security.txt 674 Change controller: IETF 676 Specification document(s): this document 678 Status: permanent 680 7.2. Registry for security.txt Header Fields 682 IANA is requested to create the "security.txt Header Fields" registry 683 in accordance with [RFC8126]. This registry will contain header 684 fields for use in security.txt files, defined by this specification. 686 New registrations or updates MUST be published in accordance with the 687 "Expert Review" guidelines as described in section 4.5 of [RFC8126]. 688 Any new field thus registered is considered optional by this 689 specification unless a new version of this specification is 690 published. 692 New registrations and updates MUST contain the following information: 694 1. Name of the field being registered or updated 696 2. Short description of the field 698 3. Whether the field can appear more than once 700 4. The document in which the specification of the field is published 702 5. New or updated status, which MUST be one of: current: The field 703 is in current use deprecated: The field is in current use, but 704 its use is discouraged historic: The field is no longer in 705 current use 707 An update may make a notation on an existing registration indicating 708 that a registered field is historical or deprecated if appropriate. 710 The initial registry contains these values: 712 Field Name: Acknowledgments 713 Description: link to page where security researchers are recognized 714 Multiple Appearances: Yes 715 Published in: this document 716 Status: current 718 Field Name: Canonical 719 Description: canonical URL for this file 720 Multiple Appearances: No 721 Published in: this document 722 Status: current 724 Field Name: Contact 725 Description: contact information to use for reporting vulnerabilities 726 Multiple Appearances: Yes 727 Published in: this document 728 Status: current 730 Field Name: Encryption 731 Description: link to a key to be used for encrypted communication 732 Multiple Appearances: Yes 733 Published in: this document 734 Status: current 736 Field Name: Hiring 737 Description: link to the vendor's security-related job positions 738 Multiple Appearances: Yes 739 Published in: this document 740 Status: current 742 Field Name: Policy 743 Description: link to security policy page 744 Multiple Appearances: Yes 745 Published in: this document 746 Status: current 748 Field Name: Preferred-Languages 749 Description: list of preferred languages for security reports 750 Multiple Appearances: No 751 Published in: this document 752 Status: current 754 8. Contributors 756 The authors would like to acknowledge the help provided during the 757 development of this document by Tom Hudson, Jobert Abma, Gerben 758 Janssen van Doorn, Austin Heap, Stephane Bortzmeyer, Max Smith, 759 Eduardo Vela and Krzysztof Kotowicz. 761 The authors would also like to acknowledge the feedback provided by 762 multiple members of IETF's SAAG and SEC-DISPATCH lists. 764 9. References 766 9.1. Normative References 768 [RFC1945] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext 769 Transfer Protocol -- HTTP/1.0", RFC 1945, 770 DOI 10.17487/RFC1945, May 1996, 771 . 773 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 774 Extensions (MIME) Part Two: Media Types", RFC 2046, 775 DOI 10.17487/RFC2046, November 1996, 776 . 778 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 779 Requirement Levels", BCP 14, RFC 2119, 780 DOI 10.17487/RFC2119, March 1997, 781 . 783 [RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and 784 Functions", RFC 2142, DOI 10.17487/RFC2142, May 1997, 785 . 787 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 788 Languages", BCP 18, RFC 2277, DOI 10.17487/RFC2277, 789 January 1998, . 791 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 792 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 793 2003, . 795 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 796 RFC 3966, DOI 10.17487/RFC3966, December 2004, 797 . 799 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 800 Resource Identifier (URI): Generic Syntax", STD 66, 801 RFC 3986, DOI 10.17487/RFC3986, January 2005, 802 . 804 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 805 Thayer, "OpenPGP Message Format", RFC 4880, 806 DOI 10.17487/RFC4880, November 2007, 807 . 809 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 810 Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, 811 . 813 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 814 Specifications: ABNF", STD 68, RFC 5234, 815 DOI 10.17487/RFC5234, January 2008, 816 . 818 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 819 DOI 10.17487/RFC5322, October 2008, 820 . 822 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 823 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 824 September 2009, . 826 [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' 827 URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010, 828 . 830 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 831 Verification of Domain-Based Application Service Identity 832 within Internet Public Key Infrastructure Using X.509 833 (PKIX) Certificates in the Context of Transport Layer 834 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 835 2011, . 837 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 838 Protocol (HTTP/1.1): Message Syntax and Routing", 839 RFC 7230, DOI 10.17487/RFC7230, June 2014, 840 . 842 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 843 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 844 DOI 10.17487/RFC7231, June 2014, 845 . 847 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 848 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 849 May 2017, . 851 [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers 852 (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, 853 . 855 9.2. Informative References 857 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 858 RFC 793, DOI 10.17487/RFC0793, September 1981, 859 . 861 [RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, 862 DOI 10.17487/RFC2196, September 1997, 863 . 865 [RFC2350] Brownlee, N. and E. Guttman, "Expectations for Computer 866 Security Incident Response", BCP 21, RFC 2350, 867 DOI 10.17487/RFC2350, June 1998, 868 . 870 [RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS 871 Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999, 872 . 874 [RFC3013] Killalea, T., "Recommended Internet Service Provider 875 Security Services and Procedures", BCP 46, RFC 3013, 876 DOI 10.17487/RFC3013, November 2000, 877 . 879 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 880 "Special-Purpose IP Address Registries", BCP 153, 881 RFC 6890, DOI 10.17487/RFC6890, April 2013, 882 . 884 [RFC7485] Zhou, L., Kong, N., Shen, S., Sheng, S., and A. Servin, 885 "Inventory and Analysis of WHOIS Registration Objects", 886 RFC 7485, DOI 10.17487/RFC7485, March 2015, 887 . 889 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 890 Writing an IANA Considerations Section in RFCs", BCP 26, 891 RFC 8126, DOI 10.17487/RFC8126, June 2017, 892 . 894 Appendix A. Note to Readers 896 *Note to the RFC Editor:* Please remove this section prior to 897 publication. 899 Development of this draft takes place on Github at 900 https://github.com/securitytxt/security-txt 902 Appendix B. Document History 904 *Note to the RFC Editor:* Please remove this section prior to 905 publication. 907 B.1. Since draft-foudil-securitytxt-00 909 o Moved to use IETF's markdown tools for draft updates 911 o Added table of contents and a fuller list of references 913 o Moved file to .well-known URI and added IANA registration (#3) 915 o Added extensibility with an IANA registry for fields (#34) 917 o Added text explaining relationship to RFC 2142 / security@ email 918 address (#25) 920 o Scope expanded to include internal hosts, domains, IP addresses 921 and file systems 923 o Support for digital signatures added (#19) 925 The full list of changes can be viewed via the IETF document tracker: 926 https://tools.ietf.org/html/draft-foudil-securitytxt-01 928 B.2. Since draft-foudil-securitytxt-01 930 o Added appendix with pointer to Github and document history 932 o Added external signature file to the well known URI registry (#59) 934 o Added policy field (#53) 936 o Added diagram explaining the location of the file on public vs. 937 internal systems 939 o Added recommendation that external signature files should use 940 HTTPS (#55) 942 o Added recommendation that organizations should monitor their 943 security.txt files (#14) 945 The full list of changes can be viewed via the IETF document tracker: 946 https://tools.ietf.org/html/draft-foudil-securitytxt-02 948 B.3. Since draft-foudil-securitytxt-02 950 o Use "mailto" and "tel" (#62) 952 o Fix typo in the "Example" section (#64) 954 o Clarified that the root directory is a fallback option (#72) 956 o Defined content-type for the response (#68) 958 o Clarify the scope of the security.txt file (#69) 960 o Cleaning up text based on the NITS tools suggestions (#82) 962 o Added clarification for newline values 964 o Clarified the encryption field language, added examples of DNS- 965 stored encryption keys (#28 and #94) 967 o Added "Hiring" field 969 B.4. Since draft-foudil-securitytxt-03 971 o Added "Hiring" field to the registry section 973 o Added an encryption example using a PGP fingerprint (#107) 975 o Added reference to the mailing list (#111) 977 o Added a section referencing related work (#113) 979 o Fixes for idnits (#82) 981 o Changing some references to informative instead of normative 983 o Adding "Permission" field (#30) 985 o Fixing remaining ABNF issues (#83) 987 o Additional editorial changes and edits 989 B.5. Since draft-foudil-securitytxt-04 991 o Addressing IETF feedback (#118) 993 o Case sensitivity clarification (#127) 995 o Syntax fixes (#133, #135 and #136) 996 o Removed permission directive (#30) 998 o Removed signature directive and switched to inline signatures (#93 999 and #128) 1001 o Adding canonical directive (#100) 1003 o Text and ABNF grammar improvements plus ABNF changes for comments 1004 (#123) 1006 o Changed ".security.txt" to "security.txt" to be consistent 1008 B.6. Since draft-foudil-securitytxt-05 1010 o Changing HTTPS to MUST (#55) 1012 o Adding language recommending encryption for email reports (#134) 1014 o Added language handling redirects (#143) 1016 o Expanded security considerations section and fixed typos (#30, 1017 #73, #103, #112) 1019 B.7. Since draft-foudil-securitytxt-06 1021 o Fixed ABNF grammar for non-chainable directives (#150) 1023 o Clarified ABNF grammar (#152) 1025 o Clarified redirect logic (#143) 1027 o Clarified comments (#158) 1029 o Updated references and template for well-known URI to RFC 8615 1031 o Fixed nits from the IETF validator 1033 Full list of changes can be viewed via the IETF document tracker: 1034 https://tools.ietf.org/html/draft-foudil-securitytxt 1036 Authors' Addresses 1038 Edwin Foudil 1040 Email: contact@edoverflow.com 1041 Yakov Shafranovich 1042 Nightwatch Cybersecurity 1044 Email: yakov+ietf@nightwatchcybersecurity.com