简单讲讲 ASN.1 与 OID

当你打开一个 HTTPS 网站，浏览器会校验证书中的签名算法；当网络管理员通过 SNMP 监控交换机端口流量，系统会读取一个个管理变量；当手机接入 4G/5G 网络，核心网与终端之间交换着复杂的信令。这些看似毫无关联的场景，背后却共同依赖着两项已经存在了三十多年的技术——ASN.1 和 OID。

本文由人工智能辅助收集资料和创作。

摘要

ASN.1（Abstract Syntax Notation One，抽象语法记法一）是一套用于描述数据结构的标准化语言，广泛应用于通信协议、安全证书、电信系统、网络管理、密码学、身份认证等领域。它并不直接规定数据在字节层面的具体表示方式，而是定义一种与平台、编程语言、操作系统和传输介质无关的数据描述方法。

OID（Object Identifier，对象标识符）是一种层次化、全局唯一的标识机制，常与 ASN.1 一起使用。OID 可以为算法、证书扩展、组织、协议对象、管理对象、属性类型等分配唯一编号。X.509 证书、SNMP MIB、LDAP Schema、PKCS 系列标准以及大量密码学协议都大量依赖 OID。

ASN.1 解决的是“如何准确描述数据结构”的问题，OID 解决的是“如何全局唯一标识对象”的问题。二者结合，使得复杂系统中的数据结构、算法、属性、协议元素可以被精确描述、唯一标识并长期互操作。

ASN.1

ASN.1（Abstract Syntax Notation One，抽象语法标记一）是一种独立于机器架构的数据描述语言。你可以把它想象成一份用通用术语写成的数据结构菜单，而具体的烹饪方法（编码规则）可以另选。

它的核心理念是：先抽象定义信息的内容和结构，再根据场景选择具体的二进制表达方式。

例如：

Person ::= SEQUENCE {
    name        UTF8String,
    age         INTEGER,
    email       IA5String OPTIONAL
}

这个定义表示：

• Person 是一个复合结构；
• 它由 name、age、email 三个字段组成；
• name 是 UTF-8 字符串；
• age 是整数；
• email 是 IA5String，并且是可选字段。

ASN.1 本身不是一种编程语言，也不是一种网络协议，而是一种数据抽象描述语言。

简单来说，它的核心目标是：

1. 精确描述数据结构；
2. 与具体编程语言无关；
3. 与 CPU 架构、字节序、操作系统无关；
4. 与具体编码方式解耦；
5. 便于不同厂商、不同系统、不同语言实现之间互操作。

ASN.1 的标准体系

ASN.1 由 ITU-T 和 ISO/IEC 联合标准化。其核心标准主要包括：

ASN.1 的标准化非常成熟，其历史可以追溯到 20 世纪 80 年代，并长期用于电信、金融、网络安全、身份认证等对互操作性要求极高的领域。

ASN.1 的设计思想

ASN.1 中有两个非常重要的概念：

1. 抽象语法
2. 传输语法

抽象语法

抽象语法描述的是数据的逻辑结构。例如：

CertificateSerialNumber ::= INTEGER

这个定义只说明证书序列号是一个整数，但没有说明它在网络上传输时应该占几个字节、采用大端还是小端、是否带长度字段等。

传输语法

传输语法描述的是数据如何被编码成字节流。ASN.1 的传输语法由各种编码规则提供，例如：

• BER
• CER
• DER
• PER
• OER
• XER
• JER

同一个 ASN.1 数据结构可以使用不同编码规则转换为不同形式的字节流。这种设计使得 ASN.1 具有很强的抽象性和可移植性。

OID：全球命名的那棵树

OID（Object Identifier，对象标识符）是一种全球唯一、层次化、树状分配的标识体系。它常用于给算法、组织、标准、证书扩展、目录属性、网络管理对象等分配唯一名称。相比普通字符串名称，OID 的优势在于它不依赖自然语言，不容易因为同名而冲突，并且可以通过分层授权长期扩展。

一个典型 OID 如下：

1.2.840.113549.1.1.1

