当前位置:文档之家› RFC2459(中文版)

RFC2459(中文版)

RFC2459(中文版)
RFC2459(中文版)

Internet X.509 公钥基础设施

证书和CRL简介

(Internet X.509 Public Key Infrastructure

Certificate and CRL Profile)

备忘录现状

这份文档需要Internet社区进一步讨论和改进的Internet试验标准协议。关于这份文档的标准化情况和状态请参阅"Internet官方协议标准"(STD1)组织的当前版。这份备忘录分发不受限制。

版权声明

Copyright (C)The Internet Society (1999)。版权所有。

摘要

这份备忘录描述了应用在Internet中的X.509 v3证书和X.509 v2CRL(证书撤销列表),以接近的综述和模型引入介绍。X.509 v3证书格式随着关于Internet名字(例如IP地址)的格式和语义学附加信息被描绘。标准证书扩展被描绘和新的Internet-specific(特有扩展)被定义。一套证书扩展被指定。同时X.509 v2 CRL格式被描绘和一套扩展被定义。一组X.509证书路径确认算法被描述。X.509证书中通用Internet公开密钥密码算法(即RSA,DSA和Diffie-Hellman)的公开密钥和数字签名的格式在补充信息中提供描述。ASN.1模块和例子在附录中提供。

约定:

本文中的关键词"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED","MAY",以及"OPTIONAL"与RFC 2119【3】中的描述的意义是相同的。

目录

1介绍 (5)

2要求和假定 (5)

2.1通讯和拓扑 (6)

2.2可以接受的标准(Acceptability Criteria) (6)

2.3用户期望 (6)

2.4行政管理人员期望 (7)

3 概览 (7)

3.1 X.509 v3证书 (8)

3.2证书路径和信任 (9)

3.3撤销 (10)

3.4操作协议 (11)

3.5管理协议 (11)

4证书和证书扩展项概要 (12)

4.1基本证书字段 (12)

4.1.1证书字段 (13)

4.1.1.1 tbsCertificate (14)

4.1.1.2 signatureAlgorithm (14)

4.1.1.3 signatureValue (14)

4.1.2 TBSCertificate (15)

4.1.2.1版本 (15)

4.1.2.2序列号 (15)

4.1.2.3签名 (15)

4.1.2.4发行者 (15)

4.1.2.5有效性 (18)

4.1.2.5.1 UTCTime (18)

4.1.2.5.2 GeneralizedTime (19)

4.1.2.6主题 (19)

4.1.2.7主题公开密钥信息 (20)

4.1.2.8唯一标识符 (20)

4.1.2.9扩展 (20)

4.2标准证书扩展 (20)

4.2.1标准扩展 (21)

4.2.1.1权威密钥标识符 (22)

4.2.1.2主题密钥标识符 (22)

4.2.1.3 密钥使用 (23)

4.2.1.4私有密钥使用周期 (25)

4.2.1.5证书策略 (25)

4.2.1.6策略映射 (27)

4.2.1.7主题可替换名字 (27)

4.2.1.8发行者可替换名字 (29)

4.2.1.9主题目录服务系统属性 (30)

4.2.1.10基本约束 (30)

4.2.1.11名字约束 (30)

4.2.1.12策略约束 (32)

4.2.1.13扩大密钥使用领域 (33)

4.2.1.14 CRL发布点 (34)

4.2.2私有Internet扩展 (35)

4.2.2.1权威信息存取 (35)

5 CRL和CRL扩展简介 (36)

5.1 CRL字段 (37)

5.1.1 CertificateList字段 (37)

5.1.1.1 tbsCertList (38)

5.1.1.2 signatureAlgorithm (38)

5.1.1.3 signatureValue (38)

5.1.2证书列表" To Be Signed" (38)

5.1.2.1版本 (39)

5.1.2.2签名 (39)

5.1.2.3发行者名字 (39)

5.1.2.4更新 (39)

5.1.2.5下次更新 (40)

5.1.2.6撤销证书 (40)

5.1.2.7扩展 (40)

5.2 CRL扩展 (40)

5.2.1权威密钥标识符 (41)

5.2.2发行者可替换名字 (41)

5.2.3 CRL Number (41)

5.2.4 Delta CRL标识符 (42)

5.2.5发行发布点 (42)

5.3 CRL入口扩展 (43)

5.3.1理由代码 (43)

5.3.2保持指示代码 (44)

5.3.3无效日期 (45)

5.3.4证书发行者 (45)

6证书路径批准 (45)

6.1基本路径批准 (46)

6.2扩展路径批准 (49)

7算法技术支持 (49)

7.1个单向哈希函数 (49)

7.1.1 MD2单向哈希函数 (50)

7.1.2 MD5单向哈希函数 (50)

7.1.3 SHA1单向哈希函数 (50)

7.2签名算法 (50)

7.2.1 RSA签名算法 (51)

7.2.2 DSA签名算法 (52)

7.3主题公开密钥算法 (52)

7.3.1 RSA密钥 (53)

7.3.2 Diffie-Hellman密钥交换密钥 (53)

7.3.3 DSA签名密钥 (55)

8参考资料 (56)

9知识产权 (58)

10安全考虑 (58)

附录A. PsuedoASN.1结构和OIDs .............................................................. 错误!未定义书签。

A.1 明示目标模块(Explicitly Tagged Module),1988句法 ............ 错误!未定义书签。

A.2 隐式目标模块(Implicitly Tagged Module), 1988 句法 ........... 错误!未定义书签。附录

B. 1993 ASN.1 结构 and OIDs ........................................................... 错误!未定义书签。

B.1 明示目标模块(Explicitly Tagged Module), 1993 句法............ 错误!未定义书签。

B.2 隐示目标模块(Implicitly Tagged Module), 1993 句法............ 错误!未定义书签。附录

C. ASN.1 注解 ..................................................................................... 错误!未定义书签。附录

D. 示例................................................................................................. 错误!未定义书签。

D.1 证书................................................................................................. 错误!未定义书签。

D.2 证书................................................................................................. 错误!未定义书签。

D.3 RSA算法终端证书 ......................................................................... 错误!未定义书签。

D.4 证书撤销列表................................................................................. 错误!未定义书签。附录

E. Authors' Addresses ............................................................................ 错误!未定义书签。附录

F.完整版权声明..................................................................................... 错误!未定义书签。

1介绍

本文作为Internet中X.509公开密钥基础设施(PKI)标准家族的一部分,同时也是独立的文件;另外这套标准的执行可能继续同其他部分分开。

本文介绍了应用于Internet PKI证书和证书撤销列表的格式和语义学。描述了在Internet 环境中证书路径的处理,提供密码学算法的编码规则。最后,在附录中以ASN.1语法形式描述了本文出现的所有数据结构定义。

本文描绘了能激起完善本文档的激情和影响它的在部分2中(范围)的假定。第3段引见一个结构的模块以及描绘它们和前一IETF和ISO/IECITU标准的关系。特别是本文IETF PEM描述和ISO/IEC ITU X.509文档之间的关系。

本文在部分4中介绍了X.509 v3证书;在部分5中介绍了X.509 v2证书撤销列表(CRL)。包括在Internet PKI中有效的ISO/IEC/ITU和ANSI扩展的定义。本文使用的是1988年定义的摘要句法注释1(ASN.1),而不是在1994年在ISO/IEC/ITU定义的语法标准。

本文还在部分6中说明了路径确认过程。这些过程基于在ISOIEC/ITU上的定义,但是颁发假定一个或多个自我签名受信任的CA证书,只需要得到同样的结果,而不需要制定具体的处理过程。

本文第7部分描绘公开密钥内容和数字签名的确认和编码的过程。不需要任何特别的密码学算法,然而需要能识别出(这些)算法,这些算法能被识别出并可编码。

最后,四个附录中提供了implementers(应用)帮助。附录A包含所有的在本文说明以内或者推荐的ASN.1结构。正如上面所说的,这些数据结构的描述应用1988的摘要语法注释1(ASN.1),而不是1994的句法。附录B包含了同样的信息,这些信息使用作为更新的toolsets(工具集)的implementers(应用)服务的1994 ASN.1注释。但是,附录A采取时间次序以防冲突。附录C包含关于在本文说明以内使用ASN.1注释的不那么熟悉特征的笔记。附录D含有证书和CRL的例子。

2要求和假定

本文的目标是提供帮助,以方便在那些Internet社区内希望利用X.509技术申请X.509证书的使用。这些应用包括WWW、电子邮件、用户证明和Ipsec等。为了减轻某些使用X.509证书的障碍,本文定义了促进证书管理系统发展的轮廓;应用工具的发展;和按照可由双方共同制定的策略。

为了附加(额外)批准,保证或者操作上的要求符合专门的应用领域、或者环境的要求,一些社区将需要补充、或许取代本文的(某些)描述。但是,为了基本应用,那些经常用的属性和共用的代表被定义出来,以便应用开发者能得到必要知识,而不管证书或者证书撤销列表(CRL)的发行者。

在信赖之前,一个证书用户应该浏览证书策略,由证书权威机构(CA,以下统称CA)所产生的授权或者非拒绝服务,这些服务和一个特定证书中的公开密钥联系起来。为此目的,这标准不定义合法捆绑的规则或者职责。

当补充授权和属性管理工具出现时,例如属性证书,它适合限制在一张证书内的授权的属性证明。这些(其它的、辅助的)管理工具可以提供表达很多属性授权的更适合方法。

2.1通讯和拓扑

使用证书的用户将在关于他们的通讯拓扑环境中,特别是安全电子邮件的用户的宽阔范围中操作。本文支持那些没有高带宽,实时IP连接或者高连接可用(high connection availability)的可能性用户。此外,本文允许防火墙或者(其他)过滤通讯设备的存在。

本文不假定X.500目录服务系统的展开。本文不禁止X.500目录服务系统的使用,但是发布证书和证书撤销列表(CRLs)的(其他)另一手段可以被使用。

