Separate signing, encryption and permission
06Three different questions remain: who vouches for this file, how to protect a report in transit, and what testing the organization allows. A security.txt file does not answer all three just by existing.
The existence of this file leads to contact and policy information. Without the required authorization, the illustrated security-testing path stops at a permission decision.
Source for this drawing: RFC 9116 · Read RFC section 2.3 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
- Cleartext signature
- An OpenPGP signature accompanying readable content; it does not encrypt that content.
- Encryption key URI
- A location for obtaining a report-encryption key, which may differ from the signing key.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Signing the file with an OpenPGP cleartext signature is RECOMMENDED. When signing, using Canonical is also RECOMMENDED. The researcher is responsible for deciding whether the signing key is trusted.
- Signing the file with an OpenPGP cleartext signature is RECOMMENDED. When signing, using Canonical is also RECOMMENDED. The researcher is responsible for deciding whether the signing key is trusted.
- A signature can authenticate signed content only with an appropriately trusted verification key. A compromised site can also alter security.txt or redirect it; suspicious files should not be used, and historical or out-of-band checks can help.
- Encryption MUST contain a URI pointing to a retrievable key, not the key itself. If it is a web URI it MUST use HTTPS. The encryption key must be checked for trust; do not assume it is the same key that signed the file.
- Serving the file and retrieving referenced web URIs MUST use HTTPS except where the specification notes otherwise. Invalid-certificate or non-HTTPS exceptional cases call for additional human validation, not automatic trust. Encryption keys are recommended for protecting reports unless HTTPS submission is used.
- The presence or absence of security.txt does not grant or deny testing permission. Consult an applicable disclosure policy or other explicit authorization. Publishing the file does not promise a reward, safe harbor or a response.
- Files, linked resources and received reports may be malicious. Parsers should handle malformed or huge input safely; section 5.4 gives optional defensive bounds, not universal format limits. Organizations should reserve both security.txt locations against tenant takeover and weigh spam/report handling costs.
The signature scene is schematic, not a valid signed fixture or a claim of actual key verification. The Encryption URI points to a fictional public-key resource; no real key is imported. No report is submitted and no security testing is performed. Discovery, authentication, confidentiality and permission remain distinct decisions.
Read the RFC section ↗