Sequoia Web of Trust

一个使用 OpenPGP 的信任网进行用户 ID 和证书绑定验证的 Rust 库。该库围绕 OpenPGP 的数据结构设计，但不需要 OpenPGP 数据。相反，可以手动描述一个信任网。

此 crate 还包括一个 CLI 工具 sq-wot，用于验证绑定和探索信任网。

简介

信任网 是一种去中心化的信任模型，由 PGP 推广。它是 X.509 的超集，X.509 是一种层次化信任模型，并且是目前公网上最受欢迎的信任模型。然而，在公网上使用时，X.509 依赖于少数几个全球的 证书颁发机构 (CA)，这些机构往往 损害其安全性。

信任网比 X.509 更为复杂。使用信任网，可以通过只部分信任 CA 来通过多个独立路径验证绑定。这防止了一个恶意行为者破坏其安全性。而那些有更严格安全要求的人可以在完全去中心化的方式下使用信任网，其中只有他们选择的个人（不一定是机构）充当受信任的介绍人。

今天，围绕信任网的工具非常原始。许多人认为这种缺乏良好工具是信任网本质难以使用的迹象。我们不同意，并认为像我们的 OpenPGP CA 这样的努力提供了证据，证明这不是事实。

有关语义和实现的深入讨论，请参阅 规范。

本库提供了在信任网络中查找任意路径的功能，以及验证和检查特定路径的功能。此功能也通过命令行工具 sq-wot 提供接口。

使用方法

要从您的项目中使用 sequoia-wot，您应该在您的 Cargo.toml 文件中添加以下内容

[dependencies]
sequoia-wot = "0.8"
sequoia-cert-store = "0.3"
sequoia-openpgp = { version = "1.0.0", default-features = false }

要编译您的crate，请运行以下命令

$ cargo build --release --features sequoia-openpgp/default
$ cargo test --features sequoia-openpgp/default
$ cargo doc --no-deps --features sequoia-openpgp/default

如果您没有禁用 sequoia-openpgp 的默认功能，那么 sequoia-openpgp 将选择默认的加密后端，您的用户将无法轻松使用不同的加密后端编译您的crate。

sequoia-openpgp 目前使用 Nettle 作为其默认的加密后端。 sequoia-openpgp 还支持 OpenSSL (sequoia-openpgp/crypto-openssl)、Botan 3 (sequoia-openpgp/crypto-botan)、Botan 2 (sequoia-openpgp/crypto-botan2)、Windows CNG (sequoia-openpgp/crypto-cng) 和 Rust Crypto (sequoia-openpgp/crypto-rust)。有关构建 sequoia-openpgp 的更多信息，请参阅 sequoia-openpgp 的 README。这还包括有关不同后端的 构建要求 的信息。

sq-wot

sq-wot 是库的命令行接口。它实现了五个子命令：authenticate、lookup、identify、list 和 path。所有命令都会进行认证。在这个上下文中，authenticate 意味着基于用户和其他人做出的声明，建立身份与 OpenPGP 证书相关联的程度。通常有一个最小的信任阈值，如果累计信任量低于该阈值，则命令失败。

前四个子命令通过在信任网络中查找路径来通过认证绑定。这是通过在信任根和绑定之间计算最大流量来完成的。由于复杂性，这可能会在计算上很昂贵，但在实践中非常快：查询通常少于毫秒。计算成本通常被解析和验证证书所需的时间所掩盖。最后一个子命令验证并检查路径。由于路径已知，因此这非常快。

简而言之，authenticate 与特定的绑定一起工作；lookup 查找针对特定用户 ID 或电子邮件地址进行认证的证书；identify 查找可以使用特定证书进行认证的用户 ID；list 查找所有已认证的绑定；以及 path 检查路径的真实性。

authenticate 认证绑定

绑定是一对由证书和用户ID组成的组合。证书通常用其指纹或密钥ID表示。一个绑定的例子是：8F17777118A33DDA9BA48E62AACB3243630052D9 和 Neal H. Walfield <neal@sequoia-pgp.org>。另一个例子是 CBCD8F030588653EEDD7E2659B7DD433F254904A 和 Justus Winter <justus@sequoia-pgp.org>。

如果从可信根节点，通过中间介绍者，到一个目标绑定存在有效路径，则绑定是可信的。可信根节点是你用来断言绑定真实性的证书。可信根节点有时也称为可信锚点。中间介绍者是可信根节点或其他中间介绍者委托其介绍能力的证书。它们也称为认证机构。可信根节点和中间介绍者统称为可信介绍者。

