分享
 
 
 

RFC2015 - MIME Security with Pretty Good Privacy (PGP)

王朝other·作者佚名  2008-05-31
窄屏简体版  字體: |||超大  

Network Working Group M. Elkins

Request for Comments: 2015 The Aerospace Corporation

Category: Standards Track October 1996

MIME Security with Pretty Good Privacy (PGP)

Status of this Memo

This document specifies an Internet standards track protocol for the

Internet community, and requests discussion and suggestions for

improvements. Please refer to the current edition of the "Internet

Official Protocol Standards" (STD 1) for the standardization state

and status of this protocol. Distribution of this memo is unlimited.

Abstract

This document describes how Pretty Good Privacy (PGP) can be used to

provide privacy and authentication using the Multipurpose Internet

Mail Extensions (MIME) security content types described in RFC1847.

1. IntrodUCtion

Previous work on integrating PGP with MIME (including the since

withdrawn application/pgp content type) has suffered from a number of

problems, the most significant of which is the inability to recover

signed message bodies without parsing data structures specific to

PGP. This work makes use of the elegant solution proposed in

RFC1847, which defines security multipart formats for MIME. The

security multiparts clearly separate the signed message body from the

signature, and have a number of other desirable properties. This

document is styled after RFC1848, which defines MIME Object Security

Services (MOSS) for providing security and authentication.

This document defines three new content types for implementing

security and privacy with PGP: application/pgp-encrypted,

application/pgp-signature and application/pgp-keys.

1.1 Compliance

In order for an implementation to be compliant with this

specification, is it absolutely necessary for it to obey all items

labeled as MUST or REQUIRED.

2. PGP data formats

PGP can generate either ASCII armor (described in [3]) or 8-bit

binary output when encrypting data, generating a digital signature,

or extracting public key data. The ASCII armor output is the

REQUIRED method for data transfer. This allows those users who do

not have the means to interpret the formats described in this

document to be able extract and use the PGP information in the

message.

When the amount of data to be transmitted requires that it be sent in

many parts, the MIME message/partial mechanism should be used rather

than the multipart ASCII armor PGP format.

3. Content-Transfer-Encoding restrictions

Multipart/signed and multipart/encrypted are to be treated by agents

as opaque, meaning that the data is not to be altered in any way [1].

However, many existing mail gateways will detect if the next hop does

not support MIME or 8-bit data and perform conversion to either

Quoted-Printable or Base64. This presents serious problems for

multipart/signed, in particular, where the signature is invalidated

when such an operation occurs. For this reason all data signed

according to this protocol MUST be constrained to 7 bits (8- bit data

should be encoded using either Quoted-Printable or Base64). Note

that this also includes the case where a signed object is also

encrypted (see section 6). This restriction will increase the

likelihood that the signature will be valid upon receipt.

Data that is ONLY to be encrypted is allowed to contain 8-bit

characters and therefore need not be converted to a 7-bit format.

Implementor's note: It cannot be stressed enough that applications

using this standard should follow MIME's suggestion that you "be

conservative in what you generate, and liberal in what you accept."

In this particular case it means it would be wise for an

implementation to accept messages with any content-transfer-

encoding, but restrict generation to the 7-bit format required by

this memo. This will allow future compatibility in the event the

Internet SMTP framework becomes 8-bit friendly.

4. PGP encrypted data

Before encryption with PGP, the data should be written in MIME

canonical format (body and headers).

PGP encrypted data is denoted by the "multipart/encrypted" content

type, described in [1], and MUST have a "protocol" parameter value of

"application/pgp-encrypted". Note that the value of the parameter

MUST be enclosed in quotes.

The multipart/encrypted MUST consist of exactly two parts. The first

MIME body part must have a content type of "application/pgp-

encrypted". This body contains the control information. A message

complying with this standard MUST contain a "Version: 1" field in

this body. Since the PGP packet format contains all other

information necessary for decrypting, no other information is

required here.

The second MIME body part MUST contain the actual encrypted data. It

must be labeled with a content type of "application/octet- stream".

Example message:

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 signed data

PGP signed messages are denoted by the "multipart/signed" content

type, described in [1], with a "protocol" parameter which MUST have a

value of "application/pgp-signature" (MUST be quoted). The "micalg"

parameter MUST have a value of "pgp-<hash-symbol>", where <hash-

symbol> identifies the message integrity check (MIC) used to generate

the signature. The currently defined values for <hash-symbol> are

"md5" for the MD5 checksum, and "sha1" for the SHA.1 algorithm.

The multipart/signed body MUST consist of exactly two parts. The

first part contains the signed data in MIME canonical format,

including a set of appropriate content headers describing the data.

The second body MUST contain the PGP digital signature. It MUST be

labeled with a content type of "application/pgp-signature".

When the PGP digital signature is generated:

(1) The data to be signed must first be converted to its

type/suBType specific canonical form. For text/plain, this

means conversion to an appropriate character set and conversion

of line endings to the canonical <CR><LF> sequence.

(2) An appropriate Content-Transfer-Encoding is then applied. Each

line of the encoded data MUST end with the canonical <CR><LF>

sequence.

(3) MIME content headers are then added to the body, each ending

with the canonical <CR><LF> sequence.

(4) As described in [1], the digital signature MUST be calculated

over both the data to be signed and its set of content headers.

(5) The signature MUST be generated detached from the signed data

so that the process does not alter the signed data in any way.

Example message:

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--

The "&"s in the previous example indicate the portion of the data

over which the signature was calculated.

Though not required, it is generally a good idea to use Quoted-

Printable encoding in the first step (writing out the data to be

signed in MIME canonical format) if any of the lines in the data

begin with "From ", and encode the "F". This will avoid an MTA

inserting a ">" in front of the line, thus invalidating the

signature!

Upon receipt of a signed message, an application MUST:

(1) Convert line endings to the canonical <CR><LF> sequence before

the signature can be verified. This is necessary since the

local MTA may have converted to a local end of line convention.

(2) Pass both the signed data and its associated content headers

along with the PGP signature to the signature verification

service.

6. Encrypted and Signed Data

Sometimes it is desirable to both digitally sign and then encrypt a

message to be sent. This protocol allows for two methods of

accomplishing this task.

6.1 RFC1847 Encapsulation

[1], it is stated that the data should first be signed as a

multipart/signature body, and then encrypted to form the final

multipart/encrypted body, i.e.,

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 Combined method

Versions 2.x of PGP also allow data to be signed and encrypted in one

operation. This method is an acceptable shortcut, and has the

benefit of less overhead. The resulting data should be formed as a

"multipart/encrypted" object as described above.

Messages which are encrypted and signed in this combined fashion are

REQUIRED to follow the same canonicalization rules as for

multipart/signed objects.

It is eXPlicitly allowed for an agent to decrypt a combined message

and rewrite it as a multipart/signed object using the signature data

embedded in the encrypted version.

7. Distribution of PGP public keys

Content-Type: application/pgp-keys

Required parameters: none

Optional parameters: none

This is the content type which should be used for relaying public key

blocks.

8. Notes

PGP and Pretty Good Privacy are trademarks of Philip Zimmermann.

9. Security Considerations

Use of this protocol has the same security considerations as PGP, and

is not known to either increase or decrease the security of messages

using it; see [3] for more information.

10. Author's Address

Michael Elkins

P.O. Box 92957 - M1/102

Los Angeles, CA 90009-2957

Phone: +1 310 336 8040

Fax: +1 310 336 4402

References

[1] Galvin, J., Murphy, G., Crocker, S., and N. Freed, "Security

Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",

RFC1847, October 1995.

[2] Galvin, J., Murphy, G., Crocker, S., and N. Freed, "MIME Object

Security Services", RFC1848, October 1995.

[3] Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message

Exchange Formats", RFC1991, August 1996.

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有