idnits 2.17.1 draft-foudil-securitytxt-08.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 (November 19, 2019) is 1621 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: May 22, 2020 Nightwatch Cybersecurity 6 November 19, 2019 8 A Method for Web Security Policies 9 draft-foudil-securitytxt-08 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 May 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, 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. 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 . . . . . . . . . . . . . . . . . 14 85 6.6. Protecting Data in Transit . . . . . . . . . . . . . . . 14 86 6.7. Spam and Spurious Reports . . . . . . . . . . . . . . . . 14 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 88 7.1. Well-Known URIs registry . . . . . . . . . . . . . . . . 15 89 7.2. Registry for security.txt Header Fields . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . . 21 96 B.1. Since draft-foudil-securitytxt-00 . . . . . . . . . . . . 21 97 B.2. Since draft-foudil-securitytxt-01 . . . . . . . . . . . . 22 98 B.3. Since draft-foudil-securitytxt-02 . . . . . . . . . . . . 22 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 . . . . . . . . . . . . 23 102 B.7. Since draft-foudil-securitytxt-06 . . . . . . . . . . . . 24 103 B.8. Since draft-foudil-securitytxt-07 . . . . . . . . . . . . 24 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 106 1. Introduction 108 1.1. Motivation, Prior Work and Scope 110 Many security researchers encounter situations where they are unable 111 to report security vulnerabilities to organizations because there is 112 no course of action laid out and no way indicated to contact the 113 owner of a particular resource. 115 As per section 4 of [RFC2142], there is an existing convention of 116 using the email address for communications 117 regarding security vulnerabilities. That convention provides only a 118 single, email-based channel of communication for security 119 vulnerabilities per domain, and does not provide a way for domain 120 owners to publish information about their security disclosure 121 policies. 123 There are also contact conventions prescribed for Internet Service 124 Providers (ISPs) in section 2 of [RFC3013], for Computer Security 125 Incident Response Teams (CSIRTs) in section 3.2 of [RFC2350] and for 126 site operators in section 5.2 of [RFC2196]. As per [RFC7485], there 127 is also contact information provided by Regional Internet Registries 128 (RIRs) and domain registries for owners of IP addresses, autonomous 129 system numbers (ASNs) and domain names. However, none of these 130 address the issue of how security researchers can locate disclosure 131 policies and contact information for organizations in order to report 132 security vulnerabilities. 134 In this document, we define a richer, machine-parsable and extensible 135 way for organizations to communicate information about their security 136 disclosure policies, which is not limited to email and also allows 137 for additional features such as encryption. This format is designed 138 to help assist with the security disclosure process by making it 139 easier for organizations to designate the preferred steps for 140 researchers to take when trying to reach out to them with security 141 vulnerabilities. 143 Other details of vulnerability disclosure are outside the scope of 144 this document. Readers are encouraged to consult other documents 145 such as [ISO.29147.2018] or [CERT.CVD]. 147 1.2. Terminology 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 151 "OPTIONAL" in this document are to be interpreted as described in BCP 152 14 [RFC2119] [RFC8174] when, and only when, they appear in all 153 capitals, as shown here. 155 2. Note to Readers 157 *Note to the RFC Editor:* Please remove this section prior to 158 publication. 160 Development of this draft takes place on Github at: 161 https://github.com/securitytxt/security-txt 163 3. The Specification 165 This document defines a text file to be placed in a known location 166 that provides information for security researchers to assist in 167 disclosing security vulnerabilities. 169 The file is named "security.txt", and this file SHOULD be placed 170 under the /.well-known/ path ("/.well-known/security.txt") [RFC8615] 171 of a domain name or IP address for web properties. For legacy 172 compatibility, a security.txt file might be placed at the top level 173 path (see Section 4.1). 175 For web-based services, the file MUST be accessible via the Hypertext 176 Transfer Protocol (HTTP) [RFC1945] as a resource of Internet Media 177 Type "text/plain" with the default charset parameter set to "utf-8" 178 per section 4.1.3 of [RFC2046], and it MUST be served with "https" 179 (as per section 2.7.2 of [RFC7230]). For file systems and version 180 control repositories a "security.txt" file SHOULD be placed in the 181 root directory of a particular file system or source code project. 183 This text file contains multiple directives with different values. 184 The "directive" is the first part of a field all the way up to the 185 colon ("Contact:") and follows the syntax defined for "field-name" in 186 section 3.6.8 of [RFC5322]. Directives are case-insensitive (as per 187 section 2.3 of [RFC5234]). The "value" comes after the directive 188 ("https://example.com/security") and follows the syntax defined for 189 "unstructured" in section 3.2.5 of [RFC5322]. 191 A "field" MUST always consist of a directive and a value ("Contact: 192 https://example.com/security"). A security.txt file can have an 193 unlimited number of fields. It is important to note that each field 194 MUST appear on its own line. Unless specified otherwise by the field 195 definition, multiple values MUST NOT be chained together for a single 196 directive. Unless otherwise indicated in a definition of a 197 particular field, any directive MAY appear multiple times. 199 3.1. Scope of the File 201 A "security.txt" file MUST only apply to the domain in the URI used 202 to retrieve it, not to any of its subdomains or parent domains. A 203 "security.txt" file that is found in a file system or version control 204 repository MUST only apply to the folder or repository in which it is 205 located, and not to any of its parent or sibling folders, or 206 repositories. However, it will apply to all subfolders. 208 Some examples appear below: 210 # The following only applies to example.com. 211 https://example.com/.well-known/security.txt 213 # This only applies to subdomain.example.com. 214 https://subdomain.example.com/.well-known/security.txt 216 # This security.txt file applies to IPv4 address of 192.0.2.0. 217 https://192.0.2.0/.well-known/security.txt 219 # This security.txt file applies to IPv6 address of 2001:db8:8:4::2. 220 https://[2001:db8:8:4::2]/.well-known/security.txt 222 # This file applies to the /example/folder1 directory and subfolders. 223 /example/folder1/security.txt 225 3.2. Comments 227 Any line beginning with the "#" (%x30) symbol MUST be interpreted as 228 a comment. The content of the comment may contain any ASCII or 229 Unicode characters in the %x21-7E and %x80-FFFFF ranges plus the tab 230 (%x09) and space (%x20) characters. 232 Example: 234 # This is a comment. 236 One or more comments MAY be used as descriptive text immediately 237 before the field. Parsers SHOULD associate the comments with the 238 respective field. Only the line most immediately preceding a field 239 SHOULD be associated with that field. 241 3.3. Line Separator 243 Every line MUST end either with a carriage return and line feed 244 characters (CRLF / %x0D %x0A) or just a line feed character (LF / 245 %x0A). 247 3.4. Digital signature 249 It is RECOMMENDED that a security.txt file be digitally signed using 250 an OpenPGP cleartext signature as described in section 7 of 251 [RFC4880]. When digital signatures are used, it is also RECOMMENDED 252 that implementors use the "Canonical" directive (as per 253 Section 3.5.2), thus allowing the digital signature to authenticate 254 the location of the file. 256 When it comes to verifying the key used to generate the signature, it 257 is always the security researcher's responsibility to make sure the 258 key being used is indeed one they trust. 260 3.5. Field Definitions 262 3.5.1. Acknowledgments 264 This directive indicates a link to a page where security researchers 265 are recognized for their reports. The page being referenced SHOULD 266 list individuals or organizations that reported security 267 vulnerabilities and collaborated to remediate them. Organizations 268 SHOULD be careful to limit the vulnerability information being 269 published in order to prevent future attacks. 271 If this directive indicates a web URL, then it MUST begin with 272 "https://" (as per section 2.7.2 of [RFC7230]). 274 Example: 276 Acknowledgments: https://example.com/hall-of-fame.html 278 Example security acknowledgments page: 280 We would like to thank the following researchers: 282 (2017-04-15) Frank Denis - Reflected cross-site scripting 283 (2017-01-02) Alice Quinn - SQL injection 284 (2016-12-24) John Buchner - Stored cross-site scripting 285 (2016-06-10) Anna Richmond - A server configuration issue 287 3.5.2. Canonical 289 This directive indicates the canonical URI where the security.txt 290 file is located, which is usually something like 291 "https://example.com/.well-known/security.txt". If this directive 292 indicates a web URL, then it MUST begin with "https://" (as per 293 section 2.7.2 of [RFC7230]). The purpose of this directive is to 294 allow a digital signature to be applied to the location of the 295 "security.txt" file. 297 This directive MUST NOT appear more than once. 299 Canonical: https://example.com/.well-known/security.txt 301 3.5.3. Contact 303 This directive indicates an address that researchers should use for 304 reporting security vulnerabilities. The value MAY be an email 305 address, a phone number and/or a web page with contact information. 306 The "Contact:" directive MUST always be present in a security.txt 307 file. If this directive indicates a web URL, then it MUST begin with 308 "https://" (as per section 2.7.2 of [RFC7230]). Security email 309 addresses SHOULD use the conventions defined in section 4 of 310 [RFC2142]. 312 The value MUST follow the URI syntax described in [RFC3986]. This 313 means that "mailto" and "tel" URI schemes MUST be used when 314 specifying email addresses and telephone numbers, as defined in 315 [RFC6068] and [RFC3966]. When the value of this directive is an 316 email address, it is RECOMMENDED that encryption be used (as per 317 Section 3.5.4). 319 The precedence SHOULD be in listed order. The first field is the 320 preferred method of contact. In the example below, the email address 321 is the preferred method of contact. 323 Contact: mailto:security@example.com 324 Contact: tel:+1-201-555-0123 325 Contact: https://example.com/security-contact.html 327 3.5.4. Encryption 329 This directive indicates an encryption key that security researchers 330 SHOULD use for encrypted communication. Keys MUST NOT appear in this 331 field - instead the value of this field MUST be a URI pointing to a 332 location where the key can be retrieved. If this directive indicates 333 a web URL, then it MUST begin with "https://" (as per section 2.7.2 334 of [RFC7230]). 336 When it comes to verifying the authenticity of the key, it is always 337 the security researcher's responsibility to make sure the key being 338 specified is indeed one they trust. Researchers MUST NOT assume that 339 this key is used to generate the digital signature referenced in 340 Section 3.4. 342 Example of an OpenPGP key available from a web server: 344 Encryption: https://example.com/pgp-key.txt 346 Example of an OpenPGP key available from an OPENPGPKEY DNS record: 348 Encryption: dns:5d2d37ab76d47d36._openpgpkey.example.com?type=OPENPGPKEY 350 Example of an OpenPGP key being referenced by its fingerprint: 352 Encryption: openpgp4fpr:5f2de5521c63a801ab59ccb603d49de44b29100f 354 3.5.5. Hiring 356 The "Hiring" directive is used for linking to the vendor's security- 357 related job positions. If this directive indicates a web URL, then 358 it MUST begin with "https://" (as per section 2.7.2 of [RFC7230]). 360 Hiring: https://example.com/jobs.html 362 3.5.6. Policy 364 This directive indicates a link to where the security policy and/or 365 disclosure policy is located. This can help security researchers 366 understand what an organization is looking for and how to report 367 security vulnerabilities. If this directive indicates a web URL, 368 then it MUST begin with "https://" (as per section 2.7.2 of 369 [RFC7230]). 371 Example: 373 Policy: https://example.com/security-policy.html 375 3.5.7. Preferred-Languages 377 This directive can be used to indicate a set of natural languages 378 that are preferred when submitting security reports. This set MAY 379 list multiple values, separated by commas. If this directive is 380 included then at least one value MUST be listed. The values within 381 this set are language tags (as defined in [RFC5646]). If this 382 directive is absent, security researchers MAY assume that English is 383 the default language to be used (as per section 4.5 of [RFC2277]). 385 The order in which they appear MUST NOT be interpreted as an 386 indication of priority - rather these MUST be interpreted as all 387 being of equal priority. 389 This directive MUST NOT appear more than once. 391 Example (English, Spanish and French): 393 Preferred-Languages: en, es, fr 395 3.6. Example of an unsigned "security.txt" file 397 # Our security address 398 Contact: mailto:security@example.com 400 # Our OpenPGP key 401 Encryption: https://example.com/pgp-key.txt 403 # Our security policy 404 Policy: https://example.com/security-policy.html 406 # Our security acknowledgments page 407 Acknowledgments: https://example.com/hall-of-fame.html 409 3.7. Example of a signed "security.txt" file 411 ----BEGIN PGP SIGNED MESSAGE----- 412 Hash: SHA256 414 # Canonical URL 415 Canonical: https://example.com/.well-known/security.txt 417 # Our security address 418 Contact: mailto:security@example.com 420 # Our OpenPGP key 421 Encryption: https://example.com/pgp-key.txt 423 # Our security policy 424 Policy: https://example.com/security-policy.html 426 # Our security acknowledgments page 427 Acknowledgments: https://example.com/hall-of-fame.html 428 -----BEGIN PGP SIGNATURE----- 429 Version: GnuPG v2.2 431 [signature] 432 -----END PGP SIGNATURE----- 434 4. Location of the security.txt file 436 4.1. Web-based services 438 Web-based services SHOULD place the security.txt file under the 439 /.well-known/ path; e.g. https://example.com/.well-known/security.txt 440 as per [RFC8615]. For legacy compatibility, a security.txt file 441 might be placed at the top-level path or redirect (as per section 6.4 442 of [RFC7231]) to the security.txt file under the /.well-known/ path. 444 If retrieval of a "security.txt" file from the top-level path results 445 in a redirect (as per section 6.4 of [RFC7231]), the implementors 446 MUST NOT follow that redirect if it leads to another domain or 447 subdomain but SHOULD follow that redirect within the same domain name 448 (but not different subdomain on the same domain). 450 The guidance regarding redirects SHOULD NOT apply to the resource 451 locations that appear within the file. 453 4.2. Filesystems 455 File systems SHOULD place the "security.txt" file under the root 456 directory; e.g., "/security.txt", "C:\security.txt". 458 Example file system: 460 /example-directory-1/ 461 /example-directory-2/ 462 /example-directory-3/ 463 /example-file 464 /security.txt 466 4.3. Internal hosts 468 An internal host is "a host served by a NAT gateway, or protected by 469 a firewall" (as per section 3 of [RFC6887]) and might not be 470 accessible directly from the Internet. On such systems, a 471 "security.txt" file SHOULD be placed in the root directory. 473 4.4. Extensibility 475 Like many other formats and protocols, this format may need to be 476 extended over time to fit the ever-changing landscape of the 477 Internet. Therefore, extensibility is provided via an IANA registry 478 for directives as defined in Section 7.2. Any directives registered 479 via that process MUST be considered optional. To encourage 480 extensibility and interoperability, implementors MUST ignore any 481 fields they do not explicitly support. 483 In general, implementors SHOULD "be conservative in what you do, be 484 liberal in what you accept from others" (as per [RFC0793]). 486 5. File Format Description and ABNF Grammar 488 The expected file format of the security.txt file is plain text (MIME 489 type "text/plain") as defined in section 4.1.3 of [RFC2046] and is 490 encoded using UTF-8 [RFC3629] in Net-Unicode form [RFC5198]. 492 The following is an ABNF definition of the security.txt format, using 493 the conventions defined in [RFC5234]. 495 body = signed / unsigned 497 signed = sign-header unsigned sign-footer 499 sign-header = < headers and line from section 7 of [RFC4880] > 501 sign-footer = < OpenPGP signature from section 7 of [RFC4880] > 503 unsigned = *line [can-field eol] 504 *line (contact-field eol) 505 *line [lang-field eol] *line 506 ; the order of elements is not important 508 line = (field / comment) eol 510 eol = *WSP [CR] LF 512 field = ack-field / 513 contact-field / 514 encryption-field / 515 hiring-field / 516 policy-field / 517 ext-field 519 fs = ":" 521 comment = "#" *(WSP / VCHAR / %x80-FFFFF) 523 ack-field = "Acknowledgments" fs SP uri 525 can-field = "Canonical" fs SP uri 527 contact-field = "Contact" fs SP uri 529 lang-tag = < Language-Tag from section 2.1 of [RFC5646] > 530 uri = < URI as per [RFC3986] > 532 encryption-field = "Encryption" fs SP uri 534 hiring-field = "Hiring" fs SP uri 536 policy-field = "Policy" fs SP uri 538 lang-field = "Preferred-Languages" fs SP lang-values 540 lang-values = lang-tag *(*WSP "," *WSP lang-tag) 542 ext-field = field-name fs SP unstructured 544 field-name = < imported from section 3.6.8 of [RFC5322] > 546 unstructured = < imported from section 3.2.5 of [RFC5322] > 548 "ext-field" refers to extension fields, which are discussed in 549 Section 4.4 551 6. Security Considerations 553 In addition to the security considerations of [RFC8615], the 554 following considerations apply. 556 6.1. Compromised Files and Redirects 558 An attacker that has compromised a website is able to compromise the 559 "security.txt" file as well or setup a redirect to their own site. 560 This can result in security reports not being received by the 561 organization or sent to the attacker. 563 To protect against this, organizations SHOULD digitally sign their 564 "security.txt" files (as per Section 3.4), use the canonical 565 directive to sign the location of the file (as per Section 3.5.2), 566 and regularly monitor the file and the referenced resources to detect 567 tampering. 569 Security researchers SHOULD check the "security.txt" file including 570 verifying the digital signature and checking any available historical 571 records before using the information contained in the file. If 572 "security.txt" file looks suspicious or compromised, it SHOULD NOT be 573 used. 575 To avoid redirect attacks, redirects for these files MUST NOT be 576 followed when the file is placed in the top level path and they lead 577 to a different domain (as per Section 4.1). This restriction is 578 because the top level path is potentially more likely to be 579 compromised as opposed to the ".well-known" path. 581 6.2. Incorrect or Stale Information 583 If information and resources referenced in a "security.txt" file are 584 incorrect or not kept up to date, this can result in security reports 585 not being received by the organization or sent to incorrect contacts, 586 thus exposing possible security issues to third parties. Not having 587 a security.txt file may be preferable to having stale information in 588 this file. 590 Organizations SHOULD ensure that information in this file and any 591 referenced resources such as web pages, email addresses and telephone 592 numbers are kept current, are accessible, controlled by the 593 organization, and are kept secure. 595 6.3. Intentionally Malformed Files, Resources and Reports 597 It is possible for compromised or malicious sites to create files 598 that are extraordinarily large or otherwise malformed in an attempt 599 to discover or exploit weaknesses in parsing code. Implementors 600 SHOULD make sure that any such code is robust against large and 601 malformed files. The ABNF grammar (as defined in Section 5) SHOULD 602 be used as a way to verify these files. 604 The same concerns apply to any other resources referenced within 605 security.txt files, as well as any security reports received as a 606 result of publishing this file. Such resources and reports may be 607 hostile, malformed or malicious. 609 6.4. No Implied Permission for Testing 611 The presence of a security.txt file might be interpreted by 612 researchers as providing permission to do security testing against 613 that asset. This might result in increased testing against an 614 organization by researchers. On the other hand, a decision not to 615 publish a security.txt file might be interpreted by the organization 616 operating that website to be a way to signal to researchers that 617 permission to test that particular site or project is denied. This 618 might result in pushback against researchers reporting security 619 issues to that organization. 621 Therefore, implementors MUST NOT assume that presence or absence of a 622 "security.txt" file grants or denies permission for security testing. 623 Any such permission MAY be defined in a security or disclosure policy 624 (as per Section 3.5.6) or a new directive (as per Section 4.4). 626 6.5. Multi-user Environments 628 In multi-user / multi-tenant environments, it may possible for a user 629 to take over the location of the "security.txt" file. Organizations 630 SHOULD reserve the "security.txt" namespace at the root to ensure no 631 third-party can create a page with the "security.txt" AND "/.well- 632 known/security.txt" names. 634 6.6. Protecting Data in Transit 636 To protect a "security.txt" file from being tampered with in transit, 637 implementors MUST use HTTPS (as per [RFC2818]) when serving the file 638 itself and for retrieval of any web URLs referenced in it (except 639 when otherwise noted in this specification). As part of the TLS 640 handshake, implementors MUST validate the provided X.509 certificate 641 in accordance with [RFC6125] and the following considerations: 643 o Matching is performed only against the DNS-ID identifiers. 645 o DNS domain names in server certificates MAY contain the wildcard 646 character '*' as the complete left-most label within the 647 identifier. 649 The certificate MAY be checked for revocation via the Online 650 Certificate Status Protocol (OCSP) [RFC6960], certificate revocation 651 lists (CRLs), or similar mechanisms. 653 As an additional layer of protection, it is also RECOMMENDED that 654 organizations digitally sign their "security.txt" file with OpenPGP 655 (as per Section 3.4). Also, to protect security reports from being 656 tampered with or observed while in transit, organizations SHOULD 657 specify encryption keys (as per Section 3.5.4) unless HTTPS is being 658 used. 660 However, the determination of validity of such keys is out of scope 661 for this specification. Implementors MUST establish other secure 662 means to verify them. 664 6.7. Spam and Spurious Reports 666 Similar to concerns in [RFC2142], denial of service attacks via spam 667 reports would become easier once a "security.txt" file is published 668 by an organization. In addition, there is an increased likelihood of 669 reports being sent in an automated fashion and/or as result of 670 automated scans without human triage. 672 Organizations SHOULD weigh the advantages of publishing this file 673 versus the possible disadvantages and increased resources required to 674 triage security reports. 676 Security researchers SHOULD consult the organization's policy, if 677 available, before submitting reports in an automated fashion or as 678 resulting from automated scans. 680 7. IANA Considerations 682 example.com is used in this document following the uses indicated in 683 [RFC2606]. 685 192.0.2.0 and 2001:db8:8:4::2 are used in this document following the 686 uses indicated in [RFC6890]. 688 7.1. Well-Known URIs registry 690 The "Well-Known URIs" registry should be updated with the following 691 additional values (using the template from [RFC8615]): 693 URI suffix: security.txt 695 Change controller: IETF 697 Specification document(s): this document 699 Status: permanent 701 7.2. Registry for security.txt Header Fields 703 IANA is requested to create the "security.txt Header Fields" registry 704 in accordance with [RFC8126]. This registry will contain header 705 fields for use in security.txt files, defined by this specification. 707 New registrations or updates MUST be published in accordance with the 708 "Expert Review" guidelines as described in sections 4.5 and 5 of 709 [RFC8126]. Any new field thus registered is considered optional by 710 this specification unless a new version of this specification is 711 published. 713 Designated Experts are expected to check whether a proposed 714 registration or update makes sense in the context of this 715 specification and provides value to the wider Internet community. 717 New registrations and updates MUST contain the following information: 719 1. Name of the field being registered or updated 720 2. Short description of the field 722 3. Whether the field can appear more than once 724 4. The document in which the specification of the field is published 725 (if available) 727 5. New or updated status, which MUST be one of: 729 * current: The field is in current use 731 * deprecated: The field is in current use, but its use is 732 discouraged 734 * historic: The field is no longer in current use 736 6. Change controller 738 An update may make a notation on an existing registration indicating 739 that a registered field is historical or deprecated if appropriate. 741 The initial registry contains these values: 743 Field Name: Acknowledgments 744 Description: link to page where security researchers are recognized 745 Multiple Appearances: Yes 746 Published in: this document 747 Status: current 748 Change controller: IESG 750 Field Name: Canonical 751 Description: canonical URL for this file 752 Multiple Appearances: No 753 Published in: this document 754 Status: current 755 Change controller: IESG 757 Field Name: Contact 758 Description: contact information to use for reporting vulnerabilities 759 Multiple Appearances: Yes 760 Published in: this document 761 Status: current 762 Change controller: IESG 764 Field Name: Encryption 765 Description: link to a key to be used for encrypted communication 766 Multiple Appearances: Yes 767 Published in: this document 768 Status: current 769 Change controller: IESG 771 Field Name: Hiring 772 Description: link to the vendor's security-related job positions 773 Multiple Appearances: Yes 774 Published in: this document 775 Status: current 776 Change controller: IESG 778 Field Name: Policy 779 Description: link to security policy page 780 Multiple Appearances: Yes 781 Published in: this document 782 Status: current 783 Change controller: IESG 785 Field Name: Preferred-Languages 786 Description: list of preferred languages for security reports 787 Multiple Appearances: No 788 Published in: this document 789 Status: current 790 Change controller: IESG 792 8. Contributors 794 The authors would like to acknowledge the help provided during the 795 development of this document by Tom Hudson, Jobert Abma, Gerben 796 Janssen van Doorn, Austin Heap, Stephane Bortzmeyer, Max Smith, 797 Eduardo Vela and Krzysztof Kotowicz. 799 The authors would also like to acknowledge the feedback provided by 800 multiple members of IETF's SAAG and SECDISPATCH lists. 802 9. References 804 9.1. Normative References 806 [RFC1945] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext 807 Transfer Protocol -- HTTP/1.0", RFC 1945, 808 DOI 10.17487/RFC1945, May 1996, 809 . 811 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 812 Extensions (MIME) Part Two: Media Types", RFC 2046, 813 DOI 10.17487/RFC2046, November 1996, 814 . 816 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 817 Requirement Levels", BCP 14, RFC 2119, 818 DOI 10.17487/RFC2119, March 1997, 819 . 821 [RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and 822 Functions", RFC 2142, DOI 10.17487/RFC2142, May 1997, 823 . 825 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 826 Languages", BCP 18, RFC 2277, DOI 10.17487/RFC2277, 827 January 1998, . 829 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 830 DOI 10.17487/RFC2818, May 2000, 831 . 833 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 834 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 835 2003, . 837 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 838 RFC 3966, DOI 10.17487/RFC3966, December 2004, 839 . 841 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 842 Resource Identifier (URI): Generic Syntax", STD 66, 843 RFC 3986, DOI 10.17487/RFC3986, January 2005, 844 . 846 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 847 Thayer, "OpenPGP Message Format", RFC 4880, 848 DOI 10.17487/RFC4880, November 2007, 849 . 851 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 852 Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, 853 . 855 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 856 Specifications: ABNF", STD 68, RFC 5234, 857 DOI 10.17487/RFC5234, January 2008, 858 . 860 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 861 DOI 10.17487/RFC5322, October 2008, 862 . 864 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 865 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 866 September 2009, . 868 [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' 869 URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010, 870 . 872 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 873 Verification of Domain-Based Application Service Identity 874 within Internet Public Key Infrastructure Using X.509 875 (PKIX) Certificates in the Context of Transport Layer 876 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 877 2011, . 879 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 880 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 881 DOI 10.17487/RFC6887, April 2013, 882 . 884 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 885 Galperin, S., and C. Adams, "X.509 Internet Public Key 886 Infrastructure Online Certificate Status Protocol - OCSP", 887 RFC 6960, DOI 10.17487/RFC6960, June 2013, 888 . 890 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 891 Protocol (HTTP/1.1): Message Syntax and Routing", 892 RFC 7230, DOI 10.17487/RFC7230, June 2014, 893 . 895 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 896 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 897 DOI 10.17487/RFC7231, June 2014, 898 . 900 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 901 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 902 May 2017, . 904 [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers 905 (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, 906 . 908 9.2. Informative References 910 [CERT.CVD] 911 Software Engineering Institute, Carnegie Mellon 912 University, "The CERT Guide to Coordinated Vulnerability 913 Disclosure (CMU/SEI-2017-SR-022)", 2017. 915 [ISO.29147.2018] 916 International Organization for Standardization (ISO), 917 "ISO/IEC 29147:2018, Information technology -- Security 918 techniques -- Vulnerability disclosure", 2018. 920 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 921 RFC 793, DOI 10.17487/RFC0793, September 1981, 922 . 924 [RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, 925 DOI 10.17487/RFC2196, September 1997, 926 . 928 [RFC2350] Brownlee, N. and E. Guttman, "Expectations for Computer 929 Security Incident Response", BCP 21, RFC 2350, 930 DOI 10.17487/RFC2350, June 1998, 931 . 933 [RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS 934 Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999, 935 . 937 [RFC3013] Killalea, T., "Recommended Internet Service Provider 938 Security Services and Procedures", BCP 46, RFC 3013, 939 DOI 10.17487/RFC3013, November 2000, 940 . 942 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 943 "Special-Purpose IP Address Registries", BCP 153, 944 RFC 6890, DOI 10.17487/RFC6890, April 2013, 945 . 947 [RFC7485] Zhou, L., Kong, N., Shen, S., Sheng, S., and A. Servin, 948 "Inventory and Analysis of WHOIS Registration Objects", 949 RFC 7485, DOI 10.17487/RFC7485, March 2015, 950 . 952 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 953 Writing an IANA Considerations Section in RFCs", BCP 26, 954 RFC 8126, DOI 10.17487/RFC8126, June 2017, 955 . 957 Appendix A. Note to Readers 959 *Note to the RFC Editor:* Please remove this section prior to 960 publication. 962 Development of this draft takes place on Github at 963 https://github.com/securitytxt/security-txt 965 Appendix B. Document History 967 *Note to the RFC Editor:* Please remove this section prior to 968 publication. 970 B.1. Since draft-foudil-securitytxt-00 972 o Moved to use IETF's markdown tools for draft updates 974 o Added table of contents and a fuller list of references 976 o Moved file to .well-known URI and added IANA registration (#3) 978 o Added extensibility with an IANA registry for fields (#34) 980 o Added text explaining relationship to RFC 2142 / security@ email 981 address (#25) 983 o Scope expanded to include internal hosts, domains, IP addresses 984 and file systems 986 o Support for digital signatures added (#19) 988 The full list of changes can be viewed via the IETF document tracker: 989 https://tools.ietf.org/html/draft-foudil-securitytxt-01 991 B.2. Since draft-foudil-securitytxt-01 993 o Added appendix with pointer to Github and document history 995 o Added external signature file to the well known URI registry (#59) 997 o Added policy field (#53) 999 o Added diagram explaining the location of the file on public vs. 1000 internal systems 1002 o Added recommendation that external signature files should use 1003 HTTPS (#55) 1005 o Added recommendation that organizations should monitor their 1006 security.txt files (#14) 1008 The full list of changes can be viewed via the IETF document tracker: 1009 https://tools.ietf.org/html/draft-foudil-securitytxt-02 1011 B.3. Since draft-foudil-securitytxt-02 1013 o Use "mailto" and "tel" (#62) 1015 o Fix typo in the "Example" section (#64) 1017 o Clarified that the root directory is a fallback option (#72) 1019 o Defined content-type for the response (#68) 1021 o Clarify the scope of the security.txt file (#69) 1023 o Cleaning up text based on the NITS tools suggestions (#82) 1025 o Added clarification for newline values 1027 o Clarified the encryption field language, added examples of DNS- 1028 stored encryption keys (#28 and #94) 1030 o Added "Hiring" field 1032 B.4. Since draft-foudil-securitytxt-03 1034 o Added "Hiring" field to the registry section 1036 o Added an encryption example using a PGP fingerprint (#107) 1038 o Added reference to the mailing list (#111) 1040 o Added a section referencing related work (#113) 1042 o Fixes for idnits (#82) 1044 o Changing some references to informative instead of normative 1046 o Adding "Permission" field (#30) 1048 o Fixing remaining ABNF issues (#83) 1050 o Additional editorial changes and edits 1052 B.5. Since draft-foudil-securitytxt-04 1054 o Addressing IETF feedback (#118) 1056 o Case sensitivity clarification (#127) 1058 o Syntax fixes (#133, #135 and #136) 1060 o Removed permission directive (#30) 1062 o Removed signature directive and switched to inline signatures (#93 1063 and #128) 1065 o Adding canonical directive (#100) 1067 o Text and ABNF grammar improvements plus ABNF changes for comments 1068 (#123) 1070 o Changed ".security.txt" to "security.txt" to be consistent 1072 B.6. Since draft-foudil-securitytxt-05 1074 o Changing HTTPS to MUST (#55) 1076 o Adding language recommending encryption for email reports (#134) 1078 o Added language handling redirects (#143) 1079 o Expanded security considerations section and fixed typos (#30, 1080 #73, #103, #112) 1082 B.7. Since draft-foudil-securitytxt-06 1084 o Fixed ABNF grammar for non-chainable directives (#150) 1086 o Clarified ABNF grammar (#152) 1088 o Clarified redirect logic (#143) 1090 o Clarified comments (#158) 1092 o Updated references and template for well-known URI to RFC 8615 1094 o Fixed nits from the IETF validator 1096 B.8. Since draft-foudil-securitytxt-07 1098 o Addressing AD feedback (#165) 1100 o Fix for ABNF grammar in lang-values (#164) 1102 o Fixing idnits warnings 1104 o Adding guidance for designated experts 1106 Full list of changes can be viewed via the IETF document tracker: 1107 https://tools.ietf.org/html/draft-foudil-securitytxt 1109 Authors' Addresses 1111 Edwin Foudil 1113 Email: contact@edoverflow.com 1115 Yakov Shafranovich 1116 Nightwatch Cybersecurity 1118 Email: yakov+ietf@nightwatchcybersecurity.com