路径的一个例子是：8F17777118A33DDA9BA48E62AACB3243630052D9，CBCD8F030588653EEDD7E2659B7DD433F254904A，Justus Winter <justus@sequoia-pgp.org>。此路径包括一个根和一个目标绑定，但没有中间介绍者。

sq-wot authenticate 尝试验证绑定。它看起来像这样：

$ sq-wot --gpg authenticate CBCD8F030588653EEDD7E2659B7DD433F254904A 'Justus Winter <[email protected]>'
[✓] CBCD8F030588653EEDD7E2659B7DD433F254904A Justus Winter <[email protected]>: fully authenticated (133%)
  Path #1 of 2, trust amount 40:
    ◯ CBCD8F030588653EEDD7E2659B7DD433F254904A "Justus Winter <[email protected]>"

  Path #2 of 2, trust amount 120:
    ◯ F7173B3C7C685CD9ECC4191B74E445BA0E15C957 ("Neal H. Walfield (Code Signing Key) <[email protected]>")
    │   certified the following binding on 2022-02-04
    └ CBCD8F030588653EEDD7E2659B7DD433F254904A "Justus Winter <[email protected]>"

sq-wot 打印出从可信根节点到指定绑定的路径。因为我将尝试验证的证书标记为部分可信的可信根节点在 gpg 中，因此它部分地验证了自己，如第一条路径所示。第二条路径是有效的，因为我直接签发了该绑定。

--gpg 选项告诉 sq-wot 从 gpg 读取我的可信根节点，并从 gpg 的密钥环中读取。可信根节点也可以使用 --trust-root 或 -r 选项明确指定。可以使用 --keyring 选项指定密钥环。例如，我可以确认 Clint Adams 为用户ID <dkg@debian.org> 签发了 dkg 的证书。

$ sq-wot -r F6D3495BB0AE9A02 --keyring /usr/share/keyrings/debian-keyring.gpg authenticate C29F8A0C01F35E34D816AA5CE092EB3A5CA10DBA "<[email protected]>"
[✓] C29F8A0C01F35E34D816AA5CE092EB3A5CA10DBA <[email protected]>: fully authenticated (100%)
  ◯ 2100A32C46F895AF3A08783AF6D3495BB0AE9A02 ("Clint Adams (GNU) <[email protected]>")
  │   certified the following binding on 2021-01-01 (expiry: 2023-12-24)
  └ C29F8A0C01F35E34D816AA5CE092EB3A5CA10DBA "<[email protected]>"

注意，在上面的示例中，我使用了整个用户ID，而不仅仅是电子邮件地址。sq-wot 还有一个 --email 标志，它会导致它考虑所有包含指定电子邮件地址的用户ID。例如

$ sq-wot --gpg authenticate CBCD8F030588653EEDD7E2659B7DD433F254904A --email [email protected]
...

有时无法验证绑定。在这种情况下，你可以尝试以下几种方法：你可以使用公钥服务器来增强你的密钥环；你可以通过将信任网络视为认证网络而不是认证网络来放宽认证标准；你还可以查询信任网络，以了解其他人（你没有直接或间接指定为可信介绍者）对特定绑定的看法。

使用公共证书存储

默认情况下，sq-wot 只使用您明确提供的证书。可能是因为缺少证书，阻止了您对绑定进行身份验证。如果您指定了 --network，那么 sq-wot 将在密钥服务器上查找缺少的证书。（默认为 hkps://keyserver.ubuntu.com，它是 SKS 网络的一部分，并提供了第三方认证。）注意：即使证书已过期，sq-wot 也不会检查更新；如果密钥存在于本地，则将其按原样使用。您可以通过运行 parcimonie 或定期运行类似操作来保持您的 gpg 密钥环更新。

$ gpg --export \
  | sq keyring list \
  | awk '{ print $2}' \
  | while read fpr; do \
    sq keyserver -s hkps://keyserver.ubuntu.com get $fpr; \
  done \
  | gpg --import

如果提供了 --network，那么 sq-wot 也将咨询 WKD，但当前它只针对目标证书这样做。

认证网络

通常，sq-wot 与一个认证网络一起工作。在一个认证网络中，Alice 声称某人（比如 Mallory）控制特定的密钥，与 Alice 声称 Mallory 可靠地做出断言之间存在差异。也就是说，在一个认证网络中，验证某人的身份与委托给他们和无条件相信他们所声称的内容在本质上是有区别的。

