摘要
本文檔描述了無需證書撤消列表就可以決定一張數字證書當前狀態的協定。附加描述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) ，表現為腔隙綜合徵，純運動性， 純感覺性， 共濟失調性輕偏癱及感覺運動性障礙。