2.2可以接受的标准(Acceptability Criteria)

Internet公开密钥基础设施(PKI)的目标是要满足决定论(deterministic),自动化确认,认证,存取控制授权功能的需求。支持这些服务是通过包含在证书中的属性,以及一些从属的控制信息,例如证书中策略数据和证书路径约束。

2.3用户期望

Internet PKI的用户是在证书中使用客户软件和主题名字的人们和过程。他们包括那些使用电子邮件的读者和作者,WWW浏览器客户,WWW服务器和路由器中Ipsec的密钥管理。本文识别那些使用局限性平台和局限于老于世故和注意的用户自己。这个在极小用户配置责任(例如受信任的CA密钥,规则),明确在证书中的平台使用约束,证书路径约束以及自动的验证有效性功能,使其保护用户免受很多恶意行为。

2.4行政管理人员期望

和用户期望一样,Internet PKI是有结构地支持通常运作CAs的个体。为行政管理人员提供无边际的选择以减少CA行政管理人员微妙错误造成的宽广损害结果的机会。同时,无边际的选择造成处理和验证由CA中心签发证书的有效性软件的复杂化。

3 概览

下面是按照PKIX标准本文说明的假定结构模范视图。

+---+

| C | +------------+

| e | <-------------------->| End entity |

| r | Operational +------------+

| t | transactions ^

| | and management | Management

| / | transactions | transactions

| | | PKI users

| C | v

| R | -------------------+--+-----------+----------------

| L | ^ ^

| | | | PKI management

| | v | entities

| R | +------+ |

| e | <---------------------| RA | <---+ |

| p | Publish certificate +------+ | |

| o | | |

| s | | |

| I | v v

| t | +------------+

| o | <------------------------------| CA |

| r | Publish certificate +------------+

| y | Publish CRL ^

| | |

+---+ Management |

transactions |

v

+------+

| CA |

+------+

图1-PKI实体

这个模型组成部分包括:

?末端实体(end entity):PKI证书或者最终用户证书主题系统的用户;

?CA:证书授权中心;

?RA:证书登记中心,即一个可选的由CA委派的具有管理功能的代表系统;

?存储:一个系统或者收集的分配系统,存储分配给末端实体的证书和CRLs以及服务。

3.1 X.509 v3证书

公开密钥的用户将是对结合私有密钥被确定的远程主体(人或者系统),这些实体将使用加密或者签名算法。信任是通过证书中公开密钥的使用而得到,证书是绑定公开密钥到主题信息的数据结构。捆绑通过信任的CA数字签名的证书,CA可以基于这样的技术手段(a.k.a.,posession的通过“挑战反应”协议证明)断言,或者有关一个按照主题断言的私有密钥的描述上。每张证书在它的签名内容中都有生命期。因为每张证书的签名和生命期在证书使用的客户端是独立检查的,证书能够(可以)在不受信任的通讯和服务器系统中传输也能在证书使用系统中非安全存储。

ITU TX.509(过去CCITT X.509)或者ISO/IEC ITU9594-8定义一标准证书格式[X.509],首先在1988年作为X.500目录服务系统推荐的一部分出版。在1988标准中证书格式称为版本1(v1)格式。当X.500在1993年修正的时候,在版本2(v2)格式中增加一额外的两个字段。这两个字段可以使用来支持目录服务系统的存取控制。

在1993年出版的Internet隐私增强邮递(PEM)RFCs,包含在X.509 v1证书[RFC 1422]的基础上公开密钥基础设施建立说明。在部署RFC 1422的尝试中获得经验明确表示v1和v2证书格式在几个方面不足。最重要的是在PEM设计和应用经验已证明需要携带更多的信息。面对这些新的要求,ISO IEC/ITU和ANSI X9开发了X.509版本3(v3)证书格式。v3格式在v2基础上通过扩展添加额外的字段(扩展字段)。特殊的扩展字段类型可以在标准中或者可以由任何组织或者社区定义和注册。在1996年6月,基本v3格式的标准化被完成[X.509]。

同时ISO IEC/ITU和ANSI X9为在v3扩展字段[X.509][X9.55]中使用发展标准范围。这些扩展能表达像附加主题确认信息、密钥属性信息、策略信息和证书路径约束这样的数据。

然而ISO IEC/ITU和ANSI X9标准扩展在他们的应用中是非常宽广的。为了开发Internet 使用X.509 v3系统可由双方共同操作的工具,指定一本文作为使X.509 v3扩展适合Internet 的使用是必要的。它是本文的一个目标,指定一本文作为Internet WWW,电子邮件和IPsec 应用。同时随着附加要求环境的改变可以建设本文或者可以取代它。

3.2证书路径和信任

作为安全服务的用户通常需要公开密钥如何获得以及需要公开密钥验证证书有效性方面的知识。如果公开密钥用户还没有一份由CA签发的证书的公开密钥拷贝、CA的名字和相关信息(例如有效期和名字约束),然后它可能需要一张附加证书得到公开密钥。一般地说,需要经过CA签发的一系列多重证书公开密钥所有者(末端实体)和其它CAs签发的零张或更多附加CAs证书。这样的链被称作证书路径,因为一个公开密钥用户仅用有限CA 的数目签发。

