本備忘錄的狀態
本文檔講述了一種Internet社區的Internet標準跟蹤協議，它需要進一步進行討論和建
議以得到改進。請參考最新版的“Internet正式協議標準”(STD1)來獲得本協議的標準化
程度和狀態。本備忘錄的發布不受任何限制。

版權聲明
Copyright(C)TheInternetSociety(1999).AllRightsReserved.

1. 摘要
本文檔描述了無需證書撤消列表就可以決定一張數字證書當前狀態的協議。附加描述
PKIX操作必要條件的機制在另外的文檔中有具體說明。
第二章中有協議的概述。功能必要條件在第三章中有具體描述。第四章是具體協議。第
五章我們將討論一些和協議有關的安全問題。附錄A定義了在HTTP之上的OCSP，附
錄B有ASN.1的語義元素，附錄C具體描述了信息的mime類型。
本文檔中的要害字"MUST","MUSTNOT","REQUIRED","SHALL","SHALLNOT",
"SHOULD","SHOULDNOT","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{
tbsRequestTBSRequest,
optionalSignature[0]EXPLICITSignatureOPTIONAL}

TBSRequest::=SEQUENCE{

version[0]EXPLICITVersionDEFAULTv1,
requestorName[1]EXPLICITGeneralNameOPTIONAL,
requestListSEQUENCEOFRequest,
requestExtensions[2]EXPLICITExtensionsOPTIONAL}

Signature::=SEQUENCE{
signatureAlgorithmAlgorithmIdentifier,
signatureBITSTRING,
certs[0]EXPLICITSEQUENCEOFCertificate
OPTIONAL}

Version::=INTEGER{v1(0)}

Request::=SEQUENCE{
reqCertCertID,
singleRequestExtensions[0]EXPLICITExtensionsOPTIONAL}

CertID::=SEQUENCE{
hashAlgorithmAlgorithmIdentifier,
issuerNameHashOCTETSTRING,--HashofIssuer'sDN
issuerKeyHashOCTETSTRING,--HashofIssuerspublickey
serialNumberCertificateSerialNumber}

