增加aspa对象解析

2026-02-02 15:39:22 +08:00
parent bcd4829486
commit 56ae2ca4fc
44 changed files with 1608 additions and 0 deletions
--- a/specs/00_common_types.md
+++ b/specs/00_common_types.md
@@ -182,6 +182,8 @@ RFC 引用：RFC 5280 §4.2.2.1；RFC 5280 §4.2.2.2；RFC 5280 §4.2.1.6。
 | `1.2.840.113549.1.9.5` | CMS signedAttrs: signing-time | RFC 9589 §4（更新 RFC 6488 §3(1f)/(1g)） |
 | `1.2.840.113549.1.9.16.1.24` | ROA eContentType: id-ct-routeOriginAuthz | RFC 9582 §3 |
 | `1.2.840.113549.1.9.16.1.26` | Manifest eContentType: id-ct-rpkiManifest | RFC 9286 §4.1 |
+| `1.2.840.113549.1.9.16.1.35` | Ghostbusters eContentType: id-ct-rpkiGhostbusters | RFC 6493 §6；RFC 6493 §9.1 |
+| `1.2.840.113549.1.9.16.1.49` | ASPA eContentType: id-ct-ASPA | `draft-ietf-sidrops-aspa-profile-21` §2 |
 | `1.3.6.1.5.5.7.1.1` | X.509 v3 扩展：authorityInfoAccess | RFC 5280 §4.2.2.1 |
 | `1.3.6.1.5.5.7.1.11` | X.509 v3 扩展：subjectInfoAccess | RFC 5280 §4.2.2.2；RPKI 约束见 RFC 6487 §4.8.8 |
 | `1.3.6.1.5.5.7.48.2` | AIA accessMethod: id-ad-caIssuers | RFC 5280 §4.2.2.1 |
