回復的值應該是基本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: mmyers@verisign.com
   Rich Ankney
   CertCo, LLC
   13506 King Charles Dr.
   Chantilly, VA  20151
   EMail: rankney@erols.com
   Ambarish Malpani
   ValiCert, Inc.
   1215 Terra Bella Ave.
   Mountain View, CA 94043
   Phone: 650.567.5457
   EMail: ambarish@valicert.com
   Slava Galperin
   My CFO, Inc.
   1945 Charleston Road
   Mountain View, CA
   EMail: galperin@mycfo.com
   Carlisle Adams
   Entrust Technologies
   750 Heron Road, Suite E08
   Ottawa, Ontario
   K1V 1A7
   Canada
   EMail: cadams@entrust.com

附錄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)