在认证网络中，所有认证都被视为委托。具体来说，所有认证都被视为具有无限的信任深度和没有正则表达式。

使用认证网络可能很危险。如果您认证了 Mallory 的证书，那么 Mallory 可以让您考虑任何绑定都经过了身份验证。尽管如此，认证网络还是有用的。

由于信任是随着时间的推移获得的，认证网络可以了解哪些潜在的有用受信任的中介可能是什么，然后可以单独升级它们的认证。例如，Alice 可能在她多年前第一次见到 Bob 时认证了 Bob 的证书。现在 Alice 想要认证 Carol 的证书。Alice 可能发现她的认证网络中没有通向 Alice 的路径，但她可能发现 Bob 在她的认证网络中认证了 Alice。由于 Alice 已与 Bob 认识多年，并且他已经证明了自己是可靠的，她可能会决定让 Bob 成为受信任的中介。这样就可以让她通过她的认证网络来认证 Carol。

认证网络在小型封闭社区中也有用，如 Linux 内核开发者、Debian 维护者或 Arch 维护者。在这里，假设所有成员都或多或少是可信的。使用认证网络，可以看到谁审核了谁。

认证网络也由所谓的 PGP 路径查找算法使用。这种模式符合它们的行为。

要告诉 sq-wot 将信任网视为认证网络而不是认证网络，请使用 --certification-network 选项。注意：这可以用于 sq-wot 的所有子命令，而不仅仅是 sq-wot authenticate。

使用此选项与我们的第一个示例，我们发现从 Neal 到 Justus 的额外路径包括

$ sq-wot --gpg --certification-network authenticate CBCD8F030588653EEDD7E2659B7DD433F254904A 'Justus Winter <[email protected]>'
...
  Path #4 of 4, trust amount 120:
    ◯ 8F17777118A33DDA9BA48E62AACB3243630052D9 ("Neal H. Walfield <[email protected]>")
    │   certified the following certificate on 2022-10-07
    ├ 653909A2F0E37C106F5FAF546C8857E0D8E8F074 ("Wiktor Kwapisiewicz <[email protected]>")
    │   certified the following certificate on 2018-02-06
    ├ 7420DF86BCE15A458DCE997639278DA8109E6244 ("Guilhem Moulin")
    │   certified the following certificate on 2018-02-10
    ├ 7845120B07CBD8D6ECE5FF2B2A1743EDA91A35B6 ("Darshit Shah <[email protected]>")
    │   certified the following certificate on 2015-11-09
    ├ D4AB192964F76A7F8F8A9B357BD18320DEADFA11 ("Valodim Skywalker <[email protected]>")
    │   certified the following certificate on 2017-11-19
    ├ CBCD8F030588653EEDD7E2659B7DD433F254904A ("<[email protected]>")
    │   certified the following binding on 2023-01-24
    └ CBCD8F030588653EEDD7E2659B7DD433F254904A "Justus Winter <[email protected]>"

八卦

有时在认证网络中，从信任根到您试图验证的绑定没有路径。在这种情况下，了解谁认证了特定的证书可能仍然是有帮助的。也就是说，倾听他人的八卦可能是有帮助的。--gossip 选项通过将所有证书都视为信任根（尽管信任度为零）来找到特定证书的任意路径。

八卦对于识别认证证书的替代方式很有用。例如，假设爱德想认证劳拉的证书，但直接询问她不方便。爱德发现米卡已经认证了劳拉的证书，但爱德还没有认证米卡的证书。如果爱德愿意依赖米卡作为受信任的介绍人，并且认证米卡的证书比认证劳拉的证书更容易，那么爱德就了解了一种更容易认证劳拉证书的方法。

在以下示例中，我们看到一个具有自签名用户ID OpenPGP CA <openpgp-ca@sequoia-pgp.org> 的证书已经认证了尤斯塔斯的证书

$ sq-wot --gpg --gossip authenticate CBCD8F030588653EEDD7E2659B7DD433F254904A 'Justus Winter <[email protected]>'
...
[ ] CBCD8F030588653EEDD7E2659B7DD433F254904A Justus Winter <[email protected]>: not authenticated (0%)
  ◯ 34F9E4B6A0A70BFEC5AE45198356989DF1977575 ("OpenPGP CA <[email protected]>")
  │   certified the following binding on 2022-02-09
  └ CBCD8F030588653EEDD7E2659B7DD433F254904A "Justus Winter <[email protected]>"

