本備忘錄的狀態
本文檔講述了一種Internet社區的Internet標準跟蹤協議,它需要進一步進行討論和建議以得到改進。請參考最新版的“Internet正式協議標準” (STD1)來獲得本協議的標準化程度和狀態。本備忘錄的發布不受任何限制。
版權聲明
Copyright (C) The Internet Society (1999). All Rights Reserved.
摘要
本文檔中描述的協議約定滿足Internet公用密鑰機制(PKI)中的許多可操作的需求.本文檔同時講述了一些使用文件傳輸協議(FTP)和超文本傳輸協議(HTTP)來從PKI倉庫中獲取證書和證書撤消列表(CRL)的協定. 附加的描述訪問PKI倉庫的機制在另外的文檔中有詳細說明.
目錄
1 介紹 1
1.1 模型 2
1.2 證書和CRL倉庫 3
2 FTP約定 3
3 HTTP約定 3
4 MIME登記 4
4.1 申請/PKIX-CERT 4
4.2 申請/PKIX-CRL 5
參考資料 5
安全方面的考慮 5
作者的地址 6
版權說明 6
致謝 7
1 介紹
本說明是使用X.509證書和證書撤消列表(CRL)的Internet公用密鑰機制(PKI)多個標準的一部分. 本文檔同時講述了一些使用文件傳輸協議(FTP)和超文本傳輸協議(HTTP)來從PKI倉庫中獲取證書和證書撤消列表(CRL)的協定. 附加的描述訪問PKI倉庫的機制在另外的文檔中有詳細說明.
1.1 模型
下面是由Internet PKI規范中假定的結構模型的簡單視圖.
+---+
| C | +------------+
| e | <-------------------->| 終端實體 |
| r | 操作事務和 +------------+
| t | 管理事務 ^
| / | | 管理事務
| | | PKI 用戶
| C | v
| R | -------------------+--+-----------+-----------------
| L | ^ ^
| | | | PKI 管理實體
| | v |
| R | +------+ |
| e | <---------------------| RA | <---+ |
| p | 發布證書 +------+ | |
| o | | |
| s | | |
| I | v v
| t | +------------+
| o | <------------------------------| CA |
| r | 發布證書 +------------+
| y | 發布CRL ^
| | |
+---+ 管理事務 |
v
+------+
| CA |
+------+
這個模型中由以下幾部分組成:
終端實體:PKI證書用戶及/或者作為證書主題的最終用戶系統.
CA.授權機構
RA:登記機構.例如,CA可以把某些管理功能委托給一個可選系統.
倉庫:一個保存證書和CRL的系統或分布系統的集合,它是一種分發證書和CRL到終端用戶的方法.
1.2 證書和CRL倉庫
許多CA要求使用在線的校驗服務,而其他分布式的CRL允許證書用戶自己去實施證書的校驗。通常,CA通過把CRL發布到目錄中,使得證書用戶就可以使用了。目錄也是一種正規的證書分配機制.然而。目前,Internet的許多方面還沒有提供目錄服務。 RFC959中定義的文件傳輸協議(FTP)和RFC2068中定義的超文本傳輸協議(HTTP)提供了分配證書和CRL的可選方法。
終端實體和認證機構都可以使用FTP或HTTP協議從證書倉庫中檢索證書和CRL.終端實體可以使用FTP或HTTP來把他們自己的證書發布到倉庫中,而登記機構與認證機構也可以使用FTP或HTTP把證書和CRL發布到倉庫中.
2 FTP約定
在證書擴展和CRL擴展中,全名(GeneralName)的統一資源標識(URI)形式是用來指明證書發起者和可以得到CRL的位置。比如,一個指定證書標題的URI應該用subjectAltName證書擴展名來傳輸。一個IA5String描述了如何用匿名FTP方式去獲取證書和CRL的有關信息.例如:
ftp://ftp.netcom.com/sp/spyrus/housley.cer
ftp://ftp.your.org/pki/id48.cer
ftp://ftp.your.org/pki/id48.no42.crl
Internet用戶可以在他的商業名片上發布一個指向包含他的證書文件的URI引用。這種方法,在該用戶沒有目錄服務人口時非常有效。FTP已被廣泛使用,另外匿名FTP也已經被許多防火墻所接受。因此,FTP是通過目錄存取協議來進行證書和CRL分配的一種極具吸引力的可選方法. 盡管這種服務能夠滿足檢索已通過URI指定的證書的相關信息的要求,但是它卻無法解決在知道一個用戶的其他信息,如電子郵件地址或公司的聯系地址等的情況下,查找該用戶證書這樣更為通用的問題.
為了方便起見,包含證書的文件應該有一個后綴:.cer.每一個"cer"文件實際上包含了一個以DER格式編碼的證書。同樣,包含CRL的文件應該有一個后綴:.crl. 每一個"crl"文件實際上包含了一個以DER格式編碼的CRL.
3 HTTP約定
在證書擴展和CRL擴展中,全名(GeneralName)的統一資源標識(URI)形式是用來指明證書發起者和可以得到CRL的位置。比如,一個指定證書標題的URI應該用subjectAltName證書擴展名來傳輸。一個IA5String描述了如何用匿名HTTP方式去獲取證書和CRL的有關信息.例如:
http://www.netcom.com/sp/spyrus/housley.cer
http://www.your.org/pki/id48.cer
http://www.your.org/pki/id48.no42.crl
Internet用戶可以在他的商業名片上發布一個指向包含他的證書文件的URI引用。這種方法,在該用戶沒有目錄服務人口時非常有效。HTTP已被廣泛使用,另外HTTP也已經被許多防火墻所接受。因此,FTP是通過目錄存取協議來進行證書和CRL分配的一種極具吸引力的可選方法. 盡管這種服務能夠滿足檢索已通過URI指定的證書的相關信息的要求,但是它卻無法解決在知道一個用戶的其他信息,如電子郵件地址或公司的聯系地址等的情況下,查找該用戶證書這樣更為通用的問題.
為了方便起見,包含證書的文件應該有一個后綴:.cer.每一個"cer"文件實際上包含了一個以DER格式編碼的證書。同樣,包含CRL的文件應該有一個后綴:.crl. 每一個"crl"文件實際上包含了一個以DER格式編碼的CRL.
4 MIME登記
為支持證書和CRL的傳輸,定義了兩種MIME(多用途的網際郵件擴充協議)類型: application/pkix-cert及application/pkix-crl
4.1 申請/pkix-cert
To: ietf-types@iana.org
Subject: Registration of MIME media type application/pkix-cert
MIME媒介類型名稱: 申請
MIME 子類型名稱: pkix-cert
需要的參數: 無
可選參數: 版本 (缺省為 "1")
郵件編碼:不應該是8位傳輸,應該是7位傳輸或SMTP中的Base64碼
安全性方面的考慮:帶有加密的證書
互用性方面的考慮:無
發布規范:draft-ietf-pkix-ipki-part1
申請將會使用的媒介類型:所有兼容MIME的傳輸
附加信息:
魔數:無
文件的擴展名: .CER
Macintosh中的文件類型碼:無
如果需要更多的信息,請與以下E-MAIL聯系:
Russ Housley
Intended usage: COMMON
作者/變動 控制:
Russ Housley
4.2 申請/pkix-crl
To: ietf-types@iana.org
Subject: Registration of MIME media type application/pkix-crl
MIME媒介類型名稱: 應用
MIME 子類型名稱: pkix-crl
需要的參數: 無
可選參數: 版本 (缺省為 "1")
郵件編碼:不應該是8位傳輸,應該是7位傳輸或SMTP中的Base64
安全性方面的考慮:帶有加密的證書撤消列表
協同性方面的考慮:無
發布規范:draft-ietf-pkix-ipki-part1
申請將會使用的媒介類型:所有兼容MIME的傳輸
附加信息:
魔數:無
文件的擴展名: .CRL
Macintosh中的文件類型碼:無
如果需要更多的信息,請與以下E-MAIL聯系::
Russ Housley
Intended usage: COMMON
作者/變動 控制:
Russ Housley
參考資料
[RFC959] Postel, J. and J. Reynolds, "文件傳輸協議(FTP)"
STD 5, RFC959, October 1985
[RFC1738] Berners-Lee, T., Masinter, L. and M. McCahill,"通用資源定位(URL)" RFC1738, December 1994.
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and
T. Berners-Lee; "超文本傳輸協議 -- HTTP/1.1",
RFC2068, January 1997.
安全方面的考慮
因為證書和CRL是數字簽名的,因此并不需要附加的完整性服務.證書和CRL都不需要秘密地保存,對證書和CRL的匿名訪問通常也是可以被接受的.因此,并不需要秘密的服務.
在Internet上,HTTP緩存代理是很普遍的,許多代理并不檢查一個對象的最新版本的正確性.如果一個證書或CRL的HTTP請求通過了一個配置不當或忽然中斷的代理,該代理可能會返回一個已超期的響應.
FTP和WWW服務器的操作者應該對發布證書的終端實體及那些發布證書和CRL的CA與RA進行認證。然而,并不需要對檢索證書和CRL進行鑒定認證。
作者的地址
Russell Housley
SPYRUS 381 Elden Street, Suite 1120 Herndon, VA 20170 USA
EMail: housley@spyrus.com
Paul Hoffman
Internet Mail Consortium 127 Segre Place
Santa Cruz, CA 95060 USA
EMail: phoffman@imc.org
版權說明
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its suclearcase/" target="_blank" >ccessors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
致謝
感謝Internet協會給予RFC編輯部門的資金。