AUN 根证书管理局治理机制

概述

AUN 根证书管理局（AUN Root CA Authority）是 AUN 网络的信任根，负责维护受信根证书列表，管理 Root CA 的准入、监督和退出。

本文档详细说明管理局的治理结构、决策机制、准入流程、退出流程和吊销机制。

四级证书体系概览

AUN 采用四级证书体系，Root CA 的职责严格限定为签发 Registry CA：

Root CA (离线, pathlen:2) → 只签发 Registry CA
  └─ Registry CA (在线, pathlen:1) → 只签发 Issuer CA
      └─ Issuer CA (在线, pathlen:0) → 只签发 Agent 终端证书
          └─ Agent 证书 (终端实体)

每级 CA 的签发范围通过 pathlen 在密码学层面强制约束，不依赖运营策略。

治理结构：多方共治模型

AUN 根证书管理局采用**多方共治（Multi-Stakeholder Governance）**模型，类似 ICANN、W3C 或欧盟的治理结构，确保决策的公正性和透明度。

组织架构

┌─────────────────────────────────────────────────────────┐
│           AUN 根证书管理局治理结构                         │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  理事会（Board of Directors）                            │
│  ├─ 技术社区代表（2 席）                                  │
│  ├─ 商业组织代表（2 席）                                  │
│  ├─ 学术机构代表（1 席）                                  │
│  ├─ 政府/监管机构代表（1 席，可选）                        │
│  └─ 独立专家（1 席）                                      │
│                                                         │
│  技术委员会（Technical Committee）                        │
│  ├─ 制定证书策略（Certificate Policy）                    │
│  ├─ 审查 Root CA 技术合规性                              │
│  └─ 评估安全事件和应急响应                                │
│                                                         │
│  审计委员会（Audit Committee）                            │
│  ├─ 监督 Root CA 年度审计                                │
│  ├─ 审查安全事件报告                                      │
│  └─ 评估管理局自身的合规性                                │
│                                                         │
│  运营团队（Operations Team）                             │
│  ├─ 管理受信根证书列表                                    │
│  ├─ 处理 Root CA 申请和吊销                              │
│  ├─ 维护管理局 HSM 和密钥                                │
│  └─ 发布列表更新和公告                                    │
│                                                         │
└─────────────────────────────────────────────────────────┘

理事会（Board of Directors）

职责：

制定管理局的战略方向和政策
批准 Root CA 的准入和退出
监督技术委员会和审计委员会的工作
处理重大安全事件和应急响应
批准年度预算和财务报告

组成：

技术社区代表（2 席）：来自开源社区、标准化组织、技术公司
商业组织代表（2 席）：来自运营 Root CA 的商业组织
学术机构代表（1 席）：来自大学或研究机构的密码学/安全专家
政府/监管机构代表（1 席，可选）：来自相关政府部门或监管机构
独立专家（1 席）：独立的 PKI/安全专家，无利益冲突

任期：

每届任期 3 年，可连任一次
每年轮换 1/3 成员，确保连续性

会议：

定期会议：每季度一次
临时会议：应急事件或重大决策时召开

技术委员会（Technical Committee）

职责：

制定和维护 AUN 证书策略（Certificate Policy, CP）
审查 Root CA 的技术合规性
评估新技术和算法的引入
制定安全最佳实践指南
评估安全事件和应急响应

组成：

5-7 名 PKI/密码学/安全专家
由理事会任命，任期 2 年

工作方式：

每月例会
通过邮件列表和 GitHub 协作
技术文档公开发布（草案和最终版）

审计委员会（Audit Committee）

职责：

监督 Root CA 的年度审计
审查安全事件报告
评估管理局自身的合规性
确保透明度和问责制

组成：

3-5 名审计专家（财务审计 + 安全审计）
由理事会任命，任期 2 年
必须独立于 Root CA 运营商

工作方式：

每季度审查 Root CA 审计报告
年度审查管理局自身的运营
审计报告公开发布（敏感信息除外）

运营团队（Operations Team）

职责：