注意：默认情况下，--gossip 使用一个认证网络。--gossip 可以与 --certification-network 结合使用，以获取更不可靠的信息。

lookup 通过用户ID或电子邮件地址

lookup 子命令查找为指定用户ID认证的证书。当您想要找到某人的证书时，这很有用。和以前一样，我们可以使用 --email 选项

$ sq-wot --gpg lookup --email [email protected]
[✓] CBCD8F030588653EEDD7E2659B7DD433F254904A Justus Winter <[email protected]>: fully authenticated (133%)
  Path #1 of 2, trust amount 40:
    ◯ CBCD8F030588653EEDD7E2659B7DD433F254904A "Justus Winter <[email protected]>"

  Path #2 of 2, trust amount 120:
    ◯ F7173B3C7C685CD9ECC4191B74E445BA0E15C957 ("Neal H. Walfield (Code Signing Key) <[email protected]>")
    │   certified the following binding on 2022-02-04
    └ CBCD8F030588653EEDD7E2659B7DD433F254904A "Justus Winter <[email protected]>"

lookup 子命令也是评估相同用户ID在不同证书中认证程度的有用工具。这有助于区分证书是伪造的还是合法的替换。

以下图像展示了这一点，该图像使用 sq-wot 的 DOT 输出格式选项创建，并使用 Graphiz 的 DOT 编译器转换为 SVG

$ sq-wot \
    -r 2AC0A42EFB0B5CBC7A0402ED4DC95B6D7BE9892E \
    -r D8AFDDA07A5B6EDFA7D8CCDAD6D055F927843F1C \
    -r 75BD80E4D834509F6E740257B1B73B02CC52A02A \
    -r 91FFE0700E80619CEB73235CA88E23E377514E00 \
    -r 0E8B644079F599DFC1DDC3973348882F6AC6A4C2 \
    -r 69E6471E3AE065297529832E6BA0F5A2037F4F41 \
    -k archlinux.pgp \
    -f dot \
    -a 500 \
    lookup \
    --email [email protected] | dot -Tsvg

identify 通过证书

identify 子命令查找给定证书可以认证的所有绑定。当您想要确定证书属于谁时，这很有用

$ sq-wot --gpg identify CBCD8F030588653EEDD7E2659B7DD433F254904A
[✓] CBCD8F030588653EEDD7E2659B7DD433F254904A Justus Winter <[email protected]>: fully authenticated (133%)
  Path #1 of 2, trust amount 40:
    ◯ CBCD8F030588653EEDD7E2659B7DD433F254904A "Justus Winter <[email protected]>"

  Path #2 of 2, trust amount 120:
    ◯ F7173B3C7C685CD9ECC4191B74E445BA0E15C957 ("Neal H. Walfield (Code Signing Key) <[email protected]>")
    │   certified the following binding on 2022-02-04
    └ CBCD8F030588653EEDD7E2659B7DD433F254904A "Justus Winter <[email protected]>"

[✓] CBCD8F030588653EEDD7E2659B7DD433F254904A Justus Winter <[email protected]>: fully authenticated (133%)
  Path #1 of 2, trust amount 40:
    ◯ CBCD8F030588653EEDD7E2659B7DD433F254904A "Justus Winter <[email protected]>"

  Path #2 of 2, trust amount 120:
    ◯ F7173B3C7C685CD9ECC4191B74E445BA0E15C957 ("Neal H. Walfield (Code Signing Key) <[email protected]>")
    │   certified the following binding on 2022-02-04
    └ CBCD8F030588653EEDD7E2659B7DD433F254904A "Justus Winter <[email protected]>"
...

identify 子命令还显示同一证书上的不同用户ID可能没有达到相同的认证程度。

以下图形说明了这一点，该图形使用 DOT 输出格式创建

$ sq-wot \
    -r 2AC0A42EFB0B5CBC7A0402ED4DC95B6D7BE9892E \
    -r D8AFDDA07A5B6EDFA7D8CCDAD6D055F927843F1C \
    -r 75BD80E4D834509F6E740257B1B73B02CC52A02A \
    -r 91FFE0700E80619CEB73235CA88E23E377514E00 \
    -r 0E8B644079F599DFC1DDC3973348882F6AC6A4C2 \
    -r 69E6471E3AE065297529832E6BA0F5A2037F4F41 \
    -k archlinux.pgp \
    -f dot \
    -a 500 \
    identify \
    B5971F2C5C10A9A08C60030F786C63F330D7CB92 | dot -Tsvg

list 所有已认证绑定