--- a/specs/06_manifest_mft.md
+++ b/specs/06_manifest_mft.md
@@ -102,5 +102,9 @@ FileAndHash ::=     SEQUENCE {
 Manifest 使用“one-time-use EE certificate”进行签名验证，规范对该 EE 证书的使用方式给出约束：

 - Manifest 相关 EE 证书应为 one-time-use（每次新 manifest 生成新密钥对/新 EE）。RFC 9286 §4（Section 4 前导段落）。
+- 用于签名/验证 manifest 的 EE 证书在 RFC 3779 的资源扩展中描述 INRs 时，**MUST** 使用 `inherit`（而不是显式列出资源集合）。RFC 9286 §5.1（生成步骤 2）。
+  - 若证书包含 **IP Address Delegation Extension**（IP prefix delegation）：内容必须为 `inherit`（不得显式列 prefix/range）。RFC 9286 §5.1；RFC 3779。
+  - 若证书包含 **AS Identifier Delegation Extension**（ASN delegation）：内容必须为 `inherit`（不得显式列 ASID/range）。RFC 9286 §5.1；RFC 3779。
+  - 另外按资源证书 profile：资源证书 **MUST** 至少包含上述两类扩展之一（也可两者都有），且这些扩展 **MUST** 标记为 critical。RFC 6487 §2。
 - 用于验证 manifest 的 EE 证书 **MUST** 具有与 `thisUpdate..nextUpdate` 区间一致的有效期，以避免 CRL 无谓增长。RFC 9286 §4.2.1（manifestNumber 段落前的说明）。
 - 替换 manifest 时，CA 必须撤销旧 manifest 对应 EE 证书；且若新 manifest 早于旧 manifest 的 nextUpdate 发行，则 CA **MUST** 同时发行新 CRL 撤销旧 manifest EE。RFC 9286 §4.2.1（nextUpdate 段落末）；RFC 9286 §5.1（生成步骤）。
--- a/specs/08_aspa.md
+++ b/specs/08_aspa.md
@@ -0,0 +1,100 @@
+# 08. ASPA（Autonomous System Provider Authorization）
+
+## 8.1 对象定位
+
+ASPA（Autonomous System Provider Authorization）是一种 RPKI Signed Object，用于由“客户 AS”（Customer AS, CAS）签名声明其上游“提供者 AS”（Provider AS, PAS）集合，以支持路由泄漏（route leak）检测/缓解。`draft-ietf-sidrops-aspa-profile-21`；`draft-ietf-sidrops-aspa-verification`。
+
+ASPA 由 CMS 外壳 + ASPA eContent 组成：
+
+- 外壳：RFC 6488（更新：RFC 9589）
+- eContent：`draft-ietf-sidrops-aspa-profile-21`
+
+## 8.2 原始载体与编码
+
+- 外壳：CMS SignedData DER（见 `05_signed_object_cms.md`）。RFC 6488 §2-§3；RFC 9589 §4。
+- eContentType：`id-ct-ASPA`，OID `1.2.840.113549.1.9.16.1.49`。`draft-ietf-sidrops-aspa-profile-21` §2。
+- eContent：DER 编码 ASN.1 `ASProviderAttestation`。`draft-ietf-sidrops-aspa-profile-21` §3。
+
+### 8.2.1 eContentType 与 eContent 的 ASN.1 定义（`draft-ietf-sidrops-aspa-profile-21` §2-§3）
+
+ASPA 是一种 RPKI signed object（CMS 外壳见 `05_signed_object_cms.md`）。其 `eContentType` 与 `eContent`（payload）的 ASN.1 定义见 `draft-ietf-sidrops-aspa-profile-21` §2-§3。
+
+**eContentType（OID）**：`draft-ietf-sidrops-aspa-profile-21` §2。
+
+```asn1
+id-ct-ASPA OBJECT IDENTIFIER ::=
+  { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
+    pkcs-9(9) id-smime(16) id-ct(1) aspa(49) }
+```
+
+**eContent（ASPA ASN.1 模块）**：`draft-ietf-sidrops-aspa-profile-21` §3。
+
+```asn1
+ASProviderAttestation ::= SEQUENCE {
+  version [0]   INTEGER DEFAULT 0,
+  customerASID  ASID,
+  providers     ProviderASSet }
+
+ProviderASSet ::= SEQUENCE (SIZE(1..MAX)) OF ASID
+
+ASID ::= INTEGER (0..4294967295)
+```
+
+编码/解码要点（与上面 ASN.1 结构直接对应）：
+
+- `version`：规范要求 **MUST 为 1** 且 **MUST 显式编码**（不得依赖 DEFAULT 省略）。`draft-ietf-sidrops-aspa-profile-21` §3.1。
+- `customerASID`：客户 AS 号（CAS）。`draft-ietf-sidrops-aspa-profile-21` §3.2。
+- `providers`：授权的提供者 AS 集合（SPAS）。并对“自包含/排序/去重”施加额外约束（见下）。`draft-ietf-sidrops-aspa-profile-21` §3.3。
+
+## 8.3 解析规则（eContent 语义层）
+
+输入：`RpkiSignedObject`。
+
+1) 解析 CMS 外壳，得到 `econtent_type` 与 `econtent_der`。RFC 6488 §3；RFC 9589 §4。  
+2) 要求 `econtent_type == 1.2.840.113549.1.9.16.1.49`。`draft-ietf-sidrops-aspa-profile-21` §2。  
+3) 将 `econtent_der` 以 DER 解析为 `ASProviderAttestation` ASN.1。`draft-ietf-sidrops-aspa-profile-21` §3。  
+4) 将 `providers` 映射为语义字段 `provider_as_ids: list[int]`，并对其执行“约束检查/（可选）归一化”。`draft-ietf-sidrops-aspa-profile-21` §3.3。
+
+## 8.4 抽象数据模型（接口）
+
+### 8.4.1 `AspaObject`
+
+| 字段 | 类型 | 语义 | 约束/解析规则 | 规范引用 |
+|---|---|---|---|---|
+| `signed_object` | `RpkiSignedObject` | CMS 外壳 | 外壳约束见 RFC 6488/9589 | RFC 6488 §3；RFC 9589 §4 |
+| `econtent_type` | `Oid` | eContentType | 必须为 `1.2.840.113549.1.9.16.1.49` | `draft-ietf-sidrops-aspa-profile-21` §2 |
+| `aspa` | `AspaEContent` | eContent 语义对象 | 见下 | `draft-ietf-sidrops-aspa-profile-21` §3 |
+
+### 8.4.2 `AspaEContent`（ASProviderAttestation）
+
+| 字段 | 类型 | 语义 | 约束/解析规则 | 规范引用 |
+|---|---|---|---|---|
+| `version` | `int` | ASPA 版本 | MUST 为 `1` 且 MUST 显式编码（字段不可省略） | `draft-ietf-sidrops-aspa-profile-21` §3.1 |
+| `customer_as_id` | `int` | Customer ASID | 0..4294967295 | `draft-ietf-sidrops-aspa-profile-21` §3.2（ASID 定义） |
+| `provider_as_ids` | `list[int]` | Provider ASID 列表（SPAS） | 长度 `>= 1`；且满足“不得包含 customer、升序、去重” | `draft-ietf-sidrops-aspa-profile-21` §3.3 |
+
+## 8.5 字段级约束清单（实现对照）
+
+- eContentType 必须为 `id-ct-ASPA`（OID `1.2.840.113549.1.9.16.1.49`），且该 OID 必须同时出现在 eContentType 与 signedAttrs.content-type。`draft-ietf-sidrops-aspa-profile-21` §2（引用 RFC 6488）。
+- eContent 必须 DER 编码并符合 `ASProviderAttestation` ASN.1。`draft-ietf-sidrops-aspa-profile-21` §3。
+- `version` 必须为 1，且必须显式编码（缺失视为不合规）。`draft-ietf-sidrops-aspa-profile-21` §3.1。
+- `providers`（`provider_as_ids`）必须满足：
+  - `customer_as_id` **MUST NOT** 出现在 `provider_as_ids` 中；
+  - `provider_as_ids` 必须按数值 **升序排序**；
+  - `provider_as_ids` 中每个 ASID 必须 **唯一**。`draft-ietf-sidrops-aspa-profile-21` §3.3。
+
+## 8.6 与 EE 证书的语义约束（为后续验证准备）
+
+ASPA 的外壳包含一个 EE 证书，用于验证 ASPA 签名；规范对该 EE 证书与 ASPA payload 的匹配关系提出要求：
+
+- EE 证书必须包含 AS 资源扩展（Autonomous System Identifier Delegation Extension），且 `customer_as_id` 必须与该扩展中的 ASId 匹配。`draft-ietf-sidrops-aspa-profile-21` §4（引用 RFC 3779）。
+- EE 证书的 AS 资源扩展 **必须**：
+  - 恰好包含 1 个 `id` 元素；
+  - **不得**包含 `inherit` 元素；
+  - **不得**包含 `range` 元素。`draft-ietf-sidrops-aspa-profile-21` §4（引用 RFC 3779 §3.2.3.3 / §3.2.3.6 / §3.2.3.7）。
+- EE 证书 **不得**包含 IP 资源扩展（IP Address Delegation Extension）。`draft-ietf-sidrops-aspa-profile-21` §4（引用 RFC 3779）。
+
+## 8.7 实现建议（非规范约束）
+
+`draft-ietf-sidrops-aspa-profile-21` 给出了一条 RP 侧建议：实现可对单个 `customer_as_id` 的 `provider_as_ids` 数量施加上界（例如 4,000~10,000），超过阈值时建议将该 `customer_as_id` 的所有 ASPA 视为无效并记录错误日志。`draft-ietf-sidrops-aspa-profile-21` §6。
+
--- a/specs/09_ghostbusters_gbr.md
+++ b/specs/09_ghostbusters_gbr.md
@@ -0,0 +1,87 @@
+# 09. Ghostbusters Record（GBR）
+
+## 9.1 对象定位
+
+Ghostbusters Record（GBR）是一个可选的 RPKI Signed Object，用于承载“联系人信息”（人类可读的联系渠道），以便在证书过期、CRL 失效、密钥轮换等事件中能够联系到维护者。RFC 6493 §1。
+
+GBR 由 CMS 外壳 + vCard 载荷组成：
+
+- 外壳：RFC 6488（更新：RFC 9589）
+- 载荷（payload）：RFC 6493 定义的 vCard profile（基于 RFC 6350 vCard 4.0 的严格子集）。RFC 6493 §5。
+
+## 9.2 原始载体与编码
+
+- 外壳：CMS SignedData DER（见 `05_signed_object_cms.md`）。RFC 6493 §6（引用 RFC 6488）。
+- eContentType：`id-ct-rpkiGhostbusters`，OID `1.2.840.113549.1.9.16.1.35`。RFC 6493 §6；RFC 6493 §9.1。
+- eContent：一个 OCTET STRING，其 octets 是 vCard 文本（vCard 4.0，且受 RFC 6493 的 profile 约束）。RFC 6493 §5；RFC 6493 §6。
+
+> 说明：与 ROA/MFT 这类“eContent 内部再 DER 解码为 ASN.1 结构”的对象不同，GBR 的 eContent 语义上就是“vCard 文本内容本身”（由 Signed Object Template 的 `eContent OCTET STRING` 承载）。RFC 6493 §6。
+
+## 9.3 vCard profile（RFC 6493 §5）
+
+GBR 的 vCard payload 是 RFC 6350 vCard 4.0 的严格子集，仅允许以下属性（properties）：
+
+- `BEGIN`：必须为第一行，值必须为 `BEGIN:VCARD`。RFC 6493 §5。
+- `VERSION`：必须为第二行，值必须为 `VERSION:4.0`。RFC 6493 §5（引用 RFC 6350 §3.7.9）。
+- `FN`：联系人姓名或角色名。RFC 6493 §5（引用 RFC 6350 §6.2.1）。
+- `ORG`：组织信息（可选）。RFC 6493 §5（引用 RFC 6350 §6.6.4）。
+- `ADR`：邮寄地址（可选）。RFC 6493 §5（引用 RFC 6350 §6.3）。
+- `TEL`：语音/传真电话（可选）。RFC 6493 §5（引用 RFC 6350 §6.4.1）。
+- `EMAIL`：邮箱（可选）。RFC 6493 §5（引用 RFC 6350 §6.4.2）。
+- `END`：必须为最后一行，值必须为 `END:VCARD`。RFC 6493 §5。
+
+额外约束：
+
+- `BEGIN`、`VERSION`、`FN`、`END` 必须包含。RFC 6493 §5。
+- 为保证可用性，`ADR`/`TEL`/`EMAIL` 三者中至少一个必须包含。RFC 6493 §5。
+- 除上述属性外，**其他属性 MUST NOT** 出现。RFC 6493 §5。
+
+## 9.4 解析规则（payload 语义层）
+
+输入：`RpkiSignedObject`。
+
+1) 解析 CMS 外壳，得到 `econtent_type` 与 `econtent_bytes`。RFC 6488 §3；RFC 9589 §4。  
+2) 要求 `econtent_type == 1.2.840.113549.1.9.16.1.35`。RFC 6493 §6。  
+3) 将 `econtent_bytes` 解析为 vCard 文本，并按 RFC 6493 §5 的 profile 校验（属性集合、必选项、行首/行尾约束）。RFC 6493 §5；RFC 6493 §7。  
+4) 通过校验后，将允许属性映射为 `GhostbustersVCard` 语义对象（见下）。
+
+## 9.5 抽象数据模型（接口）
+
+### 9.5.1 `GhostbustersObject`
+
+| 字段 | 类型 | 语义 | 约束/解析规则 | RFC 引用 |
+|---|---|---|---|---|
+| `signed_object` | `RpkiSignedObject` | CMS 外壳 | 外壳约束见 RFC 6488/9589 | RFC 6493 §6；RFC 6488 §3；RFC 9589 §4 |
+| `econtent_type` | `Oid` | eContentType | 必须为 `1.2.840.113549.1.9.16.1.35` | RFC 6493 §6 |
+| `vcard` | `GhostbustersVCard` | vCard 语义对象 | 由 eContent 文本解析并校验 profile | RFC 6493 §5；RFC 6493 §7 |
+
+### 9.5.2 `GhostbustersVCard`（vCard 4.0 profile）
+
+| 字段 | 类型 | 语义 | 约束/解析规则 | RFC 引用 |
+|---|---|---|---|---|
+| `raw_text` | `string` | 原始 vCard 文本 | 由 eContent bytes 解码得到；用于保留原文/诊断 | RFC 6493 §5-§7 |
+| `fn` | `string` | 联系人姓名/角色名 | `FN` 必须存在 | RFC 6493 §5 |
+| `org` | `optional[string]` | 组织 | `ORG` 可选 | RFC 6493 §5 |
+| `adrs` | `list[string]` | 邮寄地址（原始 ADR value） | 允许 0..N；至少满足“ADR/TEL/EMAIL 至少一项存在” | RFC 6493 §5 |
+| `tels` | `list[Uri]` | 电话 URI（从 TEL 提取的 `tel:` 等 URI） | 允许 0..N；至少满足“ADR/TEL/EMAIL 至少一项存在” | RFC 6493 §5 |
+| `emails` | `list[string]` | 邮箱地址 | 允许 0..N；至少满足“ADR/TEL/EMAIL 至少一项存在” | RFC 6493 §5 |
+
+> 说明：RFC 6493 并未要求 RP 必须完整解析 vCard 参数（例如 `TYPE=WORK`、`VALUE=uri`），因此此处将 `ADR`/`TEL`/`EMAIL` 建模为“足以联络”的最小语义集合；实现可在保留 `raw_text` 的同时按 RFC 6350 扩展解析能力。
+
+## 9.6 字段级约束清单（实现对照）
+
+- eContentType 必须为 `id-ct-rpkiGhostbusters`（OID `1.2.840.113549.1.9.16.1.35`），且该 OID 必须同时出现在 eContentType 与 signedAttrs.content-type。RFC 6493 §6（引用 RFC 6488）。
+- eContent 必须是 vCard 4.0 文本，且必须满足 RFC 6493 §5 的 profile：
+  - 第一行 `BEGIN:VCARD`；
+  - 第二行 `VERSION:4.0`；
+  - 末行 `END:VCARD`；
+  - 必须包含 `FN`；
+  - `ADR`/`TEL`/`EMAIL` 至少一个存在；
+  - 除允许集合外不得出现其他属性。RFC 6493 §5；RFC 6493 §7。
+
+## 9.7 与 EE 证书的语义约束（为后续验证准备）
+
+GBR 使用 CMS 外壳内的 EE 证书验证签名。RFC 6493 对该 EE 证书提出一条资源扩展约束：
+
+- 用于验证 GBR 的 EE 证书在描述 Internet Number Resources 时，必须使用 `inherit`，而不是显式资源集合。RFC 6493 §6（引用 RFC 3779）。
+