idnits 2.17.1 draft-foudil-securitytxt-05.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 (January 12, 2019) is 1928 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 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 2 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: July 16, 2019 Nightwatch Cybersecurity 6 January 12, 2019 8 A Method for Web Security Policies 9 draft-foudil-securitytxt-05 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 July 16, 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 . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . . . . 5 62 3.4. Digital signature . . . . . . . . . . . . . . . . . . . . 6 63 3.5. Field Definitions . . . . . . . . . . . . . . . . . . . . 6 64 3.5.1. Acknowledgments . . . . . . . . . . . . . . . . . . . 6 65 3.5.2. Canonical . . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . 9 74 4.1. Web-based services . . . . . . . . . . . . . . . . . . . 10 75 4.2. Filesystems . . . . . . . . . . . . . . . . . . . . . . . 10 76 4.3. Internal hosts . . . . . . . . . . . . . . . . . . . . . 11 77 4.4. Extensibility . . . . . . . . . . . . . . . . . . . . . . 11 78 5. File Format Description and ABNF Grammar . . . . . . . . . . 11 79 6. Security considerations . . . . . . . . . . . . . . . . . . . 12 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 81 7.1. Well-Known URIs registry . . . . . . . . . . . . . . . . 13 82 7.2. Registry for security.txt Header Fields . . . . . . . . . 13 83 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 86 9.2. Informative References . . . . . . . . . . . . . . . . . 17 87 Appendix A. Note to Readers . . . . . . . . . . . . . . . . . . 17 88 Appendix B. Document History . . . . . . . . . . . . . . . . . . 18 89 B.1. Since draft-foudil-securitytxt-00 . . . . . . . . . . . . 18 90 B.2. Since draft-foudil-securitytxt-01 . . . . . . . . . . . . 18 91 B.3. Since draft-foudil-securitytxt-02 . . . . . . . . . . . . 19 92 B.4. Since draft-foudil-securitytxt-03 . . . . . . . . . . . . 19 93 B.5. Since draft-foudil-securitytxt-04 . . . . . . . . . . . . 19 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 96 1. Introduction 98 1.1. Motivation and Prior Work 100 Many security researchers encounter situations where they are unable 101 to report security vulnerabilities to organizations because there is 102 no course of action laid out or no way indicated to contact the owner 103 of a particular resource. 105 As per section 4 of [RFC2142], there is an existing convention of 106 using the email address for communications 107 regarding security vulnerabilities. That convention provides only a 108 single, email-based channel of communication for security 109 vulnerabilities per domain, and does not provide a way for domain 110 owners to publish information about their security disclosure 111 policies. 113 There are also contact conventions prescribed for Internet Service 114 Providers (ISPs) in section 2 of [RFC3013], for Computer Security 115 Incident Response Teams (CSIRTs) in section 3.2 of [RFC2350] and for 116 site operators in section 5.2 of [RFC2196]. As per [RFC7485], there 117 is also contact information provided by Regional Internet Registries 118 (RIRs) and domain registries for owners of IP addresses, autonomous 119 system numbers (ASNs) and domain names. However, none of these 120 address the issue of how security researchers can locate disclosure 121 policies and contact information for organizations in order to report 122 security vulnerabilities. 124 In this document, we define a richer, machine-parsable and more 125 extensible way for organizations to communicate information about 126 their security disclosure policies, which is not limited to email and 127 also allows for additional features such as encryption. This format 128 is designed to help assist with the security disclosure process by 129 making it easier for organizations to designate the preferred steps 130 for researchers to take when trying to reach out to them with 131 security vulnerabilities. 133 1.2. Terminology 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 137 "OPTIONAL" in this document are to be interpreted as described in BCP 138 14 [RFC2119] [RFC8174] when, and only when, they appear in all 139 capitals, as shown here. 141 2. Note to Readers 143 *Note to the RFC Editor:* Please remove this section prior to 144 publication. 146 Development of this draft takes place on Github at: 147 https://github.com/securitytxt/security-txt 149 3. The Specification 151 This document defines a text file to be placed in a known location 152 that provides information for security researchers to assist in 153 disclosing security vulnerabilities. 155 The file is named "security.txt", and this file SHOULD be placed 156 under the /.well-known/ path ("/.well-known/security.txt") [RFC5785] 157 of a domain name or IP address for web properties. If it is not 158 possible to place the security.txt file in the /.well-known/ path or 159 setup a redirect, web-based services MAY place the file in the top- 160 level path of a given web domain or IP address ("/security.txt") as a 161 fall back option. For web-based services, the file MUST be 162 accessible via the Hypertext Transfer Protocol [RFC1945] as a 163 resource of Internet Media Type "text/plain" with the default charset 164 parameter set to "utf-8" per section 4.1.3 of [RFC2046], and it is 165 RECOMMENDED that this file be served with "https" (as per section 166 2.7.2 of [RFC7230]). For file systems and version control 167 repositories a "security.txt" file SHOULD be placed in the root 168 directory of a particular file system or source code project. 170 This text file contains multiple directives with different values. 171 The "directive" is the first part of a field all the way up to the 172 colon ("Contact:") and follows the syntax defined for "field-name" in 173 section 3.6.8 of [RFC5322]. Directives MUST be case-insensitive (as 174 per section 2.3 of [RFC5234]). The "value" comes after the directive 175 ("https://example.com/security") and follows the syntax defined for 176 "unstructured" in section 3.2.5 of [RFC5322]. 178 A "field" MUST always consist of a directive and a value ("Contact: 179 https://example.com/security"). A security.txt file can have an 180 unlimited number of fields. It is important to note that you MUST 181 have a separate line for every field. One MUST NOT chain multiple 182 values for a single directive and everything MUST be in a separate 183 field. Unless otherwise indicated in a definition of a particular 184 field, any directive MAY appear multiple times. 186 3.1. Scope 188 A "security.txt" file MUST only apply to the domain in the URI used 189 to retrieve it, not to any of its subdomains or parent domains. A 190 "security.txt" file that is found in a file system or version control 191 repository MUST only apply to the folder or repository in which it is 192 located, and not to any of its parent or sibling folders, or 193 repositories. However, it will apply to all subfolders. 195 Some examples appear below: 197 # The following only applies to example.com. 198 https://example.com/.well-known/security.txt 200 # This only applies to subdomain.example.com. 201 https://subdomain.example.com/.well-known/security.txt 203 # This security.txt file applies to IPv4 address of 192.0.2.0. 204 https://192.0.2.0/.well-known/security.txt 206 # This security.txt file applies to IPv6 address of 2001:db8:8:4::2. 207 https://[2001:db8:8:4::2]/.well-known/security.txt 209 # This security.txt file applies to the /example/folder1 directory. 210 /example/folder1/security.txt 212 3.2. Comments 214 Any line beginning with the "#" (%x30) symbol MUST be interpreted as 215 a comment. The content of the comment may contain any ASCII or 216 Unicode characters in the %x21-7E and %x80-FFFFF ranges plus the tab 217 (%x09) and space (%x20) characters. 219 Example: 221 # This is a comment. 223 You MAY use one or more comments as descriptive text immediately 224 before the field. Parsers SHOULD associate the comments with the 225 respective field. 227 3.3. Separate Fields 229 A separate line is REQUIRED for every new value and field. You MUST 230 NOT chain everything into a single field. Every line MUST end either 231 with a carriage return and line feed characters (CRLF / %x0D %x0A) or 232 just a line feed character (LF / %x0A). 234 3.4. Digital signature 236 It is RECOMMENDED that a security.txt file be digitally signed using 237 an OpenPGP cleartext signature as described in section 7 of 238 [RFC4880]. When digital signatures are used, it is also RECOMMENDED 239 that implementors use the "Canonical" directive as per Section 3.5.2, 240 thus allowing the digital signature to authenticate the location of 241 the file. 243 When it comes to verifying the key used to generate the signature, it 244 is always the security researcher's responsibility to make sure the 245 key being used is indeed one they trust. 247 3.5. Field Definitions 249 3.5.1. Acknowledgments 251 This directive allows you to link to a page where security 252 researchers are recognized for their reports. The page being linked 253 to SHOULD list individuals or organizations that reported security 254 vulnerabilities and worked with you to remediate the issue. 255 Organizations SHOULD be careful to limit the vulnerability 256 information being published in order to prevent future attacks. 258 Example: 260 Acknowledgments: https://example.com/hall-of-fame.html 262 Example security acknowledgments page: 264 We would like to thank the following researchers: 266 (2017-04-15) Frank Denis - Reflected cross-site scripting 267 (2017-01-02) Alice Quinn - SQL injection 268 (2016-12-24) John Buchner - Stored cross-site scripting 269 (2016-06-10) Anna Richmond - A server configuration issue 271 3.5.2. Canonical 273 This directive indicates the canonical URI where the security.txt 274 file is located, which is usually something like 275 "https://example.com/.well-known/security.txt". 277 This directive MUST NOT appear more than once. 279 Canonical: https://example.com/.well-known/security.txt 281 3.5.3. Contact 283 This directive allows you to provide an address that researchers 284 SHOULD use for reporting security vulnerabilities. The value MAY be 285 an email address, a phone number and/or a web page with contact 286 information. The "Contact:" directive MUST always be present in a 287 security.txt file. If this directive indicates a web URL, then it 288 RECOMMENDED that it begins with "https://" (as per section 2.7.2 of 289 [RFC7230]). Security email addresses SHOULD use the conventions 290 defined in section 4 of [RFC2142]. 292 The value MUST follow the URI syntax described in [RFC3986]. This 293 means that "mailto" and "tel" URI schemes MUST be used when 294 specifying email addresses and telephone numbers, as defined in 295 [RFC6068] and [RFC3966]. 297 The precedence SHOULD be in listed order. The first field is the 298 preferred method of contact. In the example below, the e-mail 299 address is the preferred method of contact. 301 Contact: mailto:security@example.com 302 Contact: tel:+1-201-555-0123 303 Contact: https://example.com/security-contact.html 305 3.5.4. Encryption 307 This directive allows you to point to an encryption key that security 308 researchers SHOULD use for encrypted communication. You MUST NOT 309 directly add your key to the field, instead the value of this field 310 MUST be a URI pointing to a location where the key can be retrieved 311 from. If this directive indicates a web URL, then it is RECOMMENDED 312 to always use "https://" URLs (as per section 2.7.2 of [RFC7230]). 314 When it comes to verifying the authenticity of the key, it is always 315 the security researcher's responsibility to make sure the key being 316 specified is indeed one they trust. Researchers MUST NOT assume that 317 this key is used to generate the digital signature referenced in 318 Section 3.4. 320 Example of an OpenPGP key available from a web server: 322 Encryption: https://example.com/pgp-key.txt 324 Example of an OpenPGP key available from an OPENPGPKEY DNS record: 326 Encryption: dns:5d2d37ab76d47d36._openpgpkey.example.com?type=OPENPGPKEY 328 Example of an OpenPGP key being referenced by its fingerprint: 330 Encryption: openpgp4fpr:5f2de5521c63a801ab59ccb603d49de44b29100f 332 3.5.5. Hiring 334 The "Hiring" directive is used for linking to the vendor's security- 335 related job positions. If this directive indicates a web URL, then 336 it is RECOMMENDED to always use "https://" URLs (as per section 2.7.2 337 of [RFC7230]). 339 Hiring: https://example.com/jobs.html 341 3.5.6. Policy 343 This directive allows you to link to where your security policy and/ 344 or disclosure policy is located. This can help security researchers 345 understand what you are looking for and how to report security 346 vulnerabilities. If this directive indicates a web URL, then it is 347 RECOMMENDED to always use "https://" URLs (as per section 2.7.2 of 348 [RFC7230]). 350 Example: 352 Policy: https://example.com/security-policy.html 354 3.5.7. Preferred-Languages 356 This directive can be used to indicate a set of natural languages 357 that are preferred when submitting security reports. This set MAY 358 list multiple values, separated by commas. If this directive is 359 included then at least one value MUST be listed. The values within 360 this set are language tags (as defined in [RFC5646]). If this 361 directive is absent, security researchers MAY assume that English is 362 the default language to be used (as per section 4.5 of [RFC2277]). 364 The order in which they appear MUST NOT be interpreted as an 365 indication of priority - rather these MUST BE interpreted as all 366 being of equal priority. 368 This directive MUST NOT appear more than once. 370 Example: 372 Preferred-Languages: en, es, fr 374 3.6. Example of an unsigned "security.txt" file 376 # Our security address 377 Contact: mailto:security@example.com 379 # Our OpenPGP key 380 Encryption: https://example.com/pgp-key.txt 382 # Our security policy 383 Policy: https://example.com/security-policy.html 385 # Our security acknowledgments page 386 Acknowledgments: https://example.com/hall-of-fame.html 388 3.7. Example of a signed "security.txt" file 390 ----BEGIN PGP SIGNED MESSAGE----- 391 Hash: SHA256 393 # Canonical URL 394 Canonical: https://example.com/.well-known/security.txt 396 # Our security address 397 Contact: mailto:security@example.com 399 # Our OpenPGP key 400 Encryption: https://example.com/pgp-key.txt 402 # Our security policy 403 Policy: https://example.com/security-policy.html 405 # Our security acknowledgments page 406 Acknowledgments: https://example.com/hall-of-fame.html 407 -----BEGIN PGP SIGNATURE----- 408 Version: GnuPG v1 410 [signature] 411 -----END PGP SIGNATURE----- 413 4. Location of the security.txt file 414 External 415 +----------------------------------------------------------------+ 416 | Default | 417 | +-----------------------------+ +-----------------+ | 418 | | | Redirect | | | 419 | | /.well-known/security.txt <----------+ /security.txt | | 420 | | | | | | 421 | +-----------------------------+ +-----------------+ | 422 | | 423 +----------------------------------------------------------------+ 425 Internal 426 +------------------------+ 427 | | 428 | +------------------+ | 429 | | | | 430 | | /security.txt | | 431 | | | | 432 | +------------------+ | 433 | | 434 +------------------------+ 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/ 440 security.txt. A security.txt file located under the top-level path 441 SHOULD either redirect (as per section 6.4 of [RFC7231]) to the 442 security.txt file under the /.well-known/ path or be used as a fall 443 back. 445 4.2. Filesystems 447 File systems SHOULD place the "security.txt" file under the root 448 directory; e.g., "/security.txt", "C:\security.txt". 450 Example file system: 452 /example-directory-1/ 453 /example-directory-2/ 454 /example-directory-3/ 455 /example-file 456 /security.txt 458 4.3. Internal hosts 460 A "security.txt" file SHOULD be placed in the root directory of an 461 internal host. 463 4.4. Extensibility 465 Like many other formats and protocols, this format may need to be 466 extended over time to fit the ever-changing landscape of the 467 Internet. Therefore, extensibility is provided via an IANA registry 468 for directives as defined in Section 7.2. Any directives registered 469 via that process MUST be considered optional. To encourage 470 extensibility and interoperability, implementors MUST ignore any 471 fields they do not explicitly support. 473 5. File Format Description and ABNF Grammar 475 The expected file format of the security.txt file is plain text (MIME 476 type "text/plain") as defined in section 4.1.3 of [RFC2046] and is 477 encoded using UTF-8 [RFC3629] in Net-Unicode form [RFC5198]. 479 The following is an ABNF definition of the security.txt format, using 480 the conventions defined in [RFC5234]. 482 body = signed / unsigned 484 signed = sign-header unsigned sign-footer 486 sign-header = 488 sign-footer = 490 unsigned = *line (canonical-field eol) (lang-field eol) *line 492 line = (field / comment) eol 494 eol = *WSP [CR] LF 496 field = ack-field / 497 contact-field / 498 encryption-field / 499 hiring-field / 500 policy-field / 501 ext-field 503 fs = ":" 505 comment = "#" *(WSP / VCHAR / %x80-FFFFF) 506 ack-field = "Acknowledgments" fs SP uri 508 canonical-field = "Canonical" fs SP uri 510 contact-field = "Contact" fs SP uri 512 lang-tag = 514 uri = 516 encryption-field = "Encryption" fs SP uri 518 hiring-field = "Hiring" fs SP uri 520 policy-field = "Policy" fs SP uri 522 lang-field = "Preferred-Languages" fs SP lang-values 524 lang-values = lang-tag *("," [WSP] lang-tag) 526 ext-field = field-name fs SP unstructured 528 field-name = 530 unstructured = 532 "ext-field" refers to extension fields, which are discussed in 533 Section 4.4 535 6. Security considerations 537 Organizations creating security.txt files will need to consider 538 several security-related issues. These include exposure to sensitive 539 information and attacks where limited access to a server could grant 540 the ability to modify the contents of the security.txt file or affect 541 how it is served. Organizations SHOULD also monitor their 542 security.txt files regularly to detect tampering. Organizations 543 SHOULD also ensure that any resources such as web pages, email 544 addresses and telephone numbers references by a "security.txt" file 545 are kept current, are accessible and controlled by the organization, 546 and are kept secure. 548 To ensure the authenticity of the security.txt file, organizations 549 SHOULD digitally sign this file with OpenPGP as per Section 3.4 and 550 SHOULD also use the "Canonical" directive as per Section 3.5.2. As 551 stated in Section 3.5.4, it is RECOMMENDED that encryption keys be 552 loaded over HTTPS (as per section 2.7.2 of [RFC7230]). 554 Websites SHOULD reserve the security.txt namespace to ensure no 555 third-party can create a page with the "security.txt" name. 557 7. IANA Considerations 559 example.com is used in this document following the uses indicated in 560 [RFC2606]. 562 192.0.2.0 and 2001:db8:8:4::2 are used in this document following the 563 uses indicated in [RFC6890]. 565 7.1. Well-Known URIs registry 567 The "Well-Known URIs" registry should be updated with the following 568 additional values (using the template from [RFC5785]): 570 URI suffix: security.txt 572 Change controller: IETF 574 Specification document(s): this document 576 7.2. Registry for security.txt Header Fields 578 IANA is requested to create the "security.txt Header Fields" registry 579 in accordance with [RFC8126]. This registry will contain header 580 fields for use in security.txt files, defined by this specification. 582 New registrations or updates MUST be published in accordance with the 583 "Expert Review" guidelines as described in section 4.5 of [RFC8126]. 584 Any new field thus registered is considered optional by this 585 specification unless a new version of this specification is 586 published. 588 New registrations and updates MUST contain the following information: 590 1. Name of the field being registered or updated 592 2. Short description of the field 594 3. Whether the field can appear more than once 596 4. The document in which the specification of the field is published 598 5. New or updated status, which MUST be one of: current: The field 599 is in current use deprecated: The field is in current use, but 600 its use is discouraged historic: The field is no longer in 601 current use 603 An update may make a notation on an existing registration indicating 604 that a registered field is historical or deprecated if appropriate. 606 The initial registry contains these values: 608 Field Name: Acknowledgments 609 Description: link to page where security researchers are recognized 610 Multiple Appearances: Yes 611 Published in: this document 612 Status: current 614 Field Name: Canonical 615 Description: canonical URL for this file 616 Multiple Appearances: No 617 Published in: this document 618 Status: current 620 Field Name: Contact 621 Description: contact information to use for reporting vulnerabilities 622 Multiple Appearances: Yes 623 Published in: this document 624 Status: current 626 Field Name: Encryption 627 Description: link to a key to be used for encrypted communication 628 Multiple Appearances: Yes 629 Published in: this document 630 Status: current 632 Field Name: Hiring 633 Description: link to the vendor's security-related job positions 634 Multiple Appearances: Yes 635 Published in: this document 636 Status: current 638 Field Name: Policy 639 Description: link to security policy page 640 Multiple Appearances: Yes 641 Published in: this document 642 Status: current 644 Field Name: Preferred-Languages 645 Description: list of preferred languages for security reports 646 Multiple Appearances: No 647 Published in: this document 648 Status: current 650 8. Contributors 652 The authors would like to acknowledge the help provided during the 653 development of this document by Tom Hudson, Jobert Abma, Gerben 654 Janssen van Doorn, Austin Heap, Stephane Bortzmeyer, Eduardo Vela and 655 Krzysztof Kotowicz. 657 The authors would also like to acknowledge the feedback provided by 658 multiple members of IETF's SAAG and SEC-DISPATCH lists. 660 9. References 662 9.1. Normative References 664 [RFC1945] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext 665 Transfer Protocol -- HTTP/1.0", RFC 1945, 666 DOI 10.17487/RFC1945, May 1996, 667 . 669 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 670 Extensions (MIME) Part Two: Media Types", RFC 2046, 671 DOI 10.17487/RFC2046, November 1996, 672 . 674 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 675 Requirement Levels", BCP 14, RFC 2119, 676 DOI 10.17487/RFC2119, March 1997, 677 . 679 [RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and 680 Functions", RFC 2142, DOI 10.17487/RFC2142, May 1997, 681 . 683 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 684 Languages", BCP 18, RFC 2277, DOI 10.17487/RFC2277, 685 January 1998, . 687 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 688 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 689 2003, . 691 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 692 RFC 3966, DOI 10.17487/RFC3966, December 2004, 693 . 695 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 696 Resource Identifier (URI): Generic Syntax", STD 66, 697 RFC 3986, DOI 10.17487/RFC3986, January 2005, 698 . 700 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 701 Thayer, "OpenPGP Message Format", RFC 4880, 702 DOI 10.17487/RFC4880, November 2007, 703 . 705 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 706 Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, 707 . 709 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 710 Specifications: ABNF", STD 68, RFC 5234, 711 DOI 10.17487/RFC5234, January 2008, 712 . 714 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 715 DOI 10.17487/RFC5322, October 2008, 716 . 718 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 719 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 720 September 2009, . 722 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 723 Uniform Resource Identifiers (URIs)", RFC 5785, 724 DOI 10.17487/RFC5785, April 2010, 725 . 727 [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' 728 URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010, 729 . 731 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 732 Protocol (HTTP/1.1): Message Syntax and Routing", 733 RFC 7230, DOI 10.17487/RFC7230, June 2014, 734 . 736 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 737 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 738 DOI 10.17487/RFC7231, June 2014, 739 . 741 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 742 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 743 May 2017, . 745 9.2. Informative References 747 [RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, 748 DOI 10.17487/RFC2196, September 1997, 749 . 751 [RFC2350] Brownlee, N. and E. Guttman, "Expectations for Computer 752 Security Incident Response", BCP 21, RFC 2350, 753 DOI 10.17487/RFC2350, June 1998, 754 . 756 [RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS 757 Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999, 758 . 760 [RFC3013] Killalea, T., "Recommended Internet Service Provider 761 Security Services and Procedures", BCP 46, RFC 3013, 762 DOI 10.17487/RFC3013, November 2000, 763 . 765 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 766 "Special-Purpose IP Address Registries", BCP 153, 767 RFC 6890, DOI 10.17487/RFC6890, April 2013, 768 . 770 [RFC7485] Zhou, L., Kong, N., Shen, S., Sheng, S., and A. Servin, 771 "Inventory and Analysis of WHOIS Registration Objects", 772 RFC 7485, DOI 10.17487/RFC7485, March 2015, 773 . 775 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 776 Writing an IANA Considerations Section in RFCs", BCP 26, 777 RFC 8126, DOI 10.17487/RFC8126, June 2017, 778 . 780 Appendix A. Note to Readers 782 *Note to the RFC Editor:* Please remove this section prior to 783 publication. 785 Development of this draft takes place on Github at 786 https://github.com/securitytxt/security-txt 788 Appendix B. Document History 790 *Note to the RFC Editor:* Please remove this section prior to 791 publication. 793 B.1. Since draft-foudil-securitytxt-00 795 o Moved to use IETF's markdown tools for draft updates 797 o Added table of contents and a fuller list of references 799 o Moved file to .well-known URI and added IANA registration (#3) 801 o Added extensibility with an IANA registry for fields (#34) 803 o Added text explaining relationship to RFC 2142 / security@ email 804 address (#25) 806 o Scope expanded to include internal hosts, domains, IP addresses 807 and file systems 809 o Support for digital signatures added (#19) 811 The full list of changes can be viewed via the IETF document tracker: 812 https://tools.ietf.org/html/draft-foudil-securitytxt-01 814 B.2. Since draft-foudil-securitytxt-01 816 o Added appendix with pointer to Github and document history 818 o Added external signature file to the well known URI registry (#59) 820 o Added policy field (#53) 822 o Added diagram explaining the location of the file on public vs. 823 internal systems 825 o Added recommendation that external signature files should use 826 HTTPS (#55) 828 o Added recommendation that organizations should monitor their 829 security.txt files (#14) 831 The full list of changes can be viewed via the IETF document tracker: 832 https://tools.ietf.org/html/draft-foudil-securitytxt-02 834 B.3. Since draft-foudil-securitytxt-02 836 o Use "mailto" and "tel" (#62) 838 o Fix typo in the "Example" section (#64) 840 o Clarified that the root directory is a fall back option (#72) 842 o Defined content-type for the response (#68) 844 o Clarify the scope of the security.txt file (#69) 846 o Cleaning up text based on the NITS tools suggestions (#82) 848 o Added clarification for newline values 850 o Clarified the encryption field language, added examples of DNS- 851 stored encryption keys (#28 and #94) 853 o Added "Hiring" field 855 B.4. Since draft-foudil-securitytxt-03 857 o Added "Hiring" field to the registry section 859 o Added an encryption example using a PGP fingerprint (#107) 861 o Added reference to the mailing list (#111) 863 o Added a section referencing related work (#113) 865 o Fixes for idnits (#82) 867 o Changing some references to informative instead of normative 869 o Adding "Permission" field (#30) 871 o Fixing remaining ABNF issues (#83) 873 o Additional editorial changes and edits 875 B.5. Since draft-foudil-securitytxt-04 877 o Addressing IETF feedback (#118) 879 o Case sensitivity clarification (#127) 881 o Syntax fixes (#133, #135 and #136) 882 o Removed permission directive (#30) 884 o Removed signature directive and switched to inline signatures (#93 885 and #128) 887 o Adding canonical directive (#100) 889 o Text and ABNF grammar improvements plus ABNF changes for comments 890 (#123) 892 o Changed ".security.txt" to "security.txt" to be consistent 894 Full list of changes can be viewed via the IETF document tracker: 895 https://tools.ietf.org/html/draft-foudil-securitytxt 897 Authors' Addresses 899 Edwin Foudil 901 Email: contact@edoverflow.com 903 Yakov Shafranovich 904 Nightwatch Cybersecurity 906 Email: yakov+ietf@nightwatchcybersecurity.com