Python 新的 ASN.1 API 预览

A New ASN.1 API for Python

Source | HN Comments

文章预告了为 Python 构建的新 ASN.1 API。该 API 旨在解决现有库在性能、差异化和现代化方面的不足。新 API 将使用 Rust 编写的 ASN.1 解析器，提高性能，减少解析差异，并提供基于 `dataclasses` 的声明式接口，增强类型检查兼容性。该项目由 Alpha-Omega 资助，并计划集成到 PyCA Cryptography 库中，以改进 Python 在密码学和供应链安全领域的应用。

抢先看：一个用于 Python 的新 ASN.1 API

William Woodruff 2025 年 4 月 18 日 open-source, engineering-practice, cryptography

如果你曾经在 Python 中处理过密码学、PKI 方案或底层网络，你可能遇到过 ASN.1。ASN.1 是每个 TLS 握手的基础（通过 X.509 路径验证），为核心互联网协议（如 LDAP, SNMP 和 3GPP）提供序列化层，并且通常作为密码学原语和协议表示的 通用语言 运行。

ASN.1 的关键作用与它丰富的安全历史相辅相成：ASN.1 编码规则的实现历来是内存损坏和拒绝服务漏洞的丰富来源。类似地，ASN.1 在互联网协议的最底层出现，使得性能和缺乏 parser differentials 成为关键要求。

Python 有多个优秀的 ASN.1 实现（如 pyasn1, asn1, 和 asn1tools），但这些通常属于后一类：完全用 Python 编写使得性能成为一个问题，并且集成到使用其他 ASN.1 解析器的堆栈中（例如，在 X.509 层）引入了差异风险。

我们正在改变这一点：在 Alpha-Omega 的资助下，我们正在为 PyCA Cryptography 构建一个 ASN.1 API，以解决当今 Python 生态系统中的三个关键缺点：

性能: 这个新的 API 将使用一个 pure Rust ASN.1 parser，从而为我们提供接近原生的解析性能。
差异化减少: 上面提到的解析器已经被 PyCA Cryptography 用于其 X.509 APIs。这将减少对 ASN.1 解析的“混合搭配”方法的需求，从而降低差异化漏洞的风险。
现代化: 新的 API 将公开一个声明性的 dataclasses 风格接口，该接口带有类型提示，使其熟悉、地道并与类型检查器兼容。

例如，像这样的 ASN.1 定义：

Doohickies ::= SEQUENCE {
  tschotchkes    OCTET STRING,
  baubles      INTEGER,
  knickknacks    UTF8String,
  whatchamacallits SEQUENCE OF OBJECT IDENTIFIER,
  gizmos      SET OF GeneralizedTime OPTIONAL
}

...将对应于以下 Python 代码：

from datetime import datetime
from cryptography.hazmat import asn1
@asn1.sequence
class Doohickies:
  tschotchkes: bytes
  baubles: int
  knickknacks: str
  whatchamacallits: list[asn1.ObjectIdentifier]
  gizmos: set[datetime] | None
doohickies = Doohickies.from_der(b"...")
print(doohickies.tschotchkes)
doohickies.to_der() # b"..."

这项工作是我们之前在 X.509 路径验证方面工作的逻辑延续，该工作由 Sovereign Tech Fund 资助。它反映了我们不断致力于改进 Python 生态系统，尤其是在密码学和供应链安全领域。

如果您有兴趣了解更多信息或资助类似工作，请联系我们！

关于 ASN.1 的一些快速背景知识

ASN.1，或抽象语法表示法一，是一种 接口描述语言 (IDL)。这是一种描述数据结构的语法，与语言和平台无关。

令人困惑的是，ASN.1 本身不是 一种序列化格式。相反，它定义了 编码规则，这些规则反过来定义了不同设置中 ASN.1 结构的序列化和反序列化。在实践中，ASN.1 是 Distinguished Encoding Rules（DER）的同义词1。

图 1：ASN.1 不同编码规则的实用可视解释

