rfcrfc2560.txt

本程序为在linux下实现FTP传输文件的实现

组织：中国互动出版网（http://www.china-pub.com/）
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：[e-mail]
译者：姚玥（yaoyue  [e-mail]）
译文发布时间：2001-6-8
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须
保留本文档的翻译及版权信息。


Network Working Group                                           M. Myers
Request for Comments: 2560                                      VeriSign
Category: Standards Track                                      R. Ankney
                                                                  CertCo
                                                              A. Malpani
                                                                ValiCert
                                                             S. Galperin
                                                                  My CFO
                                                                C. Adams
                                                Entrust Technologies June 1999


x.509因特网公钥基础设施在线证书状态协议——OCSP
(RFC2560  X.509 Internet Public Key Infrastructure Online Certificate Status 
Protocol – OCSP)


本备忘录的状态
本文档讲述了一种Internet社区的Internet标准跟踪协议，它需要进一步进行讨论和建
议以得到改进。请参考最新版的“Internet正式协议标准” (STD1)来获得本协议的标准化
程度和状态。本备忘录的发布不受任何限制。

版权声明
Copyright (C) The Internet Society (1999).  All Rights Reserved.

1.	摘要
本文档描述了无需证书撤消列表就可以决定一张数字证书当前状态的协议。附加描述
PKIX操作必要条件的机制在另外的文档中有详细说明。
第二章中有协议的概述。功能必要条件在第三章中有详细描述。第四章是具体协议。第
五章我们将讨论一些和协议有关的安全问题。附录A定义了在HTTP之上的OCSP，附
录B有ASN.1的语义元素，附录C详细描述了信息的mime类型。
本文档中的关键字"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"同
RFC2119中的叙述一样。

2.	协议概述
作为检查定期证书撤消列表的补充，有些场合下必须要获得一些有关证书撤消状态的即
时信息。（RFC2459章节3.3）例如涉及大量资金的交易或者股票买卖。
在线证书状态协议（OCSP）使得应用程序可以测定所需要检验证书的（撤消）状态。
OCSP。一个OCSP客户端发布一个状态查询给一个OCSP响应器并且侦听当前证书直到
响应器提供了一个响应。
这个协议描述了在应用程序检查证书状态和服务器提供状态之间所需要交换的数据。

2.1请求
一个OCSP请求包含以下数据
——协议版本
——服务请求
——目标证书标识
——可能被OCSP响应器处理的可选扩展
在接受一个请求之后，一个OCSP响应器检测是否：
1．	信息正确格式化
2．	响应器被配置提供请求服务而且
3．	请求包含了响应器需要的信息，如果任何一个先决条件没有满足，那么OCSP响应器将
产生一个错误信息；否则的话，返回一个确定的回复。

2.2回复
OCSP回复可以有几种类型。一个OCSP回复由回复类型和实际回复字节组成。有一种
OCSP基本回复类型必须被所有的OCSP服务器和客户端支持。本章的其余部分都仅适用于
这个回复类型。
所有确定的回复都应被数字签名。被用来签名回复信息的密钥必须是下列中的一个
——颁发所涉及证书的CA
——一个被信任的响应器，它的公钥被请求者信任
——一个CA指派的响应器（被授权的响应器），它具有一张由CA直接颁发的用来表示此
响应器可以为本CA发布OCSP回复的特别标记证书。
一个确定的回复信息由以下组成：
——回复语法的版本
——响应器名称
——对每一张被提及证书的回复
——可选扩展
——签名算法对象标识符号
——对回复信息散列后的签名
对每一张被请求证书的回复包括
——目标证书识别
——证书状态值
——回复有效期
——可选扩展
这个说明定义了以下在证书状态值中使用的一些确定回复识别：
——良好
——已撤消
——未知
“良好”状态表示一个对状态查询的积极回复。至少，这个积极回复表示这张证书没有
被撤消，但是不一定意味着这张证书曾经被颁发过或者产生这个回复在证书有效期内。回复
扩展可以被用来传输一些附加信息，响应器由此可以对这张证书的状态做出一些积极的声
明，诸如（已颁发）保证，有效期等等。
“已撤消”状态表示证书已被撤消（无论是临时性的还是永久性的（待判断））
“未知”状态表示响应器不知道请求的证书。

2.3例外情况
万一出错，OCSP响应器会返回一个出错信息。
这些信息无须签名。出错信息可以是以下一些类型
——未正确格式化的请求（malformedRequest）
——内部错误（internalError）
——请稍后再试(trylater)
——需要签名(sigRequired)
——未授权(unauthorized)
如果接受到一个没有遵循OCSP语法的请求，服务器产生“未正确格式化的请求”回复。
回复“内部错误”表示OCSP响应器处于一个不协调的内部状态。请求需要再试，暗示
尝试另一个响应器。
如果OCSP响应器正在工作，但是不能返回被请求证书的状态，那么“稍后再试”回复
能被用来表示服务存在，但暂时不能响应。
当服务器需要客户端签名请求后才能产生一个回复时，回复“需要签名”将被返回。
当客户端未被授权允许向这台服务器发送请求时，回复“未授权”将被返回。

2.4此次更新(thisUpdate)，下次更新(nextUpdate)和产生时间(producedAt)的语义
回复信息可以在其中包含三种时间——此次更新，下次更新和产生时间。这些域的语义
如下：
——此次更新：此证书状态被表示为正确的时间
——下次更新：在此时间之后，可获得此证书状态的新近信息
——产生时间：OCSP签名这个回复的时间
如果响应器未设置下次更新，那意味着新近的撤消信息在任何时候都可以被获得。

2.5回复预产生
OCSP响应器可以预先产生用来描述在某个确定时间此证书状态的已签名回复。通过在
回复的此次更新域的反映，获得此状态的时间可以被正确认识。下次新近信息则反映在下次
更新域中，与此同时产生这个回复的时间则出现在回复的产生时间域中。

2.6	OCSP签名权威代表
用来签名证书状态信息的密钥不一定需要和签名此证书的密钥相同。通过发布一张包含
有扩展密钥用途域唯一值的OCSP签名者证书证书发布者，可以明确的指派OCSP签名权威
机构。这张证书必须直接由认知的CA颁发给响应器。

2.7	当CA密钥不安全
如果一个OCSP响应器知道一个特定的CA私钥不安全，那么针对所有这个CA颁布的
证书都可以返回一个撤消状态。

3	功能必要条件
3.1	证书内容
为了传达给OCSP客户端一个知道的信息获取点，CA们可以在权威机构信息获取扩展
（可以被检测用来使用OCSP）提供这样的能力。作为另外一种选择，也可以在OCSP客户
端本地配置OCSP提供者获取地（信息）。
支持OCSP服务的CA，无论是自身实现还是通过授权响应器来提供，都必须提供包括
统一资源识别形式的获取地信息和在一个获取描述序列中的对象识别符号形式的获取方法。
在主体证书的获取地域中的值定义了使用什么传输（例如HTTP）来获取OCSP响应器
并且可以包含其他传输相关信息（例如URL）。

3.2	已签名回复的接受条件
在接受一个已签名的回复为有效之前，OCSP客户端必须确认：
1.	在回复信息中所指的证书和相应请求中所指证书一致。
2.	回复中的签名有效。
3.	签名者的身份和相映应接受请求者匹配。
4.	签名者正被授权签名回复。
5.	表示状态被认为是正确的时间（此次更新）足够新。
6.	如果有的话，下次更新的时间应该晚于现时时间。

4.	具体协议
这个ASN.1语法引用了在RFC2459中定义的术语。至于签名运算，被签名的数据使用
ASN.1显示编码规则（DER）[x.690]。
除非指定了其他，否则默认使用ASN.1外在标记。从别处引用的的术语有：扩展
(Extensions)，证书序列号（CertificateSerialNumber）,主体公钥信息(SubjectPublicKeyInfo),
名称(Name),算法识别(AlgorithmIdentifier),证书撤消列表原因（CRLReason）

4.1请求
这一节描述了请求信息的ASN.1规范。实际的信息格式根据所使用的传输机制
(HTTP,SMTP,LDAP等等)而不同。

