idnits 2.17.1 draft-foudil-securitytxt-06.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 10 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 (April 08, 2019) is 1816 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 5785 (Obsoleted by RFC 8615) ** 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: 5 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: October 10, 2019 Nightwatch Cybersecurity 6 April 08, 2019 8 A Method for Web Security Policies 9 draft-foudil-securitytxt-06 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 October 10, 2019. 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 . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . 14 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 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 104 1. Introduction 106 1.1. Motivation and Prior Work 108 Many security researchers encounter situations where they are unable 109 to report security vulnerabilities to organizations because there is 110 no course of action laid out or no way indicated to contact the owner 111 of a particular resource. 113 As per section 4 of [RFC2142], there is an existing convention of 114 using the email address for communications 115 regarding security vulnerabilities. That convention provides only a 116 single, email-based channel of communication for security 117 vulnerabilities per domain, and does not provide a way for domain 118 owners to publish information about their security disclosure 119 policies. 121 There are also contact conventions prescribed for Internet Service 122 Providers (ISPs) in section 2 of [RFC3013], for Computer Security 123 Incident Response Teams (CSIRTs) in section 3.2 of [RFC2350] and for 124 site operators in section 5.2 of [RFC2196]. As per [RFC7485], there 125 is also contact information provided by Regional Internet Registries 126 (RIRs) and domain registries for owners of IP addresses, autonomous 127 system numbers (ASNs) and domain names. However, none of these 128 address the issue of how security researchers can locate disclosure 129 policies and contact information for organizations in order to report 130 security vulnerabilities. 132 In this document, we define a richer, machine-parsable and more 133 extensible way for organizations to communicate information about 134 their security disclosure policies, which is not limited to email and 135 also allows for additional features such as encryption. This format 136 is designed to help assist with the security disclosure process by 137 making it easier for organizations to designate the preferred steps 138 for researchers to take when trying to reach out to them with 139 security vulnerabilities. 141 1.2. Terminology 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 145 "OPTIONAL" in this document are to be interpreted as described in BCP 146 14 [RFC2119] [RFC8174] when, and only when, they appear in all 147 capitals, as shown here. 149 2. Note to Readers 151 *Note to the RFC Editor:* Please remove this section prior to 152 publication. 154 Development of this draft takes place on Github at: 155 https://github.com/securitytxt/security-txt 157 3. The Specification 159 This document defines a text file to be placed in a known location 160 that provides information for security researchers to assist in 161 disclosing security vulnerabilities. 163 The file is named "security.txt", and this file SHOULD be placed 164 under the /.well-known/ path ("/.well-known/security.txt") [RFC5785] 165 of a domain name or IP address for web properties. If it is not 166 possible to place the security.txt file in the /.well-known/ path or 167 setup a redirect, web-based services MAY place the file in the top- 168 level path of a given web domain or IP address ("/security.txt") as a 169 fallback option (see Section 4.1). 171 For web-based services, the file MUST be accessible via the Hypertext 172 Transfer Protocol (HTTP) [RFC1945] as a resource of Internet Media 173 Type "text/plain" with the default charset parameter set to "utf-8" 174 per section 4.1.3 of [RFC2046], and it MUST be served with "https" 175 (as per section 2.7.2 of [RFC7230]). For file systems and version 176 control repositories a "security.txt" file SHOULD be placed in the 177 root directory of a particular file system or source code project. 179 This text file contains multiple directives with different values. 180 The "directive" is the first part of a field all the way up to the 181 colon ("Contact:") and follows the syntax defined for "field-name" in 182 section 3.6.8 of [RFC5322]. Directives MUST be case-insensitive (as 183 per section 2.3 of [RFC5234]). The "value" comes after the directive 184 ("https://example.com/security") and follows the syntax defined for 185 "unstructured" in section 3.2.5 of [RFC5322]. 187 A "field" MUST always consist of a directive and a value ("Contact: 188 https://example.com/security"). A security.txt file can have an 189 unlimited number of fields. It is important to note that you MUST 190 have a separate line for every field. One MUST NOT chain multiple 191 values for a single directive unless it is explicitly defined by that 192 particular field. Unless otherwise indicated in a definition of a 193 particular field, any directive MAY appear multiple times. 195 3.1. Scope 197 A "security.txt" file MUST only apply to the domain in the URI used 198 to retrieve it, not to any of its subdomains or parent domains. A 199 "security.txt" file that is found in a file system or version control 200 repository MUST only apply to the folder or repository in which it is 201 located, and not to any of its parent or sibling folders, or 202 repositories. However, it will apply to all subfolders. 204 Some examples appear below: 206 # The following only applies to example.com. 207 https://example.com/.well-known/security.txt 209 # This only applies to subdomain.example.com. 210 https://subdomain.example.com/.well-known/security.txt 212 # This security.txt file applies to IPv4 address of 192.0.2.0. 213 https://192.0.2.0/.well-known/security.txt 215 # This security.txt file applies to IPv6 address of 2001:db8:8:4::2. 216 https://[2001:db8:8:4::2]/.well-known/security.txt 218 # This security.txt file applies to the /example/folder1 directory and subfolders. 219 /example/folder1/security.txt 221 3.2. Comments 223 Any line beginning with the "#" (%x30) symbol MUST be interpreted as 224 a comment. The content of the comment may contain any ASCII or 225 Unicode characters in the %x21-7E and %x80-FFFFF ranges plus the tab 226 (%x09) and space (%x20) characters. 228 Example: 230 # This is a comment. 232 You MAY use one or more comments as descriptive text immediately 233 before the field. Parsers SHOULD associate the comments with the 234 respective field. 236 3.3. Separate Fields 238 A separate line is REQUIRED for every new value and field. You MUST 239 NOT chain everything into a single field unless defined by that 240 field. Every line MUST end either with a carriage return and line 241 feed characters (CRLF / %x0D %x0A) or just a line feed character (LF 242 / %x0A). 244 3.4. Digital signature 246 It is RECOMMENDED that a security.txt file be digitally signed using 247 an OpenPGP cleartext signature as described in section 7 of 248 [RFC4880]. When digital signatures are used, it is also RECOMMENDED 249 that implementors use the "Canonical" directive (as per 250 Section 3.5.2), thus allowing the digital signature to authenticate 251 the location of the file. 253 When it comes to verifying the key used to generate the signature, it 254 is always the security researcher's responsibility to make sure the 255 key being used is indeed one they trust. 257 3.5. Field Definitions 259 3.5.1. Acknowledgments 261 This directive allows you to link to a page where security 262 researchers are recognized for their reports. The page being linked 263 to SHOULD list individuals or organizations that reported security 264 vulnerabilities and worked with you to remediate the issue. 265 Organizations SHOULD be careful to limit the vulnerability 266 information being published in order to prevent future attacks. 268 If this directive indicates a web URL, then it MUST begin with 269 "https://" (as per section 2.7.2 of [RFC7230]). 271 Example: 273 Acknowledgments: https://example.com/hall-of-fame.html 275 Example security acknowledgments page: 277 We would like to thank the following researchers: 279 (2017-04-15) Frank Denis - Reflected cross-site scripting 280 (2017-01-02) Alice Quinn - SQL injection 281 (2016-12-24) John Buchner - Stored cross-site scripting 282 (2016-06-10) Anna Richmond - A server configuration issue 284 3.5.2. Canonical 286 This directive indicates the canonical URI where the security.txt 287 file is located, which is usually something like 288 "https://example.com/.well-known/security.txt". If this directive 289 indicates a web URL, then it MUST begin with "https://" (as per 290 section 2.7.2 of [RFC7230]). The purpose of this directive is to 291 allow a digital signature to be applied to the location of the 292 "security.txt" file. 294 This directive MUST NOT appear more than once. 296 Canonical: https://example.com/.well-known/security.txt 298 3.5.3. Contact 300 This directive allows you to provide an address that researchers 301 SHOULD use for reporting security vulnerabilities. The value MAY be 302 an email address, a phone number and/or a web page with contact 303 information. The "Contact:" directive MUST always be present in a 304 security.txt file. If this directive indicates a web URL, then it 305 MUST begin with "https://" (as per section 2.7.2 of [RFC7230]). 306 Security email addresses SHOULD use the conventions defined in 307 section 4 of [RFC2142]. 309 The value MUST follow the URI syntax described in [RFC3986]. This 310 means that "mailto" and "tel" URI schemes MUST be used when 311 specifying email addresses and telephone numbers, as defined in 312 [RFC6068] and [RFC3966]. When the value of this directive is an 313 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 field is the 317 preferred method of contact. In the example below, the email address 318 is the preferred method of contact. 320 Contact: mailto:security@example.com 321 Contact: tel:+1-201-555-0123 322 Contact: https://example.com/security-contact.html 324 3.5.4. Encryption 326 This directive allows you to point to an encryption key that security 327 researchers SHOULD use for encrypted communication. You MUST NOT 328 directly add your key to the field, instead the value of this field 329 MUST be a URI pointing to a location where the key can be retrieved 330 from. If this directive indicates a web URL, then it MUST begin with 331 "https://" (as per section 2.7.2 of [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. Hiring 353 The "Hiring" directive is used for linking to the vendor's security- 354 related job positions. If this directive indicates a web URL, then 355 it MUST begin with "https://" (as per section 2.7.2 of [RFC7230]). 357 Hiring: https://example.com/jobs.html 359 3.5.6. Policy 361 This directive allows you to link to where your security policy and/ 362 or disclosure policy is located. This can help security researchers 363 understand what you are looking for and how to report security 364 vulnerabilities. If this directive indicates a web URL, then it MUST 365 begin with "https://" (as per section 2.7.2 of [RFC7230]). 367 Example: 369 Policy: https://example.com/security-policy.html 371 3.5.7. Preferred-Languages 373 This directive can be used to indicate a set of natural languages 374 that are preferred when submitting security reports. This set MAY 375 list multiple values, separated by commas. If this directive is 376 included then at least one value MUST be listed. The values within 377 this set are language tags (as defined in [RFC5646]). If this 378 directive is absent, security researchers MAY assume that English is 379 the default language to be used (as per section 4.5 of [RFC2277]). 381 The order in which they appear MUST NOT be interpreted as an 382 indication of priority - rather these MUST BE interpreted as all 383 being of equal priority. 385 This directive MUST NOT appear more than once. 387 Example (English, Spanish and French): 389 Preferred-Languages: en, es, fr 391 3.6. Example of an unsigned "security.txt" file 393 # Our security address 394 Contact: mailto:security@example.com 396 # Our OpenPGP key 397 Encryption: https://example.com/pgp-key.txt 399 # Our security policy 400 Policy: https://example.com/security-policy.html 402 # Our security acknowledgments page 403 Acknowledgments: https://example.com/hall-of-fame.html 405 3.7. Example of a signed "security.txt" file 407 ----BEGIN PGP SIGNED MESSAGE----- 408 Hash: SHA256 410 # Canonical URL 411 Canonical: https://example.com/.well-known/security.txt 413 # Our security address 414 Contact: mailto:security@example.com 416 # Our OpenPGP key 417 Encryption: https://example.com/pgp-key.txt 419 # Our security policy 420 Policy: https://example.com/security-policy.html 422 # Our security acknowledgments page 423 Acknowledgments: https://example.com/hall-of-fame.html 424 -----BEGIN PGP SIGNATURE----- 425 Version: GnuPG v1 427 [signature] 428 -----END PGP SIGNATURE----- 430 4. Location of the security.txt file 432 4.1. Web-based services 434 Web-based services SHOULD place the security.txt file under the 435 /.well-known/ path; e.g. https://example.com/.well-known/security.txt 436 as per [RFC5785]. A security.txt file located under the top-level 437 path SHOULD either redirect (as per section 6.4 of [RFC7231]) to the 438 security.txt file under the /.well-known/ path or be used as a 439 fallback if the ".well-known" path cannot be used. 441 If retrieval of a "security.txt" file results in a redirect (as per 442 section 6.4 of [RFC7231]), the implementors MUST NOT follow redirects 443 that lead to another domain or subdomain but SHOULD follow redirects 444 within the same domain name (but not different subdomain on the same 445 domain). 447 The guidance regarding redirects SHOULD NOT apply to the resource 448 locations that appear within the file. 450 4.2. Filesystems 452 File systems SHOULD place the "security.txt" file under the root 453 directory; e.g., "/security.txt", "C:\security.txt". 455 Example file system: 457 /example-directory-1/ 458 /example-directory-2/ 459 /example-directory-3/ 460 /example-file 461 /security.txt 463 4.3. Internal hosts 465 A "security.txt" file SHOULD be placed in the root directory of an 466 internal host. 468 4.4. Extensibility 470 Like many other formats and protocols, this format may need to be 471 extended over time to fit the ever-changing landscape of the 472 Internet. Therefore, extensibility is provided via an IANA registry 473 for directives as defined in Section 7.2. Any directives registered 474 via that process MUST be considered optional. To encourage 475 extensibility and interoperability, implementors MUST ignore any 476 fields they do not explicitly support. 478 In general, implementors SHOULD "be conservative in what you do, be 479 liberal in what you accept from others" (as per [RFC0793]). 481 5. File Format Description and ABNF Grammar 483 The expected file format of the security.txt file is plain text (MIME 484 type "text/plain") as defined in section 4.1.3 of [RFC2046] and is 485 encoded using UTF-8 [RFC3629] in Net-Unicode form [RFC5198]. 487 The following is an ABNF definition of the security.txt format, using 488 the conventions defined in [RFC5234]. 490 body = signed / unsigned 492 signed = sign-header unsigned sign-footer 494 sign-header = 496 sign-footer = 498 unsigned = *line (canonical-field eol) (lang-field eol) *line 500 line = (field / comment) eol 502 eol = *WSP [CR] LF 504 field = ack-field / 505 contact-field / 506 encryption-field / 507 hiring-field / 508 policy-field / 509 ext-field 511 fs = ":" 513 comment = "#" *(WSP / VCHAR / %x80-FFFFF) 515 ack-field = "Acknowledgments" fs SP uri 517 canonical-field = "Canonical" fs SP uri 519 contact-field = "Contact" fs SP uri 521 lang-tag = 523 uri = 525 encryption-field = "Encryption" fs SP uri 526 hiring-field = "Hiring" fs SP uri 528 policy-field = "Policy" fs SP uri 530 lang-field = "Preferred-Languages" fs SP lang-values 532 lang-values = lang-tag *("," [WSP] lang-tag) 534 ext-field = field-name fs SP unstructured 536 field-name = 538 unstructured = 540 "ext-field" refers to extension fields, which are discussed in 541 Section 4.4 543 6. Security Considerations 545 6.1. Compromised Files and Redirects 547 An attacker that has compromised a website is able to compromise the 548 "security.txt" file as well or setup a redirect to their own site. 549 This can result in security reports not being received by the 550 organization or sent to the attacker. 552 To protect against this, organizations SHOULD digitally sign their 553 "security.txt" files (as per Section 3.4), use the canonical 554 directive to sign the location of the file (as per Section 3.5.2), 555 and regularly monitor the file and the referenced resources to detect 556 tampering. 558 Security researchers SHOULD check the "security.txt" file including 559 verifying the digital signature and checking any available historical 560 records before using the information contained in the file. If 561 "security.txt" file looks suspicious or compromised, it SHOULD NOT be 562 used. 564 To avoid redirect attacks, redirects for these files MUST NOT be 565 followed if they lead to a different domain (as per Section 4.1). 567 6.2. Incorrect or Stale Information 569 If information and resources referenced in a "security.txt" file are 570 incorrect or not kept up to date, this can result in security reports 571 not being received by the organization or sent to incorrect contacts, 572 thus exposing possible security issues to third parties. 574 Organizations SHOULD ensure that information in this file and any 575 referenced resources such as web pages, email addresses and telephone 576 numbers are kept current, are accessible, controlled by the 577 organization, and are kept secure. 579 6.3. Intentionally Malformed Files, Resources and Reports 581 It is possible for attackers to generate files that are 582 extraordinarily large or otherwise malformed in an attempt to 583 discover or exploit weaknesses in parsing code. Implementors SHOULD 584 make sure that any such code be robust against large and malformed 585 files. ABNF grammar (as defined in Section 5) SHOULD be used as a 586 way to verify these files. 588 Same concerns apply to any other resources referenced within 589 security.txt files, as well as any security reports received as a 590 result of publishing this file. Such resources and reports may be 591 hostile, malformed or malicious. 593 6.4. No Implied Permission for Testing 595 The presence of a security.txt file can be interpreted by researchers 596 as providing permission to do security testing against that asset. 597 This can lead to increased testing against an organization by 598 researchers. On the other hand, a decision not to publish a 599 security.txt file, can be interpreted by the organization operating 600 that website to be a way to signal to researchers that permission to 601 test that particular site or project is denied. This can lead to 602 pushback against researchers reporting security issues to that 603 organization. 605 Therefore, implementors MUST NOT assume that presence or absence of a 606 "security.txt" file grants or denies permission for security testing. 607 Any such permission MAY be defined in a security or disclosure policy 608 (as per Section 3.5.6) or a new directive (as per Section 4.4). 610 6.5. Multi-user Environments 612 In multi-user / multi-tenant environments, it may possible for a user 613 to take over the location of the "security.txt" file. Organizations 614 SHOULD reserve the "security.txt" namespace to ensure no third-party 615 can create a page with the "security.txt" AND "/.well-known/ 616 security.txt" names. 618 6.6. Protecting Data in Transit 620 To protect a "security.txt" file from being tampered in transit, 621 implementors MUST use HTTPS when serving the file itself and any web 622 URLs referenced in it (except as noted in this specification). 623 Implementors MUST also perform the correct TLS verification (as per 624 [RFC6125]). 626 As an additional layer of protection, it is also RECOMMENDED that 627 organizations digitally sign their "security.txt" file with OpenPGP 628 (as per Section 3.4). Also, to protect security reports from being 629 tampered with or observed while in transit, organizations SHOULD 630 specify encryption keys (as per Section 3.5.4) unless HTTPS is being 631 used. 633 However, the determination of validity of keys being used is out of 634 scope for this specification. Implementors MUST establish other 635 secure means to verify these keys. 637 6.7. Spam and Spurious Reports 639 Similar to concerns in [RFC2142], denial of service attacks via spam 640 reports would become easier once a "security.txt" file is published 641 by an organization. In addition, there is an increased likelihood of 642 reports being sent in an automated fashion and/or as result of 643 automated scans without human triage. 645 Organizations SHOULD weigh the advantages of publishing this file 646 versus the possible disadvantages and increased resources required to 647 triage security reports. 649 Security researchers SHOULD consult the organization's policy, if 650 available, before submitting reports in an automated fashion or as 651 resulting from automated scans. 653 7. IANA Considerations 655 example.com is used in this document following the uses indicated in 656 [RFC2606]. 658 192.0.2.0 and 2001:db8:8:4::2 are used in this document following the 659 uses indicated in [RFC6890]. 661 7.1. Well-Known URIs registry 663 The "Well-Known URIs" registry should be updated with the following 664 additional values (using the template from [RFC5785]): 666 URI suffix: security.txt 668 Change controller: IETF 670 Specification document(s): this document 672 7.2. Registry for security.txt Header Fields 674 IANA is requested to create the "security.txt Header Fields" registry 675 in accordance with [RFC8126]. This registry will contain header 676 fields for use in security.txt files, defined by this specification. 678 New registrations or updates MUST be published in accordance with the 679 "Expert Review" guidelines as described in section 4.5 of [RFC8126]. 680 Any new field thus registered is considered optional by this 681 specification unless a new version of this specification is 682 published. 684 New registrations and updates MUST contain the following information: 686 1. Name of the field being registered or updated 688 2. Short description of the field 690 3. Whether the field can appear more than once 692 4. The document in which the specification of the field is published 694 5. New or updated status, which MUST be one of: current: The field 695 is in current use deprecated: The field is in current use, but 696 its use is discouraged historic: The field is no longer in 697 current use 699 An update may make a notation on an existing registration indicating 700 that a registered field is historical or deprecated if appropriate. 702 The initial registry contains these values: 704 Field Name: Acknowledgments 705 Description: link to page where security researchers are recognized 706 Multiple Appearances: Yes 707 Published in: this document 708 Status: current 710 Field Name: Canonical 711 Description: canonical URL for this file 712 Multiple Appearances: No 713 Published in: this document 714 Status: current 716 Field Name: Contact 717 Description: contact information to use for reporting vulnerabilities 718 Multiple Appearances: Yes 719 Published in: this document 720 Status: current 722 Field Name: Encryption 723 Description: link to a key to be used for encrypted communication 724 Multiple Appearances: Yes 725 Published in: this document 726 Status: current 728 Field Name: Hiring 729 Description: link to the vendor's security-related job positions 730 Multiple Appearances: Yes 731 Published in: this document 732 Status: current 734 Field Name: Policy 735 Description: link to security policy page 736 Multiple Appearances: Yes 737 Published in: this document 738 Status: current 740 Field Name: Preferred-Languages 741 Description: list of preferred languages for security reports 742 Multiple Appearances: No 743 Published in: this document 744 Status: current 746 8. Contributors 748 The authors would like to acknowledge the help provided during the 749 development of this document by Tom Hudson, Jobert Abma, Gerben 750 Janssen van Doorn, Austin Heap, Stephane Bortzmeyer, Max Smith, 751 Eduardo Vela and Krzysztof Kotowicz. 753 The authors would also like to acknowledge the feedback provided by 754 multiple members of IETF's SAAG and SEC-DISPATCH lists. 756 9. References 758 9.1. Normative References 760 [RFC1945] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext 761 Transfer Protocol -- HTTP/1.0", RFC 1945, 762 DOI 10.17487/RFC1945, May 1996, 763 . 765 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 766 Extensions (MIME) Part Two: Media Types", RFC 2046, 767 DOI 10.17487/RFC2046, November 1996, 768 . 770 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 771 Requirement Levels", BCP 14, RFC 2119, 772 DOI 10.17487/RFC2119, March 1997, 773 . 775 [RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and 776 Functions", RFC 2142, DOI 10.17487/RFC2142, May 1997, 777 . 779 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 780 Languages", BCP 18, RFC 2277, DOI 10.17487/RFC2277, 781 January 1998, . 783 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 784 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 785 2003, . 787 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 788 RFC 3966, DOI 10.17487/RFC3966, December 2004, 789 . 791 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 792 Resource Identifier (URI): Generic Syntax", STD 66, 793 RFC 3986, DOI 10.17487/RFC3986, January 2005, 794 . 796 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 797 Thayer, "OpenPGP Message Format", RFC 4880, 798 DOI 10.17487/RFC4880, November 2007, 799 . 801 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 802 Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, 803 . 805 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 806 Specifications: ABNF", STD 68, RFC 5234, 807 DOI 10.17487/RFC5234, January 2008, 808 . 810 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 811 DOI 10.17487/RFC5322, October 2008, 812 . 814 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 815 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 816 September 2009, . 818 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 819 Uniform Resource Identifiers (URIs)", RFC 5785, 820 DOI 10.17487/RFC5785, April 2010, 821 . 823 [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' 824 URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010, 825 . 827 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 828 Verification of Domain-Based Application Service Identity 829 within Internet Public Key Infrastructure Using X.509 830 (PKIX) Certificates in the Context of Transport Layer 831 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 832 2011, . 834 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 835 Protocol (HTTP/1.1): Message Syntax and Routing", 836 RFC 7230, DOI 10.17487/RFC7230, June 2014, 837 . 839 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 840 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 841 DOI 10.17487/RFC7231, June 2014, 842 . 844 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 845 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 846 May 2017, . 848 9.2. Informative References 850 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 851 RFC 793, DOI 10.17487/RFC0793, September 1981, 852 . 854 [RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, 855 DOI 10.17487/RFC2196, September 1997, 856 . 858 [RFC2350] Brownlee, N. and E. Guttman, "Expectations for Computer 859 Security Incident Response", BCP 21, RFC 2350, 860 DOI 10.17487/RFC2350, June 1998, 861 . 863 [RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS 864 Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999, 865 . 867 [RFC3013] Killalea, T., "Recommended Internet Service Provider 868 Security Services and Procedures", BCP 46, RFC 3013, 869 DOI 10.17487/RFC3013, November 2000, 870 . 872 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 873 "Special-Purpose IP Address Registries", BCP 153, 874 RFC 6890, DOI 10.17487/RFC6890, April 2013, 875 . 877 [RFC7485] Zhou, L., Kong, N., Shen, S., Sheng, S., and A. Servin, 878 "Inventory and Analysis of WHOIS Registration Objects", 879 RFC 7485, DOI 10.17487/RFC7485, March 2015, 880 . 882 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 883 Writing an IANA Considerations Section in RFCs", BCP 26, 884 RFC 8126, DOI 10.17487/RFC8126, June 2017, 885 . 887 Appendix A. Note to Readers 889 *Note to the RFC Editor:* Please remove this section prior to 890 publication. 892 Development of this draft takes place on Github at 893 https://github.com/securitytxt/security-txt 895 Appendix B. Document History 897 *Note to the RFC Editor:* Please remove this section prior to 898 publication. 900 B.1. Since draft-foudil-securitytxt-00 902 o Moved to use IETF's markdown tools for draft updates 904 o Added table of contents and a fuller list of references 906 o Moved file to .well-known URI and added IANA registration (#3) 908 o Added extensibility with an IANA registry for fields (#34) 910 o Added text explaining relationship to RFC 2142 / security@ email 911 address (#25) 913 o Scope expanded to include internal hosts, domains, IP addresses 914 and file systems 916 o Support for digital signatures added (#19) 918 The full list of changes can be viewed via the IETF document tracker: 919 https://tools.ietf.org/html/draft-foudil-securitytxt-01 921 B.2. Since draft-foudil-securitytxt-01 923 o Added appendix with pointer to Github and document history 925 o Added external signature file to the well known URI registry (#59) 927 o Added policy field (#53) 929 o Added diagram explaining the location of the file on public vs. 930 internal systems 932 o Added recommendation that external signature files should use 933 HTTPS (#55) 935 o Added recommendation that organizations should monitor their 936 security.txt files (#14) 938 The full list of changes can be viewed via the IETF document tracker: 939 https://tools.ietf.org/html/draft-foudil-securitytxt-02 941 B.3. Since draft-foudil-securitytxt-02 943 o Use "mailto" and "tel" (#62) 945 o Fix typo in the "Example" section (#64) 947 o Clarified that the root directory is a fallback option (#72) 949 o Defined content-type for the response (#68) 951 o Clarify the scope of the security.txt file (#69) 953 o Cleaning up text based on the NITS tools suggestions (#82) 955 o Added clarification for newline values 957 o Clarified the encryption field language, added examples of DNS- 958 stored encryption keys (#28 and #94) 960 o Added "Hiring" field 962 B.4. Since draft-foudil-securitytxt-03 964 o Added "Hiring" field to the registry section 966 o Added an encryption example using a PGP fingerprint (#107) 968 o Added reference to the mailing list (#111) 970 o Added a section referencing related work (#113) 972 o Fixes for idnits (#82) 974 o Changing some references to informative instead of normative 976 o Adding "Permission" field (#30) 978 o Fixing remaining ABNF issues (#83) 980 o Additional editorial changes and edits 982 B.5. Since draft-foudil-securitytxt-04 984 o Addressing IETF feedback (#118) 986 o Case sensitivity clarification (#127) 988 o Syntax fixes (#133, #135 and #136) 989 o Removed permission directive (#30) 991 o Removed signature directive and switched to inline signatures (#93 992 and #128) 994 o Adding canonical directive (#100) 996 o Text and ABNF grammar improvements plus ABNF changes for comments 997 (#123) 999 o Changed ".security.txt" to "security.txt" to be consistent 1001 B.6. Since draft-foudil-securitytxt-05 1003 o Changing HTTPS to MUST (#55) 1005 o Adding language recommending encryption for email reports (#134) 1007 o Added language handling redirects (#143) 1009 o Expanded security considerations section and fixed typos (#30, 1010 #73, #103, #112) 1012 Full list of changes can be viewed via the IETF document tracker: 1013 https://tools.ietf.org/html/draft-foudil-securitytxt 1015 Authors' Addresses 1017 Edwin Foudil 1019 Email: contact@edoverflow.com 1021 Yakov Shafranovich 1022 Nightwatch Cybersecurity 1024 Email: yakov+ietf@nightwatchcybersecurity.com