security.txt的选项之一是包含对 PGP 密钥的引用，以便在以私密、安全的方式报告漏洞时使用。对我来说，研究人员使用 PGP 加密消息以报告漏洞对我来说非常有意义。
但是另一端的业务呢？他们应该如何安全地为此类报告实施 PGP 密钥？
一种选择是简单地使用一个人的个人（或者更有可能是专门为此目的创建的一次性）密钥，但随后存在该人死亡（不可用）或变成流氓的风险（DOS/MitM 报告）。
另一种选择是为此目的生成一个密钥对并在一组受信任的个人之间共享。这解决了“死亡”问题和 DOS 问题，但它扩大了一个人收到报告并对其进行恶意操作的风险。
共享密钥还意味着任何私钥持有者都可以“作为”该身份发布消息。这可能可以通过在铸造时明确说明密钥用于“仅收据”来解决。
有没有标准和/或安全的方法来做这样的事情？
我建议的一种方法是在安全团队成员之间共享 Encryption 子密钥，而不是 Certify（“主”）或 Sign 子密钥。这样，团队的每个成员都可以解密发送到 security.txt 中列出的电子邮件地址的消息，但不能发回签名的电子邮件。Certify 和 Sign 子密钥可以保存在保险库系统中，可用于以下目的：
保险库系统可以在某种 HSM 上拥有那些无法物理删除的子项；同样，系统本身或保存它的房间必须需要多人在场才能运行。
好问题。
与往常一样，这取决于您的特定威胁模型。
您提出了许多有趣的问题（例如内幕、流氓、死亡等......）
对于大多数使用 security.txt 的人来说，问题主要停留在“我如何让研究人员与我的公司进行安全通信”，并且假设企业已经解决了这些访问私钥的问题，但是对于他们特定的风险承受能力是有意义的.
如果只有一个人负责响应安全报告，那么他们为此目的生成的密钥就可以了，并且企业接受您为单个用户概述的各种风险。如果它是一个团队，那么根据定义，团队都可以访问，而您将面临另一类风险。
一种尺寸不会适合所有人。如果我在设计某些东西，并要求考虑您概述的所有威胁，我会选择以下内容：
存储在 AWS Secrets Manager 中的 PGP 对的私有密钥
https://aws.amazon.com/secrets-manager/
以及通过密钥管理服务通过角色和策略管理的访问权限
这使企业负责定义适合其风险状况以及他们关心的威胁的角色和策略以及访问控制。
没有一个人，甚至是一群人控制“私钥”，但是可以通过根据组织规则添加和删除权限来集中授予和撤销使用它的权限。
这还将为您提供组中的哪个成员使用密钥响应特定请求的审计跟踪。