RFC 9116

A File Format to Aid in Security Vulnerability Disclosure

📅 published April 2022, from ietf

A File Format to Aid in Security Vulnerability Disclosure 🎀

Bestie, here's the paperwork vibe check ✨

This one is RFC 9116, published in April 2022 as an Informational document (not a Standards Track spec, so it's a guide, not a rulebook 🫶). The authors are E. Foudil and Y. Shafranovich, and Shafranovich is with Nightwatch Cybersecurity. It's part of the ISSN 2070-1721 series. The title block doesn't list anything it obsoletes or updates, so it's a clean slate 🧹

Abstract

okay so security researchers find bugs all the time, but they often have no idea where to send them 😭 which means some vulnerabilities just... never get reported. 💀 This document defines a machine-parsable file called "security.txt" 📄 that lets an organization describe how it handles vulnerability disclosure, so researchers can actually figure out how to report stuff. main character energy for the whole security community 👑

Status of This Memo

this is not an Internet Standards Track spec, it's just published for information 📚

it's an IETF product 💅 and it represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 if you're curious 🤓

for updates, errata, or to leave feedback, go to https://www.rfc-editor.org/info/rfc9116 🦋

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. ✨

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stood on the publication date. read those carefully, bestie, they spell out your rights and restrictions for this doc 🧐

and if you pull Code Components out of this doc, they must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions. they come with no warranty, per the Revised BSD License 🌸

Table of Contents

1.  Introduction
  1.1.  Motivation, Prior Work, and Scope
  1.2.  Terminology
2.  The Specification
  2.1.  Comments
  2.2.  Line Separator
  2.3.  Digital Signature
  2.4.  Extensibility
  2.5.  Field Definitions
    2.5.1.  Acknowledgments
    2.5.2.  Canonical
    2.5.3.  Contact
    2.5.4.  Encryption
    2.5.5.  Expires
    2.5.6.  Hiring
    2.5.7.  Policy
    2.5.8.  Preferred-Languages
  2.6.  Example of an Unsigned "security.txt" File
  2.7.  Example of a Signed "security.txt" File
3.  Location of the security.txt File
  3.1.  Scope of the File
4.  File Format Description and ABNF Grammar
5.  Security Considerations
  5.1.  Compromised Files and Incident Response
  5.2.  Redirects
  5.3.  Incorrect or Stale Information
  5.4.  Intentionally Malformed Files, Resources, and Reports
  5.5.  No Implied Permission for Testing
  5.6.  Multi-User Environments
  5.7.  Protecting Data in Transit
  5.8.  Spam and Spurious Reports
6.  IANA Considerations
  6.1.  Well-Known URIs Registry
  6.2.  Registry for security.txt Fields
7.  References
  7.1.  Normative References
  7.2.  Informative References
Acknowledgments
Authors' Addresses

1. Introduction

1.1. Motivation, Prior Work, and Scope

lots of security researchers hit a wall 🧱 they want to report a vulnerability, but there's no reporting channel for the owner of the resource, and no info at all about how that owner handles disclosure. so they just... give up 😭

as per Section 4 of [RFC2142], there's an existing convention of using the <SECURITY@domain> email address for security stuff. the problem is that it gives you exactly one email-based channel per domain, and it has no way for domain owners to publish their disclosure practices 💅

there are also contact conventions for other folks: Internet Service Providers (ISPs) in Section 2 of [RFC3013], Computer Security Incident Response Teams (CSIRTs) in Section 3.2 of [RFC2350], and site operators in Section 5.2 of [RFC2196]. as per [RFC7485], Regional Internet Registries (RIRs) and domain registries also provide contact info for owners of IP addresses, Autonomous System Numbers (ASNs), and domain names. but none of these solve the actual problem, which is how a researcher can find contact info and disclosure practices for an organization in order to report a vulnerability 🙈

so this doc defines a richer, machine-parsable, and more extensible way for organizations to share their security disclosure practices and how to reach them ✨ other details of vulnerability disclosure are out of scope here. readers are encouraged to check out other docs like [ISO.29147.2018] or [CERT.CVD] 📚

as per [CERT.CVD], "vulnerability response" means reports of product vulnerabilities. it's related to, but different from, reports of network intrusions and compromised websites, which is "incident response" 🔥 this mechanism is meant for the former ("vulnerability response"). if implementors want to use it for incident response, they should be aware of the additional security considerations in Section 5.1 👀

the "security.txt" file is meant to complement other public resources organizations keep about their security disclosure practices. it's NOT a replacement for them 🫶

1.2. Terminology

okay this part is important bestie 🎀 the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. so lowercase "should" is just a regular word, but CAPITAL "SHOULD" is a real requirement 💜

"researcher" is the same as "finder" and "reporter" in [ISO.29147.2018] and [CERT.CVD]. "organization" is the same as "vendor" in those same docs 🌈

and "implementors" covers every party involved in the vulnerability disclosure process 🧚

2. The Specification

this doc defines a text file that lives in a known location and tells you how a particular organization handles vulnerability disclosure 📄 the format is machine parsable, and the file MUST follow the ABNF grammar in Section 4. the whole point is to help security researchers disclose vulnerabilities 🦋

by convention, the file is called "security.txt". where it lives and its scope are in Section 3 🌸

the file has multiple fields, each with a value. a field has a "name", which is everything from the start of the field up to the colon (like "Contact:"), and it follows the "field-name" syntax in Section 3.6.8 of [RFC5322]. field names are case insensitive (as per Section 2.3 of [RFC5234]) ✨ the "value" comes after the field name (like "mailto:security@example.com") and follows the "unstructured" syntax in Section 3.2.5 of [RFC5322]. the file MAY also contain blank lines 🫧

a field MUST always consist of a name and a value (like Contact: mailto:security@example.com). a "security.txt" file can have an unlimited number of fields 🤯 each field MUST appear on its own line. unless the field definition says otherwise, multiple values MUST NOT be chained together for a single field. and unless a field definition says otherwise, a field MAY appear multiple times 💅

implementors should know that some fields may contain URIs using percent-encoding (as per Section 2.1 of [RFC3986]) 🙈

2.1. Comments

any line that begins with the "#" (%x23) symbol MUST be interpreted as a comment 💬 the comment can contain any ASCII or Unicode characters in the %x21-7E and %x80-FFFFF ranges, plus the tab (%x09) and space (%x20) characters.

Example:

# This is a comment.

2.2. Line Separator

every line MUST end with either a carriage return and line feed (CRLF / %x0D %x0A) or just a line feed (LF / %x0A) 📏

2.3. Digital Signature

it is RECOMMENDED that a "security.txt" file be digitally signed using an OpenPGP cleartext signature, as described in Section 7 of [RFC4880] 🔐 when signatures are used, it is also RECOMMENDED that organizations use the "Canonical" field (as per Section 2.5.2). that way, the signature can authenticate where the file lives 🧾

when it comes to verifying the key used to make the signature, it is always the security researcher's job to make sure they actually trust that key 🕵️‍♀️

2.4. Extensibility

like many formats and protocols, this one may need to change over time to keep up with the ever-changing internet 🌐 so extensibility is handled through an IANA registry for fields, as defined in Section 6.2. any field registered through that process MUST be considered optional. and to keep things interoperable, researchers MUST ignore any fields they don't explicitly support 🫶

in general, implementors should "be conservative in what you do, be liberal in what you accept from others" (as per [RFC0793]) 💖

2.5. Field Definitions

unless stated otherwise, all fields MUST be considered optional ✨

2.5.1. Acknowledgments

the "Acknowledgments" field links to a page where security researchers get recognized for their reports 🏆 that page should list researchers who reported vulnerabilities and worked with the org to fix them. organizations should be careful not to publish so much vulnerability info that it helps future attacks 🙈

if this field is a web URI, it MUST begin with "https://" (as per Section 2.7.2 of [RFC7230]) 🔒

Example:

Acknowledgments: https://example.com/hall-of-fame.html

Example security acknowledgments page:

We would like to thank the following researchers:

(2017-04-15) Frank Denis - Reflected cross-site scripting
(2017-01-02) Alice Quinn  - SQL injection
(2016-12-24) John Buchner - Stored cross-site scripting
(2016-06-10) Anna Richmond - A server configuration issue

2.5.2. Canonical

the "Canonical" field lists the canonical URIs where the "security.txt" file lives, which is usually something like "https://example.com/.well-known/security.txt" 📍 if this field is a web URI, it MUST begin with "https://" (as per Section 2.7.2 of [RFC7230]) 🔒

so this field says that a "security.txt" retrieved from a given URI is meant to apply to that URI. but it MUST NOT be read as applying to every canonical URI listed inside the file 🚫 researchers SHOULD use an extra trust mechanism, like a digital signature (as per Section 2.3), to decide whether a particular canonical URI actually applies 🧐

and if this field shows up in a "security.txt" file, but the URI used to retrieve that file isn't listed in any canonical field, then the file's contents SHOULD NOT be trusted 💀

Example:

Canonical: https://www.example.com/.well-known/security.txt
Canonical: https://someserver.example.com/.well-known/security.txt

2.5.3. Contact 📬

The "Contact" field is where researchers can find out how to report security vulnerabilities 🔐 okay so this can be an email address, a phone number, a web page with contact info, or any combo of those. This field MUST always be present in a "security.txt" file, no exceptions bestie 🙅‍♀️. If the value is a web URI, it MUST begin with "https://" (as per Section 2.7.2 of [RFC7230]). Security email addresses should follow the conventions in Section 4 of [RFC2142] 💌.

The value MUST follow the URI syntax from Section 3 of [RFC3986] 🧚. That means email addresses have to use the "mailto" scheme and phone numbers have to use the "tel" scheme, as defined in [RFC6068] and [RFC3966] 📱. When the value is an email address, it is RECOMMENDED that encryption be used (as per Section 2.5.4) 🔒✨.

These SHOULD be listed in order of preference 💅, so the first occurrence is the preferred method of contact, the second occurrence is the second most preferred, and so on 🥇🥈🥉. In the example below, the first email address ("security@example.com") is the preferred method of contact 💖.

Contact: mailto:security@example.com
Contact: mailto:security%2Buri%2Bencoded@example.com
Contact: tel:+1-201-555-0123
Contact: https://example.com/security-contact.html

2.5.4. Encryption 🔐🦋

The "Encryption" field points to an encryption key that security researchers should use for encrypted communication 💜. Keys MUST NOT appear in this field, bestie 🙅‍♀️. Instead, the value MUST be a URI pointing to a location where the key can be retrieved 🗝️. If the value is a web URI, it MUST begin with "https://" (as per Section 2.7.2 of [RFC7230]) 🌐.

Verifying the authenticity of the key is always the security researcher's responsibility 🕵️‍♀️. Make sure the key is one you actually trust. Researchers must not assume this key is used to generate the digital signature referenced in Section 2.3 🙈.

Example of an OpenPGP key available from a web server:

Encryption: https://example.com/pgp-key.txt

Example of an OpenPGP key available from an OPENPGPKEY DNS record:

Encryption: dns:5d2d37ab76d47d36._openpgpkey.example.com?type=OPENPGPKEY

Example of an OpenPGP key being referenced by its fingerprint:

Encryption: openpgp4fpr:5f2de5521c63a801ab59ccb603d49de44b29100f

2.5.5. Expires ⏰

The "Expires" field tells everyone the date and time after which the data in the "security.txt" file is considered stale and should not be used (as per Section 5.3) 🥀. The value is formatted according to the Internet profiles of [ISO.8601-1] and [ISO.8601-2] as defined in [RFC3339] 📅. It is RECOMMENDED that the value be less than a year into the future to avoid staleness 🙌.

This field MUST always be present and MUST NOT appear more than once 🚫. One and done, periodt 💅.

Expires: 2021-12-31T18:37:07z

2.5.6. Hiring 💼

The "Hiring" field is used for linking to the vendor's security-related job positions 👩‍💻✨. If the value is a web URI, it MUST begin with "https://" (as per Section 2.7.2 of [RFC7230]) 🔗.

Hiring: https://example.com/jobs.html

2.5.7. Policy 📜

The "Policy" field links to where the vulnerability disclosure policy lives 📖. This can help security researchers understand the organization's vulnerability reporting practices, which is lowkey so important 🧠. If the value is a web URI, it MUST begin with "https://" (as per Section 2.7.2 of [RFC7230]) 🔒.

Example:

Policy: https://example.com/disclosure-policy.html

2.5.8. Preferred-Languages 🌍🗣️

The "Preferred-Languages" field can be used to say which natural languages are preferred when submitting security reports 💬. This set MAY list multiple values, separated by commas 🎀. If this field is included, then at least one value MUST be listed, no empty vibes 🙅‍♀️. The values are language tags (as defined in [RFC5646]) 🏳️‍🌈. If this field is absent, security researchers may assume that English is the language to be used (as per Section 4.5 of [RFC2277]) 🇬🇧.

The order they appear in is not an indication of priority 🙃. The listed languages are intended to have equal priority, so no favourites 💖.

This field MUST NOT appear more than once 🚫.

Example (English, Spanish and French):

Preferred-Languages: en, es, fr

2.6. Example of an Unsigned "security.txt" File 📝

# Our security address
Contact: mailto:security@example.com

# Our OpenPGP key
Encryption: https://example.com/pgp-key.txt

# Our security policy
Policy: https://example.com/security-policy.html

# Our security acknowledgments page
Acknowledgments: https://example.com/hall-of-fame.html

Expires: 2021-12-31T18:37:07z

2.7. Example of a Signed "security.txt" File ✍️💅

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

# Canonical URI
Canonical: https://example.com/.well-known/security.txt

# Our security address
Contact: mailto:security@example.com

# Our OpenPGP key
Encryption: https://example.com/pgp-key.txt

# Our security policy
Policy: https://example.com/security-policy.html

# Our security acknowledgments page
Acknowledgments: https://example.com/hall-of-fame.html

Expires: 2021-12-31T18:37:07z
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.2

[signature]
-----END PGP SIGNATURE-----

3. Location of the security.txt File 📍🦋

For web-based services, organizations MUST place the "security.txt" file under the "/.well-known/" path, e.g., https://example.com/.well-known/security.txt as per [RFC8615] of a domain name or IP address 🌸. For legacy compatibility, a "security.txt" file might be placed at the top-level path or redirect (as per Section 6.4 of [RFC7231]) to the "security.txt" file under the "/.well-known/" path 🔁. If a "security.txt" file is present in both locations, the one in the "/.well-known/" path MUST be used 👑.

The file MUST be accessed via HTTP 1.0 or a higher version, and the file access MUST use the "https" scheme (as per Section 2.7.2 of [RFC7230]) 🔐. It MUST have a Content-Type of "text/plain" with the default charset parameter set to "utf-8" (as per Section 4.1.3 of [RFC2046]) 📄✨.

Retrieval of "security.txt" files and the resources indicated within them may result in a redirect (as per Section 6.4 of [RFC7231]) ↪️. Researchers should perform additional analysis (as per Section 5.2) to make sure these redirects are not malicious or pointing to resources controlled by an attacker 🚨👀. Not giving attackers a free pass, obviously 😤.

3.1. Scope of the File 🎯

A "security.txt" file MUST only apply to the domain or IP address in the URI used to retrieve it, not to any of its subdomains or parent domains 🙅‍♀️. A "security.txt" file MAY also apply to products and services provided by the organization publishing the file 🛍️.

As per Section 1.1, this specification is intended for a vulnerability response. If implementors want to use this for an incident response, they should be aware of additional security considerations discussed in Section 5.1 ⚠️.

Organizations SHOULD use the policy directive (as per Section 2.5.7) to provide additional details regarding the scope and details of their vulnerability disclosure process 📜💖.

Some examples appear below 👇:

# The following only applies to example.com.
https://example.com/.well-known/security.txt

# This only applies to subdomain.example.com.
https://subdomain.example.com/.well-known/security.txt

# This security.txt file applies to IPv4 address of 192.0.2.0.
https://192.0.2.0/.well-known/security.txt

# This security.txt file applies to IPv6 address of 2001:db8:8:4::2.
https://[2001:db8:8:4::2]/.well-known/security.txt

4. File Format Description and ABNF Grammar 📝

okay bestie, the format rules are next and they're strict 💅 The file MUST be plain text (MIME type "text/plain") as defined in Section 4.1.3 of [RFC2046], and it MUST be encoded using UTF-8 [RFC3629] in Net-Unicode form [RFC5198] 🎀

The format MUST follow the ABNF definition below. It builds on the core ABNF rules from [RFC5234] and uses the case-sensitive string support from [RFC7405] ✨

body             =  signed / unsigned

unsigned         =  *line (contact-field eol) ; one or more required
                    *line (expires-field eol) ; exactly one required
                    *line [lang-field eol] *line ; exactly one optional
                    ; order of fields within the file is not important
                    ; except that if contact-field appears more
                    ; than once, the order of those indicates
                    ; priority (see Section 3.5.3)

; signed is the production that should match the OpenPGP clearsigned
; document
signed           =  cleartext-header
                    1*(hash-header)
                    CRLF
                    cleartext
                    signature

cleartext-header =  %s"-----BEGIN PGP SIGNED MESSAGE-----" CRLF

hash-header      =  %s"Hash: " hash-alg *("," hash-alg) CRLF

hash-alg         =  token
                      ; imported from RFC 2045; see RFC 4880 Section
                      ; 10.3.3 for a pointer to the registry of
                      ; valid values

;cleartext       =  1*( UTF8-octets [CR] LF)
                      ; dash-escaped per RFC 4880 Section 7.1

cleartext        =  *((line-dash / line-from / line-nodash) [CR] LF)

line-dash        =  ("- ") "-" *UTF8-char-not-cr
                       ; MUST include initial "- "

line-from        =  ["- "] "From " *UTF8-char-not-cr
                      ; SHOULD include initial "- "

line-nodash      =  ["- "] *UTF8-char-not-cr
                      ; MAY include initial "- "

UTF8-char-not-dash =  UTF8-1-not-dash / UTF8-2 / UTF8-3 / UTF8-4
UTF8-1-not-dash  =  %x00-2C / %x2E-7F
UTF8-char-not-cr =  UTF8-1-not-cr / UTF8-2 / UTF8-3 / UTF8-4
UTF8-1-not-cr    =  %x00-0C / %x0E-7F

; UTF8 rules from RFC 3629
UTF8-octets      =  *( UTF8-char )
UTF8-char        =  UTF8-1 / UTF8-2 / UTF8-3 / UTF8-4
UTF8-1           =  %x00-7F
UTF8-2           =  %xC2-DF UTF8-tail
UTF8-3           =  %xE0 %xA0-BF UTF8-tail / %xE1-EC 2( UTF8-tail ) /
                    %xED %x80-9F UTF8-tail / %xEE-EF 2( UTF8-tail )
UTF8-4           =  %xF0 %x90-BF 2( UTF8-tail ) /
                    %xF1-F3 3( UTF8-tail ) /
                    %xF4 %x80-8F 2( UTF8-tail )
UTF8-tail        =  %x80-BF

signature        =  armor-header
                    armor-keys
                    CRLF
                    signature-data
                    armor-tail

armor-header     =  %s"-----BEGIN PGP SIGNATURE-----" CRLF

armor-keys       =  *(token ": " *( VCHAR / WSP ) CRLF)
                      ; Armor Header Keys from RFC 4880

armor-tail       =  %s"-----END PGP SIGNATURE-----" CRLF

signature-data   =  1*(1*(ALPHA / DIGIT / "=" / "+" / "/") CRLF)
                      ; base64; see RFC 4648
                      ; includes RFC 4880 checksum

line             =  [ (field / comment) ] eol

eol              =  *WSP [CR] LF

field            =  ; optional fields
                    ack-field /
                    can-field /
                    contact-field / ; optional repeated instances
                    encryption-field /
                    hiring-field /
                    policy-field /
                    ext-field

fs               =  ":"

comment          =  "#" *(WSP / VCHAR / %x80-FFFFF)

ack-field        =  "Acknowledgments" fs SP uri

can-field        =  "Canonical" fs SP uri

contact-field    =  "Contact" fs SP uri

expires-field    =  "Expires" fs SP date-time

encryption-field =  "Encryption" fs SP uri

hiring-field     =  "Hiring" fs SP uri

lang-field       =  "Preferred-Languages" fs SP lang-values

policy-field     =  "Policy" fs SP uri

date-time        =  < imported from Section 5.6 of [RFC3339] >

lang-tag         =  < Language-Tag from Section 2.1 of [RFC5646] >

lang-values      =  lang-tag *(*WSP "," *WSP lang-tag)

uri              =  < URI as per Section 3 of [RFC3986] >

ext-field        =  field-name fs SP unstructured

field-name       =  < imported from Section 3.6.8 of [RFC5322] >

unstructured     =  < imported from Section 3.2.5 of [RFC5322] >

token            =  < imported from Section 5.1 of [RFC2045] >

ALPHA            =  %x41-5A / %x61-7A   ; A-Z / a-z

BIT              =  "0" / "1"

CHAR             =  %x01-7F
                      ; any 7-bit US-ASCII character,
                      ;  excluding NUL

CR               =  %x0D
                      ; carriage return

CRLF             =  CR LF
                      ; Internet standard newline

CTL              =  %x00-1F / %x7F
                      ; controls

DIGIT            =  %x30-39
                      ; 0-9

DQUOTE           =  %x22
                      ; " (Double Quote)

HEXDIG           =  DIGIT / "A" / "B" / "C" / "D" / "E" / "F"

HTAB             =  %x09
                      ; horizontal tab

LF               =  %x0A
                      ; linefeed

LWSP             =  *(WSP / CRLF WSP)
                      ; Use of this linear-white-space rule
                      ;  permits lines containing only white
                      ;  space that are no longer legal in
                      ;  mail headers and have caused
                      ;  interoperability problems in other
                      ;  contexts.
                      ; Do not use when defining mail
                      ;  headers and use with caution in
                      ;  other contexts.

OCTET            =  %x00-FF
                      ; 8 bits of data

SP               =  %x20

VCHAR            =  %x21-7E
                      ; visible (printing) characters

WSP              =  SP / HTAB
                      ; white space

"ext-field" refers to extension fields, which are discussed in Section 2.4 💖

5. Security Considerations 🛡️

Okay, this part is serious, but I'm still going to be extra about it 😭 Because of the use of URIs and well-known resources, the security considerations of [RFC3986] and [RFC8615] apply here too, on top of the ones listed below 🔐

5.1. Compromised Files and Incident Response

An attacker that has compromised a website is able to compromise the "security.txt" file as well, or set up a redirect to their own site 💀 That can mean security reports never reach the organization, or they get sent straight to the attacker 🙈

To protect against this, organizations should use the "Canonical" field to indicate the locations of the file (as per Section 2.5.2), digitally sign their "security.txt" files (as per Section 2.3), and regularly monitor the file and the referenced resources to detect tampering 🔥

Security researchers should validate the "security.txt" file, including verifying the digital signature and checking any available historical records, before using the information in the file 🧐 If the "security.txt" file looks suspicious or compromised, it should not be used 🚫

While it is not recommended, implementors may choose to use the information published within a "security.txt" file for an incident response. In such cases, extreme caution should be taken before trusting that information, since it may have been compromised by an attacker 😬 Researchers should use additional methods to verify such data, including out-of-band verification of the Pretty Good Privacy (PGP) signature, DNSSEC-based approaches, etc. 🌈

5.2. Redirects

When retrieving the file and any resources referenced in the file, researchers should record any redirects, since they can lead to a different domain or IP address controlled by an attacker 👀 Further inspection of such redirects is recommended before using the information contained within the file 🦋

5.3. Incorrect or Stale Information

If information and resources referenced in a "security.txt" file are incorrect or not kept up to date, this can result in security reports not being received by the organization, or being sent to incorrect contacts, thus exposing possible security issues to third parties 😭 Not having a "security.txt" file may be preferable to having stale information in this file 🥀 Organizations must use the "Expires" field (see Section 2.5.5) to indicate to researchers when the data in the file is no longer valid ⏰

Organizations should ensure that information in this file and any referenced resources, such as web pages, email addresses, and telephone numbers, are kept current, are accessible, are controlled by the organization, and are kept secure 🫶

5.4. Intentionally Malformed Files, Resources, and Reports

It is possible for compromised or malicious sites to create files that are extraordinarily large or otherwise malformed, in an attempt to discover or exploit weaknesses in the parsing code 💣 Researchers should make sure that any such code is robust against large or malformed files and fields. They may choose to have the code not parse files larger than 32 KBs, those with fields longer than 2,048 characters, or those containing more than 1,000 lines 📏 The ABNF grammar (as defined in Section 4) can also be used as a way to verify these files ✅

The same concerns apply to any other resources referenced within "security.txt" files, as well as any security reports received as a result of publishing this file. Such resources and reports may be hostile, malformed, or malicious 👾

5.5. No Implied Permission for Testing

The presence of a "security.txt" file might be interpreted by researchers as permission to do security testing against the domain or IP address where it is published, or against products and services provided by the organization publishing the file 🕵️ This might result in increased testing against an organization by researchers. On the other hand, a decision not to publish a "security.txt" file might be interpreted by the organization operating that website as a way to signal to researchers that permission to test that particular site or project is denied 🚧 This might result in pushback against researchers reporting security issues to that organization 😤

Therefore, researchers shouldn't assume that the presence or absence of a "security.txt" file grants or denies permission for security testing 🙅‍♀️ Any such permission may be indicated in the company's vulnerability disclosure policy (as per Section 2.5.7) or in a new field (as per Section 2.4) 💜

5.6. Multi-User Environments

In multi-user or multi-tenant environments, it may be possible for a user to take over the location of the "security.txt" file 👯 Organizations should reserve the "security.txt" namespace at the root, to ensure no third party can create a page with the "security.txt" AND "/.well-known/security.txt" names 🌸

5.7. Protecting Data in Transit 🔒✨

okay so the whole point here is keeping a "security.txt" file from getting messed with while it's zooming across the internet 🚗💨. implementors MUST use HTTPS (as per Section 2.7.2 of [RFC7230]) when serving the file itself and when fetching any web URIs referenced in it (except when this specification says otherwise 🙈). during the TLS handshake, researchers should validate the X.509 certificate in accordance with [RFC6125], and keep these extra considerations in mind:

  • Matching is performed only against the DNS-ID identifiers.
  • DNS domain names in server certificates MAY contain the wildcard character '*' as the complete leftmost label within the identifier.

the certificate may also be checked for revocation via the Online Certificate Status Protocol (OCSP) [RFC6960], certificate revocation lists (CRLs), or similar mechanisms. revocation checks are giving main character energy 💅

in cases where the "security.txt" file can't be served via HTTPS (like localhost) or is being served with an invalid certificate, additional human validation is recommended, since the contents may have been modified in transit. ngl, this is where a real person has to double-check things 🫶

as an extra layer of protection, it's also recommended that organizations digitally sign their "security.txt" file with OpenPGP (as per Section 2.3). also, to protect security reports from being tampered with or observed in transit, organizations should specify encryption keys (as per Section 2.5.4) unless HTTPS is being used for report submission. 🔐

however, determining whether those keys are valid is out of scope for this specification. security researchers need to establish other secure means to verify them. so yeah, that's a whole separate quest 🗺️

5.8. Spam and Spurious Reports 📬🙈

similar to concerns in [RFC2142], denial-of-service attacks via spam reports would get easier once a "security.txt" file is published by an organization. on top of that, there's a higher chance that reports get sent automatically or from automated scans with no human looking at them first 🤖. attackers can also use this file to spam unrelated third parties by listing their resources and/or contact information. not the vibe 💀

organizations need to weigh the advantages of publishing this file against the possible disadvantages and the extra resources needed to analyze security reports. it's a real tradeoff, bestie ⚖️

security researchers should review all of the information in the "security.txt" file before submitting reports in an automated fashion or reports that result from automated scans. 🧐

6. IANA Considerations 🏛️

implementors should be aware that any resources referenced within a "security.txt" file MUST NOT point to the Well-Known URIs namespace unless they are registered with IANA (as per [RFC8615]). don't go poking the Well-Known namespace without registering first, okay? 🙅‍♀️

6.1. Well-Known URIs Registry

IANA has updated the "Well-Known URIs" registry with the following additional values (using the template from [RFC8615]):

URI suffix:  security.txt
Change controller:  IETF
Specification document(s):  RFC 9116
Status:  permanent

6.2. Registry for security.txt Fields 🗂️

IANA has created the "security.txt Fields" registry in accordance with [RFC8126]. this registry contains the fields for use in "security.txt" files that are defined by this specification. ✨

new registrations or updates MUST be published in accordance with the "Expert Review" guidelines described in Sections 4.5 and 5 of [RFC8126]. any new field registered this way is considered optional by this specification unless a new version of this specification is published. so optional by default, but it can level up 🎮

designated experts should determine whether a proposed registration or update provides value to organizations and researchers using this format, and whether it makes sense in the context of industry-accepted vulnerability disclosure processes such as [ISO.29147.2018] and [CERT.CVD]. 🕵️‍♀️

new registrations and updates MUST contain the following information:

  1. Name of the field being registered or updated
  2. Short description of the field
  3. Whether the field can appear more than once
  4. New or updated status, which MUST be one of the following:
    • current: The field is in current use.
    • deprecated: The field has been in use, but new usage is discouraged.
    • historic: The field is no longer in current use.
  5. Change controller
  6. The document in which the specification of the field is published (if available)

existing registrations may be marked historic or deprecated, as appropriate, by a future update to this document. retirement arc, but make it iconic 🌅

the initial registry contains these values:

Field Name:  Acknowledgments
Description:  link to page where security researchers are recognized
Multiple Appearances:  yes
Status:  current
Change controller:  IETF
Reference:  RFC 9116

Field Name:  Canonical
Description:  canonical URI for this file
Multiple Appearances:  yes
Status:  current
Change controller:  IETF
Reference:  RFC 9116

Field Name:  Contact
Description:  contact information to use for reporting
   vulnerabilities
Multiple Appearances:  yes
Status:  current
Change controller:  IETF
Reference:  RFC 9116

Field Name:  Expires
Description:  date and time after which this file is considered stale
Multiple Appearances:  no
Status:  current
Change controller:  IETF
Reference:  RFC 9116

Field Name:  Encryption
Description:  link to a key to be used for encrypted communication
Multiple Appearances:  yes
Status:  current
Change controller:  IETF
Reference:  RFC 9116

Field Name:  Hiring
Description:  link to the vendor's security-related job positions
Multiple Appearances:  yes
Status:  current
Change controller:  IETF
Reference:  RFC 9116

Field Name:  Policy
Description:  link to security policy page
Multiple Appearances:  yes
Status:  current
Change controller:  IETF
Reference:  RFC 9116

Field Name:  Preferred-Languages
Description:  list of preferred languages for security reports
Multiple Appearances:  no
Status:  current
Change controller:  IETF
Reference:  RFC 9116

7. References 📚

7.1. Normative References

[RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
           Extensions (MIME) Part Two: Media Types", RFC 2046,
           DOI 10.17487/RFC2046, November 1996,
           <https://www.rfc-editor.org/info/rfc2046>.

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC2142]  Crocker, D., "Mailbox Names for Common Services, Roles and
           Functions", RFC 2142, DOI 10.17487/RFC2142, May 1997,
           <https://www.rfc-editor.org/info/rfc2142>.

[RFC2277]  Alvestrand, H., "IETF Policy on Character Sets and
           Languages", BCP 18, RFC 2277, DOI 10.17487/RFC2277,
           January 1998, <https://www.rfc-editor.org/info/rfc2277>.

[RFC3339]  Klyne, G. and C. Newman, "Date and Time on the Internet:
           Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
           <https://www.rfc-editor.org/info/rfc3339>.

[RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
           10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
           2003, <https://www.rfc-editor.org/info/rfc3629>.

[RFC3966]  Schulzrinne, H., "The tel URI for Telephone Numbers",
           RFC 3966, DOI 10.17487/RFC3966, December 2004,
           <https://www.rfc-editor.org/info/rfc3966>.

[RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
           Resource Identifier (URI): Generic Syntax", STD 66,
           RFC 3986, DOI 10.17487/RFC3986, January 2005,
           <https://www.rfc-editor.org/info/rfc3986>.

[RFC4880]  Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
           Thayer, "OpenPGP Message Format", RFC 4880,
           DOI 10.17487/RFC4880, November 2007,
           <https://www.rfc-editor.org/info/rfc4880>.

[RFC5198]  Klensin, J. and M. Padlipsky, "Unicode Format for Network
           Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008,
           <https://www.rfc-editor.org/info/rfc5198>.

[RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
           Specifications: ABNF", STD 68, RFC 5234,
           DOI 10.17487/RFC5234, January 2008,
           <https://www.rfc-editor.org/info/rfc5234>.

[RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
           DOI 10.17487/RFC5322, October 2008,
           <https://www.rfc-editor.org/info/rfc5322>.

[RFC5646]  Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
           Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
           September 2009, <https://www.rfc-editor.org/info/rfc5646>.

[RFC6068]  Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto'
           URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010,
           <https://www.rfc-editor.org/info/rfc6068>.

[RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
           Verification of Domain-Based Application Service Identity
           within Internet Public Key Infrastructure Using X.509
           (PKIX) Certificates in the Context of Transport Layer
           Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
           2011, <https://www.rfc-editor.org/info/rfc6125>.

[RFC6960]  Santesson, S., Myers, M., Ankney, R., Malpani, A.,
           Galperin, S., and C. Adams, "X.509 Internet Public Key
           Infrastructure Online Certificate Status Protocol - OCSP",
           RFC 6960, DOI 10.17487/RFC6960, June 2013,
           <https://www.rfc-editor.org/info/rfc6960>.

[RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
           Protocol (HTTP/1.1): Message Syntax and Routing",
           RFC 7230, DOI 10.17487/RFC7230, June 2014,
           <https://www.rfc-editor.org/info/rfc7230>.

[RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
           Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
           DOI 10.17487/RFC7231, June 2014,
           <https://www.rfc-editor.org/info/rfc7231>.

[RFC7405]  Kyzivat, P., "Case-Sensitive String Support in ABNF",
           RFC 7405, DOI 10.17487/RFC7405, December 2014,
           <https://www.rfc-editor.org/info/rfc7405>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8615]  Nottingham, M., "Well-Known Uniform Resource Identifiers
           (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
           <https://www.rfc-editor.org/info/rfc8615>.

7.2. Informative References 📚✨

These are the extra reads that the spec points to, bestie. Here's the whole reading list 💅

Acknowledgments 🫶💖

The authors wanted to give a huge shoutout to everyone who helped build this doc: Tom Hudson, Jobert Abma, Gerben Janssen van Doorn, Austin Heap, Stephane Bortzmeyer, Max Smith, Eduardo Vela, and Krzysztof Kotowicz. You're all absolute legends 👑

They also thanked the people on the IETF's LAST CALL, SAAG, and SECDISPATCH lists who gave feedback. Community feedback is everything 🌈

And Yakov Shafranovich wanted to add a special thank you to L.T.S. for everything 🥹💜

Authors' Addresses 💌

Edwin Foudil Email: contact@edoverflow.com

Yakov Shafranovich Nightwatch Cybersecurity Email: yakov+ietf@nightwatchcybersecurity.com

📦 where this page comes from