日常运营管理
维护管理局 HSM 和密钥
处理 Root CA 申请和吊销
发布受信根证书列表更新
提供技术支持

组成：

全职运营人员（3-5 人）
7x24 小时值班制度
多人授权机制（5/7 多签）

决策机制

决策类型和要求

决策类型	决策者	投票要求	公示期	示例
重大决策	理事会	2/3 多数	30 天	Root CA 准入/吊销、证书策略重大修改
技术决策	技术委员会 + 理事会批准	简单多数	14 天	新算法引入、技术规范更新
应急响应	运营团队 + 事后报告	无需投票	无	紧急吊销、安全事件响应
日常运营	运营团队	无需投票	无	列表更新、技术支持

投票流程

重大决策投票流程：

提案提交
  │
  │ 1. 提案公示（30 天）
  │    - 发布到公开邮件列表
  │    - 接受社区反馈
  ↓
技术委员会审查
  │
  │ 2. 技术评估（14 天）
  │    - 评估技术可行性
  │    - 评估安全影响
  │    - 提交评估报告
  ↓
理事会投票
  │
  │ 3. 投票（7 天）
  │    - 每位理事会成员一票
  │    - 需 2/3 多数通过（至少 5/7）
  │    - 投票记录公开
  ↓
执行
  │
  │ 4. 执行决策
  │    - 运营团队执行
  │    - 发布公告
  │    - 更新文档

透明度和问责

公开信息：

所有理事会会议纪要（敏感信息除外）
所有投票记录和理由
年度财务报告
年度审计报告
Root CA 准入/退出公告

社区参与：

公开邮件列表接受反馈
年度社区会议
GitHub 仓库接受 Issue 和 PR

Root CA 准入流程

详细的准入流程请参考：Root_CA_准入流程.md

流程概览：

申请提交（第 1 周）
技术审查（第 2-9 周）
合规审查（第 10-13 周）
理事会投票（第 14 周）
加入列表（第 15 周）

准入条件：

HSM 存储私钥（FIPS 140-2 Level 3+）
通过 WebTrust for CAs 或等效审计
签署 AUN 根证书互信协议
至少 2 年 CA 运营经验
具备签发和运营 Registry CA 的能力

Root CA 退出流程

详细的退出流程请参考：Root_CA_退出流程.md

退出类型：

类型	触发条件	过渡期	决策要求	迁移支持
主动退出	Root CA 申请	90-180 天	简单多数	Root CA 负责
合规吊销	违反证书策略	30-90 天	2/3 多数	管理局协助
紧急吊销	私钥泄露	立即	1/2 多数	管理局主导

管理局密钥管理

管理局证书

管理局证书（AUN Root CA Authority Certificate）
├── 自签名（没有更上层的签发者）
├── P-384 密钥对，离线 HSM 中生成
├── 用途：签名受信根证书列表（不签发下级证书）
├── 公钥：硬编码在所有 AUN 客户端中
├── 多人授权：签名操作需 5/7 理事会成员授权
└── 有效期：30+ 年

注意：管理局证书仅用于签名受信根证书列表，不参与证书签发链。
证书签发链为：Root CA → Registry CA → Issuer CA → Agent

HSM 配置

�M 要求：

FIPS 140-2 Level 4 或 Common Criteria EAL 5+
物理隔离，存储在安全设施中
多人授权（5/7 多签）
完整的审计日志

密钥生成仪式：

在公证人见证下进行
全程录像记录
多方参与（至少 7 人）
生成报告公开发布

密钥轮换

采用 KSK Rollover 机制（类似 DNSSEC）：

旧密钥有效期内
  │
  │ 1. 生成新密钥对（密钥生成仪式）
  │ 2. 用旧私钥签名声明：
  │    {"new_authority_key": "<新公钥>", "effective_from": "2036-01-01"}
  ↓
客户端
  │
  │ 3. 验证旧签名
  │ 4. 将新公钥加入本地信任锚
  ↓
过渡期（1-2 年）
  │
  │ 5. 新旧两个公钥均可验签
  │ 6. 逐步迁移到新密钥
  ↓