它表示 RSA 加密算法 rsaEncryption。这个数字串看似晦涩，但实际上它是一条从 OID 根节点一路向下的路径。

OID 的基本形式

OID 通常使用点分十进制表示，每个数字称为一个 arc，可译为“弧”或“节点”。

1.2.840.113549.1.1.1

可以拆成：

1 / 2 / 840 / 113549 / 1 / 1 / 1

也可以写成 ASN.1 名称形式：

{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) rsaEncryption(1) }

两种写法表达的是同一个对象：

点分十进制最适合程序、配置文件和日志；名称形式更适合标准文档和人工阅读。

OID 树的根节点

OID 是一棵树。根节点下面最重要的三个一级分支是：

可以把它想象成：

OID Root
├── 0 itu-t
├── 1 iso
└── 2 joint-iso-itu-t

OID 的唯一性来自这棵树的分层授权：上级节点把某个子节点分配给一个组织后，该组织就可以在自己的子树下继续分配新的节点。

从树根走到 RSA：一个 OID 的路径

还是以 rsaEncryption 的 OID 为例：

1.2.840.113549.1.1.1

它可以展开为：

iso(1)
└── member-body(2)
    └── us(840)
        └── rsadsi(113549)
            └── pkcs(1)
                └── pkcs-1(1)
                    └── rsaEncryption(1)

对应关系如下：

这个例子体现了 OID 的核心思想：每个 OID 都不是孤立编号，而是一条有管理来源的树路径。

OID 为什么能做到全球唯一

OID 不是靠一个中央数据库为所有对象逐个命名，而是靠层级分配保证唯一性。

例如：

1.2.840.113549

这个节点分配给 RSA Data Security, Inc. 后，RSA 就可以在其下继续定义：

1.2.840.113549.1
1.2.840.113549.1.1
1.2.840.113549.1.1.1
1.2.840.113549.1.1.5
1.2.840.113549.1.1.11

只要每个节点的管理者不在自己的子树下重复分配同一个子编号，整棵树就能保持全局唯一。

这种机制与域名系统有些相似：

OID 更像是标准世界中的永久编号，而不是互联网访问地址。

OID 在 ASN.1 中的表示

ASN.1 直接提供了 OBJECT IDENTIFIER 类型。

例如：

AlgorithmIdentifier ::= SEQUENCE {
    algorithm   OBJECT IDENTIFIER,
    parameters  ANY OPTIONAL
}

这个结构的含义是：

• algorithm 字段保存算法的 OID；
• parameters 字段保存该算法的参数；
• 不同的 algorithm OID 决定 parameters 应该如何解释。

例如：

algorithm = 1.2.840.113549.1.1.1

表示 RSA 加密算法。

algorithm = 1.2.840.10045.2.1

表示椭圆曲线公钥算法。

也就是说，OID 常常不仅仅是一个编号，而是一个“解释开关”：看到某个 OID，解析器才知道后面的数据应该按照什么规则理解。

OID 与 X.509 证书

X.509 证书是普通用户最容易接触到 OID 的地方。证书中的很多字段都由 OID 标识。

证书属性 OID

证书扩展 OID

例如证书扩展通常可抽象为：

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

其中 extnID 就是扩展的 OID。解析器根据它判断 extnValue 里面到底是什么结构。

OID 与算法标识

密码学协议大量使用 OID 来标识算法。原因很简单：算法名称可能有别名、大小写差异或历史写法，而 OID 是明确的数字标识。

例如，一个证书中如果出现 1.2.840.113549.1.1.11，解析器就知道它表示 sha256WithRSAEncryption，而不是只凭字符串猜测算法。

OID 与 SNMP 网络管理

在 SNMP 中，OID 是管理对象的「地址」。网络管理系统通过 OID 查询设备信息，例如设备名称、接口流量、运行时间等。

一个常见 OID：

1.3.6.1.2.1.1.1.0

表示 sysDescr.0，也就是系统描述信息。

展开如下：

iso(1)
└── identified-organization(3)
    └── dod(6)
        └── internet(1)
            └── mgmt(2)
                └── mib-2(1)
                    └── system(1)
                        └── sysDescr(1)
                            └── instance(0)

