組織：中國互動出版網（http://www.china-pub.com/）
RFC文檔中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
譯者：牛韜（NT   niutao@sohu.com）
譯文發布時間：2001-11-17
版權：本中文翻譯文檔版權歸中國互動出版網所有。可以用于非商業用途自由轉載，但必須
保留本文檔的翻譯及版權信息。





Network Working Group                                          M. Elkins
Request for Comments: 2015                     The Aerospace Corporation
Category: Standards Track                                   October 1996

具有相當好的保密性(PGP)
多用途網際郵件擴充協議(MIME)安全
（RFC2015——MIME Security with Pretty Good Privacy (PGP)）

本備忘錄的狀態

   本文檔描述了一個用于Internet社團的Internet標準跟蹤協議，希望得到有關進一步改
進的討論及建議。有關本協議的標準狀態及狀態，請參照“Internet正式協議標準”（STD1）  
的當前版本。本備忘錄的發布不受任何限制。

摘要

   本文檔描述了如何將較好的安全保密性應用于RFC1847中描述的多用途郵件擴充協議安
全內容類型描述。

1.  介紹

   那些早期將PGP集成于MIME（包括那些較偏的應用/pgp內容類型）的工作經歷了很多的
問題，它們中最重要的問題就是，如果不分解指定給PGP的數據結構，無法恢復帶符號的消
息。應用RFC1847中所提議的完美的方法解決了這一問題，RFC1847為MIME定義了多部分格
式。毫無疑問，多部分安全格式將帶符號消息主體與符號分開了，并且擁有其它的大量的令
人滿意的特征。該文檔列在RFC1848之后，RFC1848為提供安全和身份驗證定義了MIME對象
安全服務（MOSS）。

   本文檔定義了三個新的內容類型為實現使用PGP的安全和隱私定義了三個新的內容類型：
application/pgp-encrypted，application/pgp-signature 和application/pgp-keys。

1.1  一致

   為了實現與規格說明書的一致性，絕對有必要遵守所有標必需標簽的條目。

2.  PGP 數據格式

   PGP 在加密時能夠產生任何ASCII的外殼（在第3節進行了描述）或8位二進制輸出。生
氣數字簽名，或提取公用密鑰數據。ASCII外殼的輸出對于數據傳輸來說是必需的方法 。這
允許那些沒有辦法破譯此文檔中所用的描述格式的人能夠從這些信息中提取和使用PGP信
息。

   當要傳輸的數據需要分成幾部分傳輸時，MIME消息/部分機制應當使用勝于多部分ASCII
外殼PGP的格式

3.  內容傳略編碼約束

   多部分/帶符號的和多部分/加密的是由代理進行了不透明加工的，也就是說數據以任何一
種方式[1]處理都不會發生變化。然而，許多現有的郵件網關會進行測試，是否下一個網段不
支持MIME或8位數據和執行向可打印符號或Base64的轉換。這樣的話，對于多部分/帶符號
就出現了一些嚴重的問題，特別是當此類操作發生時，簽名是無效的。由于這一原因，所有
根據該協議標記的數據必須被強制轉換為7位（8位數據應使用可打印符號或基于64位的符
號進行編碼）。注意，這同樣包含標記對象被加密的情況（見第6節）。這一約束將提高接收
到的簽名合法性的可能。

   只有被加密的數據允許包含8位字符，因此不需要將其轉換為7位格式。

    實現者注意：無法進行充分的強調——對使用這一標準的應用應當遵循MIME的建議——
“對產生的要保守，對接收到的要寬容?！?在這一特定的情況下意味著要聰明的使用任意內
容傳輸編碼模式接收消息的實現，但是限制產生本備忘錄產生的7位格式。這就允許在以后
與Internet SMTP框架的事件保持兼容性，變為8位。

4.  PGP 加密數據

   在使用PGP加密前，數據應當使用MIME規范格式（主體與頭部）。

   PGP加密數據通過"multipart/encrypted" 內容類型表示，在[1]中進行了描述，并且必
須要有"application/pgp-encrypted"的協議參數值。注意，參數的值必須用引號包含起來。

   multipart/encrypted 必須確保包含兩個部分。第一個MIME主體部分必須擁有
"application/pgp-encrypted"的內容類型，這一主體包含著控制信息。遵守這一標準的消息
在主體部分必須包含一個域"Version:1"。因為PGP數據包格式包含解密需要的所有其它信
息，而沒有其他需要的數據。

   第二部分MIME主體部分必須飽含真正的加密數據。它必須擁有內容類型為
"application/octet-stream"的標志。

   范例消息:

     From: Michael Elkins <elkins@aero.org>
     To: Michael Elkins <elkins@aero.org>
     Mime-Version: 1.0
     Content-Type: multipart/encrypted; boundary=foo;
        protocol="application/pgp-encrypted"

     --foo
     Content-Type: application/pgp-encrypted

     Version: 1

     --foo
     Content-Type: application/octet-stream

     -----BEGIN PGP MESSAGE-----
     Version: 2.6.2

     hIwDY32hYGCE8MkBA/wOu7d45aUxF4Q0RKJprD3v5Z9K1YcRJ2fve87lMlDlx4Oj
     eW4GDdBfLbJE7VUpp13N19GL8e/AqbyyjHH4aS0YoTk10QQ9nnRvjY8nZL3MPXSZ
     g9VGQxFeGqzykzmykU6A26MSMexR4ApeeON6xzZWfo+0yOqAq6lb46wsvldZ96YA
     AABH78hyX7YX4uT1tNCWEIIBoqqvCeIMpp7UQ2IzBrXg6GtukS8NxbukLeamqVW3
     1yt21DYOjuLzcMNe/JNsD9vDVCvOOG3OCi8=
     =zzaA
     -----END PGP MESSAGE-----

     --foo--

5.  PGP 標記數據

   PGP 標記消息通過"multipart/signed" 內容類型表示，在[1]中進行了描述，使用必須擁
有值為"application/pgp-signature"（必須用引號引起來）的“協議”參數，參數"micalg"
必須擁有為"pgp-<hash-sybol>"的值，在這里<hash-symbol>標記消息完整性檢查（MIC）用
于產生簽名。<hash-symbol>通常定義的值為"md5"用于MD5的校驗和，"sha1"用于SHA.1
算法。

   multipart/signed 主體必須包含兩個部分。第一部分包含MIME規范格式的標記數據，包
含描述該數據的適當的內容頭的集合。
   第二部分必須包含PGP數據標記。它必須包含內容類型為"application/pgp-signature"
的標注。

   當產生PGP數字簽名時：

   (1)  要進行標記的數據必須先被轉化為其type/subtype特定規范格式。對于
text/plain，這就意味著轉化為合適的字符集并且將行末尾轉換為標準的回車和換行序列。

   (2)  然后使用一個合適的內容轉換編碼，每一行經過編碼的數據必須以標準的回車、換
行序列結束。

   (3)  MIME 內容報頭然后被加到主體上來，每一個都以標準的回車、換行序列結束。

   (4)  正如在[1]中所描述的，數字簽名必須要同時基于要進行標記的數據和其內容報頭計
算出來。

   (5)  要產生的簽名必須與待標記的數據相分離，這樣處理不管怎樣都不會改變原有的數
據。

   范例消息:

     From: Michael Elkins <elkins@aero.org>
     To: Michael Elkins <elkins@aero.org>
     Mime-Version: 1.0
     Content-Type: multipart/signed; boundary=bar; micalg=pgp-md5;
     protocol="application/pgp-signature"

     --bar
     & Content-Type: text/plain; charset=iso-8859-1
     & Content-Transfer-Encoding: quoted-printable
     &
     & =A1Hola!
     &
     & Did you know that talking to yourself is a sign of senility?
     &
     & It's generally a good idea to encode lines that begin with
     & From=20because some mail transport agents will insert a greater-
     & than (>) sign, thus invalidating the signature.
     &
     & Also, in some cases it might be desirable to encode any   =20
     &railing whitespace that occurs on lines in order to ensure  =20
     & that the message signature is not invalidated when passing =20
     & a gateway that modifies such whitespace (like BITNET). =20
     &
     & me

     --bar
     Content-Type: application/pgp-signature

    -----BEGIN PGP MESSAGE-----
   Version: 2.6.2

   iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC//
   jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq
   uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn
   HOxEa44b+EI=
   =ndaj
   -----END PGP MESSAGE-----

   --bar--

   在前例中的 "&"  表示基于其的數據部分符號是計算出來的。

   盡管不是必須的，不過通常來說如果任意一行數據以"From"開始，并且編碼"F"，那么在
