1.1. 动机、先前 工作和范围

许多安全研究人员会遇到这样的情况：他们无法 向组织报告安全漏洞，因为没有可用于联系特定 资源所有者的报告渠道，也没有关于此类所有者 漏洞披露实践的信息。¶

按照 第 4 节 of [RFC2142]， 现有约定是使用 <SECURITY@domain> 电子邮件地址进行 安全问题相关通信。该约定每个域仅提供一个 基于电子邮件的单一通信渠道，并且没有提供 一种让域所有者发布其安全披露实践信息的方式。¶

此外，第 2 节 of [RFC3013] 为互联网服务提供商 （ISP）规定了联系约定，第 3.2 节 of [RFC2350] 为计算机安全事件 响应团队（CSIRT）规定了联系约定， 第 5.2 节 of [RFC2196] 为站点运营者 规定了联系约定。按照 [RFC7485]，区域互联网注册机构 （RIR）和域名注册机构还为 IP 地址、 自治系统号（ASN）和域名的所有者提供联系信息。然而， 这些都没有解决安全研究人员如何定位组织的联系信息 和漏洞披露实践，以便报告漏洞的问题。¶

在本文档中，我们定义了一种更丰富、机器可解析且更具可扩展性 的方式，让组织可以传达关于其安全披露 实践以及联系途径的信息。漏洞披露的其他细节 不在本文档范围内。鼓励读者查阅其他 文档，例如 [ISO.29147.2018] 或 [CERT.CVD]。¶

按照 [CERT.CVD]， “漏洞响应”指产品漏洞报告， 它与网络入侵和网站被攻陷的报告 （“事件响应”）相关但不同。本文档定义的机制旨在 用于前者（“漏洞响应”）。如果实现者希望 将此机制用于事件响应，则应注意 第 5.1 节 中讨论的其他安全考虑。¶

“security.txt” 文件旨在作为组织维护的其他关于 其安全披露实践的公共资源的补充，而不是其替代品 或取代品。¶

1.2. 术语

本文档中的关键词 “MUST”、“MUST NOT”、“REQUIRED”、“SHALL”、 “SHALL NOT”、 “SHOULD”、“SHOULD NOT”、“RECOMMENDED”、“NOT RECOMMENDED”、“MAY” 和 “OPTIONAL”，当且仅当它们像这里所示以全大写形式出现时， 应按照 BCP 14 [RFC2119] [RFC8174] 中所述进行解释。¶

术语 “researcher” 对应于 [ISO.29147.2018] 和 [CERT.CVD] 中的术语 “finder” 和 “reporter”。 术语 “organization” 对应于 [ISO.29147.2018] 和 [CERT.CVD] 中的术语 “vendor”。¶

术语 “implementors” 包括参与 漏洞披露过程的所有各方。¶

2.1. 注释

任何以 “#”（%x23）符号开头的行必须 被解释为注释。注释内容可以包含 %x21-7E 和 %x80-FFFFF 范围内的任何 ASCII 或 Unicode 字符，以及制表符（%x09） 和空格（%x20）字符。¶

示例：¶

# This is a comment.

2.2. 行分隔符

每一行必须以回车和换行 字符（CRLF / %x0D %x0A）结束，或仅以换行字符（LF / %x0A）结束。¶

2.3. 数字签名

建议 使用 第 7 节 of [RFC4880] 中描述的 OpenPGP 明文签名 对 “security.txt” 文件进行数字签名。使用数字签名时，还 建议组织使用 “Canonical” 字段（按照 第 2.5.2 节）， 从而允许数字签名认证该文件的位置。¶

在验证用于生成签名的密钥时， 安全研究人员始终有责任确保所使用的密钥 确实是其信任的密钥。¶

2.4. 可扩展性

与许多其他格式和协议一样，此格式可能需要随着时间推移 发生变化，以适应不断变化的互联网环境。因此， 可扩展性通过 第 6.2 节 中定义的字段 IANA 注册表提供。 通过该过程注册的任何字段必须 视为可选。为了鼓励可扩展性和互操作性， 研究人员必须忽略他们未明确支持的任何字段。¶

一般而言，实现者应“在自己所做的事情上保守， 在接受他人的内容时宽容”（按照 [RFC0793]）。¶

2.5. 字段定义

除非另有说明，所有字段必须 视为可选。¶

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

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

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

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

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

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

Encryption: openpgp4fpr:5f2de5521c63a801ab59ccb603d49de44b29100f

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

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

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

Preferred-Languages: en, es, fr

2.6. 未签名 “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

2.7. 已签名 “security.txt” 文件示例

-----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.1. 文件的范围

“security.txt” 文件必须仅适用于用于检索它的 URI 中的域 或 IP 地址，而不适用于其任何子域或父域。 “security.txt” 文件也可以适用于发布该文件的组织 提供的产品和服务。¶

