AIC 证书草案中文对照版

说明：本文档是 draft-wei-aic-identity-cert-00（英文原版）的 中文对照阅读版，仅供作者审阅和内部交流使用，不是 IETF 提交版本。正式文本、章节编号、ASN.1 模块和表格均以英文原版为准。原文：draft-wei-aic-identity-cert-00.md

标题：AI Agent 身份证书（AIC）X.509 v3 扩展

缩写：AIC Certificate

文档名：draft-wei-aic-identity-cert-00

类别：Experimental（实验性）

提交方式：独立提交（independent）

作者：Jijie Wei（个人），pki@varwof.com，https://varwof.com

知识产权：trust200902

摘要

本文档定义了用于 X.509 v3 证书的 AI Agent 身份证书（AIC）扩展。 AIC 扩展将 AI Agent 的密码学身份与自然人（主体，principal）绑定，提供可支持将 AI 自主行为归因于主体的密码学证据。本规范有意将密码学委托与授权语义分离：AIC 定义 Agent 与主体之间的密码学绑定，而所有能力与策略语义由厂商、行业或监管机构在外部定义。该扩展使用分配给文档作者组织的 IANA 私有企业号（PEN）66257 标识。

AIC 扩展承载：Agent 身份字段（agentId、delegationMode）、将 Agent 与授权主体关联的主体标识（principalUid）、基于容器的能力声明、授权边界约束，以及带防重放保护的委托授权证据。配套的 PrincipalAuthorization 扩展锚定主体侧的能力授予声明与委托策略。 authorizationConstraints 容器提供可离线验证的执行边界（IP 范围、时间窗口）。可扩展框架允许承载厂商特定与用户特定的元数据。

本文档规定 ASN.1 模块、OID 注册、字段语义、委托模型和可扩展框架，并讨论在受监管企业环境中部署的安全考量。

引言

问题陈述

现有的 X.509 公钥证书（见 [RFC5280] 的剖面）主要通过”可分辨名称（DN）与公钥之间的密码学签名绑定”来认证身份。授权被有意留在证书之外：依赖方通过外部 IAM 策略、OAuth 作用域、RBAC 数据库或策略引擎，在 TLS 连接建立之后执行访问控制。

自主 AI Agent 提出了现有证书剖面无法满足的新需求。当 Agent 代表主体行事时，依赖方还需要回答以下附加问题：

谁委派了这一授权？
授权了哪些操作？
Agent 可以在哪些约束下运行？
授权有效期多长？
谁对所执行的行为负责？

这些问题无法仅靠身份回答。它们需要在证书内部提供一种标准化机制，来表达委托关系、能力约束、授权边界和问责链。

本文档定义了填补这一空白的 X.509 证书扩展。AI Agent 身份证书（AIC）扩展在单张证书中编码：Agent 身份、主体绑定、能力声明、委托模式、授权边界约束和密码学委托授权。配套的 PrincipalAuthorization 扩展锚定主体侧的能力授予声明、授权约束和委托策略。

AIC 旨在补充现有身份基础设施：

SPIFFE/WIMSE 通过 SAN URI 标识工作负载。AIC 在工作负载身份之上增加能力容器、主体绑定和会话控制。
OAuth 2.0 与基于 JWT 的授权（[RFC6749]）提供在线令牌交换。 AIC 允许在 TLS 握手期间做离线授权决策，无需查询外部身份提供方。
标准 X.509 扩展（证书策略、扩展密钥用法）表达预期用途，但不表达委托关系或细粒度能力约束。

AIC 面向以下部署场景：

AIC 面向复用现有 PKI 基础设施（企业 CA、HSM、智能卡）的部署；
新兴监管框架要求对自主行为进行可追溯到责任主体的密码学追踪；
离线或气隙环境要求证书自包含授权，无需外部数据库查询；
短生命周期的工作负载身份需要补充可归因的授权元数据。

本文档规定 AIC 的数据模型、证书剖面和验证要求。部署特定策略、实现细节和性能特性不在本规范范围内。

范围

本文档分为三类内容：

规范性（核心）：以下章节为规范性内容：委托模型、证书剖面（数据模型）、AIC 扩展定义、验证流程和 PrincipalAuthorization 扩展，包括其 ASN.1 定义。声称符合 AIC 的实现必须遵循这些章节。

参考性（剖面）：部署模型章节描述推荐的部署模式和网关行为。它们不是 AIC 合规所必需的，但代表最佳实践。

参考性（实现）：实现状态章节描述参考实现，作为实现指导和互操作示例。

核心规范内容有意将密码学委托与授权语义分离：AIC 定义 Agent 与主体之间的密码学绑定，而能力与策略语义在外部定义。

                     AIC 架构

   +----------------+      +------------------+
   |    主体        |      |     Agent        |
   | (用户/组织)    |      | (AI Agent)       |
   | PrincipalAuth  |      | AIC 证书         |
   | 证书           |      | 身份 +           |
   |                |      | 能力 +           |
   +-------+--------+      | 委托模式         |
           |               +--------+---------+
           | 授权                    |
           | 签名                    |
           +-------+-----------------+
                   |
                   v
         +---------------------+
         |    网关 (PEP)       |
         |  1. 验证证书链      |
         |  2. 解析 AIC        |
         |  3. 验证 DA         |
         |  4. 检查 PA 约束    |
         |  5. 检查 AIC 约束   |
         |  6. 检查能力        |
         |  7. 应用策略        |
         |  8. 决策            |
         +---------+-----------+
                   |
         +---------v-----------+
         |      目标           |
         |   资源 / API        |
         +---------------------+

设计原则

本规范由七个正交的关注点指导，每个关注点由独立层次处理：

关注点	层次	问题
身份	AgentIdentity	“你是谁？”
授权	PrincipalAuthorization	“谁授权你？”
能力	Capability（容器）	“你被允许做什么？”
委托	DelegationPolicy	“你被允许如何行事？”
约束	authorizationConstraints	“在什么边界内？”
执行	网关	“该请求现在是否被允许？”
信任	X.509（PKI）	“该证书可信吗？”
传输	TLS	“该通道安全吗？”

AIC 不重新定义信任、传输或密码学。它通过引入三个正交概念来补充 X.509：Agent 身份、主体授权和能力容器。信任仍在 PKI 层，传输仍在 TLS 层，执行仍在网关层。

AIC 定义授权相关信息的表示与密码学绑定（Agent 身份、主体绑定、能力容器、约束容器和委托证据）。它不定义通用授权语言：操作是否被允许由能力方案和部署策略决定，而非由 AIC 扩展本身决定。

需求语言