常见 SNMP OID：

这里末尾的 .0 有时很重要，它表示标量对象的具体实例。

OID 不是「含义本身」，而是「含义的索引」

理解 OID 时要避免一个误区：OID 本身只是标识符，它不是算法、不是证书扩展、也不是数据结构本体。

例如：2.5.29.17，它表示 subjectAltName 这个证书扩展，但真正的数据结构还要看 X.509 标准如何定义。

因此，OID 更像数据库中的主键：

OID → 查询标准定义 → 得到语义和解析方式

自定义 OID 与私有分支

如果组织需要定义自己的证书扩展、SNMP MIB、LDAP Schema 或内部协议对象，通常应该申请或使用合法分配的 OID 分支。

SNMP 企业私有分支常见路径是：

1.3.6.1.4.1

也就是：

iso(1)
└── identified-organization(3)
    └── dod(6)
        └── internet(1)
            └── private(4)
                └── enterprise(1)

如果某企业获得编号 99999，则可以在：

1.3.6.1.4.1.99999

下面继续分配：

1.3.6.1.4.1.99999.1
1.3.6.1.4.1.99999.2
1.3.6.1.4.1.99999.100.1

一个良好的私有 OID 文档通常应包括：

使用 OID 时的注意事项

不要随意占用别人的 OID

OID 的意义来自唯一性。随意使用已有 OID 会导致严重歧义。例如，把自己的私有扩展伪装成标准扩展 OID，可能导致解析器误解数据结构，甚至产生安全问题。

不要只记录名称，忽略数字

名称可能存在别名或大小写差异，但数字 OID 是最稳定的表示。例如应写：

sha256WithRSAEncryption: 1.2.840.113549.1.1.11

不要认为看到 OID 就等于安全

OID 只能说明「这是什么」，不能说明是否安全。

必须结合标准解释参数

同样是 AlgorithmIdentifier，不同算法对 parameters 字段要求不同。有的要求为 NULL，有的要求省略，有的需要复杂结构。实现时必须查阅对应标准，不能机械套用。

OID 是标准世界的坐标系

OID 的本质是一套全球命名坐标系。它用一棵分层授权的树，把世界上的标准、组织、算法、属性、扩展、管理对象连接起来。在 ASN.1、X.509、SNMP、LDAP、PKCS、CMS 等体系中，OID 正是这种“全球唯一名称”的基础设施。

OID 不负责承载数据本身，而负责告诉系统“这个数据、算法或对象到底是谁”。

二者如何协作

如果 ASN.1 是一种「描述语法」，OID 就是这种语法里随处被引用的「全局常量」。在 ASN.1 模块中，可以主动为某个对象赋予一个 OID 名称，比如：

-- 为虚构的 Example 公司注册一个基础 OID
id-example  OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 99999 }

-- 在该公司子树下定义一个访问控制扩展
id-ce-exampleAccessControl  OBJECT IDENTIFIER ::= { id-example 1 }

ExampleAccessControl ::= SEQUENCE {
    requiredRole  UTF8String,
    clearance     INTEGER
}

通过这段定义，任何系统只要看到 1.3.6.1.4.1.99999.1 这个 OID，就能自动理解其后跟随的数据应该按 ExampleAccessControl 的结构来解析。协议设计者可以用 OID 来标记算法、证书策略、文件格式等，把灵活的语义拓展埋入有序的注册体系当中。

藏在身边的 ASN.1 & OID

ASN.1 和 OID 看似是偏底层、偏标准化的技术，但实际上它们经常隐藏在日常使用的网络、证书、设备和身份系统背后。我们平时不一定直接看到 ASN.1 语法或 OID 数字串，却几乎每天都在间接使用它们。

• HTTPS 网站证书中有 ASN.1 和 OID
  当浏览器访问 HTTPS 网站时，服务器会发送 X.509 数字证书。这个证书的内部结构就是用 ASN.1 定义的，通常采用 DER 编码。证书里的签名算法、公钥算法、主体名称、扩展用途等，也大量依赖 OID 标识。例如，2.5.4.3 表示 commonName，2.5.29.17 表示 subjectAltName，1.2.840.113549.1.1.11 表示 sha256WithRSAEncryption。

