ocsp

目錄
·1. 摘要
·2. 協(xié)議概述
·2.1請(qǐng)求
·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請(qǐng)求
·4.1.2 請(qǐng)求（信息）語法的注意點(diǎn)
·4.2回復(fù)語法
·4.2.1 OCSP回復(fù)的ASN.1規(guī)范
·4.2.2 OCSP回復(fù)的注意點(diǎn)
·4.2.2.1 時(shí)間
·4.2.2.2 被授權(quán)的響應(yīng)器
·4.2.2.2.1 已授權(quán)響應(yīng)器的撤消檢查
·4.3強(qiáng)制和可選的加密算法




綜述

OCSP(Online Certificate Status Protocol，在線證書狀態(tài)協(xié)議)是維護(hù)服務(wù)器和其它網(wǎng)絡(luò)資源安全性的兩種普遍模式之一。另一種更老的方法是證書注銷列表（CRL）已經(jīng)被在線證書狀態(tài)協(xié)議取代了很多年了。

　　在線證書狀態(tài)協(xié)議克服了證書注銷列表（CRL）的主要缺陷：必須經(jīng)常在客戶端下載以確保列表的更新。當(dāng)用戶試圖訪問一個(gè)服務(wù)器時(shí)，在線證書狀態(tài)協(xié)議發(fā)送一個(gè)對(duì)于證書狀態(tài)信息的請(qǐng)求。服務(wù)器回復(fù)一個(gè)“有效”、“過期”或“未知”的響應(yīng)。協(xié)議規(guī)定了服務(wù)器和客戶端應(yīng)用程序的通訊語法。在線證書狀態(tài)協(xié)議給了用戶的到期的證書一個(gè)寬限期，這樣他們就可以在更新以前的一段時(shí)間內(nèi)繼續(xù)訪問服務(wù)器。


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

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


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


2.1請(qǐng)求

一個(gè)OCSP請(qǐng)求包含以下數(shù)據(jù)

——協(xié)議版本

——服務(wù)請(qǐng)求

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

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

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

1． 信息正確格式化

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

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


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

2.3例外情況

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

——未正確格式化的請(qǐng)求（malformedRequest）

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

——請(qǐng)稍后再試(trylater)

——需要簽名(sigRequired)

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

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

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

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

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


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

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

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

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

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

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


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

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


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

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


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

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


3 功能必要條件



3.1 證書內(nèi)容

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

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


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

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

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

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

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

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

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

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

4. 具體協(xié)議

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

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


4.1請(qǐng)求

這一節(jié)描述了請(qǐng)求信息的ASN.1規(guī)范。實(shí)際的信息格式根據(jù)所使用的傳輸機(jī)制(HTTP,SMTP,LDAP等等)而不同。

4.1.1 請(qǐng)求（信息）語法

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)該檢測(cè)證書發(fā)布者名稱域的DER編碼的散列。發(fā)布者密鑰散列（issuerKeyHash）是發(fā)布者公鑰的散列。對(duì)發(fā)布者證書的主體公鑰域的值（不包括標(biāo)簽和長(zhǎng)度）進(jìn)行散列。所有這些使用的散列算法都由散列算法域(hashAlgorithm)確定。序列號(hào)域（serialNumber）是被查詢狀態(tài)證書的序列號(hào)。


4.1.2 請(qǐng)求（信息）語法的注意點(diǎn)

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


4.2回復(fù)語法

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


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

一個(gè)OCSP回復(fù)至少包括用來指示對(duì)先前請(qǐng)求所處理狀態(tài)的回復(fù)狀態(tài)域（responseStatus）。如果回復(fù)狀態(tài)域的值達(dá)到某一種出錯(cuò)情況，那么回復(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）的值由對(duì)象標(biāo)識(shí)和一個(gè)編碼成OCTET字符串的回復(fù)標(biāo)記（此

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

ResponseBytes::=SEQUENCE{

responseTypeOBJECTIDENTIFIER,

responseOCTETSTRING}

對(duì)于基本的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)該對(duì)回復(fù)數(shù)據(jù)（ResponseData）的DER編碼上的散列計(jì)算而得。

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)簽和長(zhǎng)度域)

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——這個(gè)可以被一個(gè)列舉代替。