本文档中的关键词 “MUST”、“MUST NOT”、“REQUIRED”、“SHALL”、 “SHALL NOT”、“SHOULD”、“SHOULD NOT”、“RECOMMENDED”、 “NOT RECOMMENDED”、“MAY” 和 “OPTIONAL” 在全部大写出现时，按照 BCP 14 [RFC2119] [RFC8174] 解释，如下所示。

本文档通篇使用以下术语：

AIC：: AI Agent 身份证书扩展——本文档定义的 X.509 v3 扩展。
Agent：: 就本文档而言，AI Agent 是能够以不同程度自主性代表主体执行操作的软件或硬件实体。
主体（Principal）：: 授权 Agent 代表其行事的自然人或者组织实体。主体是否对 Agent 执行的行为承担法律责任，由适用法律和部署策略决定，超出本规范范围。
委托模式（Delegation Mode）：: 出于归因和授权目的，Agent 与其主体之间由协议定义的关系。这些模式在适用法律下的解释超出本规范范围。在授权模式（authorized）下，Agent 以自身身份并在主体同意下行事；在代表模式（representative）下， Agent 在委托权限范围内代表主体行事。
能力（Capability）：: Agent 被授权执行的协议级操作容器，由方案标识符和方案内的能力标识符定义。
能力方案（Capability Scheme）：: 由方案标识符（schemeId）标识、定义能力语义的系统。网关按 schemeId 将能力评估路由到对应方案插件。
凭证包（Credential Bundle）：: Agent 在 TLS 握手期间出示的证书集合，包括 Agent 证书链和主体证书。
DelegationAuthorization：: AIC 扩展内承载的密码学证据，证明主体已授权该 Agent。包含对 DelegationAuthTBS 结构的数字签名。
DelegationAuthTBS：: 待签名结构（To-Be-Signed），其 DER 编码由主体私钥签名，生成 DelegationAuthorization。
PrincipalAuthorization：: 主体证书中携带的配套 X.509 扩展（OID 1.3.6.1.4.1.66257.1.2），声明授予、授权约束和委托策略。
authorizationConstraints：: AIC 与 PrincipalAuthorization 内的可选容器，定义授权边界条件（IP 范围、并发限制、时间窗口）。约束在 TLS 握手期间离线求值。
OID：: 对象标识符——用于标识 X.509 标准中对象的全局唯一整数序列。
PEN：: 私有企业号——IANA 分配给组织在 OID 空间中私有使用的全局唯一标识符。
SPKI：: 主体公钥信息——[RFC5280] 第 4.1.2.7 节定义的 ASN.1 结构，包含公钥算法和主体公钥。

委托模型

委托模式

定义两种委托模式：

授权模式（默认）：Agent 以自身身份行事。审计日志将 Agent 证书的 agentId 记录为行为者（actor），principalUid 标识授权主体。CA 在签发时将 Agent 声明的能力与主体的 PrincipalAuthorization.grants 比对，并将结果能力集锁定进证书。授权模式下，网关运行时不再执行额外的 P_grants 超集检查。因此授权模式提供快照式授权语义：签发后主体的授予变化不影响已签发证书的能力集。

代表模式：Agent 在委托权限范围内代表主体行事。审计日志将 principalUid 记录为行为者，agentId 记录为执行者。代表模式是最小凭证包模型的例外：它要求 TLS 握手期间出示的凭证包中包含主体证书及其 PrincipalAuthorization 扩展。无法提供完整凭证包的部署必须使用授权模式。Agent 声明的能力必须在签发时（CA 验证）和运行时（网关验证）都是主体授予（grants）的子集，因为主体权限可能在 Agent 证书生命周期内发生变化。

安全包络模型

本规范使用一种安全包络启发式：减小委托权限范围或缩短凭证生命周期，可以降低凭证被攻破时的潜在暴露面。

授权模式选择窄范围 x 较长有效期——主体在签发时选择能力，能力集锁定进证书，证书有效期最长 24 小时并自动续期。

代表模式选择宽范围 x 较短有效期——Agent 可行使主体的全部权限（P_grants），但证书生命周期短，且运行时对每次操作执行 P_grants 交集验证。

权限交集

授权模型是主体授予与 Agent 能力的交集：

P_effective = P_grants (AND) C_agent

其中 P_grants 是主体声明的能力授予（PrincipalAuthorization.grants）， C_agent 是 Agent 声明的能力集（AIC.capabilities）。仅当操作同时属于两个集合时才被授权。

授权模式下，C_agent 单独作为有效能力集（P_grants 交集已在签发时由 CA 验证并锁定进证书）。代表模式下，交集在运行时对每次操作计算。

网关本地运行时策略（T_policy）——速率限制、超时、路由等部署侧控制—— 是依赖方应用的额外执行层。它不是本规范定义的授权模型的一部分，不得与 P (AND) C 授权交集混淆。

多级委托

单层委托（Principal -> Agent，chainDepth = 0）是默认且推荐的部署模式。当部署确有需求时，可以支持深度为 1 的委托链（Principal -> Agent -> sub-Agent，chainDepth = 1），此时委托 Agent 为下级 Agent 签署 DelegationAuthorization：

chainDepth = 0（默认）：主体到 Agent 的直接委托（Principal -> Agent）。
chainDepth = 1（可选）：额外一级（Principal -> Agent -> sub-Agent），由委托 Agent 为下级 Agent 签署 DelegationAuthorization。

链的每一级产生一个由委托者私钥签署的独立 DelegationAuthorization，能力沿链递归求交。链深度由 DelegationDepthControl 扩展承载，含 chainDepth 和 maxDepth 字段。任何链中 chainDepth 不得超过 maxDepth。

不建议使用深度超过 1 的链。作为最佳实践，部署不应允许 chainDepth > 1：每增加一级都会增加归责模糊性（中间 Agent 的法律地位和审计行为者语义）、扩大攻击面并增大凭证包体积。本规范的问责模型锚定在链顶端的自然人，限制在上述深度范围内最能保持这一模型。

证书剖面（数据模型）

携带 AIC 扩展的证书编码以下抽象数据模型：

组件	说明	基数
Agent 身份	Agent 的标识符	必填
主体绑定	到责任主体的链接	必填
委托模式	授权或代表	必填
能力集	声明的可操作能力	可选
授权约束	可离线验证的边界条件	可选
委托授权	主体同意的密码学证据	必填
扩展	厂商特定或未来扩展	可选

该数据模型编码为一组 X.509 v3 证书扩展，定义见下一节。

AIC 扩展定义

OID 树

