?? rfc2560.txt
字號:
組織:中國互動出版網(wǎng)(http://www.china-pub.com/)
RFC文檔中文翻譯計劃(http://www.china-pub.com/compters/emook/aboutemook.htm)
E-mail:ouyang@china-pub.com
譯者:姚玥(yaoyue baboon@public9.sta.net.cn)
譯文發(fā)布時間:2001-6-8
版權(quán):本中文翻譯文檔版權(quán)歸中國互動出版網(wǎng)所有。可以用于非商業(yè)用途自由轉(zhuǎn)載,但必須
保留本文檔的翻譯及版權(quán)信息。
Network Working Group M. Myers
Request for Comments: 2560 VeriSign
Category: Standards Track R. Ankney
CertCo
A. Malpani
ValiCert
S. Galperin
My CFO
C. Adams
Entrust Technologies June 1999
x.509因特網(wǎng)公鑰基礎(chǔ)設(shè)施在線證書狀態(tài)協(xié)議——OCSP
(RFC2560 X.509 Internet Public Key Infrastructure Online Certificate Status
Protocol – OCSP)
本備忘錄的狀態(tài)
本文檔講述了一種Internet社區(qū)的Internet標準跟蹤協(xié)議,它需要進一步進行討論和建
議以得到改進。請參考最新版的“Internet正式協(xié)議標準” (STD1)來獲得本協(xié)議的標準化
程度和狀態(tài)。本備忘錄的發(fā)布不受任何限制。
版權(quán)聲明
Copyright (C) The Internet Society (1999). All Rights Reserved.
1. 摘要
本文檔描述了無需證書撤消列表就可以決定一張數(shù)字證書當(dāng)前狀態(tài)的協(xié)議。附加描述
PKIX操作必要條件的機制在另外的文檔中有詳細說明。
第二章中有協(xié)議的概述。功能必要條件在第三章中有詳細描述。第四章是具體協(xié)議。第
五章我們將討論一些和協(xié)議有關(guān)的安全問題。附錄A定義了在HTTP之上的OCSP,附
錄B有ASN.1的語義元素,附錄C詳細描述了信息的mime類型。
本文檔中的關(guān)鍵字"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"同
RFC2119中的敘述一樣。
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ù)。
2.1請求
一個OCSP請求包含以下數(shù)據(jù)
——協(xié)議版本
——服務(wù)請求
——目標證書標識
——可能被OCSP響應(yīng)器處理的可選擴展
在接受一個請求之后,一個OCSP響應(yīng)器檢測是否:
1. 信息正確格式化
2. 響應(yīng)器被配置提供請求服務(wù)而且
3. 請求包含了響應(yīng)器需要的信息,如果任何一個先決條件沒有滿足,那么OCSP響應(yīng)器將
產(chǎn)生一個錯誤信息;否則的話,返回一個確定的回復(fù)。
2.2回復(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ù)的特別標記證書。
一個確定的回復(fù)信息由以下組成:
——回復(fù)語法的版本
——響應(yīng)器名稱
——對每一張被提及證書的回復(fù)
——可選擴展
——簽名算法對象標識符號
——對回復(fù)信息散列后的簽名
對每一張被請求證書的回復(fù)包括
——目標證書識別
——證書狀態(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)”將被返回。
2.4此次更新(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)的時間可以被正確認識。下次新近信息則反映在下次
更新域中,與此同時產(chǎn)生這個回復(fù)的時間則出現(xiàn)在回復(fù)的產(chǎn)生時間域中。
2.6 OCSP簽名權(quán)威代表
用來簽名證書狀態(tài)信息的密鑰不一定需要和簽名此證書的密鑰相同。通過發(fā)布一張包含
有擴展密鑰用途域唯一值的OCSP簽名者證書證書發(fā)布者,可以明確的指派OCSP簽名權(quán)威
機構(gòu)。這張證書必須直接由認知的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客戶端必須確認:
1. 在回復(fù)信息中所指的證書和相應(yīng)請求中所指證書一致。
2. 回復(fù)中的簽名有效。
3. 簽名者的身份和相映應(yīng)接受請求者匹配。
4. 簽名者正被授權(quán)簽名回復(fù)。
5. 表示狀態(tài)被認為是正確的時間(此次更新)足夠新。
6. 如果有的話,下次更新的時間應(yīng)該晚于現(xiàn)時時間。
4. 具體協(xié)議
這個ASN.1語法引用了在RFC2459中定義的術(shù)語。至于簽名運算,被簽名的數(shù)據(jù)使用
ASN.1顯示編碼規(guī)則(DER)[x.690]。
除非指定了其他,否則默認使用ASN.1外在標記。從別處引用的的術(shù)語有:擴展
(Extensions),證書序列號(CertificateSerialNumber),主體公鑰信息(SubjectPublicKeyInfo),
名稱(Name),算法識別(AlgorithmIdentifier),證書撤消列表原因(CRLReason)
4.1請求
這一節(jié)描述了請求信息的ASN.1規(guī)范。實際的信息格式根據(jù)所使用的傳輸機制
(HTTP,SMTP,LDAP等等)而不同。
4.1.1 請求(信息)語法
OCSPRequest ::= SEQUENCE {
tbsRequest TBSRequest,
optionalSignature [0] EXPLICIT Signature OPTIONAL }
TBSRequest ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
requestorName [1] EXPLICIT GeneralName OPTIONAL,
requestList SEQUENCE OF Request,
requestExtensions [2] EXPLICIT Extensions OPTIONAL }
Signature ::= SEQUENCE {
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING,
certs [0] EXPLICIT SEQUENCE OF Certificate
OPTIONAL}
Version ::= INTEGER { v1(0) }
Request ::= SEQUENCE {
reqCert CertID,
singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL }
CertID ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
issuerNameHash OCTET STRING, -- Hash of Issuer's DN
issuerKeyHash OCTET STRING, -- Hash of Issuers public key
serialNumber CertificateSerialNumber }
發(fā)布者名稱散列(issuerNameHash)是發(fā)布者顯式名稱的散列。應(yīng)該檢測證書發(fā)布者名稱
域的DER編碼的散列。發(fā)布者密鑰散列(issuerKeyHash)是發(fā)布者公鑰的散列。對發(fā)布者
證書的主體公鑰域的值(不包括標簽和長度)進行散列。所有這些使用的散列算法都由散列
算法域(hashAlgorithm)確定。序列號域(serialNumber)是被查詢狀態(tài)證書的序列號。
4.1.2 請求(信息)語法的注意點
除了對CA名稱進行散列外還對CA的公鑰進行散列,這樣做的主要原因是為了識別發(fā)
布者,因為兩個CA有可能選擇同一名稱(雖然建議使用獨一無二的名稱,但這并不是強制
要求的)。然而,除非兩個CA明確表示他們共享私鑰或者其中一個CA的密鑰是不安全的,
否則兩個CA是不可能有相同的密鑰。
支持任何的擴展是可選的。每一個可選擴展的重要性標志都不應(yīng)該被設(shè)置。章節(jié)4.4中
提到了一些有用的擴展。其他的一些擴展也許會在其他的一些RFC中有所定義。未被承認
的擴展必須被忽略。(除非他們的重要性標志被設(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 {
responseStatus OCSPResponseStatus,
responseBytes [0] EXPLICIT ResponseBytes OPTIONAL }
OCSPResponseStatus ::= ENUMERATED {
successful (0), --Response has valid confirmations
malformedRequest (1), --Illegal confirmation request
internalError (2), --Internal error in issuer
tryLater (3), --Try again later
--(4) is not used
sigRequired (5), --Must sign the request
unauthorized (6) --Request unauthorized
}
回復(fù)字節(jié)(responseBytes)的值由對象標識和一個編碼成OCTET字符串的回復(fù)標記(此
標記由剛才的對象標識確定)組成。
ResponseBytes ::= SEQUENCE {
responseType OBJECT IDENTIFIER,
response OCTET STRING }
對于基本的OCSP回復(fù),回復(fù)類型是id-pkix-ocsp-basic。
id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp }
id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 }
OCSP響應(yīng)器應(yīng)該有能力產(chǎn)生id-pkix-ocsp-basic回復(fù)類型的回復(fù)。同樣的,OCSP客戶
端也應(yīng)該有能力接受并且處理id-pkix-ocsp-basic類型的回復(fù)。
?? 快捷鍵說明
復(fù)制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -