ocsp

ocsp

百科解釋

目錄·1. 摘要
·2. 協(xié)議概述
·2.1請求
·2.2回復(fù)
·2.3例外情況
·2.4更新
·2.5回復(fù)預(yù)產(chǎn)生
·2.6 OCSP簽名權(quán)威代表
·2.7 當(dāng)CA密鑰不安全
·3 功能必要條件
·3.1 證書內(nèi)容
·3.2 已簽名回復(fù)的接受條件
·4.1請求
·4.1.2 請求（信息）語法的注意點
·4.2回復(fù)語法
·4.2.1 OCSP回復(fù)的ASN.1規(guī)范
·4.2.2 OCSP回復(fù)的注意點
·4.2.2.1 時間
·4.2.2.2 被授權(quán)的響應(yīng)器
·4.2.2.2.1 已授權(quán)響應(yīng)器的撤消檢查
·4.3強制和可選的加密算法

本文檔描述了無需證書撤消列表就可以決定一張數(shù)字證書當(dāng)前狀態(tài)的協(xié)議。附加描述PKIX操作必要條件的機制在另外的文檔中有詳細(xì)說明。

第二章中有協(xié)議的概述。功能必要條件在第三章中有詳細(xì)描述。第四章是具體協(xié)議。第五章我們將討論一些和協(xié)議有關(guān)的安全問題。附錄A定義了在HTTP之上的OCSP，附錄B有ASN.1的語義元素，附錄C詳細(xì)描述了信息的mime類型。

2. 協(xié)議概述

作為檢查定期證書撤消列表的補充，有些場合下必須要獲得一些有關(guān)證書撤消狀態(tài)的即時信息。（RFC2459章節(jié)3.3）例如涉及大量資金的交易或者股票買賣。在線證書狀態(tài)協(xié)議（OCSP）使得應(yīng)用程序可以測定所需要檢驗證書的（撤消）狀態(tài)。OCSP。一個OCSP客戶端發(fā)布一個狀態(tài)查詢給一個OCSP響應(yīng)器并且偵聽當(dāng)前證書直到響應(yīng)器提供了一個響應(yīng)。這個協(xié)議描述了在應(yīng)用程序檢查證書狀態(tài)和服務(wù)器提供狀態(tài)之間所需要交換的數(shù)據(jù)。

一個OCSP請求包含以下數(shù)據(jù)

——協(xié)議版本

——服務(wù)請求

——目標(biāo)證書標(biāo)識

——可能被OCSP響應(yīng)器處理的可選擴展

在接受一個請求之后，一個OCSP響應(yīng)器檢測是否：

1．信息正確格式化

2．響應(yīng)器被配置提供請求服務(wù)而且

3．請求包含了響應(yīng)器需要的信息，如果任何一個先決條件沒有滿足，那么OCSP響應(yīng)器將產(chǎn)生一個錯誤信息；否則的話，返回一個確定的回復(fù)。

OCSP回復(fù)可以有幾種類型。一個OCSP回復(fù)由回復(fù)類型和實際回復(fù)字節(jié)組成。有一種OCSP基本回復(fù)類型必須被所有的OCSP服務(wù)器和客戶端支持。本章的其余部分都僅適用于這個回復(fù)類型。所有確定的回復(fù)都應(yīng)被數(shù)字簽名。被用來簽名回復(fù)信息的密鑰必須是下列中的一個 ——頒發(fā)所涉及證書的CA ——一個被信任的響應(yīng)器，它的公鑰被請求者信任 ——一個CA指派的響應(yīng)器（被授權(quán)的響應(yīng)器），它具有一張由CA直接頒發(fā)的用來表示此響應(yīng)器可以為本CA發(fā)布OCSP回復(fù)的特別標(biāo)記證書。一個確定的回復(fù)信息由以下組成： ——回復(fù)語法的版本 ——響應(yīng)器名稱 ——對每一張被提及證書的回復(fù) ——可選擴展 ——簽名算法對象標(biāo)識符號 ——對回復(fù)信息散列后的簽名對每一張被請求證書的回復(fù)包括 ——目標(biāo)證書識別 ——證書狀態(tài)值 ——回復(fù)有效期 ——可選擴展這個說明定義了以下在證書狀態(tài)值中使用的一些確定回復(fù)識別： ——良好 ——已撤消 ——未知 “良好”狀態(tài)表示一個對狀態(tài)查詢的積極回復(fù)。至少，這個積極回復(fù)表示這張證書沒有被撤消，但是不一定意味著這張證書曾經(jīng)被頒發(fā)過或者產(chǎn)生這個回復(fù)在證書有效期內(nèi)�；貜�(fù)擴展可以被用來傳輸一些附加信息，響應(yīng)器由此可以對這張證書的狀態(tài)做出一些積極的聲明，諸如（已頒發(fā)）保證，有效期等等。 “已撤消”狀態(tài)表示證書已被撤消（無論是臨時性的還是永久性的（待判斷）） “未知”狀態(tài)表示響應(yīng)器不知道請求的證書。

