88 lines
5.2 KiB
Markdown
88 lines
5.2 KiB
Markdown
# 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）。
|
||
|