为了本文的目的，我们将“ASN.1”和“DER”视为可以互换的。与其深入研究两者的复杂性（Let's Encrypt 对它们的解释非常出色），我们将重点关注 DER 的特性，这些特性使其在几十年中保持了相关性：

DER 是一种规范编码： 在 DER 中，只有一种编码给定 ASN.1 结构的方法。换句话说，ASN.1 结构在 DER 中的编码是确定性的，并且可以往返，同时保持逐位相等。
DER 相对紧凑： DER 定义了一种二进制格式，并且作为规范的结果，禁止对整数、布尔值和时间进行非最小编码。
DER 是一种 自描述 和 自定界 编码： 给定的 DER 消息可以完全且可靠地解析，而无需事先参考架构或格式描述，只需了解 DER 本身的编码规则即可。

这些属性自然适用于 Web 开发人员所说的“渐进增强”：使用 DER 的应用程序可以解码它关心的特定结构，同时跳过它不关心的结构，只解码它们的长度以便跳到下一个结构。

DER 支持 任意精度整数： DER 中的 INTEGER 类型在大小上实际上不受限制，这使得它适合表示经常出现在加密设置中的各种大数（例如，素数）。

总而言之，这些属性使 DER 在加密、网络和电信设置中非常受欢迎。

更准确地说，它在每个设置的内部都非常受欢迎：ASN.1 用于表示保护世界 TLS 流量的 X.509 证书，广泛用于 PEM 编码的格式，并为互联网的较低协议层提供描述和序列化。

激励 Python 的 ASN.1 库

你可能会合理地问：Python 为什么需要这个？

毕竟，大多数 Python 开发人员不会每天都接触 ASN.1，而且那些接触 ASN.1 的人大多以预定义的方式（例如 X.509 证书）进行。为什么生态系统需要对 ASN.1 进行通用支持？

对此的答案是，无论好坏，在许多情况下，Python 开发人员需要进行 ASN.1 编码和解码，而不是在 X.509 和其他众所周知的格式和协议的“标准”形状之外。

这可以在 Sigstore 生态系统中看到：Sigstore 主要是一个普通的 RFC 5280 风格的 PKI，但它也包括一些用于自身目的的自定义 X.509 extensions。例如，Sigstore log entry 的摘录显示了以下扩展：

OIDC Issuer: https://token.actions.githubusercontent.com
Runner Environment: github-hosted
Source Repository URI: https://github.com/pypa/sampleproject
Source Repository Ref: refs/heads/main
Source Repository Owner URI: https://github.com/pypa

如果我们想从 Python 中使用这些（例如，为了根据策略验证 Sigstore 证书），我们需要提取它们：

from cryptography import x509
raw_cert = b"""
-----BEGIN CERTIFICATE-----
MIIGoTCCBiigAwIBAgITFai+PDKak1xA1HLq0mskqhDV5zAKBggqhkjOPQQDAzA3
MRUwEwYDVQQKEwxzaWdzdG9yZS5kZXYxHjAcBgNVBAMTFXNpZ3N0b3JlLWludGVy
bWVkaWF0ZTAeFw0yNDExMDYyMjM3MDdaFw0yNDExMDYyMjQ3MDdaMAAwWTATBgcq
hkjOPQIBBggqhkjOPQMBBwNCAARbx1Fse2Ln00On5aFaL+lHNGFYLaqeKDduplZD
PJS+w2PjYfNPL0g/n4sDWEQFZfyIExEWKulZ2GKNzAc0+SmUo4IFSDCCBUQwDgYD
VR0PAQH/BAQDAgeAMBMGA1UdJQQMMAoGCCsGAQUFBwMDMB0GA1UdDgQWBBT/uSEI
XmQzuRkppWXrTKVkfZFJbzAfBgNVHSMEGDAWgBTf0+nPViQRlvmo2OkoVaLGLhhk
PzBhBgNVHREBAf8EVzBVhlNodHRwczovL2dpdGh1Yi5jb20vcHlwYS9zYW1wbGVw
cm9qZWN0Ly5naXRodWIvd29ya2Zsb3dzL3JlbGVhc2UueW1sQHJlZnMvaGVhZHMv
bWFpbjA5BgorBgEEAYO/MAEBBCtodHRwczovL3Rva2VuLmFjdGlvbnMuZ2l0aHVi
dXNlcmNvbnRlbnQuY29tMBIGCisGAQQBg78wAQIEBHB1c2gwNgYKKwYBBAGDvzAB
AwQoNjIxZTQ5NzRjYTI1Y2U1MzE3NzNkZWY1ODZiYTNlZDhlNzM2YjNmYzAVBgor
BgEEAYO/MAEEBAdSZWxlYXNlMCAGCisGAQQBg78wAQUEEnB5cGEvc2FtcGxlcHJv
amVjdDAdBgorBgEEAYO/MAEGBA9yZWZzL2hlYWRzL21haW4wOwYKKwYBBAGDvzAB
CAQtDCtodHRwczovL3Rva2VuLmFjdGlvbnMuZ2l0aHVidXNlcmNvbnRlbnQuY29t
MGMGCisGAQQBg78wAQkEVQxTaHR0cHM6Ly9naXRodWIuY29tL3B5cGEvc2FtcGxl
cHJvamVjdC8uZ2l0aHViL3dvcmtmbG93cy9yZWxlYXNlLnltbEByZWZzL2hlYWRz
L21haW4wOAYKKwYBBAGDvzABCgQqDCg2MjFlNDk3NGNhMjVjZTUzMTc3M2RlZjU4
NmJhM2VkOGU3MzZiM2ZjMB0GCisGAQQBg78wAQsEDwwNZ2l0aHViLWhvc3RlZDA1
BgorBgEEAYO/MAEMBCcMJWh0dHBzOi8vZ2l0aHViLmNvbS9weXBhL3NhbXBsZXBy
b2plY3QwOAYKKwYBBAGDvzABDQQqDCg2MjFlNDk3NGNhMjVjZTUzMTc3M2RlZjU4
NmJhM2VkOGU3MzZiM2ZjMB8GCisGAQQBg78wAQ4EEQwPcmVmcy9oZWFkcy9tYWlu
MBgGCisGAQQBg78wAQ8ECgwIMTQ4OTk1OTYwJwYKKwYBBAGDvzABEAQZDBdodHRw
czovL2dpdGh1Yi5jb20vcHlwYTAWBgorBgEEAYO/MAERBAgMBjY0NzAyNTBjBgor
BgEEAYO/MAESBFUMU2h0dHBzOi8vZ2l0aHViLmNvbS9weXBhL3NhbXBsZXByb2pl
Y3QvLmdpdGh1Yi93b3JrZmxvd3MvcmVsZWFzZS55bWxAcmVmcy9oZWFkcy9tYWlu
MDgGCisGAQQBg78wARMEKgwoNjIxZTQ5NzRjYTI1Y2U1MzE3NzNkZWY1ODZiYTNl
ZDhlNzM2YjNmYzAUBgorBgEEAYO/MAEUBAYMBHB1c2gwWQYKKwYBBAGDvzABFQRL
DElodHRwczovL2dpdGh1Yi5jb20vcHlwYS9zYW1wbGVwcm9qZWN0L2FjdGlvbnMv
cnVucy8xMTcxMzAzODk4MS9hdHRlbXB0cy8xMBYGCisGAQQBg78wARYECAwGcHVi
bGljMIGKBgorBgEEAdZ5AgQCBHwEegB4AHYA3T0wasbHETJjGR4cmWc3AqJKXrje
PK3/h4pygC8p7o4AAAGTA5/X5AAABAMARzBFAiA6nYK0GxqVzJutrjrYA1bAIKHU
jGrsHMLrOJTTEUiERAIhAJZotATnSwlKt7C3Zwhx3fcSrhGfOakTlM2w+8qmltcj
MAoGCCqGSM49BAMDA2cAMGQCMB+ilsPgy4ynUG9GtqDEBqW8+ZqjX6LpuxQqjCr7
s4ytyt2ppFdgjrGrG1DY4nSZtQIwblrgq9t9izAMTkJeqhQBs2OUiyIJZipceD5v
AAE/Nfgd/9uK0MZAHFsLgalqOBl8
-----END CERTIFICATE-----
"""
cert = x509.load_pem_x509_certificate(raw_cert)
# 1.3.6.1.4.1.57264.1.16 对应于上面的 Source Repository Owner URI
ext = cert.extensions.get_extension_for_oid(x509.ObjectIdentifier("1.3.6.1.4.1.57264.1.16")).value
ext.value # => b'\x0c\x17https://github.com/pypa'

正如我们所看到的，X.509 扩展的值本身是 DER 编码的，PyCA Cryptography 的 API（正确地）让我们来解释它2。

因此，我们需要某种 DER 解析器。幸运的是，Python 是一个成熟的生态系统，我们可以使用 pyasn1：

from pyasn1.codec.der.decoder import decode
from pyasn1.type.char import UTF8String
ext_value = decode(ext.value, UTF8String)[0].decode()
ext_value # => 'https://github.com/pypa'

现在我们有了内部扩展值，我们可以继续生活。

但是为什么是新的库？

但是等等：如果我们有 pyasn1，为什么我们需要一个新的 ASN.1 库？

对此的答案有三方面，而不是 抨击 pyasn1 （这是一个出色的库，可以出色地发挥其作用）：

性能：Python 不是一种快速的语言，而 pyasn1 是用纯 Python 编写的。 Python 生态系统历来通过将性能敏感的代码放在原生扩展中来弥补这一点：起初是 C，但现在越来越多的是 Rust。通过利用 rust-asn1，我们可以在不离开 Python 的舒适环境的情况下接近原生代码的性能。
差异化减少：ASN.1 生态系统以其异构而闻名，ASN.1 的实现方式在很大程度上与其对 DER 严格要求的遵守程度有所不同。

特别是，许多实现发现将 Postel's Law 应用于解析传入的“DER”数据很有吸引力，只要可以推断用户的意图，就允许不正确地规范化或完全畸形的数据。这对协议演进和安全性产生了不利影响：协议在未指定行为的压力下难以演进，并且 parser differentials 是重大安全事件的一致来源。

因此，减少给定代码库中单个格式的独立解析器的数量通常是一个合理的工程选择。 PyCA Cryptography 已经围绕 rust-asn1 构建，因此在新 ASN.1 库中使用完全相同的解析例程是有意义的。 3. 现代化：dataclasses 和 dataclass 风格的声明式 API 在 Python 生态系统中掀起了一场风暴，并且有充分的理由：它们是统一的，与类型检查器干净地集成3，并将类型定义为代码而不是数据。

pyasn1 有一个很棒的声明式 API，但是该 API 早于 dataclass 的概念，因此需要混合代码和数据来定义其类型。在我们看来，使该 API 现代化至少与从 rust-asn1 创建一个新 API 一样困难，但没有性能和差异化减少的好处。

敬请关注更多信息

这只是一个先睹为快；请关注此空间以获取更新！

我们仍处于这项工作的早期开发阶段；我们的计划如下：

构建一个初始版本，支持 @asn1.sequence 和 @asn1.enum 作为主要的装饰器，并支持 ASN.1 的基本类型和修饰符（例如，OPTIONAL、DEFAULT、IMPLICIT 和 EXPLICIT）。
将此版本集成到 PyCA Cryptography 中，暂定为 cryptography.asn1 或 cryptography.hazmat.asn1 或类似名称，然后在可能的情况下努力删除重复类型。例如，cryptography.x509.ObjectIdentifier 类型已经存在，应该在两个 API 之间共享或重用。
通过 PyCA Cryptography 的主要版本发布它！

我们要感谢 Alpha-Omega 对这项工作的资助，以及 PyCA Cryptography 维护者们提供的支持和设计评审。