發布者名稱散列(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{
responseStatusOCSPResponseStatus,
responseBytes[0]EXPLICITResponseBytesOPTIONAL}

OCSPResponseStatus::=ENUMERATED{
successful(0),--Responsehasvalidconfirmations
malformedRequest(1),--Illegalconfirmationrequest
internalError(2),--Internalerrorinissuer
tryLater(3),--Tryagainlater
--(4)isnotused
sigRequired(5),--Mustsigntherequest
unauthorized(6)--Requestunauthorized
}
回復字節（responseBytes）的值由對象標識和一個編碼成OCTET字符串的回復標記（此
標記由剛才的對象標識確定）組成。
ResponseBytes::=SEQUENCE{
responseTypeOBJECTIDENTIFIER,
responSEOCTETSTRING}
對于基本的OCSP回復，回復類型是id-pkix-ocsp-basic。
id-pkix-ocspOBJECTIDENTIFIER::={id-ad-ocsp}
id-pkix-ocsp-basicOBJECTIDENTIFIER::={id-pkix-ocsp1}
OCSP響應器應該有能力產生id-pkix-ocsp-basic回復類型的回復。同樣的，OCSP客戶
端也應該有能力接受并且處理id-pkix-ocsp-basic類型的回復。
回復的值應該是基本OCSP回復（BasicOCSPResponse）的DER編碼。
BasicOCSPResponse::=SEQUENCE{
tbsResponseDataResponseData,
signatureAlgorithmAlgorithmIdentifier,
signatureBITSTRING,
certs[0]EXPLICITSEQUENCEOFCertificateOPTIONAL}
簽名值應該對回復數據（ResponseData）的DER編碼上的散列計算而得。
ResponseData::=SEQUENCE{
version[0]EXPLICITVersionDEFAULTv1,
responderIDResponderID,
producedAtGeneralizedTime,
responsesSEQUENCEOFSingleResponse,
responseExtensions[1]EXPLICITExtensionsOPTIONAL}

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

KeyHash::=OCTETSTRING--SHA-1hashofresponder'spublickey
(不包括標簽和長度域)

SingleResponse::=SEQUENCE{
certIDCertID,
certStatusCertStatus,
thisUpdateGeneralizedTime,
nextUpdate[0]EXPLICITGeneralizedTimeOPTIONAL,
singleExtensions[1]EXPLICITExtensionsOPTIONAL}

CertStatus::=CHOICE{
good[0]IMPLICITNULL,
revoked[1]IMPLICITRevokedInfo,
unknown[2]IMPLICITUnknownInfo}

RevokedInfo::=SEQUENCE{
revocationTimeGeneralizedTime,
revocationReason[0]EXPLICITCRLReasonOPTIONAL}
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-OCSPSigningOBJECTIDENTIFIER::={id-kp9}
依靠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-nocheckOBJECTIDENTIFIER::={id-pkix-ocsp5}
——一個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 隨機數
隨機數很秘密的綁定了請求和回復，用來防止重發（replayattacks）攻擊。隨機數作為
一個請求擴展被包括在請求中，同樣的也作為一個回復擴展被包括在回復中。在請求和回復
中，隨機數由對象標識id-pkix-ocsp-nonce識別，其中extnValue包含了隨機數的值。
id-pkix-ocsp-nonceOBJECTIDENTIFIER::={id-pkix-ocsp2}

4.4.2 證書撤消列表參考
也許想OCSP響應器指出可以發現已撤消或正保持證書的證書撤消列表。當OCSP在倉
庫之間使用而且作為一個審核機制時這個是很有用的。這個證書撤消列表可以由一個同一資
源定位（URL）（證書撤消列表可以從這個URL中獲得），或由一個序列號（證書撤消列表
序列號）或者由一個時間（相關證書撤消列表產生的時間）來指定。這些擴展作為單一擴展
（singleExtensions）來描述。這個擴展的標識是id-pkix-ocsp-crl，值是CrlID。
id-pkix-ocsp-crlOBJECTIDENTIFIER::={id-pkix-ocsp3}

CrlID::=SEQUENCE{
crlUrl[0]EXPLICITIA5StringOPTIONAL,
crlNum[1]EXPLICITINTEGEROPTIONAL,
crlTime[2]EXPLICITGeneralizedTimeOPTIONAL}
假如選擇使用證書撤消列表的同一資源定位，那么IA5字符串被用來定義這個可獲得證書
撤消列表的同一資源定位（URL）。假如是證書撤消列表序列號，那么用整數來描述相關證
書撤消列表的證書撤消列表序列號擴展。假如是證書撤消列表時間，那么標準化時間被用來
表示這個相關證書撤消列表發布的時間。

4.4.3可接受的回復類型
一個OCSP客戶端可以希望指定一個它所理解的回復類型。為了達到這樣的目的，它應
該使用id-pkix-ocsp-response對象標識符的擴展，并且值為可接受回復
（AcceptableResponses）。
這個擴展作為一個請求擴展被包括在請求中。在可接受回復中包括了這個客戶端可接受
的不同回復類型的對象標識符號（例如，id-pkix-ocsp-basic）。
id-pkix-ocsp-responseOBJECTIDENTIFIER::={id-pkix-ocsp4}
AcceptableResponses::=SEQUENCEOFOBJECTIDENTIFIER
如同章節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-cutoffOBJECTIDENTIFIER::={id-pkix-ocsp6}
ArchiveCutoff::=GeneralizedTime
舉個例子，假如一個服務器以7年時間長度為規則的保持力，而且狀態在時間點T1產
生。那么回復中文檔中斷的值就是t1-7年。

4.4.5 證書撤消列表入口擴展
所有的擴展同RFC2459章節5.3中所定義的CRL入口擴展描述，同樣也作為單一擴展
被支持。

4.4.6 服務定位器
一臺OCSP服務器也許是在這樣一種模式中運做的，一臺服務器收到請求后將會把該請
求路由給對此證書有權威性的OCSP服務器。為了這個目的定義了服務定位器請求擴展。這
個擴展作為單一請求擴展被包括在請求中。
id-pkix-ocsp-service-locatorOBJECTIDENTIFIER::={id-pkix-ocsp7}
ServiceLocator::=SEQUENCE{
issuerName,
locatorAuthorityInfoaccessSyntaxOPTIONAL}
這些域的值可以從主體證書中的相應域中獲得。

5 安全方面的考慮
為了使這項服務有效，證書使用系統必須連接到證書狀態服務提供者。假如這樣的連接
不可實現，那么證書使用系統可以實現證書撤消列表處理，作為一種退而求其次的方法。
假如請求過多，將會使服務器相當脆弱。密碼簽名工作也將顯著的影響到回復產生周期，從
而使情況惡化。假如不簽名，那么將使攻擊者可能發送假回復，造成協議服務被攻擊導致無
效。
使用預先產生的回復將可能導致重發攻擊，一個舊（良好狀態）的回復將被用來重發作
為一個在有效期內但已被撤消的證書狀態。所以為了實現預先產生回復帶來的好處，OCSP
應被小心配置，既要考慮到成功執行后的效率代價又要考慮到被重發攻擊的可能性。
請求不包含他們所直接面對的響應器，這將導致攻擊者向任意一個OCSP響應器重發請
求攻擊。
對于依靠于HTTP緩存的配置場合，假如中間服務器沒有被正確的配置或者存在緩存管
理錯誤，那么將會導致非期望的結果。建議實現人員仔細考慮HTTP緩存機制的可靠性當配
置OCSP在HTTP之上時。

6 參考
[RFC2459] Housley,R.,Ford,W.,Polk,W.andD.Solo,
"因特網x.509公鑰基礎設施證書和證書撤消列表輪廓"，RFC2459,1999一月
[HTTP] Fielding,R.,Gettys,J.,Mogul,J.,Frystyk,H.andT.Berners-Lee
"超文本傳輸協議——HTTP/1.1",RFC2068，1997一月
[RFC2119] Bradner,S.,
"RFC中要害字使用的需要水平"，BCP14,RFC2119,1997三月
[URL] Berners-Lee,T.,Masinter,L.andM.McCahill,
"統一資源定位(URL)"，RFC1738，1994 12月
[x.690] ITU-T 建議 x.690(1994)ISO/IEC 8825-1:1995,
信息技術——ASN.1編碼規則：基本編碼規則（BER），規范編碼規則（CER）和顯式
編碼規則（DER）的描述。

7 作者地址
MichaelMyers
VeriSign,Inc.
1350CharlestonRoad
MountainView,CA94043
EMail:mmyers@verisign.com
RichAnkney
CertCo,LLC
13506KingCharlesDr.
Chantilly,VA20151
EMail:rankney@erols.com
AmbarishMalpani
ValiCert,Inc.
1215TerraBellaAve.
MountainView,CA94043
Phone:650.567.5457
EMail:ambarish@valicert.com
SlavaGalperin
MyCFO,Inc.
1945CharlestonRoad
MountainView,CA
EMail:galperin@mycfo.com
CarlisleAdams
EntrustTechnologies
750HeronRoad,SuiteE08
Ottawa,Ontario
K1V1A7
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-encodingofbase-64encodingoftheDERencodingoftheOCSPRequest}
當{url}可以從權威機構信息獲得（AuthorityInfoAccess）或者其他一些OCSP客戶端的
本地配置信息中獲得。
一個使用POST的OCSP請求可以如下構筑：
內容類型頭部（Content-Typeheader）的值為“應用/OCSP-請求”
（"application/ocsp-request"），同時信息主體是OCSP請求（OCSPRequest）DER編碼的二
進制值。