按照 第 1.1 节，本规范 旨在用于漏洞响应。 如果实现者希望将其用于事件响应，则应注意 第 5.1 节 中讨论的其他 安全考虑。¶

组织应该使用 policy 指令（按照 第 2.5.7 节） 来提供关于其漏洞披露流程范围和细节的附加信息。¶

下面给出一些示例：¶

# 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

5.1. 被攻陷的文件和 事件响应

攻陷网站的攻击者也能够攻陷 “security.txt” 文件，或设置到其自己站点的重定向。 这可能导致安全报告无法被组织接收， 或被发送给攻击者。¶

为了防止这种情况，组织应使用 “Canonical” 字段来指示 文件的位置（按照 第 2.5.2 节），对其 “security.txt” 文件进行数字签名（按照 第 2.3 节），并定期监控该文件 和所引用的资源，以检测篡改。¶

安全研究人员在使用文件中包含的信息之前，应验证 “security.txt” 文件，包括验证 数字签名并检查任何可用的历史记录。如果 “security.txt” 文件看起来可疑或已被攻陷， 则不应使用它。¶

虽然不建议这样做，但实现者可以选择使用 “security.txt” 文件中发布的信息进行事件响应。在这种情况下， 在信任此类信息之前应极其谨慎，因为 它可能已被攻击者攻陷。研究人员应使用其他方法 来验证此类数据，包括带外验证 Pretty Good Privacy（PGP） 签名、基于 DNSSEC 的方法等。¶

5.2. 重定向

检索文件以及文件中引用的任何资源时，研究人员 应记录任何重定向，因为它们可能通向攻击者控制的 不同域或 IP 地址。 在使用文件中包含的信息之前，建议进一步 检查此类重定向。¶

5.3. 不正确或过时的 信息

如果 “security.txt” 文件中引用的信息和资源不正确 或未保持最新，这可能导致安全报告无法被 组织接收，或被发送给错误的联系人，从而可能 将安全问题暴露给第三方。没有 “security.txt” 文件可能 比在此文件中包含过时信息更好。组织必须使用 “Expires” 字段（见 第 2.5.5 节）向研究人员指明 文件中的数据何时不再有效。¶

组织应确保此文件中的信息以及任何引用的 资源（例如网页、电子邮件地址和电话号码） 保持最新、可访问、由组织控制， 并保持安全。¶

5.4. 故意格式错误的 文件、资源和报告

被攻陷或恶意站点可能会创建异常 大或其他格式错误的文件，试图发现或利用 解析代码中的弱点。 研究人员应确保任何此类代码 能够稳健地处理大型或格式错误的文件和字段，并且他们可以选择不 解析大于 32 KB、字段长于 2,048 个字符或 包含超过 1,000 行的文件。ABNF 语法（如 第 4 节 中定义）也可作为验证这些文件的方式。¶

同样的担忧也适用于 “security.txt” 文件中引用的任何其他资源， 以及发布此文件后收到的任何安全报告。 此类资源和报告可能是敌意的、格式错误的或恶意的。¶

5.5. 不暗示授予 测试许可

“security.txt” 文件的存在可能会被研究人员 解释为授予他们针对发布该文件的域或 IP 地址 或针对发布该文件的组织提供的产品和服务 进行安全测试的许可。 这可能导致研究人员对组织进行更多测试。另一方面， 不发布 “security.txt” 文件的决定可能会被 运营该网站的组织解释为向研究人员发出信号： 拒绝对该特定站点或项目进行测试的许可。这可能导致 研究人员向该组织报告安全问题时受到阻力。¶

因此，研究人员不应假定 “security.txt” 文件的存在或缺失授予或拒绝安全测试许可。 任何此类许可可以在公司的漏洞披露政策中说明 （按照 第 2.5.7 节），也可以在新字段中说明（按照 第 2.4 节）。¶

5.6. 多用户 环境

在多用户/多租户环境中，用户可能能够 接管 “security.txt” 文件的位置。组织应在根处保留 “security.txt” 命名空间，以确保没有第三方可以创建带有 “security.txt” 和 “/.well-known/security.txt” 名称的页面。¶

5.7. 保护传输中的 数据

为了防止 “security.txt” 文件在传输过程中被篡改， 实现者在提供文件本身以及检索其中 引用的任何 Web URI 时必须使用 HTTPS（按照 第 2.7.2 节 of [RFC7230]）（除非本规范另有说明）。作为 TLS 握手的一部分，研究人员应按照 [RFC6125] 和以下考虑事项验证所提供的 X.509 证书：¶

• 匹配仅针对 DNS-ID 标识符执行。¶
• 服务器证书中的 DNS 域名可以包含通配符 字符 “*”，作为标识符中完整的最左侧标签。¶

