added RFC doc
[claws.git] / doc / src / rfc2015.txt
1
2
3
4
5
6
7 Network Working Group                                          M. Elkins
8 Request for Comments: 2015                     The Aerospace Corporation
9 Category: Standards Track                                   October 1996
10
11
12               MIME Security with Pretty Good Privacy (PGP)
13
14 Status of this Memo
15
16    This document specifies an Internet standards track protocol for the
17    Internet community, and requests discussion and suggestions for
18    improvements.  Please refer to the current edition of the "Internet
19    Official Protocol Standards" (STD 1) for the standardization state
20    and status of this protocol.  Distribution of this memo is unlimited.
21
22 Abstract
23
24    This document describes how Pretty Good Privacy (PGP) can be used to
25    provide privacy and authentication using the Multipurpose Internet
26    Mail Extensions (MIME) security content types described in RFC1847.
27
28 1.  Introduction
29
30    Previous work on integrating PGP with MIME (including the since
31    withdrawn application/pgp content type) has suffered from a number of
32    problems, the most significant of which is the inability to recover
33    signed message bodies without parsing data structures specific to
34    PGP.  This work makes use of the elegant solution proposed in
35    RFC1847, which defines security multipart formats for MIME. The
36    security multiparts clearly separate the signed message body from the
37    signature, and have a number of other desirable properties. This
38    document is styled after RFC 1848, which defines MIME Object Security
39    Services (MOSS) for providing security and authentication.
40
41    This document defines three new content types for implementing
42    security and privacy with PGP: application/pgp-encrypted,
43    application/pgp-signature and application/pgp-keys.
44
45 1.1  Compliance
46
47    In order for an implementation to be compliant with this
48    specification, is it absolutely necessary for it to obey all items
49    labeled as MUST or REQUIRED.
50
51
52
53
54
55
56
57
58 Elkins                      Standards Track                     [Page 1]
59 \f
60 RFC 2015                 MIME Security with PGP             October 1996
61
62
63 2.  PGP data formats
64
65    PGP can generate either ASCII armor (described in [3]) or 8-bit
66    binary output when encrypting data, generating a digital signature,
67    or extracting public key data.  The ASCII armor output is the
68    REQUIRED method for data transfer.  This allows those users who do
69    not have the means to interpret the formats described in this
70    document to be able extract and use the PGP information in the
71    message.
72
73    When the amount of data to be transmitted requires that it be sent in
74    many parts, the MIME message/partial mechanism should be used rather
75    than the multipart ASCII armor PGP format.
76
77 3.  Content-Transfer-Encoding restrictions
78
79    Multipart/signed and multipart/encrypted are to be treated by agents
80    as opaque, meaning that the data is not to be altered in any way [1].
81    However, many existing mail gateways will detect if the next hop does
82    not support MIME or 8-bit data and perform conversion to either
83    Quoted-Printable or Base64.  This presents serious problems for
84    multipart/signed, in particular, where the signature is invalidated
85    when such an operation occurs.  For this reason all data signed
86    according to this protocol MUST be constrained to 7 bits (8- bit data
87    should be encoded using either Quoted-Printable or Base64).  Note
88    that this also includes the case where a signed object is also
89    encrypted (see section 6).  This restriction will increase the
90    likelihood that the signature will be valid upon receipt.
91
92    Data that is ONLY to be encrypted is allowed to contain 8-bit
93    characters and therefore need not be converted to a 7-bit format.
94
95      Implementor's note: It cannot be stressed enough that applications
96      using this standard should follow MIME's suggestion that you "be
97      conservative in what you generate, and liberal in what you accept."
98      In this particular case it means it would be wise for an
99      implementation to accept messages with any content-transfer-
100      encoding, but restrict generation to the 7-bit format required by
101      this memo.  This will allow future compatibility in the event the
102      Internet SMTP framework becomes 8-bit friendly.
103
104 4.  PGP encrypted data
105
106    Before encryption with PGP, the data should be written in MIME
107    canonical format (body and headers).
108
109    PGP encrypted data is denoted by the "multipart/encrypted" content
110    type, described in [1], and MUST have a "protocol" parameter value of
111
112
113
114 Elkins                      Standards Track                     [Page 2]
115 \f
116 RFC 2015                 MIME Security with PGP             October 1996
117
118
119    "application/pgp-encrypted".  Note that the value of the parameter
120    MUST be enclosed in quotes.
121
122    The multipart/encrypted MUST consist of exactly two parts.  The first
123    MIME body part must have a content type of "application/pgp-
124    encrypted".  This body contains the control information.  A message
125    complying with this standard MUST contain a "Version: 1" field in
126    this body.  Since the PGP packet format contains all other
127    information necessary for decrypting, no other information is
128    required here.
129
130    The second MIME body part MUST contain the actual encrypted data.  It
131    must be labeled with a content type of "application/octet- stream".
132
133    Example message:
134
135      From: Michael Elkins <elkins@aero.org>
136      To: Michael Elkins <elkins@aero.org>
137      Mime-Version: 1.0
138      Content-Type: multipart/encrypted; boundary=foo;
139         protocol="application/pgp-encrypted"
140
141      --foo
142      Content-Type: application/pgp-encrypted
143
144      Version: 1
145
146      --foo
147      Content-Type: application/octet-stream
148
149      -----BEGIN PGP MESSAGE-----
150      Version: 2.6.2
151
152      hIwDY32hYGCE8MkBA/wOu7d45aUxF4Q0RKJprD3v5Z9K1YcRJ2fve87lMlDlx4Oj
153      eW4GDdBfLbJE7VUpp13N19GL8e/AqbyyjHH4aS0YoTk10QQ9nnRvjY8nZL3MPXSZ
154      g9VGQxFeGqzykzmykU6A26MSMexR4ApeeON6xzZWfo+0yOqAq6lb46wsvldZ96YA
155      AABH78hyX7YX4uT1tNCWEIIBoqqvCeIMpp7UQ2IzBrXg6GtukS8NxbukLeamqVW3
156      1yt21DYOjuLzcMNe/JNsD9vDVCvOOG3OCi8=
157      =zzaA
158      -----END PGP MESSAGE-----
159
160      --foo--
161
162 5.  PGP signed data
163
164    PGP signed messages are denoted by the "multipart/signed" content
165    type, described in [1], with a "protocol" parameter which MUST have a
166    value of "application/pgp-signature" (MUST be quoted).  The "micalg"
167
168
169
170 Elkins                      Standards Track                     [Page 3]
171 \f
172 RFC 2015                 MIME Security with PGP             October 1996
173
174
175    parameter MUST have a value of "pgp-<hash-symbol>", where <hash-
176    symbol> identifies the message integrity check (MIC) used to generate
177    the signature.  The currently defined values for <hash-symbol> are
178    "md5" for the MD5 checksum, and "sha1" for the SHA.1 algorithm.
179
180    The multipart/signed body MUST consist of exactly two parts.  The
181    first part contains the signed data in MIME canonical format,
182    including a set of appropriate content headers describing the data.
183
184    The second body MUST contain the PGP digital signature.  It MUST be
185    labeled with a content type of "application/pgp-signature".
186
187    When the PGP digital signature is generated:
188
189    (1)  The data to be signed must first be converted to its
190         type/subtype specific canonical form.  For text/plain, this
191         means conversion to an appropriate character set and conversion
192         of line endings to the canonical <CR><LF> sequence.
193
194    (2)  An appropriate Content-Transfer-Encoding is then applied. Each
195         line of the encoded data MUST end with the canonical <CR><LF>
196         sequence.
197
198    (3)  MIME content headers are then added to the body, each ending
199         with the canonical <CR><LF> sequence.
200
201    (4)  As described in [1], the digital signature MUST be calculated
202         over both the data to be signed and its set of content headers.
203
204    (5)  The signature MUST be generated detached from the signed data
205         so that the process does not alter the signed data in any way.
206
207    Example message:
208
209      From: Michael Elkins <elkins@aero.org>
210      To: Michael Elkins <elkins@aero.org>
211      Mime-Version: 1.0
212      Content-Type: multipart/signed; boundary=bar; micalg=pgp-md5;
213      protocol="application/pgp-signature"
214
215      --bar
216      & Content-Type: text/plain; charset=iso-8859-1
217      & Content-Transfer-Encoding: quoted-printable
218      &
219      & =A1Hola!
220      &
221      & Did you know that talking to yourself is a sign of senility?
222      &
223
224
225
226 Elkins                      Standards Track                     [Page 4]
227 \f
228 RFC 2015                 MIME Security with PGP             October 1996
229
230
231      & It's generally a good idea to encode lines that begin with
232      & From=20because some mail transport agents will insert a greater-
233      & than (>) sign, thus invalidating the signature.
234      &
235      & Also, in some cases it might be desirable to encode any   =20
236      &railing whitespace that occurs on lines in order to ensure  =20
237      & that the message signature is not invalidated when passing =20
238      & a gateway that modifies such whitespace (like BITNET). =20
239      &
240      & me
241
242      --bar
243      Content-Type: application/pgp-signature
244
245     -----BEGIN PGP MESSAGE-----
246    Version: 2.6.2
247
248    iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC//
249    jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq
250    uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn
251    HOxEa44b+EI=
252    =ndaj
253    -----END PGP MESSAGE-----
254
255    --bar--
256
257    The "&"s in the previous example indicate the portion of the data
258    over which the signature was calculated.
259
260    Though not required, it is generally a good idea to use Quoted-
261    Printable encoding in the first step (writing out the data to be
262    signed in MIME canonical format) if any of the lines in the data
263    begin with "From ", and encode the "F".  This will avoid an MTA
264    inserting a ">" in front of the line, thus invalidating the
265    signature!
266
267    Upon receipt of a signed message, an application MUST:
268
269    (1)  Convert line endings to the canonical <CR><LF> sequence before
270         the signature can be verified.  This is necessary since the
271         local MTA may have converted to a local end of line convention.
272
273    (2)  Pass both the signed data and its associated content headers
274         along with the PGP signature to the signature verification
275         service.
276
277
278
279
280
281
282 Elkins                      Standards Track                     [Page 5]
283 \f
284 RFC 2015                 MIME Security with PGP             October 1996
285
286
287 6.  Encrypted and Signed Data
288
289    Sometimes it is desirable to both digitally sign and then encrypt a
290    message to be sent.  This protocol allows for two methods of
291    accomplishing this task.
292
293 6.1  RFC1847 Encapsulation
294
295    [1], it is stated that the data should first be signed as a
296    multipart/signature body, and then encrypted to form the final
297    multipart/encrypted body, i.e.,
298
299     Content-Type: multipart/encrypted;
300        protocol="application/pgp-encrypted"; boundary=foo
301
302     --foo
303     Content-Type: application/pgp-encrypted
304
305     Version: 1
306
307     --foo
308     Content-Type: application/octet-stream
309
310     -----BEGIN PGP MESSAGE-----
311     & Content-Type: multipart/signed; micalg=pgp-md5
312     &     protocol="application/pgp-signature"; boundary=bar
313     &
314     & --bar
315     & Content-Type: text/plain; charset=us-ascii
316     &
317     & This message was first signed, and then encrypted.
318     &
319     & --bar
320     & Content-Type: application/pgp-signature
321     &
322     & -----BEGIN PGP MESSAGE-----
323     & Version: 2.6.2
324     &
325     & iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC//
326     & jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq
327     & uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn
328     & HOxEa44b+EI=
329     & =ndaj
330     & -----END PGP MESSAGE-----
331     &
332     & --bar--
333     -----END PGP MESSAGE-----
334
335
336
337
338 Elkins                      Standards Track                     [Page 6]
339 \f
340 RFC 2015                 MIME Security with PGP             October 1996
341
342
343     --foo--
344
345     (The text preceded by '&' indicates that it is really
346     encrypted, but presented as text for clarity.)
347
348 6.2  Combined method
349
350    Versions 2.x of PGP also allow data to be signed and encrypted in one
351    operation.  This method is an acceptable shortcut, and has the
352    benefit of less overhead.  The resulting data should be formed as a
353    "multipart/encrypted" object as described above.
354
355    Messages which are encrypted and signed in this combined fashion are
356    REQUIRED to follow the same canonicalization rules as for
357    multipart/signed objects.
358
359    It is explicitly allowed for an agent to decrypt a combined message
360    and rewrite it as a multipart/signed object using the signature data
361    embedded in the encrypted version.
362
363 7.  Distribution of PGP public keys
364
365    Content-Type: application/pgp-keys
366    Required parameters: none
367    Optional parameters: none
368
369    This is the content type which should be used for relaying public key
370    blocks.
371
372 8.  Notes
373
374    PGP and Pretty Good Privacy are trademarks of Philip Zimmermann.
375
376 9.  Security Considerations
377
378    Use of this protocol has the same security considerations as PGP, and
379    is not known to either increase or decrease the security of messages
380    using it; see [3] for more information.
381
382 10.  Author's Address
383
384         Michael Elkins
385         P.O. Box 92957 - M1/102
386         Los Angeles, CA 90009-2957
387
388         Phone: +1 310 336 8040
389         Fax: +1 310 336 4402
390
391
392
393
394 Elkins                      Standards Track                     [Page 7]
395 \f
396 RFC 2015                 MIME Security with PGP             October 1996
397
398
399 References
400
401    [1]  Galvin, J., Murphy, G., Crocker, S., and N. Freed, "Security
402         Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
403         RFC 1847, October 1995.
404
405    [2]  Galvin, J., Murphy, G., Crocker, S., and N. Freed, "MIME Object
406         Security Services", RFC 1848, October 1995.
407
408    [3]  Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message
409         Exchange Formats", RFC 1991, August 1996.
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450 Elkins                      Standards Track                     [Page 8]
451 \f