• 手机和电脑里的证书文件使用 ASN.1
  常见的 .cer、.crt、.der、.pem 证书文件，背后通常都是 ASN.1 结构。DER 是 ASN.1 的二进制编码形式，而 PEM 则往往是在 DER 数据外面套了一层 Base64 文本封装。也就是说，当我们导入 CA 证书、客户端证书或查看网站证书详情时，实际上就在使用 ASN.1 和 OID。

• 电子签名、加密邮件和 PDF 签名离不开 OID
  S/MIME 加密邮件、CMS/PKCS#7 签名数据、PDF 数字签名等安全机制会用 ASN.1 描述签名数据、证书链、摘要算法、签名算法和时间戳信息。OID 则负责说明具体使用的是哪种算法，例如 SHA-256、RSA、ECDSA、RSASSA-PSS 等。

• Wi-Fi、VPN、企业内网认证中也有它们
  企业 Wi-Fi、VPN、802.1X、EAP-TLS 等认证场景常常使用客户端证书或服务器证书。这些证书同样是 ASN.1 定义的 X.509 证书，证书中的扩展密钥用途、证书策略、主体备用名称等都由 OID 标识。

• 路由器、交换机和服务器监控里有 OID
  SNMP 网络管理协议使用 OID 来定位设备上的管理对象。例如设备名称、运行时间、接口流量、CPU 使用率、端口状态等都可以通过不同 OID 查询。网管系统里看到的接口监控、流量图、告警信息，很多都来自 SNMP OID。

• LDAP、目录服务和统一身份系统中有 OID
  企业常用的目录服务，如 LDAP、Active Directory 等，在属性类型和对象类定义中大量使用 OID。比如用户名、组织、邮箱、姓氏、部门等属性，在标准模式中都有对应的对象标识符。

• SIM 卡、移动通信和 4G/5G 协议里也常见 ASN.1
  在移动通信系统中，许多信令协议会使用 ASN.1 来描述消息结构，并使用 PER 等高效编码规则传输。手机接入基站、网络切换、无线资源控制等过程背后，都可能涉及 ASN.1 编码的数据。

• 软件安装包、代码签名和系统更新也会碰到它们
  操作系统验证软件签名、驱动签名、系统更新包签名时，通常会处理 X.509 证书、PKCS#7/CMS 签名结构和算法标识符。这些结构中 ASN.1 负责组织数据，OID 负责标识算法和扩展用途。

ASN.1 像是一种隐藏的数据结构语言，OID 像是一套全球唯一编号系统。它们不常直接出现在用户界面中，却支撑着 HTTPS、数字证书、电子签名、网络设备管理、企业身份认证、移动通信等大量基础设施。

不可绕过的基石

ASN.1 和 OID 经常因为其复杂的编码规则和老旧的外表而被批评为「恐龙技术」。但如果只用「老旧」来评价它们，显然并不公平。

ASN.1 与 OID 之所以能长期存在，并不是因为历史包袱没有被清理，而是因为它们解决的是非常基础、非常长期的问题：如何精确描述数据结构，如何在全球范围内为对象分配稳定且唯一的名字。

在数字证书、电子签名、SNMP 网络管理、LDAP 目录服务、移动通信信令等场景中，系统需要的不只是「能传数据」，还需要长期兼容、跨厂商互操作、可扩展、可标准化。ASN.1 提供了严谨的数据建模能力，OID 则提供了层次化的全球命名体系。它们看起来不像现代 JSON API 那样亲切，却在许多关键基础设施中承担着更底层、更稳定的角色。

所以，ASN.1 和 OID 或许确实带着恐龙的外表，但它们更像是仍在支撑地基的古老工程结构：不轻巧，不时髦，却足够坚固。对于普通开发者来说，可以不喜欢它们的语法和编码细节；但在理解证书、密码学协议、网络管理和通信标准时，绕开它们几乎是不可能的。

参考资料