CAs可以有不同的方式被配置为了公开密钥用户能查找证书路径。在PEM,RFC 1422定义了CAs的严格等级制度的结构。有三类型的PEM证明授权中心:

(a)Internet策略注册授权中心(IPRA):这个授权中心,作为PEM证书等级制度的

根(等级1),预兆Internet社会的权力。为下一级发行证书,称为PCAs。所有

的证书路径以IPRA开始。

(b)策略授权中心(PCAs):每个PCA由IPRA等级制度中授权,PCAs在等级制定

中处于2级。PCA将建立和发表它关于确认用户或者下属认证权威(当局)策略

的声明。不同PCAs目标是符合不同用户的需要。例如,一PCA(一组织的PCA)

可以支持普遍电子邮件商业组织的需求,而另一PCA(一高保证(high-assurance )

PCA)可以有一更严格策略设计去符合合法捆绑的数字的签名要求。

(c)授权中心(CAs):CAs是在等级制度的第3级,可能也是在低水平方面。在第3

级被PCAs授权。CAs代表特殊组织,例如特定组织的单位(例如区,组织,

部门)或者特定地理区域。

此外RFC 1422还有一名字下级定义规则,其要求一CA仅能为名字是CA本身从属的实体(在X.500命名树中)颁发证书。使用PCA名字意味着把信任和一PEM证书路径联系起来。名字下级定义规则保证在PCA以下的CAs针对他们从属能验证的实体是敏感强迫的(例如,一CA仅能验证在那个特定组织名字树中的实体)。证书用户系统有能力用机器检查遵守名字下级定义的规则。

RFC 1422使用X.509 v1证书格式。X.509 v1的局限性要求征收对清楚地限制结合的策略或者限制证书的功用的几个结构上。这些限制包含:

(a)伴随所有的从IPRA开始的证书路径的纯粹上下(top-down)等级制度;

(b)限制一CA的主题名字下级命名规则;以及

(c)使用需要个人PCAs的知识构建证书逻辑的验证链条的概念。个人PCAs的知识

决定是否链条能被接受。

经过RFC 1422的呼吁请求使用证书扩展,使用X.509 v3不需要限制使用CA结构的使用。特别是,和证书政策相关联的证书扩展排除PCAs的需要以及扩展约束排除下级名字定义规则的需要。因此,本文支持更有弹性的证书结构,包含:

(a)证书路径可以在一个用户的自己领域中CA的公开密钥或者等级制度顶部的公开

密钥开始。开始于一个用户的自己领域中CA的公开密钥确实有优势。在一些环

境中,本地领域是最受信任的。

(b)名字约束可以通过在证书中的名字约束扩展的明确被接收,但不作为要求。

(c)策略扩展和策略映射代替允许一定程度的自动化PCA概念。应用程序应该能决

定是否接受把证书路径建立在代替PCAs的先验知识的证书的目录的基础上。这

允许证书链条处理的自动化。

3.3撤销

当一张证书被颁发的时候,预期它是在它的整个有效期内使用。但是,各种各样境况可能导致一张证书在有效期满期之前变得无效。这样境况包含名字的改变,在主题和CA之间联合的改变(例如,一雇员结束在一个组织的工作),以及损害或者怀疑相应的私有密钥。在这样情况下,CA需要撤销证书。

X.509定义一种证书撤销的方法。这方法需要CA周期性地发布称为证书撤销列表(CRL)的由CA签名的数据结构。CRL是盖了时间印章的经过CA签名的自由发布长期有效的能识别出被撤销证书的清单。每一个撤销证书在CRL中通过证书序列号识别出。当一证书使用系统使用证书(例如,验证一个远程用户的数字签名),那个系统不仅需要检验证书签名和有效性而且需要在最近发布的CRL中检验证书序列号不在其中。"最近发布"的意思是可能随着本地策略改变,但是它通常意味着最近一次发行的CRL。CA按照正常周期(例如,每隔一小时,每天或者每周)发行一次新的CRL。也有可能随着撤销通知的到来而发布下一个新的信息被加入到CRL。这个时刻可能出现在一正常CRL发布周期之后不久,而远离下一次发布的周期。

这种撤销算法的优势是CRLs可以准确地和证书发布同样的做法经由不受信任的通讯和服务器系统传播。

CRL撤销算法的一个局限是在不受信任的通讯和服务器限制CRL颁发周期撤销的时间粒度。例如,如果撤销现在发布,那撤销将不能保证通知证书应用系统,直到下一个周期CRL被发布,这可能是一个小时、一天或者一星期,CA发行CRLs取决于频率。

和X.509 v3证书格式一样,为了便于(支持)从多重销售商共同操作的工具,X.509 v2CRL格式应该是为Internet使用描述轮廓。这是(指定)本文的一个目标。但是,本文不要求CAs发行CRLs。支持联机(On-line)撤销通知信息格式和协议可以在其它PKIX文本中定义(中找到)。撤销通知的联机方法可以是适用于一些可选择X.509 CRL的环境。联机

