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

## D.1 概述

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` 在密码学层面强制约束，不依赖运营策略。

## D.2 治理结构：多方共治模型

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

### D.2.1 组织架构

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

### D.2.2 理事会（Board of Directors）

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

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

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

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

### D.2.3 技术委员会（Technical Committee）

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

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

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

### D.2.4 审计委员会（Audit Committee）

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

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

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

### D.2.5 运营团队（Operations Team）

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

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

## D.3 决策机制

### D.3.1 决策类型和要求

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

### D.3.2 投票流程

**重大决策投票流程**：

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

### D.3.3 透明度和问责

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

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

## D.4 Root CA 准入流程

详细的准入流程请参考：[Root_CA_准入流程.md](./Root_CA_准入流程.md)

**流程概览**：

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

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

## D.5 Root CA 退出流程

详细的退出流程请参考：[Root_CA_退出流程.md](./Root_CA_退出流程.md)

**退出类型**：

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

## D.6 管理局密钥管理

### D.6.1 管理局证书

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

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

### D.6.2 HSM 配置

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

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

### D.6.3 密钥轮换

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

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

## D.7 受信根证书列表管理

### D.7.1 列表格式

```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"
    }
  ]
}
```

### D.7.2 列表更新频率

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

### D.7.3 列表签名

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

## D.8 透明日志（Certificate Transparency）

### D.8.1 概述

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

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

### D.8.2 日志记录范围

| 操作类型 | 触发条件 | 记录内容 |
|---------|---------|---------|
| 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 | 新旧公钥、过渡计划、生效时间 |

### D.8.3 日志条目格式

```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..."
}
```

### D.8.4 日志服务架构

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

### D.8.5 签名日志证明（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 是否存在

### D.8.6 监控机制

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

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

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

### D.8.7 日志服务运营要求

- **独立性**：日志服务必须由独立于管理局的组织运营（至少 1 个镜像）
- **可用性**：主日志服务 99.9% 可用性，镜像服务 99% 可用性
- **保留期**：日志条目永久保留
- **公开接口**：提供公开的 REST API，支持查询、验证和订阅

## D.9 监督和合规

### D.9.1 Root CA 年度审计

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

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

### D.9.2 安全事件报告

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

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

### D.9.3 合规检查

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

**不合规处理**：
- 轻微违规：警告，要求整改
- 严重违规：暂停或吊销

## D.10 财务和运营

### D.10.1 资金来源

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

### D.10.2 预算分配

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

### D.10.3 财务透明

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

## D.11 应急响应

### D.11.1 应急场景

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

### D.11.2 应急联系

- 7x24 小时值班电话
- 应急邮件列表
- 安全事件报告表单

## D.12 附录

### D.12.1 相关文档

- [Root CA 准入流程](./Root_CA_准入流程.md)
- [Root CA 退出流程](./Root_CA_退出流程.md)
- [Issuer CA 申请流程](./Issuer_CA_申请流程.md)
- [AUN 证书策略（Certificate Policy）](./AUN_证书策略.md)

### D.12.2 联系方式

- 官方网站：https://authority.aun.network
- 邮件列表：governance@aun.network
- GitHub：https://github.com/aun-network/governance
- 应急联系：security@aun.network