1.3.6.1.4.1.66257 (IANA PEN -- Varwof PKI)
+-- 1 身份与授权核心
|   +-- 1 AIC（Agent 身份证书扩展）
|   |   +-- 1 AgentIdentity（agentId、principalUid、delegationMode）
|   |   +-- 2 DelegationAuthorization（reason、requestedLifetime、
|   |   |     timestamp、nonce、signatureAlgorithm、signatureValue）
|   |   +-- 4 DelegationDepthControl（chainDepth、maxDepth）
|   |   |   +-- 1 chainDepth
|   |   |   +-- 2 maxDepth
|   +-- 2 PrincipalAuthorization（grants、authorizationConstraints、
|   |     delegationPolicy）
|   |   +-- 4 DelegationPolicy
+-- 3 国家/行业认证
|   +-- 1 MarketAccessId

能力 Glob 匹配语法

能力匹配使用以下匹配规则：

模式	含义	示例
`scheme:method:path`	精确匹配	`http:GET:/api/v1/users`
`scheme:method:path/*`	单段通配（不含 “/”）	`http:GET:/api/v1/*`
`scheme:method:path/**`	多段通配（可跨 “/”）	`http:GET:/api/v1/**`
`scheme:*:path`	方法通配	`http::/api/v1/`
`scheme:*`	方案级通配	`http:*`

匹配优先级（从高到低）： 1. 精确匹配 2. 单段通配 3. 多段通配 4. 方法通配 5. 方案级通配

多条规则同时匹配时，应用最高优先级规则。若无规则匹配，该能力必须按拒绝（Deny）处理。

不允许无限制的通配符（没有前置命名空间和冒号分隔符的裸 *）。所有通配符必须限定在 schemeId 命名空间内。

ASN.1 模块

本节按 [RFC5912] 规定的约定定义 AIC 扩展的 ASN.1 模块。

编码标签约定：

必填字段使用通用标签（INTEGER、UTF8String、OCTET STRING、 SEQUENCE），不打 context-specific 标签。
所有可选字段使用 context-specific 显式标签（[n] EXPLICIT），编号按字段在结构内的顺序从 0 开始。标签号在结构内唯一，可在不同结构间复用。
标准外部类型（AlgorithmIdentifier）遵循 RFC 5280 编码约定。
DEFAULT 字段在等于默认值时可从 DER 编码中省略；实现必须同时接受两种形式。

AIC 与 PrincipalAuthorization 扩展必须为非 critical（非关键），以便不认识这些扩展的系统可以安全忽略它们。

VARWOF-AIC DEFINITIONS
    { iso(1) identified-organization(3) dod(6) internet(1)
      private(4) enterprise(1) varwof(66257) modules(2)
      id-mod-varwof-aic(1) }
DEFINITIONS ::= BEGIN

-- All SEQUENCEs SHALL use DER encoding (ordered, no indefinite-length).
-- See RFC 5912 Sec. 3 for DER encoding rules.
-- Implementations MUST reject BER indefinite-length encodings.

IMPORTS
    EXTENSION
        FROM PKIX-CommonTypes-2009
        { iso(1) identified-organization(3) dod(6) internet(1)
          security(5) mechanisms(5) pkix(7) id-mod(0)
          id-mod-pkixCommonTypes-02(57) },
    AlgorithmIdentifier
        FROM PKIXAlgs-2009
        { iso(1) identified-organization(3) dod(6) internet(1)
          security(5) mechanisms(5) pkix(7) id-mod(0)
          id-mod-pkix1-algorithms2008-02(56) } ;

-- OID Assignments

id-varwof        OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 66257 }
id-aic           OBJECT IDENTIFIER ::= { id-varwof 1 1 }

-- AIC Extension

aicExt EXTENSION ::= {
    SYNTAX         AIC
    IDENTIFIED BY  id-aic
    CRITICAL       FALSE
}

AIC ::= SEQUENCE {
    version                  INTEGER DEFAULT 1,
    agentId                  UTF8String (SIZE(1..256)),
    principalUid             PrincipalUid,
    capabilities             SEQUENCE SIZE(1..MAX) OF Capability,
    delegationMode           DelegationMode DEFAULT authorized,
    authorizationConstraints [0] EXPLICIT SEQUENCE
        SIZE(0..32) OF Capability OPTIONAL,
    delegationAuthorization  DelegationAuthorization,
    extensions               [1] EXPLICIT AICExtensions OPTIONAL
}

DelegationMode ::= INTEGER {
    authorized     (0),
    representative (1)
} (0..1)

PrincipalUid ::= SEQUENCE {
    version     INTEGER (0..255) DEFAULT 1,
    realm       UTF8String (SIZE(1..128)),
    identifier  UTF8String (SIZE(1..256)),
    keyHash     OCTET STRING (SIZE(1..64)),
    hashAlgo    [0] EXPLICIT AlgorithmIdentifier OPTIONAL
}
-- hashAlgo omitted defaults to SHA-256 (OID 2.16.840.1.101.3.4.2.1);
-- keyHash = hashAlgo(SPKI). Only hash algorithms with output length
-- not exceeding 64 bytes are supported (SHA-2/SHA-3 family, SM3,
-- BLAKE2/BLAKE3). keyHash length is determined by the algorithm.

Capability ::= SEQUENCE {
    schemeId        UTF8String (SIZE(1..128)),
    capabilityId    UTF8String (SIZE(1..256)),
    parameters      [0] EXPLICIT OCTET STRING (SIZE(0..4096)) OPTIONAL
}

-- Reason for delegation authorization (mandatory in
-- DelegationAuthorization / DelegationAuthTBS; not present in
-- PrincipalAuthorization)

Reason ::= SEQUENCE {
    reasonCode  UTF8String (SIZE(1..64)),
        -- controlled vocabulary, e.g., SCHEDULED_MAINTENANCE
    description UTF8String (SIZE(1..512))
        -- human-readable description
}

DelegationAuthorization ::= SEQUENCE {
    reason              Reason,
    requestedLifetime   INTEGER (1..86400),  -- SHOULD 3600-86400
    timestamp           GeneralizedTime,     -- MUST be UTC (Z form)
    nonce               OCTET STRING (SIZE(32)),
    signatureAlgorithm  AlgorithmIdentifier,
    signatureValue      OCTET STRING
}

-- DelegationAuthTBS (To-Be-Signed structure)
-- The principal's private key signs the DER encoding of this structure.

DelegationAuthTBS ::= SEQUENCE {
    version                  INTEGER DEFAULT 1,
    agentId                  UTF8String (SIZE(1..256)),
    principalUid             PrincipalUid,
    reason                   Reason,
    capabilities             SEQUENCE SIZE(1..MAX) OF Capability,
    delegationMode           DelegationMode,
    authorizationConstraints [0] EXPLICIT SEQUENCE
        SIZE(0..32) OF Capability OPTIONAL,
    requestedLifetime        INTEGER (1..86400),  -- SHOULD 3600-86400
    timestamp                GeneralizedTime,     -- MUST be UTC (Z)
    nonce                    OCTET STRING (SIZE(32))
}