4.2.2 OCSP回復(fù)的注意點(diǎn)
4.2.2.1 時(shí)間

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


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

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

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

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

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

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

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


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

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

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

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

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

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


4.3強(qiáng)制和可選的加密算法

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

4.4 擴(kuò)展

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

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

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

4.4.1 隨機(jī)數(shù)

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

一個(gè)請(qǐng)求擴(kuò)展被包括在請(qǐng)求中，同樣的也作為一個(gè)回復(fù)擴(kuò)展被包括在回復(fù)中。在請(qǐng)求和回復(fù)

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

id-pkix-ocsp-nonceOBJECTIDENTIFIER::=

4.4.2 證書撤消列表參考

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

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

源定位（URL）（證書撤消列表可以從這個(gè)URL中獲得），或由一個(gè)序列號(hào)（證書撤消列表

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

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

id-pkix-ocsp-crlOBJECTIDENTIFIER::=

CrlID::=SEQUENCE{

crlUrl[0]EXPLICITIA5StringOPTIONAL,

crlNum[1]EXPLICITINTEGEROPTIONAL,

crlTime[2]EXPLICITGeneralizedTimeOPTIONAL}

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

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

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

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

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

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

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

（AcceptableResponses）。

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

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

id-pkix-ocsp-responseOBJECTIDENTIFIER::=

AcceptableResponses::=SEQUENCEOFOBJECTIDENTIFIER

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

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

4.4.4文件中斷

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

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

檔中斷”日期。

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

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

名有效。

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

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

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

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

ArchiveCutoff::=GeneralizedTime

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

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

4.4.5 證書撤消列表入口擴(kuò)展

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

被支持。

4.4.6 服務(wù)定位器

一臺(tái)OCSP服務(wù)器也許是在這樣一種模式中運(yùn)做的，一臺(tái)服務(wù)器收到請(qǐng)求后將會(huì)把該請(qǐng)

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

個(gè)擴(kuò)展作為單一請(qǐng)求擴(kuò)展被包括在請(qǐng)求中。

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

ServiceLocator::=SEQUENCE{

issuerName,

locatorAuthorityInfoAccessSyntaxOPTIONAL}

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

5 安全方面的考慮

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

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

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

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

效。

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

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

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

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

求攻擊。

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

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

置OCSP在HTTP之上時(shí)。

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的請(qǐng)求和回復(fù)的格式。

A.1.1 請(qǐng)求

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

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

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

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

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

GET/

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

本地配置信息中獲得。

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

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

（"application/ocsp-request"），同時(shí)信息主體是OCSP請(qǐng)求（OCSPRequest）DER編碼的二

進(jìn)制值。

A.1.2 回復(fù)

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

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

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

他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è)

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

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

Subject（主題）:RegistrationofMIMEmediatypeapplication/ocsp-request

MIMEmediatypename:application

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

MIMEsubtypename:ocsp-request

MIME副類型名稱：OCSP-請(qǐng)求

Requiredparameters:None

必要參數(shù)：無

Optionalparameters:None

可選參數(shù)：無

Encodingconsiderations:binary

編碼考慮：二進(jìn)制

Securityconsiderations:Carriesarequestforinformation.This

requestmayoptionallybecryptographicallysigned.

安全考慮：攜帶一個(gè)信息請(qǐng)求。這個(gè)請(qǐng)求可以被密碼簽名。

Interoperabilityconsiderations:None

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

Publishedspecification:IETFPKIXWorkingGroupDraftonOnlineCertificateStatus

Protocol-OCSP

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

Applicationswhichusethismediatype:OCSPclients

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

Additionalinformation:

• 通信詞典解釋