旧密钥退役
  │
  │ 7. 停止使用旧密钥
  │ 8. 销毁旧私钥（HSM 中删除）

受信根证书列表管理

列表格式

json

{
  "version": 2,
  "issued_at": "2026-03-15T10:00:00Z",
  "next_update": "2026-03-16T10:00:00Z",
  "authority_signature": "MEUCIQDx...",
  "root_cas": [
    {
      "id": "root-ca-001",
      "name": "AUN Root CA A",
      "organization": "Organization A",
      "certificate": "-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----",
      "fingerprint_sha256": "a1b2c3d4...",
      "valid_from": "2020-01-01T00:00:00Z",
      "valid_until": "2050-01-01T00:00:00Z",
      "added_at": "2020-01-01T00:00:00Z",
      "status": "active",
      "crl_url": "http://crl.rootca-a.example/root.crl",
      "ocsp_url": "http://ocsp.rootca-a.example"
    }
  ]
}

列表更新频率

定期更新：每 24 小时发布一次（即使无变化）
紧急更新：安全事件时立即发布
客户端检查：建议每 24 小时检查一次

列表签名

使用管理局私钥签名（ECDSA P-384）
需 5/7 理事会成员授权
签名操作在离线 HSM 中进行
完整的审计日志

公开发布与下载端点

AUN 根证书管理局必须运行独立的公开网站，作为受信根证书列表的权威发布源。该网站不属于任何单个 Issuer 或 Gateway，主要发布 Root CA 准入/退出公告、审计报告、CT 日志入口、管理局证书/公钥以及最新受信根证书列表版本信息。

规范端点：

类型	URL	说明
管理局官网	`https://trust.aun.network/`	人类可读的公告、审计、治理和透明日志入口
权威列表端点	`https://trust.aun.network/.well-known/aun/trust-roots.json`	管理局签名的受信根证书列表，客户端更新信任锚时的首选来源
Gateway 镜像端点	`https://gateway.{issuer}/pki/trust-roots.json`	Issuer/Gateway 缓存并公开分发同一份签名列表，不要求鉴权
Issuer PKI 列表端点	`https://pki.{issuer}/trust-root.json`	Issuer 泛域名 PKI 服务公开分发同一份签名列表，不要求鉴权
Issuer Root CA 端点	`https://pki.{issuer}/root.crt`	下载该 Issuer 证书链锚定的 Root CA PEM 证书，不要求鉴权

Gateway 镜像端点和 pki.{issuer} 泛域名端点用于提高可用性和就近下载能力，但不改变信任边界。客户端从任何镜像获取列表时，必须像处理权威端点一样验证 authority_signature；不能因为信任某个 Gateway 或 Issuer PKI 服务而直接信任其返回的 root_cas。

https://pki.{issuer}/root.crt 仅用于获取证书材料。客户端导入前必须确认该证书是自签 Root CA，且其 SHA-256 指纹存在于已验签的受信根证书列表中；否则不得将其加入本地信任锚。

为兼容早期实现，Gateway 可以继续提供 https://gateway.{issuer}/pki/trust-roots 作为 trust-roots.json 的等价别名，并可以提供 https://gateway.{issuer}/pki/trust-root.json、https://gateway.{issuer}/pki/root.crt 作为 pki.{issuer} 端点的路径别名。同类端点返回的内容语义必须一致。

客户端更新规则

客户端的初始信任来自 SDK 内置的管理局证书/公钥或随 SDK 发布的初始受信根列表。更新流程必须遵循：

从权威列表端点下载 trust-roots.json；不可达时，可从 Gateway 镜像端点或 pki.{issuer}/trust-root.json 下载。
使用本地已信任的管理局公钥验证 authority_signature。
校验 issued_at、next_update、version 单调性和每个 Root CA 的 fingerprint_sha256。
仅在签名和结构校验通过后，才更新本地信任锚。
如果权威端点和镜像端点返回不同版本，客户端应优先接受签名有效且 version 更高、时间窗口有效的列表；发现异常时记录安全告警。
按 issuer 更新单个 root.crt 时，必须先验证该 Root CA 指纹存在于已验签列表中，再写入本地信任根 bundle。

透明日志（Certificate Transparency）

概述

AUN 网络引入透明日志（Certificate Transparency, CT）机制，确保所有关键证书操作（Root CA 准入/退出/吊销、Issuer CA 签发/吊销、受信列表变更）都有公开可审计的记录。

核心原则：

只可追加（Append-Only）：日志条目只能追加，不能修改或删除
公开可验证：任何人都可以审计日志，验证操作的合法性
Merkle 树结构：使用 Merkle 树保证日志完整性，篡改任何条目都会被发现
多镜像冗余：至少运行 2 个独立的日志镜像，防止单点故障

服务边界

服务边界要求：

CA 服务负责在证书写操作成功后追加 CT 条目，并提供内部只读查询能力。
CA 服务不得直接暴露公网 HTTP CT 端点。
ct.{issuer} 是 Issuer CT 的稳定公开访问面，只能提供公开只读查询路径。
CT 写入接口不得经由 ct.{issuer} 暴露，只能由 CA、Registry CA 或治理服务通过内部调用完成。
CT 服务的公开 URL、响应格式和验证规则必须保持兼容。
公开 CT 响应不得包含内部审计字段，例如手机号、客户端 IP、私钥摘要、内部操作者标识等。

日志记录范围

操作类型	触发条件	记录内容
Root CA 准入	理事会投票通过	Root CA 证书、投票记录、审查报告摘要
Root CA 退出	主动退出或吊销	退出原因、投票记录、生效时间
Root CA 吊销	紧急吊销	吊销原因、操作者、吊销时间
Issuer CA 签发	Registry CA 签发 Issuer CA 证书	Issuer CA 证书、签发 Registry CA、验证报告摘要
Issuer CA 吊销	私钥泄露或违规	吊销原因、吊销时间、影响范围
Registry CA 签发	Root CA 签发 Registry CA 证书	Registry CA 证书、签发 Root CA
Registry CA 吊销	私钥泄露或违规	吊销原因、吊销时间、影响范围
受信列表更新	列表内容变更	变更内容、新列表哈希、管理局签名
管理局密钥轮换	KSK Rollover	新旧公钥、过渡计划、生效时间
Agent 证书签发	Issuer CA 签发终端或内置服务证书	AID、证书序列号、证书 SHA-256、曲线、签发时间
Agent 证书续期	Issuer CA 为同一公钥续期	AID、新旧证书序列号、新证书 SHA-256
Agent 证书换钥	Issuer CA 轮换终端密钥	AID、新旧证书序列号、新公钥 SHA-256、旧证书状态
Agent 证书吊销	Issuer CA 吊销终端证书	AID、证书序列号、吊销原因、吊销时间

Root/Registry/Issuer CA 准入和吊销的详细流程见附录 E/F。Issuer 本地 Agent 证书写操作的 CT 记录要求见附录 F。

日志条目格式

json

{
  "log_id": "ct-2026-03-15-00001",
  "timestamp": "2026-03-15T10:00:00Z",
  "operation": "root_ca_add",
  "subject": {
    "id": "root-ca-003",
    "name": "AUN Root CA C",
    "fingerprint_sha256": "i9j0k1l2..."
  },
  "details": {
    "vote_result": "6/7 赞成",
    "vote_date": "2026-03-14",
    "effective_date": "2026-03-15T10:00:00Z"
  },
  "operators": ["operator1", "operator2"],
  "previous_hash": "sha256:a1b2c3d4...",
  "entry_hash": "sha256:e5f6g7h8...",
  "merkle_proof": {
    "tree_size": 42,
    "leaf_index": 41,
    "hashes": ["sha256:...", "sha256:..."]
  },
  "log_signature": "MEUCIQDx..."
}

Issuer 本地 Agent 证书 CT 条目可使用同一外层结构，operation 取值为 agent_cert_issue、agent_cert_renew、agent_cert_rekey 或 agent_cert_revoke，subject 至少包含 aid、serial、cert_sha256 和 issuer。

公开查询端点