2.3例外情況

萬一出錯，OCSP響應(yīng)器會返回一個出錯信息。這些信息無須簽名。出錯信息可以是以下一些類型

——未正確格式化的請求（malformedRequest）

——內(nèi)部錯誤（internalError）

——請稍后再試(trylater)

——需要簽名(sigRequired)

——未授權(quán)(unauthorized)

如果接受到一個沒有遵循OCSP語法的請求，服務(wù)器產(chǎn)生“未正確格式化的請求”回復(fù)。回復(fù)“內(nèi)部錯誤”表示OCSP響應(yīng)器處于一個不協(xié)調(diào)的內(nèi)部狀態(tài)。請求需要再試，暗示嘗試另一個響應(yīng)器。

如果OCSP響應(yīng)器正在工作，但是不能返回被請求證書的狀態(tài)，那么“稍后再試”回復(fù)能被用來表示服務(wù)存在，但暫時不能響應(yīng)。

當(dāng)服務(wù)器需要客戶端簽名請求后才能產(chǎn)生一個回復(fù)時，回復(fù)“需要簽名”將被返回。

當(dāng)客戶端未被授權(quán)允許向這臺服務(wù)器發(fā)送請求時，回復(fù)“未授權(quán)”將被返回。

(thisUpdate)，下次更新(nextUpdate)和產(chǎn)生時間(producedAt)的語義

回復(fù)信息可以在其中包含三種時間——此次更新，下次更新和產(chǎn)生時間。這些域的語義如下：

——此次更新：此證書狀態(tài)被表示為正確的時間

——下次更新：在此時間之后，可獲得此證書狀態(tài)的新近信息

——產(chǎn)生時間：OCSP簽名這個回復(fù)的時間

如果響應(yīng)器未設(shè)置下次更新，那意味著新近的撤消信息在任何時候都可以被獲得。

2.5回復(fù)預(yù)產(chǎn)生

OCSP響應(yīng)器可以預(yù)先產(chǎn)生用來描述在某個確定時間此證書狀態(tài)的已簽名回復(fù)。通過在回復(fù)的此次更新域的反映，獲得此狀態(tài)的時間可以被正確認(rèn)識。下次新近信息則反映在下次更新域中，與此同時產(chǎn)生這個回復(fù)的時間則出現(xiàn)在回復(fù)的產(chǎn)生時間域中。

2.6 OCSP簽名權(quán)威代表

用來簽名證書狀態(tài)信息的密鑰不一定需要和簽名此證書的密鑰相同。通過發(fā)布一張包含有擴展密鑰用途域唯一值的OCSP簽名者證書證書發(fā)布者，可以明確的指派OCSP簽名權(quán)威機構(gòu)。這張證書必須直接由認(rèn)知的CA頒發(fā)給響應(yīng)器。

2.7 當(dāng)CA密鑰不安全

如果一個OCSP響應(yīng)器知道一個特定的CA私鑰不安全，那么針對所有這個CA頒布的證書都可以返回一個撤消狀態(tài)。

3 功能必要條件

3.1 證書內(nèi)容

為了傳達給OCSP客戶端一個知道的信息獲取點，CA們可以在權(quán)威機構(gòu)信息獲取擴展（可以被檢測用來使用OCSP）提供這樣的能力。作為另外一種選擇，也可以在OCSP客戶端本地配置OCSP提供者獲取地（信息）。支持OCSP服務(wù)的CA，無論是自身實現(xiàn)還是通過授權(quán)響應(yīng)器來提供，都必須提供包括統(tǒng)一資源識別形式的獲取地信息和在一個獲取描述序列中的對象識別符號形式的獲取方法。在主體證書的獲取地域中的值定義了使用什么傳輸（例如HTTP）來獲取OCSP響應(yīng)器

并且可以包含其他傳輸相關(guān)信息（例如URL）。

3.2 已簽名回復(fù)的接受條件

在接受一個已簽名的回復(fù)為有效之前，OCSP客戶端必須確認(rèn)：

1. 在回復(fù)信息中所指的證書和相應(yīng)請求中所指證書一致。

2. 回復(fù)中的簽名有效。

3. 簽名者的身份和相映應(yīng)接受請求者匹配。

4. 簽名者正被授權(quán)簽名回復(fù)。

5. 表示狀態(tài)被認(rèn)為是正確的時間（此次更新）足夠新。

6. 如果有的話，下次更新的時間應(yīng)該晚于現(xiàn)時時間。

4. 具體協(xié)議

這個ASN.1語法引用了在RFC2459中定義的術(shù)語。至于簽名運算，被簽名的數(shù)據(jù)使用ASN.1顯示編碼規(guī)則（DER）[x.690]。

除非指定了其他，否則默認(rèn)使用ASN.1外在標(biāo)記。從別處引用的的術(shù)語有：擴展(Extensions)，證書序列號CertificateSerialNumber）,主體公鑰信息(SubjectPublicKeyInfo),名稱(Name),算法識別(AlgorithmIdentifier),證書撤消列表原因（CRLReason）

這一節(jié)描述了請求信息的ASN.1規(guī)范。實際的信息格式根據(jù)所使用的傳輸機制(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&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;sDN

issuerKeyHashOCTETSTRING,--HashofIssuerspublickey

serialNumberCertificateSerialNumber}

發(fā)布者名稱散列(issuerNameHash)是發(fā)布者顯式名稱的散列。應(yīng)該檢測證書發(fā)布者名稱域的DER編碼的散列。發(fā)布者密鑰散列（issuerKeyHash）是發(fā)布者公鑰的散列。對發(fā)布者證書的主體公鑰域的值（不包括標(biāo)簽和長度）進行散列。所有這些使用的散列算法都由散列算法域(hashAlgorithm)確定。序列號域（serialNumber）是被查詢狀態(tài)證書的序列號。

4.1.2 請求（信息）語法的注意點

除了對CA名稱進行散列外還對CA的公鑰進行散列，這樣做的主要原因是為了識別發(fā)布者，因為兩個CA有可能選擇同一名稱(雖然建議使用獨一無二的名稱，但這并不是強制要求的)。然而，除非兩個CA明確表示他們共享私鑰或者其中一個CA的密鑰是不安全的，否則兩個CA是不可能有相同的密鑰。支持任何的擴展是可選的。每一個可選擴展的重要性標(biāo)志都不應(yīng)該被設(shè)置。章節(jié)4.4中提到了一些有用的擴展。其他的一些擴展也許會在其他的一些RFC中有所定義。未被承認(rèn)的擴展必須被忽略。（除非他們的重要性標(biāo)志被設(shè)置而且未被理解）響應(yīng)器可以選擇簽名OCSP的請求。在那種情況下，簽名是根據(jù)TBS請求(tbsRequest)結(jié)構(gòu)計算得到的。如果請求被簽名，那么響應(yīng)器可以在請求者名稱域中識別處它的名稱。同樣的，為了簽名請求，請求內(nèi)容可以包括用來幫助OCSP響應(yīng)器識別請求者簽名內(nèi)容的證書。

4.2回復(fù)語法

本節(jié)描述了回復(fù)信息的ASN.1規(guī)范。實際格式根據(jù)所使用的傳輸機制(HTTP,SMTP,LDAP等等)而不同。

4.2.1 OCSP回復(fù)的ASN.1規(guī)范

一個OCSP回復(fù)至少包括用來指示對先前請求所處理狀態(tài)的回復(fù)狀態(tài)域（responseStatus）。如果回復(fù)狀態(tài)域的值達到某一種出錯情況，那么回復(fù)字節(jié)(responseStatus)將不被設(shè)置。

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

}

回復(fù)字節(jié)（responseBytes）的值由對象標(biāo)識和一個編碼成OCTET字符串的回復(fù)標(biāo)記（此

標(biāo)記由剛才的對象標(biāo)識確定）組成。

ResponseBytes::=SEQUENCE{

responseTypeOBJECTIDENTIFIER,

responseOCTETSTRING}

對于基本的OCSP回復(fù)，回復(fù)類型是id-pkix-ocsp-basic。

id-pkix-ocspOBJECTIDENTIFIER::=

id-pkix-ocsp-basicOBJECTIDENTIFIER::=

OCSP響應(yīng)器應(yīng)該有能力產(chǎn)生id-pkix-ocsp-basic回復(fù)類型的回復(fù)。同樣的，OCSP客戶

端也應(yīng)該有能力接受并且處理id-pkix-ocsp-basic類型的回復(fù)。

回復(fù)的值應(yīng)該是基本OCSP回復(fù)（BasicOCSPResponse）的DER編碼。

BasicOCSPResponse::=SEQUENCE{

tbsResponseDataResponseData,

signatureAlgorithmAlgorithmIdentifier,

signatureBITSTRING,

certs[0]EXPLICITSEQUENCEOFCertificateOPTIONAL}

簽名值應(yīng)該對回復(fù)數(shù)據(jù)（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&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;spublickey

(不包括標(biāo)簽和長度域)

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回復(fù)的注意點

此次更新和下次更新域定義了一個推薦的有效期。一個時間長度和證書撤消列表中的{此次更新，下次更新}時間長度相一致。如果下次更新的值早于當(dāng)前本地系統(tǒng)時間，那么這個回復(fù)將被認(rèn)為不可靠。如果此次更新的值晚于當(dāng)前本地系統(tǒng)時間，那么這個回復(fù)也將被認(rèn)為不可靠。回復(fù)中沒有設(shè)置下次更新值等價于CRL沒有確定的下次更新時間（見章節(jié)2.4）產(chǎn)生時間是這個回復(fù)被簽名的時間。

4.2.2.2 被授權(quán)的響應(yīng)器

用來簽名證書狀態(tài)信息的密鑰可以和簽名證書狀態(tài)的密鑰不同。但是必須保證簽名這個信息的實體已被授權(quán)。所以證書發(fā)布者必須自己簽名OCSP回復(fù)或者明確的指派這個權(quán)利給其他實體。OCSP簽名代表可以通過包含在OCSP回復(fù)簽名者證書擴展密鑰用途擴展中的id-kp-OCSPSigning來指派。這張證書必須直接由頒布所涉及證書的CA發(fā)布。

id-kp-OCSPSigningOBJECTIDENTIFIER::=依賴OCSP回復(fù)的系統(tǒng)和應(yīng)用程序必須由能力探測并且執(zhí)行id-ad-ocspSigning值的使用，如前所述。他們可以提供一種本地配置一個或更多個OCSP簽名權(quán)威機構(gòu)的方法，而且可以指定一組被信任的簽名權(quán)威機構(gòu)。當(dāng)要求驗證回復(fù)上簽名的證書未滿足以下一個標(biāo)準(zhǔn)時，他們必須拒絕這樣的回復(fù)：

1. 和本地配置的對所涉及證書的OCSP簽名權(quán)威機構(gòu)匹配；或者

2. 和頒發(fā)所涉及證書的CA相同；或者

3. 包括在擴展密鑰用途擴展中的id-ad-ocspSigning值，這種證書由頒發(fā)所涉及證書的CA頒發(fā)。

回復(fù)本身或者用來驗證回復(fù)上簽名的證書可以應(yīng)用其他接受或者拒絕的標(biāo)準(zhǔn)。

4.2.2.2.1 已授權(quán)響應(yīng)器的撤消檢查

既然一個已授權(quán)的OCSP響應(yīng)器可以為一個或多個CA提供狀態(tài)信息服務(wù)，OCSP客戶端需要明白如何確定被授權(quán)的響應(yīng)器的證書沒有被撤消。CAS可以選擇以下三種方法之一來處理這個問題：

——一個CA可以指定OCSP客戶端能夠在響應(yīng)器證書生存期內(nèi)信任該響應(yīng)器。這個CA通過（在證書中）包括id-pkix-ocsp-nocheck。這個（擴展）應(yīng)該是非重要擴展。擴展的值可以為空。CA頒發(fā)這樣這樣一張證書應(yīng)該意識到響應(yīng)器密鑰的不安全問題，這和用來簽名證書撤消列表的CA密鑰的不安全問題同樣嚴(yán)重，至少在證書有效期內(nèi)是這樣。CA也可以選擇

發(fā)布生命周期非常短的此類型證書并且頻繁更新它。id-pkix-ocsp-nocheckOBJECTIDENTIFIER::=

——一個CA可以指定如何檢查響應(yīng)器的證書是否被撤消。如果應(yīng)該使用證書撤消列表或者證書撤消列表發(fā)布點來檢查，那么也能夠使用證書撤消列表來完成確定響應(yīng)器證書是否被撤消，或者如果其他應(yīng)該使用其他的方法那么權(quán)威機構(gòu)信息獲取。指定這兩種機制的細(xì)節(jié)可以在RFC2459中獲得。

——一個CA可以選擇不指定任何方法來檢查響應(yīng)器證書的有效性（是否被撤消），在這些情況中，是由OCSP客戶端的本地安全策略來決定證書是否檢查證書有效性（是否被撤消）。

4.3強制和可選的加密算法

那些請求OCSP服務(wù)的客戶端應(yīng)該有能力處理DSA密鑰的簽名，這些DSA密鑰通過RFC2459章節(jié)7.2.2中描述的DSAsig-alg-oid來識別�？蛻舳藨�(yīng)該同樣有能力處理在RFC2459章節(jié)7.2.1描述的RSA簽名。OCSP響應(yīng)器可應(yīng)該支持SHA1散列算法。

4.4 擴展

這一節(jié)定義了一些標(biāo)準(zhǔn)擴展，基于X.509版本3證書所使用的擴展模型（請見RFC2459）。

支持所有這些擴展對客戶端和響應(yīng)器都是可選的。對于每一個擴展，定義表示了它的語法，

由OCSP響應(yīng)器實現(xiàn)處理過程，而且在相應(yīng)的回復(fù)中包括任意擴展。

4.4.1 隨機數(shù)

隨機數(shù)很秘密的綁定了請求和回復(fù)，用來防止重發(fā)（replayattacks）攻擊。隨機數(shù)作為

一個請求擴展被包括在請求中，同樣的也作為一個回復(fù)擴展被包括在回復(fù)中。在請求和回復(fù)

中，隨機數(shù)由對象標(biāo)識id-pkix-ocsp-nonce識別，其中extnValue包含了隨機數(shù)的值。

id-pkix-ocsp-nonceOBJECTIDENTIFIER::=

4.4.2 證書撤消列表參考

也許想OCSP響應(yīng)器指出可以發(fā)現(xiàn)已撤消或正保持證書的證書撤消列表。當(dāng)OCSP在倉

庫之間使用而且作為一個審核機制時這個是很有用的。這個證書撤消列表可以由一個同一資

源定位（URL）（證書撤消列表可以從這個URL中獲得），或由一個序列號（證書撤消列表

序列號）或者由一個時間（相關(guān)證書撤消列表產(chǎn)生的時間）來指定。這些擴展作為單一擴展

（singleExtensions）來描述。這個擴展的標(biāo)識是id-pkix-ocsp-crl，值是CrlID。

id-pkix-ocsp-crlOBJECTIDENTIFIER::=

CrlID::=SEQUENCE{

crlUrl[0]EXPLICITIA5StringOPTIONAL,

crlNum[1]EXPLICITINTEGEROPTIONAL,

crlTime[2]EXPLICITGeneralizedTimeOPTIONAL}

如果選擇使用證書撤消列表的同一資源定位，那么IA5字符串被用來定義這個可獲得證書

撤消列表的同一資源定位（URL）。如果是證書撤消列表序列號，那么用整數(shù)來描述相關(guān)證

書撤消列表的證書撤消列表序列號擴展。如果是證書撤消列表時間，那么標(biāo)準(zhǔn)化時間被用來

表示這個相關(guān)證書撤消列表發(fā)布的時間。

4.4.3可接受的回復(fù)類型

一個OCSP客戶端可以希望指定一個它所理解的回復(fù)類型。為了達到這樣的目的，它應(yīng)

該使用id-pkix-ocsp-response對象標(biāo)識符的擴展，并且值為可接受回復(fù)

（AcceptableResponses）。

這個擴展作為一個請求擴展被包括在請求中。在可接受回復(fù)中包括了這個客戶端可接受

的不同回復(fù)類型的對象標(biāo)識符號（例如，id-pkix-ocsp-basic）。

id-pkix-ocsp-responseOBJECTIDENTIFIER::=

AcceptableResponses::=SEQUENCEOFOBJECTIDENTIFIER

如同章節(jié)4.2.1所提到的那樣，OCSP響應(yīng)器應(yīng)該有能力回復(fù)一個id-pkix-ocsp-basic的

回復(fù)類型。OCSP客戶端也應(yīng)該有能力接受并處理id-pkix-ocsp-basic回復(fù)類型的回復(fù)。

4.4.4文件中斷

一個OCSP響應(yīng)器可以選擇當(dāng)證書過期后仍保留相應(yīng)的撤消信息。

這個日期可以從產(chǎn)生時間（producedAt）減下的保持間期值中獲得，并被定義成證書的“文

檔中斷”日期。

可以使用OCSP的應(yīng)用程序會使用一個OCSP文檔中斷日期作為一個證明，證明一個數(shù)

字簽名是（或者不是）可被信賴于它的產(chǎn)生日期，即使證書過期很久后仍被要求證明這個簽

名有效。

提供這些歷史記錄參考的OCSP服務(wù)器應(yīng)該在回復(fù)中包括一個文檔中斷日期的擴展。如

果包括的話，那么這個值應(yīng)該作為由id-pkix-ocsp-archive-cutoff確定的OCSP單一擴展，并

且為標(biāo)準(zhǔn)化時間標(biāo)記語法。

id-pkix-ocsp-archive-cutoffOBJECTIDENTIFIER::=

ArchiveCutoff::=GeneralizedTime

舉個例子，如果一個服務(wù)器以7年時間長度為規(guī)則的保持力，而且狀態(tài)在時間點T1產(chǎn)

生。那么回復(fù)中文檔中斷的值就是t1-7年。

4.4.5 證書撤消列表入口擴展

所有的擴展同RFC2459章節(jié)5.3中所定義的CRL入口擴展描述，同樣也作為單一擴展

被支持。

4.4.6 服務(wù)定位器

一臺OCSP服務(wù)器也許是在這樣一種模式中運做的，一臺服務(wù)器收到請求后將會把該請

求路由給對此證書有權(quán)威性的OCSP服務(wù)器。為了這個目的定義了服務(wù)定位器請求擴展。這

個擴展作為單一請求擴展被包括在請求中。

id-pkix-ocsp-service-locatorOBJECTIDENTIFIER::=

ServiceLocator::=SEQUENCE{

issuerName,

locatorAuthorityInfoAccessSyntaxOPTIONAL}

這些域的值可以從主體證書中的相應(yīng)域中獲得。

5 安全方面的考慮

為了使這項服務(wù)有效，證書使用系統(tǒng)必須連接到證書狀態(tài)服務(wù)提供者。如果這樣的連接

不可實現(xiàn)，那么證書使用系統(tǒng)可以實現(xiàn)證書撤消列表處理，作為一種退而求其次的方法。

如果請求過多，將會使服務(wù)器相當(dāng)脆弱。密碼簽名工作也將顯著的影響到回復(fù)產(chǎn)生周期，從

而使情況惡化。如果不簽名，那么將使攻擊者可能發(fā)送假回復(fù)，造成協(xié)議服務(wù)被攻擊導(dǎo)致無

效。

使用預(yù)先產(chǎn)生的回復(fù)將可能導(dǎo)致重發(fā)攻擊，一個舊（良好狀態(tài)）的回復(fù)將被用來重發(fā)作

為一個在有效期內(nèi)但已被撤消的證書狀態(tài)。所以為了實現(xiàn)預(yù)先產(chǎn)生回復(fù)帶來的好處，OCSP

應(yīng)被小心配置，既要考慮到成功執(zhí)行后的效率代價又要考慮到被重發(fā)攻擊的可能性。

請求不包含他們所直接面對的響應(yīng)器，這將導(dǎo)致攻擊者向任意一個OCSP響應(yīng)器重發(fā)請

求攻擊。

對于依賴于HTTP緩存的配置場合，如果中間服務(wù)器沒有被正確的配置或者存在緩存管

理錯誤，那么將會導(dǎo)致非期望的結(jié)果。建議實現(xiàn)人員仔細(xì)考慮HTTP緩存機制的可靠性當(dāng)配

置OCSP在HTTP之上時。

6 參考

[RFC2459] Housley,R.,Ford,W.,Polk,W.andD.Solo,

"因特網(wǎng)x.509公鑰基礎(chǔ)設(shè)施證書和證書撤消列表輪廓"，RFC2459,1999一月

[HTTP] Fielding,R.,Gettys,J.,Mogul,J.,Frystyk,H.andT.Berners-Lee

