ocsp

維護伺服器和網路安全的模式之一

OCSP(Online Certificate Status Protocol，在線證書狀態協議)是維護伺服器和其它網路資源安全性的兩種普遍模式之一。OCSP克服了證書註銷列表（CRL）的主要缺陷：必須經常在客戶端下載以確保列表的更新。當用戶試圖訪問一個伺服器時，在線證書狀態協議發送一個對於證書狀態信息的請求。伺服器回復一個“有效”、“過期”或“未知”的響應。協議規定了伺服器和客戶端應用程序的通訊語法。在線證書狀態協議給了用戶的到期的證書一個寬限期，這樣他們就可以在更新以前的一段時間內繼續訪問伺服器。

目錄
1摘要 2協議信息 3功能必要條件
4社區卒中計劃

摘要

本文檔描述了無需證書撤消列表就可以決定一張數字證書當前狀態的協議。附加描述PKIX操作必要條件的機制在另外的文檔中有詳細說明。
第二章中有協議的概述。功能必要條件在第三章中有詳細描述。第四章是具體協議。第五章我們將討論一些和協議有關的安全問題。附錄A定義了在HTTP之上的OCSP，附錄B有ASN.1的語義元素，附錄C詳細描述了信息的mime類型。
本文檔中的關鍵字"MUST","MUSTNOT","REQUIRED","SHALL","SHALLNOT","SHOULD","SHOULDNOT","RECOMMENDED","MAY",and"OPTIONAL"同
RFC2119中的敘述一樣。

協議信息

作為檢查定期證書撤消列表的補充，有些場合下必須要獲得一些有關證書撤消狀態的即時信息。（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.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-pkix-ocsp-basicOBJECTIDENTIFIER::=
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::=依賴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::=
——一個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::=
4.4.2 證書撤消列表參考
也許想OCSP響應器指出可以發現已撤消或正保持證書的證書撤消列表。當OCSP在倉
庫之間使用而且作為一個審核機制時這個是很有用的。這個證書撤消列表可以由一個同一資
源定位（URL）（證書撤消列表可以從這個URL中獲得），或由一個序列號（證書撤消列表
序列號）或者由一個時間（相關證書撤消列表產生的時間）來指定。這些擴展作為單一擴展
（singleExtensions）來描述。這個擴展的標識是id-pkix-ocsp-crl，值是CrlID。
id-pkix-ocsp-crlOBJECTIDENTIFIER::=
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::=
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::=
ArchiveCutoff::=GeneralizedTime
舉個例子，如果一個伺服器以7年時間長度為規則的保持力，而且狀態在時間點T1產
生。那麼回復中文檔中斷的值就是t1-7年。
4.4.5 證書撤消列表入口擴展
所有的擴展同RFC2459章節5.3中所定義的CRL入口擴展描述，同樣也作為單一擴展
被支持。
4.4.6 服務定位器
一台OCSP伺服器也許是在這樣一種模式中運做的，一台伺服器收到請求后將會把該請
求路由給對此證書有權威性的OCSP伺服器。為了這個目的定義了服務定位器請求擴展。這
個擴展作為單一請求擴展被包括在請求中。
id-pkix-ocsp-service-locatorOBJECTIDENTIFIER::=
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:[email protected]
RichAnkney
CertCo,LLC
13506KingCharlesDr.
Chantilly,VA20151
EMail:[email protected]
AmbarishMalpani
ValiCert,Inc.
1215TerraBellaAve.
MountainView,CA94043
Phone:650.567.5457
EMail:[email protected]
SlavaGalperin
MyCFO,Inc.
1945CharlestonRoad
MountainView,CA
EMail:[email protected]
CarlisleAdams
EntrustTechnologies
750HeronRoad,SuiteE08
Ottawa,Ontario
K1V1A7
Canada
EMail:[email protected]
附錄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/
當可以從權威機構信息獲得（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-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（應用/OCSP-請求）
To（寄往）:[email protected]
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
如果要獲得更多信息請寄往私人EMAIL地址AmbarishMalpani
Intendedusage:COMMON
計劃用途：普通
Author/Changecontroller:
AmbarishMalpani
作家/變化控制器：
AmbarishMalpani
C.2application/ocsp-response
應用/OCSP-回復
To（寄往）:[email protected]
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
如果要獲得更多信息請寄往私人EMAIL地址AmbarishMalpani
Intendedusage:COMMON
計劃用途：普通
Author/Changecontroller:
AmbarishMalpani
作家/變化控制器：

社區卒中計劃

急性腦梗塞的牛津郡社區卒中計劃(Oxfordshire Community StrokeProject，OCSP)分型法已經廣泛應用。該分類方法將急性缺血性中風分為四類：完全前循環腦梗死、部分前循環腦梗死、后循環腦梗死、腔隙性腦梗死。 OCSP臨床分型可以為缺血性腦卒中患者的預后判斷提供參考依據。
按Bamford提出的OCSP分型：在患者入院24 h內由神經內科醫師在不知道CT掃描結果的情況下，根據患者最嚴重的臨床癥狀和體征，按照OCSP標準分類，分為：
①全前循環梗死( TAC I)。表現為三聯征，即完全大腦中動脈綜合征的表現：大腦較高神經活動障礙(意識障礙，失語，失算，空間定向力障礙等)；同向偏盲；對側三個部位(面、上、下肢) 較嚴重的運動和(或) 感覺障礙；
②部分前循環梗死( PAC I)。表現有以上三聯征的兩個，或只有高級神經活動障礙，或感覺運動缺損較TAC I局限；
③后循環梗死( POCI)。表現為各種程度的椎基底動脈綜合征：同側顱神經癱瘓及對側感覺運動障礙(交叉)；雙側運動障礙；雙眼協同活動及小腦功能障礙, 無長束征或視野缺損；
④腔隙性梗死(LACI) ，表現為腔隙綜合征，純運動性，純感覺性，共濟失調性輕偏癱及感覺運動性障礙。

基本信息

外文名
Online Certificate Status Protocol
狀態
測定所需要檢驗證書的狀態