rfcrfc2560.txt

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

回复的值应该是基本OCSP回复（BasicOCSPResponse）的DER编码。
BasicOCSPResponse       ::= SEQUENCE {
      tbsResponseData      ResponseData,
      signatureAlgorithm   AlgorithmIdentifier,
      signature            BIT STRING,
      certs                [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }
签名值应该对回复数据（ResponseData）的DER编码上的散列计算而得。
ResponseData ::= SEQUENCE {
      version              [0] EXPLICIT Version DEFAULT v1,
      responderID              ResponderID,
      producedAt               GeneralizedTime,
      responses                SEQUENCE OF SingleResponse,
      responseExtensions   [1] EXPLICIT Extensions OPTIONAL }

   ResponderID ::= CHOICE {
      byName               [1] Name,
      byKey                [2] KeyHash }

   KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key
   (不包括标签和长度域)

   SingleResponse ::= SEQUENCE {
      certID                       CertID,
      certStatus                   CertStatus,
      thisUpdate                   GeneralizedTime,
      nextUpdate         [0]       EXPLICIT GeneralizedTime OPTIONAL,
      singleExtensions   [1]       EXPLICIT Extensions OPTIONAL }

   CertStatus ::= CHOICE {
       good        [0]     IMPLICIT NULL,
       revoked     [1]     IMPLICIT RevokedInfo,
       unknown     [2]     IMPLICIT UnknownInfo }

   RevokedInfo ::= SEQUENCE {
       revocationTime              GeneralizedTime,
       revocationReason    [0]     EXPLICIT CRLReason OPTIONAL }
UnknownInfo ::= NULL——这个可以被一个列举代替。

4.2.2	OCSP回复的注意点

4.2.2.1	时间
此次更新和下次更新域定义了一个推荐的有效期。一个时间长度和证书撤消列表中的
{此次更新，下次更新}时间长度相一致。如果下次更新的值早于当前本地系统时间，那么这
个回复将被认为不可靠。如果此次更新的值晚于当前本地系统时间，那么这个回复也将被认
为不可靠。回复中没有设置下次更新值等价于CRL没有确定的下次更新时间（见章节2.4）
	产生时间是这个回复被签名的时间。

4.2.2.2	被授权的响应器
用来签名证书状态信息的密钥可以和签名证书状态的密钥不同。但是必须保证签名这个
信息的实体已被授权。所以证书发布者必须自己签名OCSP回复或者明确的指派这个权利给
其他实体。OCSP签名代表可以通过包含在OCSP回复签名者证书扩展密钥用途扩展中的
id-kp-OCSPSigning来指派。这张证书必须直接由颁布所涉及证书的CA发布。
id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9}
依赖OCSP回复的系统和应用程序必须由能力探测并且执行id-ad-ocspSigning值的使
用，如前所述。他们可以提供一种本地配置一个或更多个OCSP签名权威机构的方法，而且
可以指定一组被信任的签名权威机构。当要求验证回复上签名的证书未满足以下一个标准
时，他们必须拒绝这样的回复：
1.	和本地配置的对所涉及证书的OCSP签名权威机构匹配；或者
2.	和颁发所涉及证书的CA相同；或者
3.	包括在扩展密钥用途扩展中的id-ad-ocspSigning值，这种证书由颁发所涉及证书的
CA颁发。
回复本身或者用来验证回复上签名的证书可以应用其他接受或者拒绝的标准。

4.2.2.2.1	已授权响应器的撤消检查
既然一个已授权的OCSP响应器可以为一个或多个CA提供状态信息服务，OCSP客户
端需要明白如何确定被授权的响应器的证书没有被撤消。CAS可以选择以下三种方法之一
来处理这个问题：
——一个CA可以指定OCSP客户端能够在响应器证书生存期内信任该响应器。这个CA通
过（在证书中）包括id-pkix-ocsp-nocheck。这个（扩展）应该是非重要扩展。扩展的值可以
为空。CA颁发这样这样一张证书应该意识到响应器密钥的不安全问题，这和用来签名证书
撤消列表的CA密钥的不安全问题同样严重，至少在证书有效期内是这样。CA也可以选择
发布生命周期非常短的此类型证书并且频繁更新它。
id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 }
——一个CA可以指定如何检查响应器的证书是否被撤消。如果应该使用证书撤消列表或者
证书撤消列表发布点来检查，那么也能够使用证书撤消列表来完成确定响应器证书是否被撤
消，或者如果其他应该使用其他的方法那么权威机构信息获取。指定这两种机制的细节可以
在RFC2459中获得。
——一个CA可以选择不指定任何方法来检查响应器证书的有效性（是否被撤消），在这些
情况中，是由OCSP客户端的本地安全策略来决定证书是否检查证书有效性（是否被撤消）。

4.3强制和可选的加密算法
那些请求OCSP服务的客户端应该有能力处理DSA密钥的签名，这些DSA密钥通过
RFC2459章节7.2.2中描述的DSAsig-alg-oid来识别。客户端应该同样有能力处理在RFC2459
章节7.2.1描述的RSA签名。OCSP响应器可应该支持SHA1散列算法。

4.4	扩展
这一节定义了一些标准扩展，基于X.509版本3证书所使用的扩展模型（请见RFC2459）。
支持所有这些扩展对客户端和响应器都是可选的。对于每一个扩展，定义表示了它的语法，
由OCSP响应器实现处理过程，而且在相应的回复中包括任意扩展。

4.4.1		随机数
随机数很秘密的绑定了请求和回复，用来防止重发（replay attacks）攻击。随机数作为
一个请求扩展被包括在请求中，同样的也作为一个回复扩展被包括在回复中。在请求和回复
中，随机数由对象标识id-pkix-ocsp-nonce识别，其中extnValue包含了随机数的值。
id-pkix-ocsp-nonce     OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }

4.4.2		证书撤消列表参考
也许想OCSP响应器指出可以发现已撤消或正保持证书的证书撤消列表。当OCSP在仓
库之间使用而且作为一个审核机制时这个是很有用的。这个证书撤消列表可以由一个同一资
源定位（URL）（证书撤消列表可以从这个URL中获得），或由一个序列号（证书撤消列表
序列号）或者由一个时间（相关证书撤消列表产生的时间）来指定。这些扩展作为单一扩展
（singleExtensions）来描述。这个扩展的标识是id-pkix-ocsp-crl，值是CrlID。
id-pkix-ocsp-crl       OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 }

   CrlID ::= SEQUENCE {
      crlUrl               [0]     EXPLICIT IA5String OPTIONAL,
      crlNum               [1]     EXPLICIT INTEGER OPTIONAL,
      crlTime              [2]     EXPLICIT GeneralizedTime OPTIONAL }
如果选择使用证书撤消列表的同一资源定位，那么IA5字符串被用来定义这个可获得证书
撤消列表的同一资源定位（URL）。如果是证书撤消列表序列号，那么用整数来描述相关证
书撤消列表的证书撤消列表序列号扩展。如果是证书撤消列表时间，那么标准化时间被用来
表示这个相关证书撤消列表发布的时间。

4.4.3可接受的回复类型
一个OCSP客户端可以希望指定一个它所理解的回复类型。为了达到这样的目的，它应
该使用id-pkix-ocsp-response对象标识符的扩展，并且值为可接受回复
（AcceptableResponses）。
这个扩展作为一个请求扩展被包括在请求中。在可接受回复中包括了这个客户端可接受
的不同回复类型的对象标识符号（例如，id-pkix-ocsp-basic）。
id-pkix-ocsp-response  OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 }
AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER
如同章节4.2.1所提到的那样，OCSP响应器应该有能力回复一个id-pkix-ocsp-basic的
回复类型。OCSP客户端也应该有能力接受并处理id-pkix-ocsp-basic回复类型的回复。

4.4.4文件中断
一个OCSP响应器可以选择当证书过期后仍保留相应的撤消信息。
这个日期可以从产生时间（producedAt）减下的保持间期值中获得，并被定义成证书的“文
档中断”日期。
可以使用OCSP的应用程序会使用一个OCSP文档中断日期作为一个证明，证明一个数
字签名是（或者不是）可被信赖于它的产生日期，即使证书过期很久后仍被要求证明这个签
名有效。
提供这些历史记录参考的OCSP服务器应该在回复中包括一个文档中断日期的扩展。如
果包括的话，那么这个值应该作为由id-pkix-ocsp-archive-cutoff确定的OCSP单一扩展，并
且为标准化时间标记语法。
id-pkix-ocsp-archive-cutoff  OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 }
ArchiveCutoff ::= GeneralizedTime
举个例子，如果一个服务器以7年时间长度为规则的保持力，而且状态在时间点T1产
生。那么回复中文档中断的值就是t1-7年。

4.4.5	证书撤消列表入口扩展
所有的扩展同RFC2459章节5.3中所定义的CRL入口扩展描述，同样也作为单一扩展
被支持。

4.4.6	服务定位器
一台OCSP服务器也许是在这样一种模式中运做的，一台服务器收到请求后将会把该请
求路由给对此证书有权威性的OCSP服务器。为了这个目的定义了服务定位器请求扩展。这
个扩展作为单一请求扩展被包括在请求中。
id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp 7 }
   ServiceLocator ::= SEQUENCE {
       issuer    Name,
       locator   AuthorityInfoAccessSyntax OPTIONAL }
这些域的值可以从主体证书中的相应域中获得。

5	安全方面的考虑
为了使这项服务有效，证书使用系统必须连接到证书状态服务提供者。如果这样的连接
不可实现，那么证书使用系统可以实现证书撤消列表处理，作为一种退而求其次的方法。
如果请求过多，将会使服务器相当脆弱。密码签名工作也将显著的影响到回复产生周期，从
而使情况恶化。如果不签名，那么将使攻击者可能发送假回复，造成协议服务被攻击导致无
效。
使用预先产生的回复将可能导致重发攻击，一个旧（良好状态）的回复将被用来重发作
为一个在有效期内但已被撤消的证书状态。所以为了实现预先产生回复带来的好处，OCSP
应被小心配置，既要考虑到成功执行后的效率代价又要考虑到被重发攻击的可能性。
请求不包含他们所直接面对的响应器，这将导致攻击者向任意一个OCSP响应器重发请
求攻击。
对于依赖于HTTP缓存的配置场合，如果中间服务器没有被正确的配置或者存在缓存管
理错误，那么将会导致非期望的结果。建议实现人员仔细考虑HTTP缓存机制的可靠性当配
置OCSP在HTTP之上时。

6	参考
[RFC2459]		Housley, R., Ford, W., Polk, W. and D. Solo,
"因特网x.509公钥基础设施证书和证书撤消列表轮廓"，RFC2459,1999一月
[HTTP]			Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.Berners-Lee
"超文本传输协议——HTTP/1.1",RFC2068，1997 一月
[RFC2119]		Bradner, S.,
"RFC中关键字使用的需要水平"， BCP 14, RFC 2119,1997 三月
[URL]	Berners-Lee, T., Masinter, L. and M. McCahill,
"统一资源定位(URL)"，RFC1738，1994	12月
[x.690]	ITU-T	建议	x.690(1994)|ISO/IEC	8825-1:1995,
信息技术——ASN.1编码规则：基本编码规则（BER），规范编码规则（CER）和显式
编码规则（DER）的描述。

7	作者地址
Michael Myers
   VeriSign, Inc.
   1350 Charleston Road
   Mountain View, CA 94043
   EMail: [e-mail]
   Rich Ankney
   CertCo, LLC
   13506 King Charles Dr.
   Chantilly, VA  20151
   EMail: [e-mail]
   Ambarish Malpani
   ValiCert, Inc.
   1215 Terra Bella Ave.
   Mountain View, CA 94043
   Phone: [phone]
   EMail: [e-mail]
   Slava Galperin
   My CFO, Inc.
   1945 Charleston Road
   Mountain View, CA
   EMail: [e-mail]
   Carlisle Adams
   Entrust Technologies
   750 Heron Road, Suite E08
   Ottawa, Ontario
   K1V 1A7
   Canada
   EMail: [e-mail]

附录A
A.1	在HTTP之上的OCSP
本章节描述了用来完成支持HTTP的请求和回复的格式。

A.1.1	请求
基于OCSP的HTTP请求可以使用GET或者POST方法来提交他们的请求。为了使用
HTTP缓存，小的请求（在编码后少于255字节），可以使用GET来提交。如果HTTP缓存
不重要，后者请求大于255字节，那么请求应该使用POST方法提交。当需要保密性时，使
用HTTP的OCSP事务交换可以使用TLS/SSL或者其他更低层的协议来保护。
一个使用GET方法OCSP请求如下构筑：
GET {url}/{url-encoding of base-64 encoding of the DER encoding of the OCSPRequest}
当{url}可以从权威机构信息获得（AuthorityInfoAccess）或者其他一些OCSP客户端的
本地配置信息中获得。
一个使用POST的OCSP请求可以如下构筑：
内容类型头部（Content-Type header）的值为“应用/OCSP-请求”
（ "application/ocsp-request"），同时信息主体是OCSP请求（OCSPRequest）DER编码的二
进制值。

A.1.2	回复
一个基于HTTP的OCSP回复的组成是，适当的HTTP头部，紧跟着一个OCSP回复
DER编码的二进制值。内容类型头部（Content-Type heade）的值为“应用/OCSP-回复”
"application/ocsp-request"。内容长度头部（Content-Length header）应该指出回复的长度。其
他HTTP头部也可以被提出而且如果不被响应器理解的话，也可以被忽视。

附录B		ASN.1中的OCSP
OCSP DEFINITIONS EXPLICIT TAGS::=
BEGIN
IMPORTS
      -- Directory Authentication Framework (X.509)
             Certificate, AlgorithmIdentifier, CRLReason
             FROM AuthenticationFramework { joint-iso-itu-t ds(5)