list 子命令查找所有证书可以认证的所有绑定。这有助于查看您可以认证的每个人，以及原因

$ sq-wot --gpg list
[✓] 8F17777118A33DDA9BA48E62AACB3243630052D9 Neal H. Walfield <[email protected]>: fully authenticated (100%)
  ◯ 8F17777118A33DDA9BA48E62AACB3243630052D9 "Neal H. Walfield <[email protected]>"

[✓] 8F17777118A33DDA9BA48E62AACB3243630052D9 Neal H. Walfield <[email protected]>: fully authenticated (100%)
  ◯ 8F17777118A33DDA9BA48E62AACB3243630052D9 "Neal H. Walfield <[email protected]>"
...
[✓] CBCD8F030588653EEDD7E2659B7DD433F254904A Justus Winter <[email protected]>: fully authenticated (133%)
  Path #1 of 2, trust amount 40:
    ◯ CBCD8F030588653EEDD7E2659B7DD433F254904A "Justus Winter <[email protected]>"

  Path #2 of 2, trust amount 120:
    ◯ F7173B3C7C685CD9ECC4191B74E445BA0E15C957 ("Neal H. Walfield (Code Signing Key) <[email protected]>")
    │   certified the following binding on 2022-02-04
    └ CBCD8F030588653EEDD7E2659B7DD433F254904A "Justus Winter <[email protected]>"
...

这也有助于检查社区内的连接。以下图表使用 sq-wot 的 DOT 输出生成，并显示了可以使用 Linux 内核的密钥环 从三位社区成员处认证的绑定

$ sq-wot \
  -f dot \
  -r ABAF11C65A2970B130ABE3C479BE3E4300411886 \
  -r 647F28654894E3BD457199BE38DBBDC86092693E \
  -r CA30110FD5285DE49BB238CD17212997986C5765 \
  -k kernel.pgp \
  list | dot -Tsvg

验证 path

path 子命令验证和检查路径。当您认为路径应该是有效的，但 sq-wot authenticate 悄无声息地不同意时，这特别有用。

路径作为从根的指纹或密钥ID开始，以目标证书的指纹或密钥ID和用户ID结束的指纹列表传递给 sq-wot path。如果路径有效，则返回成功。如果不有效，则检查路径。

在以下记录中，我们首先看到 sq-wot authenticate 无用地说从 hpa 到 Greg Kroah-Hartman 的证书没有路径。但当我们使用 sq-wot path 时，我们发现 hpa 确实认证了 Greg Kroah-Hartman 的证书，但认证使用了 SHA-1，这不再可信

$ sq-wot --keyring kernel.pgp -r BDA06085493BACE4 authenticate 38DBBDC86092693E "Greg Kroah-Hartman (Linux kernel stable release signing key) <[email protected]>"
No paths found.
$ sq-wot --keyring kernel.pgp path BDA06085493BACE4 38DBBDC86092693E "Greg Kroah-Hartman (Linux kernel stable release signing key) <[email protected]>"
[ ] 647F28654894E3BD457199BE38DBBDC86092693E Greg Kroah-Hartman (Linux kernel stable release signing key) <[email protected]>: not authenticated (0%)
  ◯ 7EAAC9693E7D220546BE576CBDA06085493BACE4 ("H. Peter Anvin (hpa) <[email protected]>")
  │   No adequate certification found.
  │   BDA06085493BACE4 did not certify <38DBBDC86092693E, "Greg Kroah-Hartman (Linux kernel stable release signing key) <[email protected]>">
  │   No active certifications by BDA06085493BACE4 for <38DBBDC86092693E, "Greg Kroah-Hartman (Linux kernel stable release signing key) <[email protected]>"> had a trust amount of at least 120
  │   Certification (B122 by BDA06085493BACE4 on 38DBBDC86092693E at 2011-09-23 18:42.09) is adequate, but it is not valid
  │     B122 by BDA06085493BACE4 on 38DBBDC86092693E at 2011-09-23 18:42.09: policy violation
  │     Policy rejected non-revocation signature (GenericCertification) requiring collision resistance
  │     SHA1 is not considered secure since 2013-02-01T00:00:00Z
  └ 647F28654894E3BD457199BE38DBBDC86092693E "Greg Kroah-Hartman (Linux kernel stable release signing key) <[email protected]>"

许可证

sequoia-wot 在 LGPL 2.0 或更高版本的条款下分发。

请参阅LICENSE.txt和CONTRIBUTING.md以获取详细信息。