4.1.1	请求（信息）语法
OCSPRequest		::=     SEQUENCE {
       tbsRequest                  TBSRequest,
       optionalSignature   [0]     EXPLICIT Signature OPTIONAL }

   TBSRequest      ::=     SEQUENCE {

       version             [0]     EXPLICIT Version DEFAULT v1,
       requestorName       [1]     EXPLICIT GeneralName OPTIONAL,
       requestList                 SEQUENCE OF Request,
       requestExtensions   [2]     EXPLICIT Extensions OPTIONAL }

   Signature       ::=     SEQUENCE {
       signatureAlgorithm      AlgorithmIdentifier,
       signature               BIT STRING,
       certs               [0] EXPLICIT SEQUENCE OF Certificate
   OPTIONAL}

   Version         ::=             INTEGER  {  v1(0) }

   Request         ::=     SEQUENCE {
       reqCert                     CertID,
       singleRequestExtensions     [0] EXPLICIT Extensions OPTIONAL }

   CertID          ::=     SEQUENCE {
       hashAlgorithm       AlgorithmIdentifier,
       issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
       issuerKeyHash       OCTET STRING, -- Hash of Issuers public key
       serialNumber        CertificateSerialNumber }

发布者名称散列(issuerNameHash)是发布者显式名称的散列。应该检测证书发布者名称
域的DER编码的散列。发布者密钥散列（issuerKeyHash）是发布者公钥的散列。对发布者
证书的主体公钥域的值（不包括标签和长度）进行散列。所有这些使用的散列算法都由散列
算法域(hashAlgorithm)确定。序列号域（serialNumber）是被查询状态证书的序列号。

4.1.2		请求（信息）语法的注意点
除了对CA名称进行散列外还对CA的公钥进行散列，这样做的主要原因是为了识别发
布者，因为两个CA有可能选择同一名称(虽然建议使用独一无二的名称，但这并不是强制
要求的)。然而，除非两个CA明确表示他们共享私钥或者其中一个CA的密钥是不安全的，
否则两个CA是不可能有相同的密钥。
支持任何的扩展是可选的。每一个可选扩展的重要性标志都不应该被设置。章节4.4中
提到了一些有用的扩展。其他的一些扩展也许会在其他的一些RFC中有所定义。未被承认
的扩展必须被忽略。（除非他们的重要性标志被设置而且未被理解）
响应器可以选择签名OCSP的请求。在那种情况下，签名是根据TBS请求(tbsRequest)结构
计算得到的。如果请求被签名，那么响应器可以在请求者名称域中识别处它的名称。同样的，
为了签名请求，请求内容可以包括用来帮助OCSP响应器识别请求者签名内容的证书。

4.2回复语法
本节描述了回复信息的ASN.1规范。实际格式根据所使用的传输机制
(HTTP,SMTP,LDAP等等)而不同。

4.2.1	OCSP回复的ASN.1规范
一个OCSP回复至少包括用来指示对先前请求所处理状态的回复状态域
（responseStatus）。如果回复状态域的值达到某一种出错情况，那么回复字节(responseStatus)
将不被设置。
OCSPResponse ::= SEQUENCE {
      responseStatus         OCSPResponseStatus,
      responseBytes          [0] EXPLICIT ResponseBytes OPTIONAL }

   OCSPResponseStatus ::= ENUMERATED {
       successful            (0),  --Response has valid confirmations
       malformedRequest      (1),  --Illegal confirmation request
       internalError         (2),  --Internal error in issuer
       tryLater              (3),  --Try again later
                                   --(4) is not used
       sigRequired           (5),  --Must sign the request
       unauthorized          (6)   --Request unauthorized
   }
回复字节（responseBytes）的值由对象标识和一个编码成OCTET字符串的回复标记（此
标记由刚才的对象标识确定）组成。
ResponseBytes ::=       SEQUENCE {
       responseType   OBJECT IDENTIFIER,
       response       OCTET STRING }
对于基本的OCSP回复，回复类型是id-pkix-ocsp-basic。
id-pkix-ocsp           OBJECT IDENTIFIER ::= { id-ad-ocsp }
   id-pkix-ocsp-basic     OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 }
OCSP响应器应该有能力产生id-pkix-ocsp-basic回复类型的回复。同样的，OCSP客户
端也应该有能力接受并且处理id-pkix-ocsp-basic类型的回复。