idnits 2.17.1 draft-elkins-pem-pgp-03.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-26) 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 a Security Considerations section. ** 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 31 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 57: '... REQUIRED method for data transfer...' RFC 2119 keyword, line 93: '... MUST be enclosed in quotes....' RFC 2119 keyword, line 95: '...tipart/encrypted MUST consist of exact...' RFC 2119 keyword, line 98: '...th this standard MUST contain a "Versi...' RFC 2119 keyword, line 102: '...d MIME body part MUST contain the actu...' (6 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 (March 1996) is 10269 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 318, 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: 14 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Michael Elkins 3 draft-elkins-pem-pgp-03.txt The Aerospace Corporation 4 elkins@aero.org 5 March 1996 7 MIME Security with Pretty Good Privacy (PGP) 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other documents 18 at any time. It is inappropriate to use Internet- Drafts as 19 reference material or to cite them other than as ``work in 20 progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 24 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Abstract 30 This document describes how Pretty Good Privacy (PGP) can be used to 31 provide privacy and authentication using the Multipurpose Internet 32 Mail Extensions (MIME) security content types described in RFC1847. 34 1. Introduction 36 Previous work on integrating PGP with MIME (including the since 37 withdrawn application/pgp content type) has suffered from a number 38 of problems, the most significant of which is the inability to 39 recover signed message bodies without parsing data structures 40 specific to PGP. This work makes use of the elegant solution 41 proposed in RFC1847, which defines security multipart formats for 42 MIME. The security multiparts clearly separate the signed message 43 body from the signature, and have a number of other desirable 44 properties. This document is styled after RFC 1848, which defines 45 MIME Object Security Services (MOSS) for providing security and 46 authentication. 48 This document defines three new content types for implementing 49 security and privacy with PGP: application/pgp-encrypted, 50 application/pgp-signature and application/pgp-keys. 52 2. PGP data formats 54 PGP can generate either ascii armor (described in [3]) or 8-bit 55 binary output when encrypting data, generating a digital signature, 56 or extracting public key data. The ascii armor output is the 57 REQUIRED method for data transfer. This allows those users who do 58 not have the means to interpret the formats described in this 59 document to be able extract and use the PGP information in the 60 message. 62 When the amount of data to be transmitted requires that it be sent 63 in many parts, the MIME message/partial mechanism should be used 64 rather than the multipart ascii armor PGP format. 66 3. Content-Transfer-Encoding restrictions 68 Multipart/signed and multipart/encrypted are to be treated by agents 69 as opaque, meaning that the data is not to be altered in any way 70 [1]. However, many existing mail gateways will detect if the next 71 hop does not support MIME or 8-bit data and perform conversion to 72 either Quoted-Printable or Base64. This presents serious problems 73 for multipart/signed, in particular, where the signature is 74 invalidated when such an operation occurs. For this reason it is 75 necessary to REQUIRE that ALL data signed according to this protocol 76 be constrained to 7 bits (8-bit data should be encoded using either 77 Quoted-Printable or Base64). Note that this also includes the case 78 where a signed object is also encrypted (see section 6). This 79 restriction will increase the likelihood that the signature will be 80 valid upon receipt. 82 Data that is only to be encrypted is allowed to contain 8-bit 83 characters and therefore need not be converted to a 7-bit format. 85 4. PGP encrypted data 87 Before encryption with PGP, the data should be written in MIME 88 canonical format (body and headers). 90 PGP encrypted data is denoted by the "multipart/encrypted" content 91 type, described in [1], and REQUIRES a "protocol" parameter value of 92 "application/pgp-encrypted". Note that the value of the parameter 93 MUST be enclosed in quotes. 95 The multipart/encrypted MUST consist of exactly two parts. The 96 first MIME body part must have a content type of "application/pgp- 97 encrypted". This body contains the control information. A message 98 complying with this standard MUST contain a "Version: 1" field in 99 this body. Since the PGP packet format contains all other 100 information for decrypting, no other information is required here. 102 The second MIME body part MUST contain the actual encrypted data. 103 It must be labeled with a content type of "application/octet- 104 stream". 106 Example message: 108 From: Michael Elkins 109 To: Michael Elkins 110 Mime-Version: 1.0 111 Content-Type: multipart/encrypted; boundary=foo; 112 protocol="application/pgp-encrypted" 114 --foo 115 Content-Type: application/pgp-encrypted 117 Version: 1 119 --foo 120 Content-Type: application/octet-stream 122 -----BEGIN PGP MESSAGE----- 123 Version: 2.6.2 125 hIwDY32hYGCE8MkBA/wOu7d45aUxF4Q0RKJprD3v5Z9K1YcRJ2fve87lMlDlx4Oj 126 eW4GDdBfLbJE7VUpp13N19GL8e/AqbyyjHH4aS0YoTk10QQ9nnRvjY8nZL3MPXSZ 127 g9VGQxFeGqzykzmykU6A26MSMexR4ApeeON6xzZWfo+0yOqAq6lb46wsvldZ96YA 128 AABH78hyX7YX4uT1tNCWEIIBoqqvCeIMpp7UQ2IzBrXg6GtukS8NxbukLeamqVW3 129 1yt21DYOjuLzcMNe/JNsD9vDVCvOOG3OCi8= 130 =zzaA 131 -----END PGP MESSAGE----- 133 --foo-- 135 5. PGP signed data 137 PGP signed messages are denoted by the "multipart/signed" content 138 type, described in [1], and REQUIRE the "protocol" parameter to have 139 a value of "application/pgp-signature" (MUST be quoted), and the 140 "micalg" parameter to have a value of "pgp-md5". 142 The multipart/signed body MUST consist of exactly two parts. The 143 first part contains the signed data in MIME canonical format, 144 including a set of appropriate content headers describing the data. 146 The second body MUST contain the PGP digital signature. It MUST be 147 labeled with a content type of "application/pgp-signature". 149 When the PGP digital signature is generated: 151 (1) The data to be signed must first be converted to its 152 type/subtype specific canonical form. For text/plain, this 153 means conversion to an appropriate character set and conversion 154 of line endings to the canonical sequence. 156 (2) An appropriate Content-Transfer-Encoding is then applied. Each 157 line of the encoded data MUST end with the canonical 158 sequence. 160 (3) MIME content headers are then added to the body, each ending 161 with the canonical sequence. 163 (4) As described in [1], the digital signature MUST be calculated 164 over both the data to be signed and its set of content headers. 166 (5) The signature MUST be generated detached from the signed data 167 so that the process does not alter the signed data in any way. 169 Example message: 171 From: Michael Elkins 172 To: Michael Elkins 173 Mime-Version: 1.0 174 Content-Type: multipart/signed; boundary=bar; micalg=pgp-md5; 175 protocol="application/pgp-signature" 177 --bar 178 & Content-Type: text/plain; charset=iso-8859-1 179 & Content-Transfer-Encoding: quoted-printable 180 & 181 & =A1Hola! 182 & 183 & Did you know that talking to yourself is a sign of senility? 184 & 185 & It's generally a good idea to encode lines that begin with 186 & From=20because some mail transport agents will insert a greater- 187 & than (>) sign, thus invalidating the signature. 188 & 189 & Also, in some cases it might be desirable to encode any =20 190 & trailing whitespace that occurs on lines in order to ensure =20 191 & that the message signature is not invalidated when passing =20 192 & a gateway that modifies such whitespace (like BITNET). =20 193 & 194 & me 196 --bar 197 Content-Type: application/pgp-signature 199 -----BEGIN PGP MESSAGE----- 200 Version: 2.6.2 202 iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC// 203 jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq 204 uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn 205 HOxEa44b+EI= 206 =ndaj 207 -----END PGP MESSAGE----- 209 --bar-- 211 The "&"s in the previous example indicate the portion of the data 212 over which the signature was calculated. 214 Though not required, it is generally a good idea to use Quoted- 215 Printable encoding in the first step (writing out the data to be 216 signed in MIME canonical format) if any of the lines in the data 217 begin with "From ", and encode the "F". This will avoid an MTA 218 inserting a ">" in front of the line, thus invalidating the 219 signature! 221 Upon receipt of a signed message, an application MUST: 223 (1) Convert line endings to the canonical sequence before 224 the signature can be verified. This is necessary since the 225 local MTA may have converted to a local end of line convention. 227 (2) Pass both the signed data and its associated content headers 228 along with the PGP signature to the signature verification 229 service. 231 6. Encrypted and Signed Data 233 Sometimes it is desirable to both digitally sign and then encrypt a 234 message to be sent. This protocol allows for two methods of 235 accomplishing this task. 237 6.1 RFC1847 Encapsulation 239 In [1], it is stated that the data should first be signed as a 240 multipart/signature body, and then encrypted to form the final 241 multipart/encrypted body, i.e., 243 Content-Type: multipart/encrypted; 244 protocol="application/pgp-encrypted"; boundary=foo 246 --foo 247 Content-Type: application/pgp-encrypted 249 Version: 1 251 --foo 252 Content-Type: application/octet-stream 254 -----BEGIN PGP MESSAGE----- 255 & Content-Type: multipart/signed; micalg=pgp-md5 256 & protocol="application/pgp-signature"; boundary=bar 257 & 258 & --bar 259 & Content-Type: text/plain; charset=us-ascii 260 & 261 & This message was first signed, and then encrypted. 262 & 263 & --bar 264 & Content-Type: application/pgp-signature 265 & 266 & -----BEGIN PGP MESSAGE----- 267 & Version: 2.6.2 268 & 269 & iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC// 270 & jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq 271 & uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn 272 & HOxEa44b+EI= 273 & =ndaj 274 & -----END PGP MESSAGE----- 275 & 276 & --bar-- 277 -----END PGP MESSAGE----- 279 --foo-- 281 (The text preceded by '&' indicates that it is really 282 encrypted, but presented as text for clarity.) 284 6.2 Combined method 286 Versions 2.x of PGP also allow data to be signed and encrypted in 287 one operation. This method is an acceptable shortcut, and has the 288 benefit of less overhead. The resulting data should be formed as a 289 "multipart/encrypted" object as described above. 291 Messages which are encrypted and signed in this combined fashion are 292 REQUIRED to follow the same canonicalization rules as for 293 multipart/signed objects. 295 It is explicitly allowed for an agent to decrypt a combined message 296 and rewrite it as a multipart/signed object using the signature data 297 embedded in the encrypted version. 299 7. Distribution of PGP public keys 301 Content-Type: application/pgp-keys 302 Required parameters: none 303 Optional parameters: none 305 This is the content type which should be used for relaying public 306 key blocks. 308 8. Notes 310 PGP and Pretty Good Privacy are trademarks of Philip Zimmermann. 312 References 314 [1] James Galvin, Gale Murphy, Steve Crocker, Ned Freed. Security 315 Multiparts for MIME: Multipart/Signed and Multipart/Encrypted. 316 RFC1847, 1994 318 [2] James Galvin, Gale Murphy, Steve Crocker, Ned Freed. MIME Object 319 Security Services. RFC1848, 1995 321 [3] Derek Atkins, William Stallings, Philip Zimmermann. PGP Message 322 Exchange Formats. draft-atkins-pgpformat-02.txt, 1995