1. ITU-T Recommendation X.680：Abstract Syntax Notation One (ASN.1): Specification of basic notation
   https://www.itu.int/rec/T-REC-X.680

2. ITU-T Recommendation X.681：ASN.1 Information object specification
   https://www.itu.int/rec/T-REC-X.681

3. ITU-T Recommendation X.682：ASN.1 Constraint specification
   https://www.itu.int/rec/T-REC-X.682

4. ITU-T Recommendation X.683：ASN.1 Parameterization of ASN.1 specifications
   https://www.itu.int/rec/T-REC-X.683

5. ITU-T Recommendation X.690：ASN.1 encoding rules: BER, CER and DER
   https://www.itu.int/rec/T-REC-X.690

6. ITU-T Recommendation X.691：ASN.1 encoding rules: Packed Encoding Rules (PER)
   https://www.itu.int/rec/T-REC-X.691

7. ITU-T Recommendation X.693：ASN.1 encoding rules: XML Encoding Rules (XER)
   https://www.itu.int/rec/T-REC-X.693

8. ITU-T Recommendation X.696：ASN.1 encoding rules: Octet Encoding Rules (OER)
   https://www.itu.int/rec/T-REC-X.696

9. ITU-T Recommendation X.697：ASN.1 encoding rules: JSON Encoding Rules (JER)
   https://www.itu.int/rec/T-REC-X.697

10. ITU-T Recommendation X.660：Procedures for the operation of object identifier registration authorities
    https://www.itu.int/rec/T-REC-X.660

11. ITU-T Object Identifier Repository
    https://oid-rep.orange-labs.fr/

12. RFC 5280：Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
    https://www.rfc-editor.org/rfc/rfc5280

13. RFC 5912：New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)
    https://www.rfc-editor.org/rfc/rfc5912

14. RFC 5911：New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME
    https://www.rfc-editor.org/rfc/rfc5911

15. RFC 8017：PKCS #1: RSA Cryptography Specifications Version 2.2
    https://www.rfc-editor.org/rfc/rfc8017

16. RFC 5208：Public-Key Cryptography Standards (PKCS) #8: Private-Key Information Syntax Specification Version 1.2
    https://www.rfc-editor.org/rfc/rfc5208

17. RFC 5958：Asymmetric Key Packages
    https://www.rfc-editor.org/rfc/rfc5958

18. RFC 5480：Elliptic Curve Cryptography Subject Public Key Information
    https://www.rfc-editor.org/rfc/rfc5480

19. RFC 3279：Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and CRL Profile
    https://www.rfc-editor.org/rfc/rfc3279

20. RFC 4055：Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and CRL Profile
    https://www.rfc-editor.org/rfc/rfc4055

21. RFC 5758：Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA
    https://www.rfc-editor.org/rfc/rfc5758

22. RFC 1155：Structure and Identification of Management Information for TCP/IP-based Internets
    https://www.rfc-editor.org/rfc/rfc1155

23. RFC 2578：Structure of Management Information Version 2 (SMIv2)
    https://www.rfc-editor.org/rfc/rfc2578

24. RFC 2579：Textual Conventions for SMIv2
    https://www.rfc-editor.org/rfc/rfc2579

25. RFC 2580：Conformance Statements for SMIv2
    https://www.rfc-editor.org/rfc/rfc2580

26. RFC 4512：Lightweight Directory Access Protocol (LDAP): Directory Information Models
    https://www.rfc-editor.org/rfc/rfc4512

27. RFC 4517：Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules
    https://www.rfc-editor.org/rfc/rfc4517

28. RFC 5652：Cryptographic Message Syntax (CMS)
    https://www.rfc-editor.org/rfc/rfc5652

29. NIST FIPS 180-4：Secure Hash Standard (SHS)
    https://csrc.nist.gov/pubs/fips/180-4/upd1/final

30. NIST FIPS 202：SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions
    https://csrc.nist.gov/pubs/fips/202/final

31. OID Repository https://oid-base.com

32. 3GPP TS 38.331 – NR; Radio Resource Control (RRC); Protocol specification 其中使用 ASN.1 定义 5G RRC 信令消息及大量 OID 引用