-- PrincipalAuthorization Extension (OID: 1.3.6.1.4.1.66257.1.2)
-- Carried in the Principal's certificate.

paExt EXTENSION ::= {
    SYNTAX         PrincipalAuthorization
    IDENTIFIED BY  id-principal-auth
    CRITICAL       FALSE
}
id-principal-auth OBJECT IDENTIFIER ::= { id-varwof 1 2 }

PrincipalAuthorization ::= SEQUENCE {
    version                  INTEGER DEFAULT 1,
    grants                   SEQUENCE SIZE(1..MAX) OF Capability,
    authorizationConstraints [0] EXPLICIT SEQUENCE
        SIZE(0..32) OF Capability OPTIONAL,
    delegationPolicy         [1] EXPLICIT DelegationPolicy OPTIONAL,
    extensions               [2] EXPLICIT AICExtensions OPTIONAL
}

DelegationPolicy ::= SEQUENCE {
    version             INTEGER DEFAULT 1,
    maxAgents           INTEGER DEFAULT 1,
    allowedMode         DelegationModeEnum DEFAULT authorizedOnly,
    maxSessionHours     [0] EXPLICIT INTEGER OPTIONAL
}

DelegationModeEnum ::= INTEGER {
    authorizedOnly        (0),
    representativeAllowed (1)
} (0..1)

-- Extensibility Framework

AICExtensions ::= SEQUENCE SIZE (1..MAX) OF ExtField

ExtField ::= SEQUENCE {
    extnID      OBJECT IDENTIFIER,
    critical    BOOLEAN DEFAULT FALSE,
    extnValue   OCTET STRING
}

-- DelegationDepthControl carries the delegation chain depth.
-- Placed in AIC extensions slot, OID 1.3.6.1.4.1.66257.1.1.4.
-- maxDepth MUST NOT exceed 1; chainDepth MUST NOT exceed maxDepth.
-- A sub-agent (chainDepth = 1) MUST NOT delegate further.

id-ddc OBJECT IDENTIFIER ::= { id-aic 4 }
DelegationDepthControl ::= SEQUENCE {
    chainDepth  INTEGER (0..255),  -- OID .1.1.4.1
    maxDepth    INTEGER (0..255)   -- OID .1.1.4.2
}

END

AIC 扩展编码示例

以下示例展示一个 AIC 扩展：agentId 为 “agent-1”，主体在 “corp.com” 域内标识为 “zhangsan”，带单个 HTTP 能力：

AIC ::= {
    agentId         "agent-1",
    principalUid    {
        realm       "corp.com",
        identifier  "zhangsan",
        keyHash     <主体 SPKI 的 32 字节哈希>
    },
    capabilities    {
        { schemeId "http", capabilityId "GET:/api/v1/users" }
    },
    delegationAuthorization {
        reason      {
            reasonCode  "SCHEDULED_MAINTENANCE",
            description "临时维护窗口"
        },
        requestedLifetime 3600,
        timestamp   "2026-08-18T00:00:00Z",
        nonce       <32 字节 CSPRNG 值>,
        signatureAlgorithm ecdsa-with-SHA256,
        signatureValue <对 DelegationAuthTBS 的 DER 编码签名>
    }
}

在本示例的 DER 编码中，DEFAULT 字段（version、delegationMode）按 ASN.1 模块允许省略，OPTIONAL 字段（authorizationConstraints、 extensions）缺省。各字段按 ASN.1 模块规定的顺序，使用 DER 规则 [RFC5280] [RFC5912] 编码。signatureValue 由主体私钥对相应 DelegationAuthTBS 结构的 DER 编码签名生成，随每次授权而变化。

字段定义

agentId

agentId 字段包含 AI Agent 实例的全局唯一标识符。同一 Agent 实例在证书续期时该标识符应保持稳定。实现可以使用 UUID、URN 形式标识符或 DNS 锚定名称。

delegationMode

delegationMode 字段定义出于归因和授权目的、Agent 与其主体之间由协议定义的关系：

authorized（0）：: Agent 在明确的主体授权下，以自身密码学身份行事。审计追踪将 agentId 记录为行为者。这是默认模式。
representative（1）：: Agent 完全代表主体。行为在审计追踪中归于主体（principalUid）。仅当主体的证书明确允许代表委托（PrincipalAuthorization. delegationPolicy 中 allowedMode=representativeAllowed）时，才允许此模式。

principalUid

principalUid 字段标识授权 Agent 行为的自然人或组织实体。它编码为 ASN.1 SEQUENCE：

PrincipalUid ::= SEQUENCE {
    version     INTEGER (0..255) DEFAULT 1,
    realm       UTF8String (SIZE(1..128)),
    identifier  UTF8String (SIZE(1..256)),
    keyHash     OCTET STRING (SIZE(1..64)),
    hashAlgo    [0] EXPLICIT AlgorithmIdentifier OPTIONAL
}

其中：

realm 是全局唯一命名空间（如组织域名），限制 128 字符；
identifier 是命名空间内的唯一标识符，限制 256 字符；
keyHash 是主体证书的 SubjectPublicKeyInfo（SPKI）按 hashAlgo 计算的哈希：keyHash = hashAlgo(SPKI)。长度由哈希算法决定且不得超过 64 字节（SHA-256 = 32 字节，SHA-384 = 48 字节， SHA-512/SHA3-512 = 64 字节，SM3 = 32 字节）。使用 SPKI 哈希而非证书指纹，使主体证书在相同密钥对下换发时不使既有 Agent 授权失效。
hashAlgo 标识 keyHash 使用的哈希算法；省略时默认为 SHA-256 （OID 2.16.840.1.101.3.4.2.1）。仅支持输出长度不超过 64 字节的哈希算法。

人类可读形式 {realm}:{identifier}:{keyFingerprint}（keyFingerprint 为按 [RFC4648] 第 5 节无填充的 base64url 编码的 keyHash）仅推荐用于展示和日志。机器级比较必须使用 ASN.1 结构比较，而非字符串解析。

keyHash 可用作管理索引（例如用于级联吊销、审计或按主体检索证书）。此类检索仅用于管理关联；授权绑定与吊销决策始终以 keyHash 和证书链验证为准。

capabilities

capabilities 字段是纯容器——本规范只定义能力的编码，不定义其语义。能力语义完全由 schemeId 标识的能力方案定义。AIC 实现不得为未知方案赋予语义。每个能力条目由指示所属方案的 schemeId、方案内的 capabilityId 和可选的 parameters 标识。

capabilityId 字段支持基于 glob 的通配符匹配：* 匹配单个路径段（不含冒号），** 跨路径段匹配（任意深度）。

网关按 schemeId 查找已注册插件来路由能力求值。当当前请求所需的能力引用未知方案或未知能力时，请求必须按拒绝（Deny）处理（fail-closed）。证书中与当前请求无关的能力不影响决策。

authorizationConstraints

authorizationConstraints 字段（可选）定义 Agent 的授权边界条件。每个约束复用 Capability 容器。schemeId 必须为 "varwof/constraint-v1"；其他 schemeId 必须拒绝。capabilityId 区分约束类型。以下约束类型作为示例定义；其他约束类型通过能力方案注册表注册（见 IANA 考虑章节），不需要修改 ASN.1 模块：

capabilityId	parameters 格式	说明
`allowed-cidr`	`["10.0.0.0/8", "192.168.0.0/16"]`	允许的 IP 范围
`max-concurrent`	`{"max": 5}`	最大并发 Agent 实例数
`time-window`	`{"start": "22:00", "end": "06:00"}`	允许的执行时间窗口（UTC）

约束语义必须定义参考时钟、时间刻度、时区解释、边界条件以及时钟不确定下的行为（例如 time-window）。

约束以 AND 逻辑求值：连接被接受前所有约束必须满足。约束数量上限为 32，单条约束的 parameters 字段限制 512 字节。未知约束类型默认记录审计告警并忽略（向前兼容）；部署可配置严格拒绝行为。

设计原则：authorizationConstraints 承载授权方决定的边界条件，因人而异、变更频率低。运行时策略（超时、重试、限流、路由）不放入 authorizationConstraints，保留在网关本地策略配置中。

authorizationConstraints 与网关运行时策略的边界是固定的：

authorizationConstraints 承载授权方设定的、可离线验证的授权边界条件（IP 范围、并发限制、时间窗口）。
网关运行时策略（超时、重试、限流、路由、日志级别）是部署特定的，不得放入 authorizationConstraints。

以相同 capabilityId 和 parameters 注册的约束类型，在实现该类型的网关上必须有一致的解释。未实现某约束类型的网关将其视为未知约束，按上述未知约束处理。

AIC.authorizationConstraints 中的约束与 PrincipalAuthorization.authorizationConstraints 中的约束相互独立—— PA 约束限制授权行为，AIC 约束限制执行行为。两者在验证时独立检查。

delegationAuthorization

delegationAuthorization 字段提供主体已授权该 Agent 的密码学证据。它包含：

DelegationAuthorization ::= SEQUENCE {
    reason              Reason,
    requestedLifetime   INTEGER (1..86400),
    timestamp           GeneralizedTime,
    nonce               OCTET STRING (SIZE(32)),
    signatureAlgorithm  AlgorithmIdentifier,
    signatureValue      OCTET STRING
}

签名算法和签名值保持为两个平铺字段——signatureAlgorithm 在 signatureValue 之前——遵循 X.509 证书惯例（RFC 5280 第 4.1 节），使解析器在读签名字节前先确定算法。它们不得合并为嵌套 SEQUENCE。

reason（必填）：本次委托的原因，同时出现在此处和 DelegationAuthTBS 中（TBS 内被主体验签覆盖）。reasonCode 是 SCREAMING_SNAKE 风格的受控词表值（如 SCHEDULED_MAINTENANCE、 AUTO_RENEWAL）；description 是人类可读说明。两个字段都必须存在且非空。reason 不出现于 PrincipalAuthorization。
requestedLifetime：主体请求的证书生命周期（秒）。wire 值必须在 1-86400 范围（SHOULD 3600-86400）。CA 决定实际 NotAfter 为 min(requestedLifetime, 本地策略上限)。
timestamp：授权授予时间。必须为 UTC，编码为 GeneralizedTime 的 Z 形式。
nonce：32 字节 CSPRNG 生成的随机值，用于防重放。CA 在签发时验证 nonce 唯一性并持久化，防止重用。
signatureAlgorithm：主体验签的算法标识（如 ecdsa-with-SHA256）。
signatureValue：主体私钥对 DelegationAuthTBS 的 DER 编码签名生成的 DER 编码签名值。

主体私钥对以下 DelegationAuthTBS 结构的 DER 编码签名：

DelegationAuthTBS ::= SEQUENCE {
    version                  INTEGER DEFAULT 1,
    agentId                  UTF8String (SIZE(1..256)),
    principalUid             PrincipalUid,
    reason                   Reason,
    capabilities             SEQUENCE SIZE(1..MAX) OF Capability,
    delegationMode           DelegationMode,
    authorizationConstraints [0] EXPLICIT SEQUENCE
        SIZE(0..32) OF Capability OPTIONAL,
    requestedLifetime        INTEGER (1..86400),
    timestamp                GeneralizedTime,
    nonce                    OCTET STRING (SIZE(32))
}

DelegationAuthTBS 的 DER 编码中全部十个字段必须存在。 authorizationConstraints 字段使用 context-specific 标签 [0] EXPLICIT 编码；其可选性不破坏未携带约束的证书的向后兼容。

扩展与可扩展性

AIC 的 extensions 字段为厂商特定和用户特定元数据提供可扩展机制，类似于 X.509 v3 扩展，但限定在 AIC 上下文内。每个扩展条目由全局唯一的 OID 标识。

厂商特定扩展应使用厂商自己的 IANA 私有企业号下的 OID。
未知且 critical = TRUE 的扩展必须导致证书被拒绝。
未知且 critical = FALSE（默认）的扩展可以静默忽略。

证书大小约束

证书必须遵守以下大小限制：

全协议安全上限：12 KB 建议，16 KB 硬上限。这是与 TCP/HTTP/DTLS/ QUIC 网关兼容的 DER 编码证书大小。16 KB 对应 QUIC 参考实现所用 QUIC 栈的 CRYPTO_BUFFER_EXCEEDED 限制；超过则握手失败。
握手证书（AIC 轻量版）：8 KB 建议，16 KB 硬上限。用于 mTLS/DTLS/QUIC 握手。双证书部署中含 agentId + principalUid + delegationMode + DelegationAuthorization，并至少携带一条能力（AIC 能力集不得为空；见 4.5.4 节）。双证书部署模型是可选的部署剖面，不定义新的 TLS 证书类型。
完整授权证书：64 KB 建议，128 KB 硬上限。携带全部 capabilities、 authorizationConstraints 和 extensions；握手后经应用层传输。超过 128 KB 的证书必须拒绝。与 QUIC 不同，TCP/TLS 传输不施加 16 KB 握手限制：证书消息由 TLS 记录层分段，因此实际可承载更大的证书直至硬上限。

extensions 字段的条目数不应超过 32。ASN.1 模块以 SIZE(1..MAX) 约束 capabilities 序列，不在 wire 格式上写死数字上限。能力条目超过 256 的证书必须拒绝以防 DoS 攻击；典型部署携带的条目远少于此数，部署应尽量保持能力集精简。

能力参数交集

在 P_grants 与 C_agent 之间匹配能力时，参数交集遵循以下规则：

若 C_agent.parameters 超出 P_grants.parameters 定义的边界，该能力条目无效（被过滤或拒绝）。
否则，完整采用 C_agent.parameters（主体边界内的 Agent 指定值）。

示例：

P_grants	C_agent	结果
`max_rows=1000`	`max_rows=100`	接受，采用 `max_rows=100`
`max_rows=1000`	`max_rows=5000`	拒绝（超出边界）

验证流程

本节定义网关或依赖方处理携带 AIC 的证书时必须执行的验证流程。

验证管线

TLS 握手完成后，网关按顺序执行以下验证步骤：

证书链（[RFC5280]）：验证证书链至可信根，包括签名验证、有效期和基本约束。
吊销状态：验证终端实体证书和链中任何中间证书均未被吊销。实现可以使用 CRL（[RFC5280]）、OCSP（[RFC6960]）或 OCSP Must-Staple （[RFC7633]）。离线部署中，本地缓存的 CRL 或短有效期窗口可作为替代吊销机制。
AIC 扩展解析：解析 AIC SEQUENCE。若扩展标记为 critical 且无法解析，证书必须拒绝。
DelegationAuthorization 验证：验证 delegationAuthorization.signatureValue 中主体验签：
- 重建 DelegationAuthTBS 的 DER 编码（含 reason 和存在的 authorizationConstraints）。TBS 按 ASN.1 模块定义的字段顺序 DER 编码；DEFAULT 字段可省略并按默认值解释。
- 使用主体公钥（由 principalUid.keyHash 标识）验证 signatureValue。
- 交叉验证 hashAlgo(principal_cert.SPKI) 等于 principalUid.keyHash （省略 hashAlgo 表示 SHA-256）。
- 验证证书有效期（notAfter - notBefore）不超过 delegationAuthorization.requestedLifetime，且 requestedLifetime 最多 86400 秒（1 天）。
- 验证 signatureAlgorithm 属于允许算法：ECDSA-SHA256（MUST）、 ECDSA-SHA384/512（MAY）、RSA-SHA256（MUST）、RSA-SHA384/512 （MAY）、RSA-PSS-SHA256（MAY）或 Ed25519（MAY）。其他算法必须拒绝。
PA.authorizationConstraints 检查：若主体证书中的 PrincipalAuthorization 扩展含 authorizationConstraints，则求值。 PA 约束限制授权行为，独立于 AIC.authorizationConstraints。
AIC.authorizationConstraints 检查：若 AIC.authorizationConstraints 存在，以 AND 逻辑求值其识别到的每个约束。所有约束必须满足。未知约束类型记录审计告警并忽略（向前兼容）。此步骤在能力求值前执行，用于快速拒绝未授权连接。
委托模式检查：若 delegationMode 为 representative：
- 加载主体证书及其 PrincipalAuthorization 扩展。
- 验证 allowedMode 允许代表委托。
- 验证 C_agent 是 P_grants 的子集（P (AND) C (AND) T）。
委托深度检查：若存在 DelegationDepthControl 扩展，验证 chainDepth 不超过 maxDepth。作为最佳实践，部署不应接受 chainDepth > 1（或 maxDepth > 1）的链；此类链超出本规范推荐的部署包络。
能力求值：对当前请求所需的能力，路由到其 schemeId 注册的插件求值。若无注册插件或能力未知，请求必须拒绝。证书中与当前请求无关的其他能力不影响决策。
决策：若所有验证步骤通过，依赖方应允许连接。任一步骤失败，依赖方必须拒绝请求。部署应记录拒绝及足够的诊断信息用于审计。

离线验证

在无法访问 CRL 或 OCSP 响应器的离线或气隙部署中，依赖方必须接受 “已吊销证书在下次缓存刷新前可能被接受”的风险。缓解措施包括：

短证书有效期窗口（RECOMMENDED <= 1 小时）；
带新鲜度检查的本地缓存 CRL 分片；
authorizationConstraints 在 TLS 握手期间完全离线求值。

主体证书取自 Agent 在 TLS 握手期间出示的凭证包（TLS 1.3 允许多个 CertificateEntry 消息）。若链中无主体证书且无本地缓存，网关必须拒绝连接（Fail-Close，故障关闭）。凭证包的传输机制是部署细节，本规范不定义为新的 TLS 消息类型。

PrincipalAuthorization 扩展

PrincipalAuthorization 扩展（OID 1.3.6.1.4.1.66257.1.2）是主体证书中携带的配套 X.509 扩展。它声明主体的权限边界，包括能力授予声明、授权约束和委托策略。

ASN.1 定义

PrincipalAuthorization ::= SEQUENCE {
    version                  INTEGER DEFAULT 1,
    grants                   SEQUENCE SIZE(1..MAX) OF Capability,
    authorizationConstraints [0] EXPLICIT SEQUENCE
        SIZE(0..32) OF Capability OPTIONAL,
    delegationPolicy         [1] EXPLICIT DelegationPolicy OPTIONAL,
    extensions               [2] EXPLICIT AICExtensions OPTIONAL
}

DelegationPolicy ::= SEQUENCE {
    version             INTEGER DEFAULT 1,
    maxAgents           INTEGER DEFAULT 1,
    allowedMode         DelegationModeEnum DEFAULT authorizedOnly,
    maxSessionHours     [0] EXPLICIT INTEGER OPTIONAL
}

DelegationModeEnum ::= INTEGER {
    authorizedOnly        (0),
    representativeAllowed (1)
} (0..1)

grants 字段定义主体可授予 Agent 的能力集——作为权限交集模型中的上界（P_grants）。

authorizationConstraints 字段携带主体级授权边界约束，复用 schemeId="varwof/constraint-v1" 的 Capability 容器。PA 约束与 AIC 约束独立求值——它们作用于不同语义层，不存在子集关系。

delegationPolicy 字段定义主体的委托边界：允许同时委托多少 Agent （maxAgents）、允许哪些委托模式（allowedMode），以及可选的最大会话时长（maxSessionHours）。

maxAgents（DelegationPolicy 中）与 max-concurrent 约束（authorizationConstraints 中）语义不同：maxAgents 限制主体可同时委托的 Agent 实例数，而 max-concurrent 限制单个 Agent 可建立的并发连接数。它们在各自层面执行（策略边界 vs 执行边界），不可互换。

主体密钥轮换

当主体私钥泄露并生成新密钥对时，principalUid.keyHash 中的 SPKI 哈希随之改变，导致所有既有代表模式 Agent 证书的授权检查失败。这是有意设计：密钥对改变时，所有关联 Agent 证书通过密钥管理操作自动失效，而非吊销广播。当主体使用相同密钥对续期证书时，SPKI 不变，既有 Agent 授权继续有效，无需重新签发。

部署模型

企业/受监管模型

principalUid 字段必须填充可验证的自然人标识。
delegationAuthorization 字段必须存在并经过密码学验证。
代表模式只能在有明确的 PrincipalAuthorization 委托授予时使用。
证书有效期应为短期（数小时至数天）。
authorizationConstraints 应携带 IP 范围、并发和时间窗口边界。
所有携带 AIC 的连接应记录日志。

消费级/个人模型

principalUid 可以省略或包含假名标识符。
低风险操作下 delegationAuthorization 字段可以省略。
不应使用代表模式。
此模型下的部署将消费者隐私保护置于细粒度身份绑定之上。

可扩展性框架

AIC 的 extensions 字段为厂商特定和用户特定元数据提供可扩展机制，类似于 X.509 v3 扩展，但限定在 AIC 上下文内。

extensions 序列中的每个扩展由全局唯一 OID 标识。适用以下指南：

厂商特定扩展应使用厂商自己的 IANA 私有企业号下的 OID。
未知且 critical = TRUE 的扩展必须导致证书被拒绝。
未知且 critical = FALSE（默认）的扩展可以静默忽略。

本文档只规定容器结构。语义由 OID 分配者定义。

隐私考虑（GDPR / 被遗忘权）

AIC 证书是静态 X.509 数据对象。一旦签发，principalUid 字段无法从已分发证书中修改或删除。部署必须确保：

principalUid 内的 identifier 字段不包含原始个人可识别信息（PII），如全名、身份证号或邮箱地址。必须使用内部 UUID 或假名标识符。
假名标识符与自然人之间的映射表存储在符合 GDPR 第 17 条或等效法规的、支持删除的合规数据库中。
证书吊销（CRL/OCSP）是表达”主体不再授权某 Agent”的唯一可用机制；吊销不擦除证书本身。
依赖方应将 AIC 证书视为无状态凭证：在 TLS 握手期间解析和验证，之后原始证书可以丢弃，无需持久化存储。
审计日志应最小化：无需记录完整 principalUid 结构或扩展内容。会话绑定指纹、操作摘要、决策结果和假名标识符足以满足问责。
日志保留必须由部署按适用法域要求配置。推荐分层模型：严监管场景长期归档、标准部署限期清理、消费场景即弃无映射模式。
密码学证据与日志映射相互独立：DelegationAuthorization 签名可独立验证，不依赖审计日志映射；删除假名映射表不会使授权密码学证据失效。

由于证书一经签发即不可变，数据主体权利（访问、更正、删除）通过证书吊销与重新签发实现：吊销携带旧标识符的证书，用新的假名标识符签发新证书，并删除关联的映射条目。

本规范仅提供隐私友好的机制。法律合规（合法依据、跨境传输、违约通知及其他义务）由作为数据控制者或处理者的部署方承担。

AIC 扩展承载的所有数据在 TLS 握手期间可见。实现不得在任何证书扩展中放置敏感数据。

安全考量

AIC 扩展本身不是认证要求：X.509 证书链已认证 Agent，AIC 扩展携带依赖方可评估的授权相关信息。要求基于 AIC 授权的部署必须配置依赖方要求并处理 AIC 扩展。

AIC 不约束 CA 签发 PrincipalAuthorization 扩展的权限。 PrincipalAuthorization 的可信度取决于 CA 签发策略和信任锚配置。

威胁模型

本规范考虑以下敌手模型：

网络攻击者（E）：能够截获、修改和重放 TLS 连接的网络级敌手。该敌手不掌握任何私钥。

恶意 Agent（M）：持有有效 AIC 证书的已认证 Agent，试图提权、冒充其他 Agent 或超出其授权能力。

被攻破的主体（P）：私钥已泄露的主体。攻击者可用该密钥签署任意 DelegationAuthorization 载荷。

被攻破的 CA（C）：掌握 CA 签名密钥的敌手。该敌手可签发任意证书，是模型中最强大的。

威胁缓解

威胁	缓解	机制
Agent 冒充	密码学身份绑定	X.509 CA 签发证书，BasicConstraints CA:FALSE
主体否认授权	授权数字签名	DelegationAuthorization.signatureValue 覆盖 DelegationAuthTBS
能力提权	权限子集检查	P_grants (AND) C_agent (AND) T_policy 交集
跨 CA 角色伪造	信任锚哈希验证	离线插件参数中的信任锚指纹比对
未知扩展绕过	critical 标志强制	拒绝未知 critical 扩展
签名重放	TBS 中的 nonce 绑定	DelegationAuthTBS 中 32 字节 nonce，CA 唯一性检查
授权伪造	双层签名嵌套	CA 对 TBSCertificate 签名 + AIC 扩展中主体验签

离线验证风险

离线部署中，存在”已吊销证书在下次缓存刷新前被接受”的风险。缓解措施包括短证书有效期窗口和严格的 authorizationConstraints（限制爆炸半径：IP 范围、并发上限）。

授权约束完整性

authorizationConstraints 字段承载于 AIC 扩展内，被 CA 对 TBSCertificate 的签名覆盖；对任何约束的修改都会导致证书签名验证失败。约束执行的有效性还取决于网关求值其识别的约束、以及约束插件实现声明的语义。约束是限制受攻破或恶意 Agent 爆炸半径的边界条件；它们不能替代网关本地策略控制（如限流或资源配额）。

主体密钥哈希绑定

principalUid.keyHash 字段通过 hashAlgo 标识的哈希算法将委托授权绑定到主体公钥。哈希输出受 ASN.1 SIZE 约束限制为 64 字节，在所选哈希算法的安全假设下，密码学安全哈希函数的碰撞被假定为计算上不可行。此外， keyHash 用于在凭证包内定位和绑定主体证书；签名验证在证书链验证后使用主体公钥，因此仅凭哈希碰撞无法让攻击者生成有效的主体签名。 keyHash 本身不建立信任：信任来自证书链验证和主体验签。keyHash 只是定位和绑定机制。

Nonce 防重放

DelegationAuthTBS 中的 32 字节 nonce 作为 DER 编码的一部分被签名，使其成为主体验签的密码学输入——而非明文参数。CA 在签发时验证 nonce 唯一性并持久化已用 nonce。网关可以可选地维护本地 NonceCache 用于额外重放检测，但非必需：主要防线是 CA 层唯一性检查。因此防重放在 CA 签发层（签发时的 nonce 唯一性）执行，而非网关运行时；网关的可选缓存仅是次级防线。

IANA 考虑

私有企业号分配

本文档使用分配给 Varwof PKI 的 IANA 私有企业号 66257（联系人：Jijie Wei，pki@varwof.com）。OID 前缀为：

1.3.6.1.4.1.66257

OID 注册

本文档定义以下 OID：

1.3.6.1.4.1.66257.1.1：: AIC 扩展（见 AIC 扩展定义章节）
1.3.6.1.4.1.66257.1.2：: PrincipalAuthorization 扩展（见 PrincipalAuthorization 章节）
1.3.6.1.4.1.66257.1.1.4：: DelegationDepthControl（见多级委托章节）

3 分支（国家/行业认证）下的附加 OID 保留给未来分配。完整 OID 树见 OID 树章节。

能力方案注册表

本版本规范不请求 IANA 注册表。能力方案标识符和约束类型通过外部能力方案注册表演进，由外部或社区方案标识符注册表维护，遵循 vendor/product 命名约定。若将来将方案命名空间移交 IANA 管理，可在未来修订中请求 IANA 注册表。

外部注册表的初始条目：

方案标识符	说明	引用
varwof/constraint-v1	授权边界约束（allowed-cidr、max-concurrent、time-window）	本文档

http 和 database 方案标识符保留为外部定义能力方案的示例；其语义由能力方案本身而非本文档定义。

实现状态

按 [RFC7942]，本规范有参考实现支持：

用 Go 编写的参考实现实现了本规范定义的协议，包括证书签发、AIC 扩展解析、准入决策、吊销和离线授权。实现尚未公开；计划公开发布。发布后补充仓库 URL。

已测试能力包括：带 authorizationConstraints 的证书签发、AIC 扩展解析、DelegationAuthorization 签名验证、权限交集（P (AND) C (AND) T）决策、能力插件路由和离线约束验证。

互操作性

与标准 X.509 扩展的关系

密钥用法与扩展密钥用法

支持 AIC 的证书应包含 digitalSignature 密钥用法（[RFC5280] 第 4.2.1.3 节）。证书用于 TLS 客户端认证时，扩展密钥用法必须包含 id-kp-clientAuth。

基本约束

AIC Agent 证书必须具有 BasicConstraints CA:FALSE。CA 签发必须拒绝请求者持有 AIC 证书的任何请求，以防止单层部署模式下的 Agent 到 Agent 链接。在深度 1 的委托链中，下级 Agent 的 DelegationAuthorization 锚定到委托 Agent 的 AIC 证书；作为最佳实践，CA 不应签发 DelegationDepthControl.maxDepth 大于 1 的证书。

互操作测试矩阵

场景	AIC 网关行为	旧客户端行为	兼容性
无 AIC 扩展的客户端	RequireAIC=true 时拒绝；false 时透传	正常 mTLS	取决于配置
带 AIC 的客户端	完整准入管线	忽略 AIC 扩展	是
多能力（<=64）	完整解析和求值	忽略	是
多能力（>256）	拒绝（DoS 防护）	忽略	受限
未知能力方案	拒绝	忽略	受限
缺少 OCSP Must-Staple	拒绝	正常 OCSP	否
离线且无 CRL 缓存	Fail-Close（拒绝）	Fail-Open（允许）	否

TLS 集成

握手要求

AIC 扩展不引入新的 TLS 握手协议。它利用 TLS 1.3 握手期间出示的既有 X.509 证书链。当 TLS 服务器要求 AIC 认证连接时，应在 CertificateRequest 消息中包含 AIC OID。

TLS 告警码

以下是 AIC 条件到 IANA TLS 告警注册表（[RFC8446]）中官方 TLS 告警码的推荐映射；实现可按照 TLS 规范选择适当的告警。

条件	TLS 告警	码	说明
要求 AIC 但缺失	unsupported_extension	116	客户端必须包含 AIC
AIC 畸形	bad_certificate	42	解析失败
能力未授权	certificate_unknown	46	权限拒绝
无 DA 冒充	access_denied	49	缺少授权
证书过期/吊销	certificate_expired	45	生命周期检查失败

限制

本规范有以下限制：

委托深度限制为 1：单层委托（Principal -> Agent）为默认；确有需要时支持深度 1 的链（Principal -> Agent -> sub-Agent）。不建议使用深度超过 1 的链（最佳实践），因为更深的链会使归责和问责复杂化，而本规范将其锚定在链顶端的自然人。
无分布式状态：多网关部署需要带外状态同步（nonce 缓存、并发跟踪）。
静态能力求值：纯容器设计将所有语义验证委托给网关插件。动态、上下文感知的策略求值不在范围内。
UDP/DTLS 传输：TCP/TLS 和 QUIC 上的 AIC 已完整规定。非 TLS UDP/DTLS 传输保留给未来修订。
后量子就绪：混合与 PQC 套件的算法 OID 已保留，但签名交换尚未规定。
部署规模：超过 100 万 Agent 的企业级验证尚未发布。

知识产权

本文档受 BCP 79（RFC 8179）约束。作者已提交与本技术相关的专利申请，包括中国专利申请第 202611238454.1 号和 202611238460.7 号（提交于中国国家知识产权局）。作者将按照 BCP 79 要求向 IETF 提交 IPR 披露。任何适用的 IPR 披露可通过 IETF IPR 披露系统获取。

致谢

作者感谢 IETF 社区就 Agent 身份与问责框架进行的持续讨论。

变更日志

draft-wei-aic-identity-cert-00（2026-08-18）： * 初始个人草案。

AIC 证书草案中文对照版

AIC 证书草案中文对照版

摘要

引言

问题陈述

范围

设计原则

需求语言

相关工作

委托模型

委托模式

安全包络模型

权限交集

多级委托

证书剖面（数据模型）

AIC 扩展定义

OID 树

能力 Glob 匹配语法

ASN.1 模块

AIC 扩展编码示例

字段定义

agentId

delegationMode

principalUid

capabilities

authorizationConstraints

delegationAuthorization

扩展与可扩展性

证书大小约束

能力参数交集

验证流程

验证管线

离线验证

PrincipalAuthorization 扩展

ASN.1 定义

主体密钥轮换

部署模型

企业/受监管模型

消费级/个人模型

可扩展性框架

隐私考虑（GDPR / 被遗忘权）

安全考量

威胁模型

威胁缓解

离线验证风险

授权约束完整性

主体密钥哈希绑定

Nonce 防重放

IANA 考虑

私有企业号分配

OID 注册

能力方案注册表

实现状态

互操作性

与标准 X.509 扩展的关系

密钥用法与扩展密钥用法

基本约束

互操作测试矩阵

TLS 集成

握手要求

TLS 告警码

限制

知识产权

致谢

变更日志