Issuer CT 的公开端点由 ct.{issuer} 承载，不要求鉴权：

方法	URL	说明
GET	`https://ct.{issuer}/sth`	获取最新签名树头（STH）
GET	`https://ct.{issuer}/entries?start=0&limit=100`	分页查询公开 CT 条目
GET	`https://ct.{issuer}/entries/{log_id}`	按日志 ID 查询单条公开 CT 条目
GET	`https://ct.{issuer}/certs/{serial}`	按证书序列号查询对应 CT 条目
GET	`https://ct.{issuer}/proof/{tree_size}/{log_id}`	获取指定树大小下的 Merkle inclusion proof

start 从 0 开始计数，limit 建议默认 100，服务端可以设置最大值。公开响应只能包含公开 CT 字段；如实现内部审计扩展，必须通过独立的鉴权后台接口访问，不能从 ct.{issuer} 返回。

签名树头（STH）

json

{
  "sth_version": 1,
  "log_id": "sha256:<日志服务公钥哈希>",
  "tree_size": 42,
  "root_hash": "sha256:ab12...",
  "timestamp": 1710489600000,
  "hash_algorithm": "sha256",
  "signature_algorithm": "ecdsa-p384-sha384",
  "signature": "MEUCIQDx..."
}

STH 用于证明某一时刻日志树的大小和根哈希。监控方应定期拉取 STH，检查树大小单调增长，并结合 inclusion proof 验证条目未被删除或篡改。

日志服务架构

┌──────────────────────────────────────────────┐
│              CT 日志服务架构                    │
├──────────────────────────────────────────────┤
│                                              │
│  提交方（管理局运营团队）                       │
│    │                                         │
│    │ 提交日志条目                              │
│    ↓                                         │
│  CT 日志服务（主节点）                          │
│    ├─ 验证条目格式和签名                       │
│    ├─ 追加到 Merkle 树                        │
│    ├─ 返回签名日志证明（SCT）                  │
│    └─ 同步到镜像节点                           │
│         │                                    │
│         ↓                                    │
│  CT 日志镜像（≥ 2 个独立运营）                 │
│    ├─ 镜像 A（由技术社区运营）                  │
│    └─ 镜像 B（由独立第三方运营）                │
│                                              │
│  监控方（任何人）                               │
│    ├─ 订阅日志更新                             │
│    ├─ 验证 Merkle 树一致性                     │
│    └─ 检测异常操作并告警                        │
│                                              │
└──────────────────────────────────────────────┘

签名日志证明（SCT）

每次写入 CT 日志后，日志服务返回 签名日志证明（Signed Certificate Timestamp, SCT）：

json

{
  "sct_version": 1,
  "log_id": "sha256:<日志服务公钥哈希>",
  "timestamp": 1710489600000,
  "entry_hash": "sha256:e5f6g7h8...",
  "signature": "MEUCIQDx..."
}

SCT 用途：

Root CA 准入/退出：SCT 附加到受信根证书列表的变更记录中
Issuer CA 签发：SCT 嵌入证书的扩展字段（X.509 v3 extension）或作为独立证明提供
Registry CA 签发/吊销：SCT 附加到 Registry CA 证书记录中
客户端可选验证：客户端在验证证书链时，可额外检查 SCT 是否存在

监控机制

任何参与方都可以运行日志监控程序：

一致性验证：定期请求 Merkle 树根哈希，验证日志未被篡改
新条目监控：订阅新日志条目，检测未经授权的操作
跨镜像比对：对比多个镜像的日志内容，发现不一致

告警场景：

出现未经理事会投票的 Root CA 准入/退出
日志条目被修改或删除（Merkle 树一致性校验失败）
不同镜像之间的日志不一致
日志服务长时间不可用

日志服务运营要求

独立性：日志服务必须由独立于管理局的组织运营（至少 1 个镜像）
可用性：主日志服务 99.9% 可用性，镜像服务 99% 可用性
保留期：日志条目永久保留
公开接口：通过 ct.{issuer} 提供公开 REST API，支持查询和验证；订阅能力为可选扩展

监督和合规

Root CA 年度审计

审计要求：

每年必须通过 WebTrust for CAs 或等效审计
审计报告必须公开发布
审计委员会审查审计报告

审计失败处理：

第一次失败：警告，要求 90 天内整改
第二次失败：暂停，停止签发新证书
第三次失败：吊销，从受信列表移除

安全事件报告

报告要求：

Root CA 必须在 24 小时内报告重大安全事件
包括：私钥泄露、误签发、系统入侵等
Registry CA 相关安全事件同样适用上述报告要求
提交事件报告和应急响应计划

处理流程：

运营团队评估风险
技术委员会调查
理事会决定是否吊销
事件报告公开发布（敏感信息除外）

合规检查

定期检查：

每季度检查 CRL/OCSP 服务可用性
每年检查密钥管理流程
随机抽查签发的证书

不合规处理：

轻微违规：警告，要求整改
严重违规：暂停或吊销

财务和运营

资金来源

Root CA 年费（根据签发证书数量）
捐赠和赞助
技术服务收入

预算分配

运营团队薪资：40%
HSM 和基础设施：30%
审计和合规：20%
社区活动和推广：10%

财务透明

年度财务报告公开发布
审计委员会审查财务
接受独立财务审计

应急响应

应急场景

场景	响应时间	决策者	处理流程
Root CA 私钥泄露	立即	运营团队 + 理事会	紧急吊销 Root CA 及其下属 Registry CA
Registry CA 私钥泄露	立即	运营团队 + 理事会	紧急吊销 Registry CA，Root CA 签发新 Registry CA
管理局私钥泄露	立即	理事会	密钥轮换 + 全网更新
大规模误签发	24 小时	技术委员会 + 理事会	调查 + 吊销
Root CA 服务中断	24 小时	运营团队	协助恢复或迁移

AUN 根证书管理局治理机制 ​

概述 ​

四级证书体系概览 ​

治理结构：多方共治模型 ​

组织架构 ​

理事会（Board of Directors） ​

技术委员会（Technical Committee） ​

审计委员会（Audit Committee） ​

运营团队（Operations Team） ​

决策机制 ​

决策类型和要求 ​

投票流程 ​

透明度和问责 ​

Root CA 准入流程 ​

Root CA 退出流程 ​

管理局密钥管理 ​

管理局证书 ​

HSM 配置 ​

密钥轮换 ​

受信根证书列表管理 ​

列表格式 ​

列表更新频率 ​

列表签名 ​

公开发布与下载端点 ​

客户端更新规则 ​

透明日志（Certificate Transparency） ​

概述 ​

服务边界 ​

日志记录范围 ​

日志条目格式 ​

公开查询端点 ​

签名树头（STH） ​

日志服务架构 ​

签名日志证明（SCT） ​

监控机制 ​

日志服务运营要求 ​

监督和合规 ​

Root CA 年度审计 ​

安全事件报告 ​

合规检查 ​

财务和运营 ​

资金来源 ​

预算分配 ​

财务透明 ​

应急响应 ​

应急场景 ​

应急联系 ​

附录 ​

相关文档 ​

联系方式 ​

AUN 根证书管理局治理机制

概述

四级证书体系概览

治理结构：多方共治模型

组织架构

理事会（Board of Directors）

技术委员会（Technical Committee）

审计委员会（Audit Committee）

运营团队（Operations Team）

决策机制

决策类型和要求

投票流程

透明度和问责

Root CA 准入流程

Root CA 退出流程

管理局密钥管理

管理局证书

HSM 配置

密钥轮换

受信根证书列表管理

列表格式

列表更新频率

列表签名

公开发布与下载端点

客户端更新规则

透明日志（Certificate Transparency）

概述

服务边界

日志记录范围

日志条目格式

公开查询端点

签名树头（STH）

日志服务架构

签名日志证明（SCT）

监控机制

日志服务运营要求

监督和合规

Root CA 年度审计

安全事件报告

合规检查

财务和运营

资金来源

预算分配

财务透明

应急响应

应急场景

应急联系

附录

相关文档

联系方式