"超文本傳輸協(xié)議——HTTP/1.1",RFC2068，1997一月

[RFC2119] Bradner,S.,

"RFC中關(guān)鍵字使用的需要水平"，BCP14,RFC2119,1997三月

Berners-Lee,T.,Masinter,L.andM.McCahill,

"統(tǒng)一資源定位(URL)"，RFC1738，1994 12月

[x.690] ITU-T 建議 x.690(1994)|ISO/IEC 8825-1:1995,

信息技術(shù)——ASN.1編碼規(guī)則：基本編碼規(guī)則（BER），規(guī)范編碼規(guī)則（CER）和顯式

編碼規(guī)則（DER）的描述。

附錄A

A.1 在HTTP之上的OCSP

本章節(jié)描述了用來完成支持HTTP的請求和回復(fù)的格式。

A.1.1 請求

基于OCSP的HTTP請求可以使用GET或者POST方法來提交他們的請求。為了使用

HTTP緩存，小的請求（在編碼后少于255字節(jié)），可以使用GET來提交。如果HTTP緩存

不重要，后者請求大于255字節(jié)，那么請求應(yīng)該使用POST方法提交。當(dāng)需要保密性時，使

用HTTP的OCSP事務(wù)交換可以使用TLS/SSL或者其他更低層的協(xié)議來保護。

一個使用GET方法OCSP請求如下構(gòu)筑：

GET/

當(dāng)可以從權(quán)威機構(gòu)信息獲得（AuthorityInfoAccess）或者其他一些OCSP客戶端的

本地配置信息中獲得。

一個使用POST的OCSP請求可以如下構(gòu)筑：

內(nèi)容類型頭部（Content-Typeheader）的值為“應(yīng)用/OCSP-請求”

（"application/ocsp-request"），同時信息主體是OCSP請求（OCSPRequest）DER編碼的二

進制值。

A.1.2 回復(fù)

一個基于HTTP的OCSP回復(fù)的組成是，適當(dāng)?shù)腍TTP頭部，緊跟著一個OCSP回復(fù)

DER編碼的二進制值。內(nèi)容類型頭部（Content-Typeheade）的值為“應(yīng)用/OCSP-回復(fù)”

"application/ocsp-request"。內(nèi)容長度頭部（Content-Lengthheader）應(yīng)該指出回復(fù)的長度。其

他HTTP頭部也可以被提出而且如果不被響應(yīng)器理解的話，也可以被忽視。

附錄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&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;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&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;&＃39;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-pkix-ocspOBJECTIDENTIFIER::=

id-pkix-ocsp-basicOBJECTIDENTIFIER::=

id-pkix-ocsp-nonceOBJECTIDENTIFIER::=

id-pkix-ocsp-crlOBJECTIDENTIFIER::=

id-pkix-ocsp-responseOBJECTIDENTIFIER::=

id-pkix-ocsp-nocheckOBJECTIDENTIFIER::=

id-pkix-ocsp-archive-cutoffOBJECTIDENTIFIER::=

id-pkix-ocsp-service-locatorOBJECTIDENTIFIER::=

END

附錄C MIME注冊

C.1 application/ocsp-request（應(yīng)用/OCSP-請求）

To（寄往）:ietf-types@iana.org

Subject（主題）:RegistrationofMIMEmediatypeapplication/ocsp-request

MIMEmediatypename:application

MIME媒介類型名稱：應(yīng)用

MIMEsubtypename:ocsp-request

MIME副類型名稱：OCSP-請求

Requiredparameters:None

必要參數(shù)：無

Optionalparameters:None

可選參數(shù)：無

Encodingconsiderations:binary

編碼考慮：二進制

Securityconsiderations:Carriesarequestforinformation.This

requestmayoptionallybecryptographicallysigned.

安全考慮：攜帶一個信息請求。這個請求可以被密碼簽名。

Interoperabilityconsiderations:None

協(xié)同能力考慮：無

Publishedspecification:IETFPKIXWorkingGroupDraftonOnlineCertificateStatus

Protocol-OCSP

公布規(guī)范：IETFPKIX工作組在線證書狀態(tài)協(xié)議草案——OCSP

Applicationswhichusethismediatype:OCSPclients

使用這種媒介類型的應(yīng)用：OCSP客戶端

Additionalinformation:

通信詞典解釋

<del id="isxnr"><dl id="isxnr"></dl></del>