获取 Gentoo！

GLEP 80: 通过 OpenPGP WoT 进行身份验证

作者 Michał Górny <mgorny@gentoo.org>
类型 标准跟踪
状态 延期
版本 1
创建 2019-03-04
最后修改 2021-05-31
发布历史 2019-03-04
GLEP 源代码 glep-0080.rst

状态

由于缺乏活动，GLEP 编辑 Ulrich Müller 于 2021 年 5 月 31 日将该 GLEP 标记为延期。

摘要

此 GLEP 提出建立一种非强制性的分布式身份验证程序，该程序与 OpenPGP 信任网兼容。它可以在需要明确验证真实姓名的情况下使用，通过单独的策略对具有高级权限的开发人员组强制执行，或者作为构建信任网的指南。提出了三种验证身份的方法：面对面、通过摄像头或通过政府控制的身份服务。

动机

GLEP 76（版权策略）规定提交给 Gentoo 代码库的所有提交都必须包含带有个人真实姓名的签署信息。但是，它没有指定任何特定的验证方法。一项既定政策是，贡献者承认所提供姓名的合法性就足够了。[1]

同时，如果开发人员对提供的姓名真实性有合理的疑虑，则会要求他们不要接受贡献。特别是，如果开发人员碰巧认识贡献者本人，贡献者表示正在使用化名或根据政策随意更改了姓名，则这种情况可能会发生。在这种情况下，我们缺乏允许贡献者重新获得信任的明确政策。

此外，对身份验证实施更高的标准可能对具有提升的权限或特定法律责任的群体有意义，例如基础设施团队或受托人。

如果在 Gentoo 中引入集中式身份验证模型，可能需要远程执行大多数验证。这将需要将敏感的个人数据传输到单个实体，这是不可取的。

另一方面，OpenPGP 信任网提供了分布式身份验证模型。在这种情况下，验证可以在开发人员的各个对之间进行，减少了单个实体掌握的敏感信息量，并增加了面对面执行验证的机会。

规范

目的和范围

本规范在任何地方都不强制执行身份验证。相反，它旨在为开发人员在建立此类流程必要时提供明确的规则。身份验证可能会在特定的开发人员组中单独强制执行，通过内部项目策略或理事会批准的策略。

如果根据本规范验证了身份，则应通过在该人的 OpenPGP 密钥上签署与已验证数据匹配的 UID 来记录此事实。此类签名以加密方式确认签名者已验证特定被签名者的 UID 提供了密钥所有者的合法真实姓名和电子邮件地址。此外，建议签名者将本 GLEP 的 URL 作为证书策略 URL（--cert-policy-url在 gpg(1) 中），并适当指示认证级别（见--default-cert-level在 gpg(1) 中）。

遵循本规范的签名的认证级别必须为 2 或 3，具体取决于签名者对被签名者身份证明的细致程度。

身份验证

面对面验证

建议的身份验证程序是让签名者与被签名者面对面见面。签名者必须

  1. 通过防篡改渠道（最好在纸上）获取被签名者的 OpenPGP 密钥指纹、完整的公钥数据或更强的摘要。签名者必须可靠地比较这些数据以验证正在签署的密钥的真实性。
  2. 使用带有照片的政府颁发身份证明验证被签名者的身份。验证必须包括，在签名者能力范围内
    1. 验证已验证文档的防伪特征是否存在并是否正确。
    2. 验证被签名者的面部是否与文档上的照片相似。
    3. 验证被签名者是否能够签署与文档上的签名类似的签名（如果存在）。
  3. 通过使用被签名者的 OpenPGP 密钥加密发送电子邮件来验证被签名者的电子邮件地址，电子邮件中包含随机生成的数据或待签名 UID 的导出签名。发送的每封邮件都必须包含独特的数据。

只有在所有三个因素都得到正面验证后，才可能根据本政策对特定 UID 进行签名。

远程摄像头验证

作为面对面验证的替代方案，可以使用高分辨率实时视频流执行验证。在这种情况下，被签名者应执行签名者能够在摄像头前验证身份证明所需的所有操作。

通过政府身份服务进行验证

最后，可以使用在特定国家/地区被认为具有法律意义的身份证明形式之一，并保证被签名者的身份已由官方验证。这可能包括例如

  • 公证员，
  • 政府身份服务（前提是签名者能够获得加密安全的身份证明），
  • 银行电汇。

GnuPG 命令行（信息性）

为了创建遵循本规范的签名，可以使用以下命令行参数

gpg --cert-policy-url 'https://gentoolinux.cn/glep/glep-0080.rst' \
    --ask-cert-level --cert-digest-algo SHA512 \
    --edit-key <key-fingerprint>