还可以通过在线证书状态协议（OCSP） [RFC6960]、证书吊销列表（CRL）或类似机制 检查证书吊销状态。¶

在 “security.txt” 文件无法通过 HTTPS 提供（例如 localhost）或使用无效证书提供的情况下，建议进行额外的人工验证，因为 内容可能在传输过程中已被修改。¶

作为额外保护层，还建议 组织使用 OpenPGP 对其 “security.txt” 文件进行数字签名（按照 第 2.3 节）。 此外，为了保护安全报告在传输过程中不被篡改或观察， 组织应指定加密密钥（按照 第 2.5.4 节），除非 使用 HTTPS 提交报告。¶

然而，此类密钥有效性的确定不在 本规范范围内。安全研究人员需要建立其他安全方式来 验证它们。¶

5.8. 垃圾信息和虚假 报告

与 [RFC2142] 中的担忧类似，一旦 组织发布 “security.txt” 文件，通过垃圾报告进行 拒绝服务攻击会变得更容易。此外， 由于自动化扫描且没有人工分析，报告 以自动化方式发送的可能性也会增加。 攻击者还可以通过列出无关第三方的资源和/或联系信息， 利用此文件向这些第三方发送垃圾信息。¶

组织需要权衡发布此文件的优势， 与分析安全报告所需的可能缺点和增加的资源之间的关系。¶

安全研究人员在以自动化方式提交报告或提交自动化扫描产生的报告之前， 应审查 “security.txt” 文件中的所有信息。¶

6.1. Well-Known URIs 注册表

IANA 已使用以下附加值更新 “Well-Known URIs” 注册表 （使用 [RFC8615] 中的模板）：¶

URI 后缀：

security.txt¶

变更控制者：

IETF¶

规范文档：

RFC 9116¶

状态：

永久¶

6.2. security.txt 字段注册表

IANA 已根据 [RFC8126] 创建 “security.txt Fields” 注册表。该注册表包含 用于 “security.txt” 文件的字段，这些字段由本规范定义。¶

新的注册或更新必须按照 [RFC8126] 的第 4.5 节和 5 节中所述的 “Expert Review” 指南发布。如此注册的任何新字段 均被本规范视为可选，除非发布本规范的新版本。¶

指定专家应确定拟议的注册或更新 是否为使用此格式的组织和研究人员提供价值，并且在行业接受的漏洞披露流程 （例如 [ISO.29147.2018] 和 [CERT.CVD]）的背景下是否合理。¶

新的注册和更新必须包含 以下信息：¶

1. 正在注册或更新的字段名称¶
2. 字段的简短描述¶
3. 该字段是否可以出现多于一次¶

4. 新的或更新后的状态，该状态必须是 下列之一：¶

   current：

   该字段正在当前使用。¶

   deprecated：

   该字段曾经使用过，但不鼓励新的使用。¶

   historic：

   该字段不再 当前使用。¶

5. 变更控制者¶
6. 发布该字段规范的文档（如果 可用）¶

现有注册可由本文档未来的更新按适当情况 标记为 historic 或 deprecated。¶

初始注册表包含以下值：¶

字段名称：

Acknowledgments¶

描述：

指向表彰安全研究人员页面的链接¶

多次出现：

是¶

状态：

current¶

变更控制者：

IETF¶

参考：

RFC 9116¶

字段名称：

Canonical¶

描述：

此文件的规范 URI¶

多次出现：

是¶

状态：

current¶

变更控制者：

IETF¶

参考：

RFC 9116¶

字段名称：

Contact¶

描述：

用于报告漏洞的联系信息¶

多次出现：

是¶

状态：

current¶

变更控制者：

IETF¶

参考：

RFC 9116¶

字段名称：

Expires¶

描述：

此文件被视为过时的日期和时间¶

多次出现：

否¶

状态：

current¶

变更控制者：

IETF¶

参考：

RFC 9116¶

字段名称：

Encryption¶

描述：

指向用于加密通信的密钥的链接¶

多次出现：

是¶

状态：

current¶

变更控制者：

IETF¶

参考：

RFC 9116¶

字段名称：

Hiring¶

描述：

指向供应商安全相关职位的链接¶

多次出现：

是¶

状态：

current¶

变更控制者：

IETF¶

参考：

RFC 9116¶

字段名称：

Policy¶

描述：

指向安全政策页面的链接¶

多次出现：

是¶

状态：

current¶

变更控制者：

IETF¶

参考：

RFC 9116¶

字段名称：

Preferred-Languages¶

描述：

安全报告的偏好语言列表¶

多次出现：

否¶

状态：

current¶

变更控制者：

IETF¶

参考：

RFC 9116¶