idnits 2.17.1 draft-elkins-pem-pgp-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-18) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 30 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 55: '... labeled as MUST or REQUIRED....' RFC 2119 keyword, line 62: '... REQUIRED method for data transfer...' RFC 2119 keyword, line 80: '...to this protocol MUST be constrained t...' RFC 2119 keyword, line 105: '... type, described in [1], and MUST have a "protocol" parameter value...' RFC 2119 keyword, line 107: '... parameter MUST be enclosed in quo...' (11 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 1996) is 10169 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 351, but no explicit reference was found in the text ** Downref: Normative reference to an Historic RFC: RFC 1848 (ref. '2') -- Unexpected draft version: The latest known version of draft-atkins-pgpformat is -01, but you're referring to -02. ** Downref: Normative reference to an Informational draft: draft-atkins-pgpformat (ref. '3') Summary: 12 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Michael Elkins 2 draft-elkins-pem-pgp-04.txt The Aerospace Corporation 3 elkins@aero.org 4 June 1996 6 MIME Security with Pretty Good Privacy (PGP) 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other documents 17 at any time. It is inappropriate to use Internet- Drafts as 18 reference material or to cite them other than as ``work in 19 progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 23 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Abstract 29 This document describes how Pretty Good Privacy (PGP) can be used to 30 provide privacy and authentication using the Multipurpose Internet 31 Mail Extensions (MIME) security content types described in RFC1847. 33 1. Introduction 35 Previous work on integrating PGP with MIME (including the since 36 withdrawn application/pgp content type) has suffered from a number 37 of problems, the most significant of which is the inability to 38 recover signed message bodies without parsing data structures 39 specific to PGP. This work makes use of the elegant solution 40 proposed in RFC1847, which defines security multipart formats for 41 MIME. The security multiparts clearly separate the signed message 42 body from the signature, and have a number of other desirable 43 properties. This document is styled after RFC 1848, which defines 44 MIME Object Security Services (MOSS) for providing security and 45 authentication. 47 This document defines three new content types for implementing 48 security and privacy with PGP: application/pgp-encrypted, 49 application/pgp-signature and application/pgp-keys. 51 1.1 Compliance 53 In order for an implementation to be compliant with this 54 specification, is it absolutely necessary for it to obey all items 55 labeled as MUST or REQUIRED. 57 2. PGP data formats 59 PGP can generate either ASCII armor (described in [3]) or 8-bit 60 binary output when encrypting data, generating a digital signature, 61 or extracting public key data. The ASCII armor output is the 62 REQUIRED method for data transfer. This allows those users who do 63 not have the means to interpret the formats described in this 64 document to be able extract and use the PGP information in the 65 message. 67 When the amount of data to be transmitted requires that it be sent 68 in many parts, the MIME message/partial mechanism should be used 69 rather than the multipart ASCII armor PGP format. 71 3. Content-Transfer-Encoding restrictions 73 Multipart/signed and multipart/encrypted are to be treated by agents 74 as opaque, meaning that the data is not to be altered in any way 75 [1]. However, many existing mail gateways will detect if the next 76 hop does not support MIME or 8-bit data and perform conversion to 77 either Quoted-Printable or Base64. This presents serious problems 78 for multipart/signed, in particular, where the signature is 79 invalidated when such an operation occurs. For this reason all data 80 signed according to this protocol MUST be constrained to 7 bits (8- 81 bit data should be encoded using either Quoted-Printable or Base64). 82 Note that this also includes the case where a signed object is also 83 encrypted (see section 6). This restriction will increase the 84 likelihood that the signature will be valid upon receipt. 86 Data that is ONLY to be encrypted is allowed to contain 8-bit 87 characters and therefore need not be converted to a 7-bit format. 89 Implementor's note: It cannot be stressed enough that 90 applications using this standard should follow MIME's 91 suggestion that you "be conservative in what you generate, and 92 liberal in what you accept." In this particular case it means 93 it would be wise for an implementation to accept messages with 94 any content-transfer-encoding, but restrict generation to the 95 7-bit format required by this memo. This will allow future 96 compatibility in the event the Internet SMTP framework becomes 97 8-bit friendly. 99 4. PGP encrypted data 101 Before encryption with PGP, the data should be written in MIME 102 canonical format (body and headers). 104 PGP encrypted data is denoted by the "multipart/encrypted" content 105 type, described in [1], and MUST have a "protocol" parameter value 106 of "application/pgp-encrypted". Note that the value of the 107 parameter MUST be enclosed in quotes. 109 The multipart/encrypted MUST consist of exactly two parts. The 110 first MIME body part must have a content type of "application/pgp- 111 encrypted". This body contains the control information. A message 112 complying with this standard MUST contain a "Version: 1" field in 113 this body. Since the PGP packet format contains all other 114 information necessary for decrypting, no other information is 115 required here. 117 The second MIME body part MUST contain the actual encrypted data. 118 It must be labeled with a content type of "application/octet- 119 stream". 121 Example message: 123 From: Michael Elkins 124 To: Michael Elkins 125 Mime-Version: 1.0 126 Content-Type: multipart/encrypted; boundary=foo; 127 protocol="application/pgp-encrypted" 129 --foo 130 Content-Type: application/pgp-encrypted 132 Version: 1 134 --foo 135 Content-Type: application/octet-stream 137 -----BEGIN PGP MESSAGE----- 138 Version: 2.6.2 140 hIwDY32hYGCE8MkBA/wOu7d45aUxF4Q0RKJprD3v5Z9K1YcRJ2fve87lMlDlx4Oj 141 eW4GDdBfLbJE7VUpp13N19GL8e/AqbyyjHH4aS0YoTk10QQ9nnRvjY8nZL3MPXSZ 142 g9VGQxFeGqzykzmykU6A26MSMexR4ApeeON6xzZWfo+0yOqAq6lb46wsvldZ96YA 143 AABH78hyX7YX4uT1tNCWEIIBoqqvCeIMpp7UQ2IzBrXg6GtukS8NxbukLeamqVW3 144 1yt21DYOjuLzcMNe/JNsD9vDVCvOOG3OCi8= 145 =zzaA 146 -----END PGP MESSAGE----- 148 --foo-- 150 5. PGP signed data 152 PGP signed messages are denoted by the "multipart/signed" content 153 type, described in [1], with a "protocol" parameter which MUST have 154 a value of "application/pgp-signature" (MUST be quoted). The 155 "micalg" parameter MUST have a value of "pgp-", where 156 identifies the message integrity check (MIC) used to 157 generate the signature. The currently defined values for are "md5" for the MD5 checksum, and "sha1" for the SHA.1 159 algorithm. 161 The multipart/signed body MUST consist of exactly two parts. The 162 first part contains the signed data in MIME canonical format, 163 including a set of appropriate content headers describing the data. 165 The second body MUST contain the PGP digital signature. It MUST be 166 labeled with a content type of "application/pgp-signature". 168 When the PGP digital signature is generated: 170 (1) The data to be signed must first be converted to its 171 type/subtype specific canonical form. For text/plain, this 172 means conversion to an appropriate character set and conversion 173 of line endings to the canonical sequence. 175 (2) An appropriate Content-Transfer-Encoding is then applied. Each 176 line of the encoded data MUST end with the canonical 177 sequence. 179 (3) MIME content headers are then added to the body, each ending 180 with the canonical sequence. 182 (4) As described in [1], the digital signature MUST be calculated 183 over both the data to be signed and its set of content headers. 185 (5) The signature MUST be generated detached from the signed data 186 so that the process does not alter the signed data in any way. 188 Example message: 190 From: Michael Elkins 191 To: Michael Elkins 192 Mime-Version: 1.0 193 Content-Type: multipart/signed; boundary=bar; micalg=pgp-md5; 194 protocol="application/pgp-signature" 196 --bar 197 & Content-Type: text/plain; charset=iso-8859-1 198 & Content-Transfer-Encoding: quoted-printable 199 & 200 & =A1Hola! 201 & 202 & Did you know that talking to yourself is a sign of senility? 203 & 204 & It's generally a good idea to encode lines that begin with 205 & From=20because some mail transport agents will insert a greater- 206 & than (>) sign, thus invalidating the signature. 207 & 208 & Also, in some cases it might be desirable to encode any =20 209 & trailing whitespace that occurs on lines in order to ensure =20 210 & that the message signature is not invalidated when passing =20 211 & a gateway that modifies such whitespace (like BITNET). =20 212 & 213 & me 215 --bar 216 Content-Type: application/pgp-signature 218 -----BEGIN PGP MESSAGE----- 219 Version: 2.6.2 221 iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC// 222 jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq 223 uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn 224 HOxEa44b+EI= 225 =ndaj 226 -----END PGP MESSAGE----- 228 --bar-- 230 The "&"s in the previous example indicate the portion of the data 231 over which the signature was calculated. 233 Though not required, it is generally a good idea to use Quoted- 234 Printable encoding in the first step (writing out the data to be 235 signed in MIME canonical format) if any of the lines in the data 236 begin with "From ", and encode the "F". This will avoid an MTA 237 inserting a ">" in front of the line, thus invalidating the 238 signature! 239 Upon receipt of a signed message, an application MUST: 241 (1) Convert line endings to the canonical sequence before 242 the signature can be verified. This is necessary since the 243 local MTA may have converted to a local end of line convention. 245 (2) Pass both the signed data and its associated content headers 246 along with the PGP signature to the signature verification 247 service. 249 6. Encrypted and Signed Data 251 Sometimes it is desirable to both digitally sign and then encrypt a 252 message to be sent. This protocol allows for two methods of 253 accomplishing this task. 255 6.1 RFC1847 Encapsulation 257 In [1], it is stated that the data should first be signed as a 258 multipart/signature body, and then encrypted to form the final 259 multipart/encrypted body, i.e., 261 Content-Type: multipart/encrypted; 262 protocol="application/pgp-encrypted"; boundary=foo 264 --foo 265 Content-Type: application/pgp-encrypted 267 Version: 1 269 --foo 270 Content-Type: application/octet-stream 272 -----BEGIN PGP MESSAGE----- 273 & Content-Type: multipart/signed; micalg=pgp-md5 274 & protocol="application/pgp-signature"; boundary=bar 275 & 276 & --bar 277 & Content-Type: text/plain; charset=us-ascii 278 & 279 & This message was first signed, and then encrypted. 280 & 281 & --bar 282 & Content-Type: application/pgp-signature 283 & 284 & -----BEGIN PGP MESSAGE----- 285 & Version: 2.6.2 286 & 287 & iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC// 288 & jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq 289 & uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn 290 & HOxEa44b+EI= 291 & =ndaj 292 & -----END PGP MESSAGE----- 293 & 294 & --bar-- 295 -----END PGP MESSAGE----- 297 --foo-- 299 (The text preceded by '&' indicates that it is really 300 encrypted, but presented as text for clarity.) 302 6.2 Combined method 304 Versions 2.x of PGP also allow data to be signed and encrypted in 305 one operation. This method is an acceptable shortcut, and has the 306 benefit of less overhead. The resulting data should be formed as a 307 "multipart/encrypted" object as described above. 309 Messages which are encrypted and signed in this combined fashion are 310 REQUIRED to follow the same canonicalization rules as for 311 multipart/signed objects. 313 It is explicitly allowed for an agent to decrypt a combined message 314 and rewrite it as a multipart/signed object using the signature data 315 embedded in the encrypted version. 317 7. Distribution of PGP public keys 319 Content-Type: application/pgp-keys 320 Required parameters: none 321 Optional parameters: none 323 This is the content type which should be used for relaying public 324 key blocks. 326 8. Notes 328 PGP and Pretty Good Privacy are trademarks of Philip Zimmermann. 330 9. Security Considerations 332 Use of this protocol has the same security considerations as PGP, 333 and is not known to either increase or decrease the security of 334 messages using it; see [3] for more information. 336 10. Author's Address 338 Michael Elkins 339 P.O. Box 92957 - M1/102 340 Los Angeles, CA 90009-2957 342 Phone: +1 310 336 8040 343 Fax: +1 310 336 4402 345 References 347 [1] James Galvin, Gale Murphy, Steve Crocker, Ned Freed. Security 348 Multiparts for MIME: Multipart/Signed and Multipart/Encrypted. 349 RFC1847, 1994 351 [2] James Galvin, Gale Murphy, Steve Crocker, Ned Freed. MIME Object 352 Security Services. RFC1848, 1995 354 [3] Derek Atkins, William Stallings, Philip Zimmermann. PGP Message 355 Exchange Formats. draft-atkins-pgpformat-02.txt, 1995