第一步中使用可打印字符進行編碼是一個好的主意（用MIME規范格式寫出要標記的數據）。
這可以避免一個報文傳略代理在行首插入一個">"，而">"將會使簽名無效。

   基于接收標記消息的基礎上的應用必須：

   (1)  在需要驗證的數字簽名之前，將行結束符轉換為規范的回車、換行序列。這很有必
要，因為本地MTA可能已經轉換為局部的行結束轉換。

   (2)  將標記的數據和與其的關聯內容報頭一起隨著PGP簽名傳遞給簽名認證服務。

6.  加密和標記了的數據

   有時對于數字標記和隨后加密將要發送的數據來說這還是比較令人滿意的。這個協議允許
使用兩種方法來實現這個任務。

6.1  RFC1847 的封裝

   [1], 規定數據應當先被標記為一個multipart/signature 主體。然后進行加密形成最終
的multipart/encrypted 主體，也就是

    Content-Type: multipart/encrypted;
       protocol="application/pgp-encrypted"; boundary=foo

    --foo
    Content-Type: application/pgp-encrypted

    Version: 1

    --foo
    Content-Type: application/octet-stream

    -----BEGIN PGP MESSAGE-----
    & Content-Type: multipart/signed; micalg=pgp-md5
    &     protocol="application/pgp-signature"; boundary=bar
    &
    & --bar
    & Content-Type: text/plain; charset=us-ascii
    &
    & This message was first signed, and then encrypted.
    &
    & --bar
    & Content-Type: application/pgp-signature
    &
    & -----BEGIN PGP MESSAGE-----
    & Version: 2.6.2
    &
    & iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC//
    & jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq
    & uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn
    & HOxEa44b+EI=
    & =ndaj
    & -----END PGP MESSAGE-----
    &
    & --bar--
    -----END PGP MESSAGE-----
    --foo--

    (The text preceded by '&' indicates that it is really
    encrypted, but presented as text for clarity.)

6.2  組合方法

   第2.x版PGP同樣允許用一種操作將數據進行標記和加密。這種方法是一種可以接受的捷
徑，并且可以花費較少的費用。生成的數據應當形成上面所描述的"multipart/encrypted" 對
象。

   至于multipart/signed對象，用這種組合方式加密和標記的消息同樣需要遵循相同的規
范約束。

   很明確，允許一個代理對組合的消息進行譯碼并將其作為使用標記數據嵌入到加密版本中
的multipart/signed 對象進行重新寫入

7.  PGP公共密鑰的分配

   Content-Type: application/pgp-keys
   Required parameters: none
   Optional parameters: none

   這是一用于傳播公共密鑰塊的內容類型。

8.  注意

   PGP and Pretty Good Privacy 是 Philip Zimmermann的商標。

9.  安全考慮

   使用本該協議與PGP具有相同的安全考慮，并未考慮對其使用時增加或者減少的消息安全
性問題。如果要獲得更多的信息，請查閱[3]。

10.  作者地址

        Michael Elkins
        P.O. Box 92957 - M1/102
        Los Angeles, CA 90009-2957

        Phone: +1 310 336 8040
        Fax: +1 310 336 4402

參考文獻

   [1]  Galvin, J., Murphy, G., Crocker, S., and N. Freed, "Security
        Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
        RFC 1847, October 1995.

   [2]  Galvin, J., Murphy, G., Crocker, S., and N. Freed, "MIME Object
        Security Services", RFC 1848, October 1995.

   [3]  Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message
        Exchange Formats", RFC 1991, August 1996.
RFC2015—MIME Security with Pretty Good Privacy (PGP)
多用途網際郵件擴充協議(MIME)安全具有相當好的保密性(PGP)


1
RFC文檔中文翻譯計劃