撤销检查可以在相当大的程度上减少在(一份)撤销报告之间和信息分配依赖双方的潜伏。CA一旦接受的报告是可靠的和有效的,任何联机服务问题将正确反映出撤销的证书批准影响。但是,这些方法需要新的安全要求;当仓库(repository)不应该受信任的同时,证书生效者将指望联机批准服务。

3.4操作协议

操作协议要求将证书和CRLs (或者状况信息)传递给客户证书应用系统。为各种各样的证书和CRL提供不同传递,包括基于LDAP、HTTP、FTP和X.500的发布过程。支持这些操作的草案在其它PKIX文本说明中被解释。这些本文说明可以包含信息格式和支持全部的上述操作的环境,包含适合MIME内容类型的定义或者参考过程的定义。

3.5管理协议

管理协议需要支持在PKI用户和管理实体之间联机相互作用。例如,管理协议随着相关联的密钥对可以在CA和客户系统之间被使用,或者在两CAs之间的交叉认证。这套功能应该潜在地按照管理协议支持,包含:

(a)登记:这是一个过程,通过它用户自身先于CA发布证书给那个用户知道CA在

哪(直接或者通过RA)。

(b)初始化:在一客户系统能安全运作之前,把密钥安装在其适合储藏密钥的其它地

方是必要的。例如,客户应该安全地在受信任的CA(s)的公开密钥和另一被保

险人信息初始化有效证书路径方面被使用。此外,一个客户(典型)应该用它自

己的密钥对初始化。

(c)认证:这是个过程,其中CA为一个用户的公开密钥发行一张证书,并且把那张

证书传递到用户的客户系统和/或在仓库中张贴那张证书。

(d)密钥对恢复:作为一个选项,用户客户密钥(用于加密的用户私有密钥)可以被

CA或者密钥备份系统备份。如果用户需要恢复这些备份密钥,(例如,当忘记密

码或者失去密钥链文件的时候)一个支持这样恢复的联机交流协议是所需要的。

(e)密钥对更新:所有的密钥对需要定期更新。例如,替换新的密钥对,发布新的证

书。

(f)撤销请求:一个授权人通知CA要求将处于不正常处境的证书被撤销。

(g)交叉认证:两CAs交换知识用于建立交叉认证证书。交叉认证证书是一张经过

一CA给另一个包括签名密钥的CA颁发的证书。

注意联机协议不是唯一的执行上述功能的方式,还有取得同样结果的离线方法,这在本文说明为不托管联机协议的使用。例如,当硬件设备(hardware tokens)使用的时候,很多功能可以作为物理设备传递的一部分而实现。此外,某些上述功能可以合并成为一种协议交换(protocol exchange)。特别的,两个或者多个登记、初始化和证书功能可以合并为一种协议交换。

PKIX系列的文本说明可以定义一套标准信息格式,支持上述功能的将来文本中说明。如果那样,表达这些在不同环境中信息(例如联机、文件传输、e-mail和WWW)的协议将在那些文本被描绘。

4证书和证书扩展项概要

这部分提出公开密钥证书概要,将帮助发展可由双方共同操作和可再用PKI体系。这部分基于X.509 v3证书标准格式和在[X.509]上定义标准证书扩展。ISO IEC/ITU文件使用1993版本的ASN.1语法;然而本文使用1988 ASN.1语法,但是证书编码和标准扩展是等同的。这部分也定义支持Internet社区PKI体系的私有扩展。

证书可以在宽广的应用环境中使用,其覆盖宽广的可由双方共同操作为目标和更宽阔范围中的操作上的和认证要求的环境。本文的目标是为宽广的由双方共同操作和有限特殊目的要求的环境建立一条共用基线。特别是强调支持X.509 v3证书应用在非正式的Internet电子邮件、IPsec和WWW上。

4.1基本证书字段

X.509 v3证书基本语法如下。为签名计算,将证书按照ASN.1语法(DER) [X.208]规则进行编码传递。ASN.1 DER编码是对每个元素对应的标签、长度、值编码系统。

Certificate ::= SEQUENCE {

tbsCertificate TBSCertificate,

signatureAlgorithm AlgorithmIdentifier,

signatureValue BIT STRING }

TBSCertificate ::= SEQUENCE {

version [0] EXPLICIT Version DEFAULT v1,

serialNumber CertificateSerialNumber,

signature AlgorithmIdentifier,

issuer Name,

validity Validity,

subject Name,

subjectPublicKeyInfo SubjectPublicKeyInfo,

issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,

-- If present, version shall be v2 or v3

subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,

-- If present, version shall be v2 or v3

extensions [3] EXPLICIT Extensions OPTIONAL

-- If present, version shall be v3

}

Version ::= INTEGER { v1(0), v2(1), v3(2) }

CertificateSerialNumber ::= INTEGER

Validity ::= SEQUENCE {

notBefore Time,

notAfter Time }

Time ::= CHOICE {

utcTime UTCTime,

generalTime GeneralizedTime }

UniqueIdentifier ::= BIT STRING

SubjectPublicKeyInfo ::= SEQUENCE {

algorithm AlgorithmIdentifier,

subjectPublicKey BIT STRING }

Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension

Extension ::= SEQUENCE {

extnID OBJECT IDENTIFIER,

critical BOOLEAN DEFAULT FALSE,

extnValue OCTET STRING }

下面几个小段的项目定义了在Internet中使用的X.509 v3证书。

4.1.1证书字段

证书是三个连串(SEQUENCE)的字段。这些字段将在下列部分中详细描绘。

4.1.1.1 tbsCertificate

这个字段含有主题和发行者的名字,主题联系起来的公开密钥,有效期和其他相关信息。字段在部分4.1.2中详细被描述;字段tbscertificate也可以包括在部分4.2中描述的扩展项。

4.1.1.2 signatureAlgorithm

signatureAlgorithm字段含有CA签发证书使用的密码学算法标识符。第7.2段列出支持的签名算法。

由下列的ASN.1结构确定一个算法标识符:

AlgorithmIdentifier ::= SEQUENCE {

algorithm OBJECT IDENTIFIER,

parameters ANY DEFINED BY algorithm OPTIONAL }

算法标识符用于识别出密码学的算法。算法标识符(OBJECT IDENTIFIER)成分识别出(例如SHA 1的DSA)算法。可选参数字段的内容将根据识别出的算法改变。第7.2段列出了本文支持的算法。

这个字段必须(MUST)含有在序列tbsCertificate(见4.1.2.3)中签名字段算法标识符同样的算法标识符。

4.1.1.3 signatureValue

signatureValue字段包括对tbsCertificate的ASN.1 DER编码的数字签名。TbsCertificate 的ASN.1 DER编码作为签名函数的输入参数。这个签名结果值然后作为BIT STRING 类型的ASN.1编码,并且包括在证书的签名字段中。这个过程在7.2段中针对每种支持算法(进行了)详细描述。

通过产生数字签名,CA能证明在tbsCertificate字段中信息的有效性。特别是,CA能够认证在证书中公开密钥和证书的主题的绑定。

4.1.2 TBSCertificate

序列TBSCertificate含有和CA发行证书的主题联系起来的信息。每一个TBSCertificate 含有主题和发行者的名字;以及和主题联系起来的公开密钥、有效期、版本号和序列号;一些可选的唯一标识符字段。这部分余下的部分描述这些字段的句法和语义学。TBSCertificate 也可以包含扩展项。扩展部分在Internet PKI(在部分)4.2中被描绘。

4.1.2.1版本

这个字段描绘编码证书的版本。当扩展被使用的时候,如同在本文中预期那样,使用X.509版本3(值是2)。但是如果没有扩展项,UniqueIdentifier将存在,这时使用版本2(值是1)。如果仅仅基本字段存在,使用版本1(作为缺省值,版本号将在证书中删掉)。

(证书系统应用)工具应该(SHOULD)有准备接受任何版本的证书。最低限度,工具(MUST)必须能够识别出第3版的证书。

第2版证书的产生不是本文预期的描述对象。

4.1.2.2序列号

序列号是CA给每一个证书分配一个整数。它必须(MUST)是特定CA签发的证书唯一识别(即,发行者名字和序列号唯一识别一张证书)。

4.1.2.3签名

这字段含有算法标识符,这个算法是CA在证书上签名使用的算法。

这个字段必须(MUST)含有作为在序列Certificate (见4.1.1.2)中signatureAlgorithm 字段同样的算法标识符。可选参数字段的内容将根据识别出的算法改变。第7.2段列出支持的签名算法。

4.1.2.4发行者

发行者字段用来标识在证书上签名和发行的实体。发行者字段必须(MUST)含有一非空的能辨别出的名字(DN)。把发行者字段定义为X.501类型名字。[X.501]名字由下列的ASN.1结构确定:

Name ::= CHOICE {

RDNSequence }

RDNSequence ::= SEQUENCE OF RelativeDistinguishedName

RelativeDistinguishedName ::=

SET OF AttributeTypeAndValue

AttributeTypeAndValue ::= SEQUENCE {

type AttributeType,

value AttributeValue }

AttributeType ::= OBJECT IDENTIFIER

AttributeValue ::= ANY DEFINED BY AttributeType

DirectoryString ::= CHOICE {

teletexString TeletexString (SIZE (1..MAX)),

printableString PrintableString (SIZE (1..MAX)),

universalString UniversalString (SIZE (1..MAX)),

utf8String UTF8String (SIZE (1.. MAX)),

bmpString BMPString (SIZE (1..MAX)) }

名字(Name)描绘了一等级制度的名字属性组成,例如国家名字和对应的值,例如US。类型AttributeValue的成分由AttributeType决定;一般地说它将是一DirectoryString(类型)。

DirectoryString类型定义为一个对PrintableString、TeletexString、BMPString、UTF8String 和UniversalString(类型)的选择。UTF8String编码是DirectoryString的首选编码,以及所有的在2003年12月31日之后签发的证书必须(MUST)使用UTF8String编码(正如同下面指出那样)。直到那日期,当创建一个可辨别的名字时CAs必须(MUST)在下列的选择中挑选,包括他们自己:

(a) 如果字符集是足够的,字符可以(MAY)被描述为一PrintableString;

(b) 失败(a),如果BMPString字符集是足够的,字符可以被描述为一BMPString;

(c) 失败(a)和(b),字符必须(MUST)被描述为一UTF8String。如果(a)

或者(b)是满足的,CA可以(MAY)仍然宁愿选择把字符描述为一

UTF8String。

2003年12月31日 UTF8编码要求的例外如下:

(a) CAs可以(MAY)签发“名字滚翻”("name rollover")支持一向UTF8String 编码整齐的迁移证书。这样证书将包含CA的作为发行者UTF8String编码名

字和作为主题的老名字编码,或者反之亦然。

(b) CAs在部分4.1.2.6中表明,主题字段必须(MUST)存在由主题CA不管如何编码签发的所有证书中发行者字段的内容相配的一非空的可识别名字。

TeletexString和UniversalString为向后兼容(性)被包含,并且不应该为新主题的证书使用。但是,这些类型可以在名字以前就存在的证书中被使用。证书用户应该(SHOULD)是有准备的以这些类型接受证书。

此外,很多遗留工具支持名字在ISO 8859-1字符集(Latin1String)中的编码,但是使用TeletexString作为他们的标签。Latin1String包含在西方欧洲人国家中使用并不是部分TeletexString 字符集的字符。加工TeletexString的工具应该(SHOULD)是有准备的处理整个ISO 8859-1字符集。[ISO 8859-1]

同样,可识别名字由属性组成。本文说明不限制可以出现在名字的属性类型。但是,工具必须(MUST)是有准备的以发行者名字接受证书,发行者名字含有下面确定的属性类型。本文说明也支持额外的属性类型。

标准套装属性被定义在X.500系列的文档中。本文说明的[X.520]工具必须(MUST)是有准备接受在发行者名字中(包括的)下列标准属性类型:国家、组织、组织的单位(organizational-unit)、限定语的可识别名字、国家或者省名字和普通名字(common name)(例如" Susan Housley")。此外,本文说明的工具应该(SHOULD)是有准备的收到下列的在发行者名字中标准属性类型:地区、题目、姓、名字、开头的字母和产生限定语(例如"Jr."",3rd"或者"IV")。这些属性类型句法和相结合对象标识符(OIDs)在附录A和B中ASN.1模块中提供说明。

此外,本文说明的工具必须(MUST)是有准备的如同[RFC 2247]定义的那样接受domainComponent属性。域名(Nameserver)系统(DNS)提供为系统贴上标签等级制度的方法。这个属性提供为希望使用DNS和他们的DNS名字平行的组织一个方便的机制。这不是用作替换名字字段的dNSName成分的替代。工具不需要把这样名字变成DNS名字。这属性类型句法和相结合的OID在附录A和B中ASN.1模块中提供。

证书用户必须(MUST)是有准备处理发行者可识别名字和主题识别名字(见4.1.2.6)去执行证书有效路径的名字链(部分6)。名字链由相匹配的随CA证书主题名字的在一张证书中可识别的名字签发者执行。

本文说明仅要求在X.500系列文档中指定功能相似的一子集名字。使工具遵照的要求如

下:

(a) 可以被假定代表不同字符,属性值在不同类型(例如PrintableString和BMPString)中编码;

(b) 除了PrintableString类型,属性值是区分大小写的(这个允许属性值和二进制对象匹配);

(c) 在PrintableString中属性值不区分大小写(例如," Marianne Swanson"和"

MARIANNE SWANSON"相同);和

(d) 在去除头部和尾部的空格以及去转换在内部子串中一个或多个连续空格为一个单一的空格后,在PrintableString中属性值可被比较。

这些名字比较规则允许一个证书用户验证使用证书用户所不熟悉的语言或者编码签发的证书的有效性。

此外,本文说明的工具可以(MAY)使用这些比较规则为名字链处理不熟悉的属性类型。这允许工具随着在发行者名字中不熟悉的属性处理证书。

注意在X.500系列文档中定义的比较规则指出用于在可识别名字中数据编码的字符集是无关紧要的。字符(他们)自身被比较而不关心编码。允许本文的工具使用定义在X.500系列文档中的比较算法。这样工具将通过前面指定算法认出相匹配的名字超集。

4.1.2.5有效性

证书有效期是时间间隔,在这期间CA保证它将保持关于证书的状况的信息。把字段描述为一连串(SEQUENCE)的两个日期:日期证书有效期开始(notBefore)和日期证书有效期结束(notAfter)。notBefore和notAfter可以作为UTCTime或者GeneralizedTime类型编码。

在本文中CAs必须(MUST)在2049年以前证书有效日期总是作为UTCTime类型编码;在2050年或者以后证书有效性日期必须(MUST)作为GeneralizedTime类型编码。

4.1.2.

5.1 UTCTime

世界时间(universal time)类型,UTCTime是作为国际应用的一标准ASN.1类型,因为本地时间不适合国际应用。UTCTime通过两个低次序数字指定年以及指定精确(性)到一分钟或者一秒钟。UTCTime包含(Zulu或者格林威治标准时间)Z或者一时间微分。

在本文描述中,UTCTime值必须(MUST)是格林威治标准时间表示(Zulu)并且必须(MUST)包含秒(即,时间(格式)是YYMMDDHHMMSSZ),甚至秒的数目等于零。系统必须(MUST)如下解释年字段(YY):

当YY大于等于50,年将被认为是19YY;和

当YY不到50,年将被认为是20YY。

4.1.2.

5.2 GeneralizedTime

普遍时间类型,GeneralizedTime为时间的可变精确性的标准ASN.1类型。随意地,GeneralizedTime字段能包含一在本地和格林威治标准时间之间时间微分的代表。

为了本文的目标,GeneralizedTime值必须(MUST)是格林威治标准时间表示(Zulu)并且必须(MUST)包含秒(即,时间格式是YYYYMMDDHHMMSSZ),甚至其秒的数目等于零。GeneralizedTime值必须不(MUST NOT)包含小数部分秒(fractional seconds)。

4.1.2.6主题

主题字段标识符与存储在主题公开密钥字段中相关联的密钥实体。主题名字和/或在subjectAltName扩展中被附带。如果主题是一CA(例如,如同在4.2.1.10讨论那样,基本约束扩展存在和cA的值是真的(TRUE)),那么主题字段必须(MUST)是随着一非空的可识别的名字存在,在所有的主题CA签发的证书和发行者字段(见4.1.2.4)的目录相匹配。如果主题命名信息仅存在subjectAltName扩展(例如一把密钥局限于一电子邮件地址或者URI)中,那么主题名字必须(MUST)是一空的序列并且subjectAltName扩展一定是关键的。

在它非空的地方,主题字段必须(MUST)含有一X.500可识别名字(DN)。DN必须(MUST)对于每一主题实体是唯一的通过被签发者名字字段定义的一CA证明。一CA可以用同样的DN向同样的主题实体签发多个证书。

主题名字字段定义为X.501类型名字。工具(应用)要求这字段是那些签发者字段定义的(见4.1.2.4)。当将类型DirectoryString的属性值编码的时候,关于签发者字段的编码规则必须(MUST)被执行。本文说明的工具一定是有准备的接收包含为签发者字段推荐的属性类型的主题名字。本文说明的工具应该(SHOULD)是有准备的接收含有为签发人字段建议属性类型的主题名字。这些属性类型句法和相结合的对象标识符(OIDs)在附录A和BASN.1模块中被提供。本文说明的工具可以(MAY)使用这些相似规则去处理不熟悉属性类型(例如,对于名字链条)。这允许工具在不熟悉属性的主题名字中处理证书。

此外,遗留工具存在于一RFC 822名字作为EmailAddress属性被嵌入在可识别的名字中。作为IA5String类型的EmailAddress属性值允许包含字符'@',其不在PrintableString字符集中。EmailAddress属性值是不区分大小写的(例如,"fanfeedback@https://www.doczj.com/doc/c016748742.html,"与FANFEEDBACK@https://www.doczj.com/doc/c016748742.html,是一样的)。

随着电子邮件地址使产生新证书工具必须(MUST)在主题字段可能的选择中使用rfc822Name (见4.2.1.7)的名字描绘。同时包含在主题中可识别名字的EmailAddress属性值去支持遗留工具被反对,但是允许(即不禁止)。

4.1.2.7主题公开密钥信息

使用这字段携带公开密钥和密钥使用算法的标识符。算法使用在部分4.1.1.2中指定AlgorithmIdentifier结构被标识。在部分7.3中指定对象标识符作为将公开密钥材料(公开密钥和参数)支持的编码算法和方法。

4.1.2.8唯一标识符

这些字段可能仅出现在版本2或者3中(见4.1.2.1)。主题和发行者的唯一标识符存在于证书中去处理在超出(有效)时间主题和/或发行者名字的再使用的可能性。本文推荐名字不在不同实体中重用以及Internet证书唯一标识符不被使用。CAs遵从本文不应该(SHOULD NOT)使用唯一标识符产生证书。遵从本文应用(程序)应该(SHOULD)是能解析唯一标识符的语法并且作比较。

4.1.2.9扩展

这字段可能如果仅出现在版本3(见 4.1.2.1)中。如果存在,这字段是一连串(SEQUENCE)的一个或多个证书扩展。在Internet PKI中证书扩展的格式和内容将在4.2定义。

4.2标准证书扩展

在X.509 v3证书扩展定义中提供为用户或者公开密钥和证书管理等级制度相结合的附加属性的方法。X.509 v3证书格式也允许社区(一个具体应用环境――译者注)定义私有范

相关主题
文本预览
相关文档 最新文档