GLEP 79：Gentoo OpenPGP 授权密钥

目的和用途

授权密钥的目的是根据 Gentoo LDAP 目录中内部提供的信息，对 Gentoo 开发人员的 OpenPGP 密钥提供自动颁发的签名。该服务提供给所有活跃的 Gentoo 开发人员，从他们被招募的那一刻起。

每当创建、重新激活、重命名开发者帐户或添加新的密钥指纹时，都会在相应的@gentoo.orgUID 上自动创建签名并推送到密钥服务器。每当旧签名即将过期时，都会自动创建新的签名。每当禁用、重命名开发者帐户或删除指纹时，都会自动撤销来自已过时 UID 的签名。

签名仅针对与 Gentoo 开发人员@gentoo.org邮箱地址匹配的 UID 以及其主密钥指纹在 Gentoo LDAPgpgfingerprint记录中列出的密钥颁发。缺少此类 UID 的密钥将被忽略。相关用户标识符上的名称未经验证。签名在颁发后 1 年内有效。

L1 和 L2 密钥

授权密钥分为两层，分别称为 L1 和 L2。

单个 L1 授权密钥仅用于（手动）认证 L2 密钥，并根据基础设施保护主密钥的策略安全地离线保存。此密钥的指纹发布在 Gentoo 网站上，并要求用户签署此密钥以通过授权密钥启用密钥有效性。

L2 授权密钥直接用于签署开发者密钥。由于它们用于自动化服务，因此容易受到攻击。它们由 L1 密钥信任签名，并且可以比 L1 密钥更频繁地撤销和轮换。

这种双层模型旨在将改进的安全性和用户便利性结合起来。虽然单个 Gentoo 密钥由 L2 密钥签名，但用户仅签署 L1 密钥，并且有效性通过链 L1 → L2 → 开发者密钥建立。如果 L2 密钥遭到破坏，这使得更换 L2 密钥成为可能，而无需用户重新建立信任。由于替换密钥也将由 L1 密钥签名（前提是它没有被破坏），因此开发者密钥的有效性将保持不变。

验证 L1 密钥

建立 L1 授权密钥的真实性对于该系统至关重要。最初，用户可以通过将密钥指纹与网站上发布的指纹进行比较来确定真实性。这将把真实性验证转移到 HTTPS（PKI/DNSSEC）。

但是，同时鼓励用户在验证密钥后签署密钥。这将有效地使其能够通过 OpenPGP 信任网建立密钥的有效性。

授权密钥模型与信任网

常规信任网模型依赖于个人验证 Gentoo 开发人员的身份和对特定@gentoo.org电子邮件地址的访问。如果足够多的人信任用户，并且已确认开发人员的身份，则认为特定 UID 是有效的。这特别依赖于能够在开发人员和用户之间建立信任链。

目前，许多现有的 Gentoo 开发人员甚至都没有在彼此之间建立信任链，更不用说能够让用户联系到任何特定开发者的信任网覆盖范围了。改进这方面的努力遭到开发人员的拒绝，主要基于这样的论点，即许多开发人员认为不可能为了身份验证的目的而与任何其他社区成员见面。

另一方面，授权密钥模型假设存在一个验证 Gentoo 开发人员密钥的单一可信权威。用户验证代表此权威的密钥并信任它。所有开发人员使用的密钥的有效性通过单个信任点建立。

建立特定密钥有效性的过程不需要与任何人见面或验证身份。虽然有效性以与信任网兼容的方式公开，但它是针对 LDAP 进行验证的，这隐含地证明了密钥的真实性。

因此，授权密钥模型更容易设置。用户只需验证一个密钥并信任它，而纯 WoT 可能需要信任多个第三方身份。它也更安全，因为它将攻击面限制到单个密钥，而不是用户需要信任的潜在大量密钥之一。如果用户决定停止信任@gentoo.orgUID，则可以通过禁用单个授权密钥轻松地撤销有效性。

授权密钥与 gentoo-keys

gentoo-keys 项目提供了足以验证密钥真实性的种子数据。但是，此数据使用完全自定义的格式，因此需要特殊的工具进行处理。此工具未打包到任何其他 Linux 发行版或操作系统中，并且对于非特权用户来说安装起来并不简单。

授权密钥模型完全基于内置的 GnuPG 功能。它不需要任何特殊的工具来运行。必要的引导可以通过 GnuPG 命令行工具手动完成。最终，如果授权密钥通过信任网覆盖，即使这样也可能变得不必要。

此外，gentoo-keys 种子数据目前需要手动更新。权限密钥系统是自动化的，因此操作延迟较小。

开发者覆盖范围

在最初的提案中，曾讨论过是否应该对新开发者实施宽限期，在此期间他们的密钥不会被签名。但是，没有提出任何论点来支持这样的期限，因此 GLEP 假设所有开发者只要被视为活跃的 Gentoo 开发者，都包含在内。

由于只有@gentoo.org电子邮件地址受 Gentoo 控制，并且发行版外部的开发者身份不在本项目的范围内，因此仅对与相应开发者地址匹配的 UID 进行签名。这样是为了防止开发者伪造他人的身份。

开发者的真实姓名未经验证。首先，本项目的目的是建立密钥与特定 Gentoo 开发者之间的关联，其主要标识符是在 Gentoo 中使用的昵称。在这种情况下，确切的真实姓名与有效性无关。其次，在 LDAP 和用户标识符之间比较真实姓名将非常复杂，并且很可能导致许多开发者由于例如修改后的姓名拼写而被静默拒绝。

caff 验证模型

在最初的讨论中，有人建议使用类似于 Debian 的 caff 工具的模型。在这个模型中，新的签名会加密发送给开发者，而不是直接上传到密钥服务器。开发者需要解密并将它们添加到自己的密钥中。 [6]

caff 模型的主要目的是帮助用户验证他们即将签名的 UID 的电子邮件地址。通过发送加密电子邮件，此模型验证接收者是否能够接收特定地址的邮件以及解密使用指定密钥加密的消息。由于消息包含可导入的完整签名，因此密钥签名过程可以完全由接收者完成，发送者无需在发送后担心。

但是，似乎没有充分的理由在此处使用此模型。可以合理地假设，如果一个人能够以特定 Gentoo 开发者的身份访问 LDAP 目录，那么他也能访问该开发者的邮箱。考虑到这一点，以 caff 方式验证电子邮件地址是多余的。

此外，实现此模型会增加服务器端和客户端两端的复杂性。服务器需要完全有状态以避免发送重复邮件，同时还需要允许重新请求签名邮件。开发者需要手动导入签名并将其发送到密钥服务器。

一些不太活跃的开发者很可能因不知情或不感兴趣而无法参与新系统而被永久排除在外。此外，签名的过期会导致密钥无效的潜在较长时间段（在签名过期和新签名导入之间）。在此期间，用户安全地向开发者发送邮件的能力将受到阻碍。

双层模型

建立双层权限密钥模型是为了将安全性与所需的自动化结合起来。L1 密钥提供更高的安全级别，但需要手动操作。L2 密钥适合自动化使用，但这意味着它们容易受到攻击。

如果模型基于单个密钥并且该密钥被泄露，则必须吊销该密钥并替换为新密钥。所有用户都必须获取新密钥并独立验证它以恢复开发者密钥的有效性。

使用两个密钥在信任链中引入了中间链接，该链接可以轻松替换。用户信任 L1 密钥，该密钥不太可能被泄露。对 L2 密钥的信任由 L1 密钥隐式提供，用户无需特别担心它。如果 L2 密钥被泄露，基础设施开发人员可以替换它并通过（未泄露的）L1 密钥恢复信任。用户只需获取新密钥，有效性即可恢复。

安全注意事项

用户需要能够验证 L1 密钥的真实性。这可以通过两种方式之一完成

1. 通过将指纹与 Gentoo 网站上的记录进行比较。这依赖于 Gentoo Web 服务器和网站内容存储库的安全性。从用户方面来说，真实性依赖于 PKI 和/或 DNSSEC，以及任何其他未来的 HTTPS 保护机制。
2. 通过信任网，前提是用户信任首先验证密钥的人。在这种情况下，真实性完全依赖于信任网模型，并且容易受到针对它的攻击（例如错误地信任恶意人员）。

L1 密钥本身通过当前的基础设施最佳实践受到保护，免受泄露。目前，这涉及密码保护和离线存储。如果密钥泄露，程序包括吊销密钥并宣布问题。

L2 密钥根据设计缺乏这种保护。如果它们被泄露，则程序涉及快速吊销密钥并用新密钥替换它。

在这两种情况下，吊销程序都依赖于用户定期从可靠来源刷新密钥。通常，这涉及通过 HKPS 使用 SKS 密钥服务器，而 HKPS 又依赖于 PKI 来防止第三方拦截吊销的传播。

开发者密钥 UID 的有效性通过 L2 密钥生成的签名来建立。如果 UID 变得不再有效，则吊销签名以使它们无效。这也依赖于用户定期从密钥服务器获取开发者密钥更新。

此外，签名使用一年的到期时间生成。在极不可能的情况下，如果脚本未能吊销特定签名，它将自动过期。