A.1.2 回復
一個基于HTTP的OCSP回復的組成是，適當的HTTP頭部，緊跟著一個OCSP回復
DER編碼的二進制值。內容類型頭部（Content-Typeheade）的值為“應用/OCSP-回復”
"application/ocsp-request"。內容長度頭部（Content-Lengthheader）應該指出回復的長度。其
他HTTP頭部也可以被提出而且假如不被響應器理解的話，也可以被忽視。

附錄B ASN.1中的OCSP
OCSPDEFINITIONSEXPLICITTAGS::=
BEGIN
IMPORTS
--DirectoryAuthenticationFramework(X.509)
Certificate,AlgorithmIdentifier,CRLReason
FROMAuthenticationFramework{joint-iso-itu-tds(5)
module(1)authenticationFramework(7)3}
--PKIXCertificateExtensions
AuthorityInfoAccessSyntax
FROMPKIX1Implicit88{iso(1)identified-organization(3)
dod(6)internet(1)security(5)mechanisms(5)pkix(7)
id-mod(0)id-pkix1-implicit-88(2)}
Name,GeneralName,CertificateSerialNumber,Extensions,
id-kp,id-ad-ocsp
FROMPKIX1Explicit88{iso(1)identified-organization(3)
dod(6)internet(1)security(5)mechanisms(5)pkix(7)
id-mod(0)id-pkix1-explicit-88(1)};
OCSPRequest::=SEQUENCE{
tbsRequestTBSRequest,
optionalSignature[0]EXPLICITSignatureOPTIONAL}

TBSRequest::=SEQUENCE{
version[0]EXPLICITVersionDEFAULTv1,
requestorName[1]EXPLICITGeneralNameOPTIONAL,
requestListSEQUENCEOFRequest,
requestExtensions[2]EXPLICITExtensionsOPTIONAL}

Signature::=SEQUENCE{
signatureAlgorithmAlgorithmIdentifier,
signatureBITSTRING,
certs[0]EXPLICITSEQUENCEOFCertificateOPTIONAL}

Version::=INTEGER{v1(0)}

Request::=SEQUENCE{
reqCertCertID,
singleRequestExtensions[0]EXPLICITExtensionsOPTIONAL}

CertID::=SEQUENCE{
hashAlgorithmAlgorithmIdentifier,
issuerNameHashOCTETSTRING,--HashofIssuer'sDN
issuerKeyHashOCTETSTRING,--HashofIssuerspublickey
serialNumberCertificateSerialNumber}

OCSPResponse::=SEQUENCE{
responseStatusOCSPResponseStatus,
responseBytes[0]EXPLICITResponseBytesOPTIONAL}

OCSPResponseStatus::=ENUMERATED{
successful(0),--Responsehasvalidconfirmations
malformedRequest(1),--Illegalconfirmationrequest
internalError(2),--Internalerrorinissuer
tryLater(3),--Tryagainlater
--(4)isnotused
sigRequired(5),--Mustsigntherequest
unauthorized(6)--Requestunauthorized
}

ResponseBytes::=SEQUENCE{
responseTypeOBJECTIDENTIFIER,
responseOCTETSTRING}

BasicOCSPResponse::=SEQUENCE{
tbsResponseDataResponseData,
signatureAlgorithmAlgorithmIdentifier,
signatureBITSTRING,
certs[0]EXPLICITSEQUENCEOFCertificateOPTIONAL}

ResponseData::=SEQUENCE{
version[0]EXPLICITVersionDEFAULTv1,
responderIDResponderID,
producedAtGeneralizedTime,
responsesSEQUENCEOFSingleResponse,
responseExtensions[1]EXPLICITExtensionsOPTIONAL}

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

KeyHash::=OCTETSTRING--SHA-1hashofresponder'spublickey
--(excludingthetagandlengthfields)

SingleResponse::=SEQUENCE{
certIDCertID,
certStatusCertStatus,
thisUpdateGeneralizedTime,

nextUpdate[0]EXPLICITGeneralizedTimeOPTIONAL,
singleExtensions[1]EXPLICITExtensionsOPTIONAL}

CertStatus::=CHOICE{
good[0]IMPLICITNULL,
revoked[1]IMPLICITRevokedInfo,
unknown[2]IMPLICITUnknownInfo}

RevokedInfo::=SEQUENCE{
revocationTimeGeneralizedTime,
revocationReason[0]EXPLICITCRLReasonOPTIONAL}

UnknownInfo::=NULL--thiscanbereplacedwithanenumeration

ArchiveCutoff::=GeneralizedTime

AcceptableResponses::=SEQUENCEOFOBJECTIDENTIFIER

ServiceLocator::=SEQUENCE{
issuerName,
locatorAuthorityInfoAccessSyntax}

--ObjectIdentifiers

id-kp-OCSPSigningOBJECTIDENTIFIER::={id-kp9}
id-pkix-ocspOBJECTIDENTIFIER::={id-ad-ocsp}
id-pkix-ocsp-basicOBJECTIDENTIFIER::={id-pkix-ocsp1}
id-pkix-ocsp-nonceOBJECTIDENTIFIER::={id-pkix-ocsp2}
id-pkix-ocsp-crlOBJECTIDENTIFIER::={id-pkix-ocsp3}
id-pkix-ocsp-responseOBJECTIDENTIFIER::={id-pkix-ocsp4}
id-pkix-ocsp-nocheckOBJECTIDENTIFIER::={id-pkix-ocsp5}
id-pkix-ocsp-archive-cutoffOBJECTIDENTIFIER::={id-pkix-ocsp6}
id-pkix-ocsp-service-locatorOBJECTIDENTIFIER::={id-pkix-ocsp7}

END

附錄C MIME注冊
C.1 application/ocsp-request（應用/OCSP-請求）
To（寄往）:ietf-types@iana.org
Subject（主題）:RegistrationofMIMEmediatypeapplication/ocsp-request
MIMEmediatypename:application
MIME媒介類型名稱：應用
MIMEsuBTypename:ocsp-request
MIME副類型名稱：OCSP-請求
Requiredparameters:None
必要參數：無
Optionalparameters:None
可選參數：無
Encodingconsiderations:binary
編碼考慮：二進制
Securityconsiderations:Carriesarequestforinformation.This
requestmayoptionallybecryptographicallysigned.
安全考慮：攜帶一個信息請求。這個請求可以被密碼簽名。
InterOperabilityconsiderations:None
協同能力考慮：無
Publishedspecification:IETFPKIXWorkingGroupDraftonOnlineCertificateStatus
Protocol-OCSP
公布規范：IETFPKIX工作組在線證書狀態協議草案——OCSP
Applicationswhichusethismediatype:OCSPclients
使用這種媒介類型的應用：OCSP客戶端
Additionalinformation:
附加信息：
Magicnumber(s):None
魔術號：無
Fileextension(s):.ORQ
物件后綴：ORQ
MacintoshFileTypeCode(s):none
Macintosh文件類型編碼：無
Person&emailaddresstocontactforfurtherinformation:
AmbarishMalpani<ambarish@valicert.com>
假如要獲得更多信息請寄往私人EMAIL地址AmbarishMalpani
<ambarish@valicert.com>
Intendedusage:COMMON
計劃用途：普通
Author/Changecontroller:
AmbarishMalpani<ambarish@valicert.com>
作家/變化控制器：
AmbarishMalpani<ambarish@valicert.com>

C.2application/ocsp-response
應用/OCSP-回復
To（寄往）:ietf-types@iana.org
Subject（主題）:RegistrationofMIMEmediatypeapplication/ocsp-response
MIMEmediatypename:application
MIME媒介類型名稱：應用
MIMEsubtypename:ocsp-response
MIME副類型名稱：OCSP-回復
Requiredparameters:None
必要參數：無
Optionalparameters:None
可選參數：無
Encodingconsiderations:binary
編碼考慮：二進制
Securityconsiderations:Carriesacryptographicallysignedresponse
安全考慮：攜帶一個密碼簽名的回復
Interoperabilityconsiderations:None
協同能力考慮：無
Publishedspecification:IETFPKIXWorkingGroupDraftonOnline
CertificateStatusProtocol-OCSP
公布規范：IETFPKIX工作組在線證書狀態協議草案——OCSP
Applicationswhichusethismediatype:OCSPservers
使用這種媒介的應用：OCSP服務器
Additionalinformation:
附加信息
Magicnumber(s):None
魔術號：無
Fileextension(s):.ORS
文件擴展：ORS
MacintoshFileTypeCode(s):none
Macintosh文件類型編碼：無
Person&emailaddresstocontactforfurtherinformation:
AmbarishMalpani<ambarish@valicert.com>
假如要獲得更多信息請寄往私人EMAIL地址AmbarishMalpani
<ambarish@valicert.com>
Intendedusage:COMMON
計劃用途：普通
Author/Changecontroller:
AmbarishMalpani<ambarish@valicert.com>
作家/變化控制器：
AmbarishMalpani<ambarish@valicert.com>

版權申明
Copyright(C)TheInternetSociety(1999).AllRightsReserved.

Thisdocumentandtranslationsofitmaybecopiedandfurnishedto
others,andderivativeworksthatcommentonorotherwiseexplainit
orassistinitsimplementationmaybeprepared,copied,published
anddistributed,inwholeorinpart,withoutrestrictionofany
kind,providedthattheabovecopyrightnoticeandthisparagraphare
includedonallsuchcopiesandderivativeworks.However,this
documentitselfmaynotbemodifiedinanyway,suchasbyremoving
thecopyrightnoticeorreferencestotheInternetSocietyorother
Internetorganizations,exceptasneededforthepurposeof
developingInternetstandardsinwhichcasetheproceduresfor
copyrightsdefinedintheInternetStandardsprocessmustbe
followed,orasrequiredtotranslateitintolanguagesotherthan
English.

Thelimitedpermissionsgrantedaboveareperpetualandwillnotbe
revokedbytheInternetSocietyoritssuccessorsorassigns.

Thisdocumentandtheinformationcontainedhereinisprovidedonan
"ASIS"basisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERING
TASKFORCEDISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,INCLUDING
BUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATION
HEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOF
MERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE.