PKI(公钥基础设施)之数字证书及结构

1 介绍

公开密钥认证(英语:Public key certificate),又称公开密钥证书、公钥证书、数字证书(digital certificate)、数字认证、身份证书(identity certificate)、电子证书或安全证书,是用于公开密钥基础建设的电子文件,用来证明公开密钥拥有者的身份。

此文件包含了公钥信息、拥有者身份信息(主体)、以及数字证书认证机构(发行者)对这份文件的数字签名,以保证这个文件的整体内容正确无误。

拥有者凭着此文件,可向计算机系统或其他用户表明身份,从而对方获得信任并授权访问或使用某些敏感的计算机服务。计算机系统或其他用户可以透过一定的程序核实证书上的内容,包括证书有否过期、数字签名是否有效,如果你信任签发的机构,就可以信任证书上的密钥,凭公钥加密与拥有者进行可靠的通信。

2 证书类型

主要的数字证书类型有两类,一类是终端/叶子证书 (End-entity or leaf certificate),一类是CA证书(CA certificate)。
终端证书由CA证书签发的。根证书(Root CA certificate),中介证书(Intermediate CA certificate)都算是CA证书。

CA证书本身可以按以下类型进行分类:
- 自行颁发的证书(Self-issued certificate),这是CA证书,其中颁发者和主题是相同的CA。可以用于在密钥翻转操作期间提供来自旧证书到新密钥的信任。

- 自签名证书(Self-signed certificate),这是自行颁发证书的特殊情况,其中私钥使用CA签署证书对应于CA证书中认证的公钥。可以用于可能会使用自签名证书来宣传他们的公钥或其他有关他们的信息操作。

- 交叉证书(Cross-certificate),这是CA证书,其中颁发者和主题是不同的CA.
CA颁发证书给其他CA作为授权主体CA存在的机制(例如,严格的(等级)或识别主题CA的存在(例如,在分布式信任模型中)。该交叉证书结构用于这两者。

3 证书的结构

业界现行的公钥证书格式标准是X.509。X.509是用ASN.1(一种标准的语言)来进行描述,现在已经到X.509 v3版本。

3.1 基本的证书字段(Basic Certificate Fields)

证书的数据结构如下:
Certificate ::= SEQUENCE{
tbsCertificate TBSCertificate, -- 证书主体
signatureAlgorithm AlgorithmIdentifier, -- 证书签名算法标识
signatureValue BIT STRING --证书签名值,是使用signatureAlgorithm部分指定的签名算法对tbsCertificate证书主题部分签名后的值.}

将证书进一步展开,数据结构如下:


TBSCertificate 字段 描述
version 版本号 指出该证书使用了哪种版本的X.509标准(版本1、版本2或是版本3),版本号会影响证书中的一些特定信息
serialNumber 序列号 标识证书的唯一整数,由证书颁发者分配的本证书的唯一标识符
signature 签名算法标识符 用于签证书的算法标识,由对象标识符加上相关的参数组成,用于说明本证书所用的数字签名算法。例如,SHA-1-RSA
issuer 颁发者名称 证书颁发者的可识别名(DN),是签发该证书的实体唯一的CA的X.500名字
validity 有效期限 证书起始日期和时间以及终止日期和时间
subject 主体名 证书持有人的唯一标识符(或称DN-distinguished name)
subjectPublicKeyInfo 公钥信息 包括证书持有人的公钥、算法
issuerUniqueID 颁发者唯一标识符 标识符—证书颁发者的唯一标识符,仅在版本2和版本3中有要求,属于可选项
subjectUniqueID 主体唯一标识符 标识符—证书颁发者的唯一标识符,仅在版本2和版本3中有要求,属于可选项
extensions 扩展信息 证书扩展段,只在证书版本3中才有

以上结构除了extensions部分,其余部分构成基本的证书字段(Basic Certificate Fields)。而证书的扩展字段(Certificate Extensions Fields)。

3.2 证书的扩展字段(Certificate Extensions Fields)


Extensions部分的结构都是固定为三部分:
extnID:表示一个扩展元素的OID。
critical:表示这个扩展元素是否极重要,如果重要为TRUE,非重要则为FALSE。
extnValue:表示这个扩展元素的值,字符串类型。

常见的扩展部分如下:

Extensions extnID/OID critical extnValue
Authority Key Identifier
授权密钥标识符:它标识用于验证此证书或CRL上的签名的公钥。它使得能够区分由相同CA使用的不同密钥(例如,当发生密钥更新时)。
2.5.29.35 FALSE 详见RF5280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
Subject Key Identifier
主体密钥标识符:它使得能够区分相同主题使用的不同密钥(例如,当发生密钥更新时)。
2.5.29.14 FALSE 详见RF5280 Internet X.510 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
Key Usage
密钥使用:一个比特串,指明(限定)证书的公钥可以完成的功能或服务,如:证书签名、数据加密等。
2.5.29.15 DEFAULT FALSE
FALSE/TRUE
详见RF5280 Internet X.511 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
Certificate Policies
证书策略:由对象标识符和限定符组成,这些对象标识符说明证书的颁发和使用策略有关。
2.5.29.32 FALSE 详见RF5280 Internet X.512 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
Policy Mappings
策略映射:表明两个CA域之间的一个或多个策略对象标识符的等价关系,仅在CA证书里存在 。
2.5.29.33 TRUE 详见RF5280 Internet X.513 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
Subject Alternative Name
主体别名:指出证书拥有者的别名,如电子邮件地址、IP地址等,别名是和DN绑定在一起的。
2.5.29.17 DEFAULT FALSE
FALSE/TRUE
详见RF5280 Internet X.514 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
Issuer Alternative Name
颁发者别名:指出证书颁发者的别名,如电子邮件地址、IP地址等,但颁发者的DN必须出现在证书的颁发者字段。
2.5.29.18 FALSE 详见RF5280 Internet X.515 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
Subject Directory Attributes
主体目录属性:指出证书拥有者的一系列属性。可以使用这一项来传递访问控制信息。
2.5.29.9 FALSE 详见RF5280 Internet X.516 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
Basic Constraints
基本约束:指示主体是否可以充当CA,并使用经过认证的公钥来验证证书签名。如果是,则还可以指定认证路径长度约束。
2.5.29.19 DEFAULT FALSE
FALSE/TRUE
详见RF5280 Internet X.517 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
Name Constraints
名称约束:此扩展仅应在CA证书中使用,表示名称空间,在该名称空间中必须定位证书路径中后续证书中的所有主题名称。
2.5.29.30 DEFAULT FALSE
FALSE/TRUE
详见RF5280 Internet X.518 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
Policy Constraints
策略制约因素:指定可能需要显式证书策略标识的约束或禁止证书路径的其余部分的策略映射。
2.5.29.36 DEFAULT FALSE
FALSE/TRUE
详见RF5280 Internet X.519 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
Extended Key Usage
扩展密钥用法:指示可以使用经认证的公共密钥的一个或多个目的,除了或代替密钥用法扩展字段中指示的基本目的。
2.5.29.37 DEFAULT FALSE
FALSE/TRUE
详见RF5280 Internet X.520 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
CRL Distribution Points
CRL分布点:指明CRL的分布地点
2.5.29.31 DEFAULT FALSE
FALSE/TRUE
详见RF5280 Internet X.521 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
Inhibit anyPolicy
X.509版本3证书扩展禁止任何策略:在颁发给CA的证书中使用。
2.5.29.54 TRUE 详见RF5280 Internet X.522 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
Freshest CRL
最新CRL:RFC 3280 Internet X.509公钥基础结构第59页最新鲜的CRL扩展标识了如何获取此完整CRL的delta CRL信息。
2.5.29.46 FALSE 详见RF5280 Internet X.523 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
Authority Information Access
授权信息访问:指示如何访问CA.证书发行人的信息和服务扩展名出现。信息和服务可能包括在线验证服务和CA策略数据。
1.3.6.1.5.5.7.1.1 FALSE 详见RF5280 Internet X.524 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
Subject Information Access
主体信息访问:指示如何访问有关证书主体的信息和服务扩展。当主体是CA时,信息和服务可能包括证书验证服务和CA策略数据。
1.3.6.1.5.5.7.1.11 FALSE 详见RF5280 Internet X.525 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile

以下列出证书整体结构,如果加载不了的可以去百度网盘取。
链接:https://pan.baidu.com/s/1U8diSNpmeMRh4ojjb_tv_Q 提取码:k7nr


5 ASN.1编码规则

ASN.1编码规则包含基本编码规则(Basic Encoding Rules BER),规范编码规则(Canonical Encoding Rules CER)和区分编码规则(Distinguished Encoding Rules DER)。

5.1基本编码规则(Basic Encoding Rules BER)

BER的OID: {joint-iso-itu-t(2) asn1(1) basic-encoding(1)},2.1.1

5.1.1编码的结构

数据值的编码结构按顺序由以下四部分组成:

  1. 数据类型标识符(Tag)
  2. 数据内容长度(Length)
  3. 数据内容(Value)
  4. 数据结束标识(可选)
    所以根据是否包含结束标识符,编码结构有两种类型。

第一种

Tag Length Value

俗称TLV结构,是最常用,最简单的结构。

第二种

Tag Length Value End

这种结构只是某种特殊情况下才会用。

4.1.2数据类型标识符Identifier octets(Tag)

4.1.2.1编码规则

数据类型标识符(Identifier octets)是由下规则组成单个字节的值,其中Tag number范围从0到30(含)。这是最常见的编码规则。

  1. Bit 8 和 Bit 7表示Tag的类别。所以共有四种,分别是Universal(00)、Application(01)、Context-specific(10)和Private(11)。


  2. Bit 6只能为0或1。 0说明编码类型是简单类型,1说明编码是结构类型。
  3. Bit 5 到Bit 0则表示Tag number,其中Bit 5是最高位。

所以整个数据类型标识符(Identifier octets)的规则可以用以下图表示:



以下列表是Universal(00)系列常见简单类型的Tag值:

Class
(Bit8 Bit7)
P/C
(Bit 6)
Tag number
(Bit 5 to 0)
Description Value (Hex)
Universal(00) 0 (00000) reserved for BER
Universal(00) Primitive (0) 1 (00001) BOOLEAN [有两个值:false或true] 0x01 (0000 0001)
Universal(00) Primitive (0) 2 (00010) INTEGER [整型值] 0x02 (0000 0010)
Universal(00) Primitive (0) 3 (00011) BIT STRING [0位或多位] 0x03 (0000 0011)
Universal(00) Primitive (0) 4 (00100) OCTET STRING [0字节或多字节] 0x04 (0000 0100)
Universal(00) Primitive (0) 5 (00101) NULL 0x05 (0000 0101)
Universal(00) Primitive (0) 6 (00110) OBJECT IDENTIFIER [相应于一个对象的独特标识数字] 0x06 (0000 0110)
Universal(00) 7 (00111) OBJECT DESCRIPTOR [一个对象的简称]
Universal(00) 8 (01000) INSTANCE OF, EXTERNAL [ASN.1没有定义的数据类型]
Universal(00) Primitive (0) 9 (01001) REAL [实数值] 0x09 (0000 1001)
Universal(00) Primitive (0) 10 (01010) ENUMERATED [数值列表,这些数据每个都有独特的标识符,作为ASN.1定义数据类型的一部分] 0x0A (0000 1010)
Universal(00) 11 (01011) EMBEDDED PDV
Universal(00) Primitive (0) 12 (01100) UTF8String 0x0C (0000 1100)
Universal(00) 13 (01101) RELATIVE-OID
Universal(00) Constructed (1) 16 (10000) SEQUENCE, SEQUENCE OF 0x30 (0011 0000)
[有序数列,SEQUENCE里面的每个数值都可以是不同类型的,而SEQUENCE OF里是0个或多个类型相同的数据]
Universal(00) Constructed (1) 17 (10001) SET, SET OF 0x31 (0011 0001)
[无序数列,SET里面的每个数值都可以是不同类型的,而SET OF里是0个或多个类型相同的数据]
Universal(00) Primitive (0) 18 (10010) NumericString [0-9以及空格] 0x12 (0001 0010)
Universal(00) Primitive (0) 19 (10011) PrintableString 0x13 (0001 0011)
[A-Z、a-z、0-9、空格以及符号'()+,-./:=?]
Universal(00) Primitive (0) 20 (10100) TeletexString, T61String 0x14 (0001 0100)
Universal(00) Primitive (0) 21 (10101) VideotexString 0x15 (0001 0101)
Universal(00) Primitive (0) 22 (10110) IA5String 0x16 (0001 0110)
Universal(00) Primitive (0) 23 (10111) UTCTime [统一全球时间格式] 0x17 (0001 0111)
Universal(00) Primitive (0) 24 (11000) GeneralizedTime 0x18 (0001 1000)
Universal(00) Primitive (0) 25 (11001) GraphicString 0x19 (0001 1001)
Universal(00) Primitive (0) 26 (11010) VisibleString, ISO646String 0x1A (0001 1010)
Universal(00) Primitive (0) 27 (11011) GeneralString 0x1B (0001 1011)
Universal(00) 28 (11100) UniversalString
Universal(00) 29 (11101) CHARACTER STRING
Universal(00) Primitive (0) 30 (11110) BMPString 0x1E (0001 1110)

4.1.2.2特殊编码规则

可能有的人会问,如果Tag number超过30怎么办?那么就需要另外一种编码规则。
数据类型标识符(Identifier octets)必须由一个前导字节(leading octet),紧接着一个或多个次级字节(subsequent octets)组成

前导字节(leading octet)的规则如下:

  1. Bit 8 和 Bit7表示Tag的类别。所以共有四种,分别是Universal(00)、Application(01)、Context-specific(10)和Private(11)。与上述5.1.2.1没有区别。
  2. Bit 6只能为0或1。0说明编码类型是简单类型,1说明编码是结构类型。与上述5.1.2.1没有区别。
  3. Bit 5 到Bit 0固定为0b 11111即全为1。

次级字节(subsequent octets)的规则如下:

  1. Bit 8 必须固定为1,除非是最后一个字节。
  2. Bit 7 到 Bit 1 表示为Tag number。
  3. 第一个的次级字节(subsequent octets)中Bit 7 到Bit 1不能全为0。

所以特殊数据类型标识符(Identifier octets)的规则可以用以下图表示:


4.1.2.3 IMPLICIT,EXPLICIT介绍

(1)一个类型被声明了IMPLICIT tag,编码时会用新的tag。即IMPLICIT前面[]括号中的值替换旧的值(IMPLICIT后面[]括号中的tag值或universal tag)。

例如:
Number1:: = INTEGER
Number2:: = [1] INTEGER
Number1的tag值为2,Number2 的tag值都是1。

然后将其声明为IMPLICIT tag后
Number1 ::= [0] IMPLICIT INTEGER
Number2 ::= [0] IMPLICIT [1] INTEGER
Number1,Number2 的tag值都是0。

另外复合类型sequence,set被声明了IMPLICIT tag,那么它的成员和成员的成员都默认为IMPLICIT,除非手工为这些成员设定了另外的tag模式。
例如:
Msg ::= [0] IMPLICIT SEQUENCE
{
YourIncome [0] INTEGER OPTIONAL,
YourDebit [1] INTEGER OPTIONAL,
AccountedClosed [2] EXPLICIT BOOLEAN
}
Msg 的YourIncome, YourDebit成员的tag是 IMPLICIT模式。AccountedClosed成员tag是
EXPLICIT模式。

(2)一个类型被声明了 EXPLICIT tag,编码时会在旧的tlv基础上嵌套一层新TLV。T是
EXPLICIT tag值,L是旧tlv的长度,V即原tlv。
例如:
Record::=SEQUENCE{
......
time [1] EXPLICIT Time OPTIONAL,
......
}

Time::=CHOICE{
utcTime UTCTime,
generalizedTime GeneralizedTime
}

假设time被赋值为UTCTime类型的值080808120000Z,运用显式标签,上例描述为:
编码规则如下:
T              L                   V
A0+Tag序号   原TLV格式编码的总长度   原TLV格式编码
上例中time=080808120000Z的编码为:
T     L               V
A1   0F   17 0D 30 38 30 38 30 38 31 32 30 30 30 30 5A

注:DER编码时,对于加了标签的项目,按如下规则编码:
对于简单类型,type=80+tag序号;对于构造类型,type=A0+tag序号。length和value不变。

再举个例子:
Type1 ::= VisibleString
Type2 ::= [APPLICATION 3] IMPLICIT Type1
Type3 ::= [2] Type2
Type4 ::= [APPLICATION 7] IMPLICIT Type3
Type5 ::= [2] IMPLICIT Type2

"Jones"按照以下编码:
For Type1:
VisibleString   Length   Contents
1A           05     4A6F6E6573
注:VisibleString 的type为0x1A (Universal(00)+ Primitive (0) + Tag number(11010) = 0001 1010)。

For Type2:
[Application 3]     Length     Contents
43              05    4A6F6E6573
注:VisibleString 的type为0x43( Application(01)+ Primitive (0) + Tag number(00011) = 0100 0011)。

For Type3:
[2]    Length                   Contents
A2    07          [APPLICATION 3]     Length     Contents
                      43            05      4A6F6E6573
注:VisibleString 被默认声明为EXPLICIT,会再次嵌套一次TLV结构。其中type为0xA2(Context-specific (10)+ Constructed (1) + Tag number (00010) = 1010 0010)。

For Type4:
[Application 7]   Length               Contents
67            07    [APPLICATION 3]       Length         Contents
                        43              05        4A6F6E6573
注:VisibleString 的type为0x67( Application(01)+ Constructed (1) + Tag number(00111) = 0110 0111)。

For Type5:
[2]     Length       Contents
82      05      4A6F6E6573
注:VisibleString 的type为0xA2(Context-specific (10)+ Primitive (0) + Tag number(00010) = 1000 0010)。

4.1.2.3 ANY,CHOICE,OPTIONAL、DEFAULT等关键字

构造类型的定义中,常常包含CHOICE、ANY、OPTIONAL、DEFAULT等关键字,其编码规则如下:

(1)CHOICE
表示一个联合体即多选一,按照实际选中的类型编码。举例:
Time::=CHOICE{
utcTime UTCTime,
generalizedTime GeneralizedTime
}
若实际用到的类型是UTCTime,则数据用UTCTime的编码规则编码。

(2)ANY
类型依赖于另一个域的值,则按照实际类型编码。举例:
AlgorithmIdentifier::=SEQUENCE{
algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY algorithm OPTIONAL
}
若algorithm的值表示RSA,则parameters按RSA算法的参数类型编码;若algorithm的值表示Diffie-Hellman算法,则parameters按Diffie-Hellman算法的参数类型编码。

(3)OPTIONAL
所标记的字段在实际中可能存在,也可能不存在。如果有值,则编码;如果无值,则直接跳过。举例:
AlgorithmIdentifier::=SEQUENCE{
algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY algorithm OPTIONAL
}
实际中,如果没有参数parameters,则相当于
AlgorithmIdentifier::=SEQUENCE{
algorithm OBJECT IDENTIFIER
}

(4)DEFAULT
如果所标记的字段在实际中正好等于缺省值,则可以编码也可以不编码,相当于是OPTIONAL;如果不等于缺省值,则应该如实编码。举例:
Certificate::=SEQUENCE{
version Version DEFAULT 0
......
}
若version的值恰好等于0(缺省值),则可以不编码;否则,必须按其类型编码。

4.1.3数据内容长度Length octets(Length)

长度字段有两种编码规则,定长形式(definite form)和不定长形式(indefinite
form)。

4.1.3.1定长形式(definite form)

定长形式规则编码方式为:

假定内容的长度为X,则

长度X范围 组成 举例 都是大端(big-endian)字节序
0<X<128 Y = X X = 56,即X = 56,则 Length为0x38
128<= X <256 一个由连接0x81 || Y组成的字符串, 其中Y为一个字节长度,Y = X。 X = 200,即0XC8,则 Length为0x81C8(大端模式)。 81的1表示81后面还有一个字节。
256<= X <65,536 一个由连接0x82 || Y组成的字符串, 其中Y为两个字节长度,Y = X。 X = 5000,即0x1388,则 Length为0x821388(大端模式)。 82的2表示82后面还有两个字节。
65,536<= X <16,777,216 一个由连接0x83 || Y组成的字符串, 其中Y为三个字节长度,Y = X。 X = 80000,即0x013880,则 Length为0x83013880(大端模式)。 83的3表示83后面还有三个字节。
以此类推…
禁止用法 一个由连接0xFF || Y组成的字符串 其中Y为127个字节长度,Y = X。 这种组合非法。 即X合法长度为 1 ~ 126个字节。

4.1.3.2不定长形式(indefinite form)

Length 固定为0x80,表示数据内容长度不定,由数据结束标识作为数据结束。

4.1.4数据内容Contents octets(Value)

数据内容由零个,一个或多个字节组成,由相应的数据类型决定。

4.1.5数据结束标识End-of-contents octets(可选)

由两个字节全0表示,即0x0000。只会在上述不定长(indefinite form)中即Length固定为0x80才会出现。
注:如果在TLV表示中,Tag为0x00,Length为0x00,Value缺失,就会跟上述两个字节缺失的情况一致。

Tag Length Value
00 00 缺失

4.2规范编码规则(Canonical Encoding Rules CER)和区分编码规则(Distinguished Encoding Rules DER)

规范编码规则的OID: {joint-iso-itu-t(2) asn1(1) ber-derived(2) canonical-encoding(0)}, 2.1.2.0
区分编码规则的OID: {joint-iso-itu-t(2) asn1(1) ber-derived(2) distinguished-encoding(1)},2.1.2.1

此章节详细待续!

附录 A OID 介绍及使用

对象标识符或OID是由国际电信联盟(ITU)和ISO / IEC标准化的标识符机制,用于命名具有全局明确的持久名称的任何对象,概念或“事物”。
OID对应于“OID树”或层次结构中的节点,其使用ITU的OID标准X.660正式定义。树中的每个节点由一系列整数表示,这些整数由句点分隔,对应于从根到祖先节点系列到节点的路径。

1 OID解析
举例:证书里面的Key usage的OID是2.5.29.15,解析如下:


第一个joint-iso-itu-t(2)是顶级/根OID,里面的2表示ISO / ITU-T联合分配。
同级的顶级OID如下:
0 - ITU-T分配
1 - ISO分配
2 - ISO / ITU-T联合分配

第二个ds(5)是次级OID,里面5表示X500目录服务。
部分同级的OID(第二级)部分如下:
2.1 - ASN.1 (JTC 1.21.17.05;21.17.06, Q19/VII)
2.2 - Association Control (ACSE)
2.3 - Reliable Transfer (RTSE)
2.4 - Remote Operations (ROSE)
2.5 - X.500 Directory Services
2.6 - X.400 Messaging services
2.7 - Commitment, concurrency and recovery
2.8 - ODA
2.9 - OSI Management
2.16 - Joint assignments by country
2.23 - International organizations
2.25 - UUID arc

第三个certificateExtension(29)是证书扩展部分id-ce。
部分同级的OID(第三极)如下:
2.5.1 - X.500 modules
2.5.2 - X.500 service environment
2.5.3 - X.500 application context
2.5.4 - X.500 attribute types
2.5.5 - X.500 attribute syntaxes
2.5.6 - X.500 standard object classes
2.5.7 - X.500 attribute sets
2.5.8 - X.500 defined algorithms
2.5.9 - X.500 abstract syntaxes
2.5.12 - DSA Operational Attributes
2.5.13 - Matching Rule
2.5.14 - X.500 knowledge Matching Rules.
2.5.15 - X.500 name forms
2.5.16 - X.500 groups
2.5.17 - X.500 subentry
2.5.18 - X.500 operational attribute type
2.5.19 - X.500 operational binding
2.5.20 - X.500 schema Object class
2.5.21 - X.500 schema operational attributes
2.5.22 - unused
2.5.23 - X.500 administrative roles
2.5.24 - X.500 access control attribute
2.5.25 - X.500 ros object
2.5.26 - X.500 contract
2.5.27 - X.500 package
2.5.28 - X.500 access control schema
2.5.29 - certificateExtension (id-ce)
2.5.30 - managementObject (id-mgt)

第四个keyUsage(15)表示证书中的公钥用途。
部分同级的OID(第四级)如下:
2.5.29.1 - old Authority Key Identifier
2.5.29.2 - old Primary Key Attributes
2.5.29.3 - Certificate Policies
2.5.29.4 - Primary Key Usage Restriction
2.5.29.9 - Subject Directory Attributes
2.5.29.14 - Subject Key Identifier
2.5.29.15 - Key Usage
2.5.29.16 - Private Key Usage Period
2.5.29.17 - Subject Alternative Name
2.5.29.18 - Issuer Alternative Name
2.5.29.19 - Basic Constraints
2.5.29.20 - CRL Number
2.5.29.21 - Reason code
2.5.29.23 - Hold Instruction Code
2.5.29.24 - Invalidity Date
2.5.29.27 - Delta CRL indicator
2.5.29.28 - Issuing Distribution Point
2.5.29.29 - Certificate Issuer
2.5.29.30 - Name Constraints
2.5.29.31 - CRL Distribution Points
2.5.29.32 - Certificate Policies
2.5.29.33 - Policy Mappings
2.5.29.35 - Authority Key Identifier
2.5.29.36 - Policy Constraints
2.5.29.37 - Extended key usage
2.5.29.46 - FreshestCRL
2.5.29.54 - X.509 version 3 certificate extension Inhibit Any-policy

注:对OID感兴趣的可以访问网址https://www.alvestrand.no/objectid/top.htmlhttp://www.oid-info.com/,里面有更详细的解释。这里只是介绍跟X509有关的OID。

2 OID值转化
对象标识符(OID),是一个用“.”隔开的非负整数组成的序列。
在实际应用中,可能需要将OID值转化为实际十六进制值。那么下面说说OID的编码规则。

设OID=V1.V2.V3.V4.V5....Vn,则DER编码的value部分规则如下:
(1)计算40*V1+V2作为第一字节;
(2)将Vi(i>=3)表示为128进制,每一个128进制位作为一个字节,再将除最后一个字节外的所有字节的最高位置1;
(3)依次排列,就得到了value部分。

举例:OID=1.2.840.11359.1.1的编码如下:


.png

注:以上规则可以在以下两个文档找到
1 NIST.SP.800-32 Introduction to Public Key Technology and the Federal PKI Infrastructure.pdf
2 NIST.SP.800-25 Federal Agency Use of Public Key Technology for Digital Signatures and Authentication.pdf

参考资料

1 维基百科 https://en.wikipedia.org/wiki/Public_key_certificate
2X.509证书的编码及解析:程序解析以及winhex模板解析http://www.cnblogs.com/jiu0821/p/4598352.html
3 https://www.cnblogs.com/nliao/archive/2012/02/15/2352887.html
4 https://blog.csdn.net/sever2012/article/details/7767867
5 https://www.cnblogs.com/jiu0821/p/4598352.html

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,456评论 5 477
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,370评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,337评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,583评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,596评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,572评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,936评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,595评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,850评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,601评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,685评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,371评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,951评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,934评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,167评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 43,636评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,411评论 2 342

推荐阅读更多精彩内容

  • PKI 基础知识 (摘自Microsoft Windows 2000 Server白皮书,2000年7月5日发布)...
    right_33cb阅读 943评论 0 1
  • 摘要 本白皮书介绍了加密和公钥基本结构(PKI)的概念和使用 Microsoft Windows 2000 Ser...
    陈sir的知识图谱阅读 963评论 0 1
  • "证书 -- 为公钥加上数字签名" 要开车得先考驾照.驾照上面记有本人的照片、姓名、出生日期等个人信息.以及有效期...
    泡泡龙吐泡泡阅读 2,987评论 1 2
  • 数字证书就是网络通讯中标志通讯各方身份信息的一系列数据,其作用类似于现实生活中的身份证。它是由一个权威机构发行的,...
    拉肚阅读 21,105评论 1 17
  • 第三十七章 指点“江山” 一周的时间,让Jerry又有了新的积攒,而此时的他,带着新的朋友以及更充足的信心,早早...
    九韦的猪阅读 387评论 0 2