或者，如果这些选项应适用于所有进行的认证，则可以将其包含在配置文件中~/.gnupg/gpg.conf:

cert-policy-url https://gentoolinux.cn/glep/glep-0080.rst
ask-cert-level
cert-digest-algo SHA512

cert-policy-url指定认证符合的策略（如上所述）。ask-cert-level要求 GnuPG 在每次签署密钥时以交互方式查询认证级别。cert-digest-algo在认证上启用更强的 SHA-2 512 位摘要。

基本原理

非强制性

之前的 WoT 提案使签名成为强制性的。这遭到了开发人员的抵制，包括声称 Gentoo 中有些人无法使用任何提出的方法对他们的密钥进行签名，以及完全拒绝真实姓名验证。[2]

因此，本提案避免了强制每个人进行密钥签名。但是，它确实旨在为密钥签名提供正式的规则集，开发人员可以自行决定使用这些规则集，或者在需要验证贡献者身份的有效情况下使用。

GLEP 还为单独强制执行身份验证做出了规定，作为一项政策。虽然它可以建议为 Infra 等特定项目建立这样的政策，但在 GLEP 中维护此类项目的列表并在每次更改时更新它没有意义。相反，各个项目可以在其成员身上强制执行姓名验证，或者理事会在达成一致意见的情况下强制执行更广泛的政策。

面对面验证规则

验证规则遵循常见的密钥签名实践。值得注意的是，它们基于以下假设：单个签名确认三个元素的组合：被签名者的主密钥、真实姓名和电子邮件地址。

验证主密钥指纹对于确保使用属于被签名者的真实密钥至关重要。否则，恶意第三方可能会创建一个具有匹配 UID 的密钥，并且签名者可能会对该密钥而不是真实密钥进行签名。

验证真实姓名是本 GLEP 的具体目的，也是 OpenPGP 信任网的标准做法。应根据预计难以伪造的文档验证姓名，并且该文档应包含可用于验证所有者的照片。由于照片验证并非易事，而且在某些情况下文档包含过时的照片，因此在可能的情况下会辅以签名验证。无论如何，这部分被认为是尽力而为。

验证电子邮件地址是必要的，因为 OpenPGP 没有提供任何地址所有权证明，并且可以将任意用户标识符添加到密钥中。需要使用唯一数据来分别验证每个地址。数据是加密的，以进一步确认电子邮件地址的所有者确实可以访问密钥，并避免意外错误。

传统上，认为为每个电子邮件地址导出签名并将其发送就足够了。然后，被签名者可以解密它，导入并随后发布其密钥的更新，而无需签名者进行任何进一步的操作。手动执行此操作并非易事；caff 工具可以提供帮助。[3]

或者，可以使用简单的加密电子邮件交换，其中包含随机数据。之后，签名者对所有已确认的 UID 进行签名并发布签名。此方法不需要特殊的工具，并且具有额外的优势，可以验证被签名者是否可以从声明的地址发送邮件。

允许使用摄像头进行身份识别

关于远程身份验证是否有效存在不同的意见。但是，这种方法在被签名者不住在任何开发人员附近的情况下可能会有所帮助。

使用实时高分辨率流旨在降低伪造和复制被签名者身份证明的风险。能够自由移动对于至少部分验证防伪措施也是必要的。

允许使用政府身份服务

最后，在直接验证不方便的情况下，可以接受依靠预计会验证公民身份的政府官员和机构。最常见的情况是公证员，他们可以提供适当的身份证明，收取一定的费用。

除此之外，如果签名者和被签名者住在同一个国家，只要特别注意进行经过身份验证的交换，就可以使用其他国家验证机制。

在某些情况下，如果被签名者的银行已知会验证其客户的身份，则通过电汇进行随机生成的数据交换可能被认为足够。

向后兼容性

该策略是非强制性的，因此不会影响现有开发人员。

现有开发人员签名可能与该策略不兼容。为了使策略一致性清晰，GLEP 建议在签名中包含适当的策略 URL。

参考资料

[1]GLEP 76: 版权策略 (https://gentoolinux.cn/glep/glep-0076.html)
[2]Michał Górny。 “pre-GLEP: Gentoo OpenPGP 信任网”。gentoo-project 邮件列表，2019 年 1 月 31 日，邮件 ID 1548943008.796.1.camel@gentoo.org (https://archives.gentoo.org/gentoo-project/message/d05ae93cac6fbac0eea07fc597519382)
[3]caff - Debian Wiki (https://wiki.debian.org/caff)