idnits 2.17.1 draft-ietf-pem-mime-alternative-00.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. ** 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 == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 1) being 63 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** 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.) ** There are 70 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 11 has weird spacing: '... This docum...' == Line 12 has weird spacing: '...cuments of th...' == Line 13 has weird spacing: '...s. Note that ...' == Line 18 has weird spacing: '... at any time....' == Line 22 has weird spacing: '...e check the ...' == (65 more instances...) -- 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 (October 1993) is 11143 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) No issues found here. Summary: 11 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Internet Engineering Task Force 2 Internet Draft Privacy Enhanced Mail Working Group 3 J. I. Schiller 4 MIT 5 October 1993 7 An Alternative PEM MIME Integration 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. Internet Drafts may be updated, replaced, or obsoleted by 18 other documents at any time. It is not appropriate to use Internet 19 Drafts as reference material or to cite them other than as a "working 20 draft" or "work in progress." 22 Please check the I-D abstract listing contained in each Internet 23 Draft directory to learn the current status of this or any other 24 Internet Draft. 26 Distribution of this memo is unlimited. Please send comments to the 27 mailing list. 29 This is the second document to describe a mechanism to enclose MIME 30 messages within PEM and vica versa. This document is an independent 31 effort to be considered as an alternative to the previous document. 32 This is *not* a revision of that document and the authors of it do 33 not necessarily endorse the approach described here. 35 Introduction 37 This document describes a mechanism for providing Privacy Enhanced 38 Mail (PEM) functionality within the context of MIME messages. 40 Background 42 MIME (RFC1341-1342) and PEM (RFC1421-1424) have taken separate 43 evolution paths. Specifically PEM was designed and specified to 44 handle RFC822 (non-MIME) messages. The goal of this document is to 45 describe a method for using PEM to protect MIME messages, and to 46 define a way to enclose PEM processed messages within MIME messages. 48 To accomplish these goals requires an additional profile for RFC1421 49 (Content-Domain: MIME) and the definition of a new MIME "application" 50 (application/pem-1421). 52 There are four possibilities for interaction between PEM and MIME. 53 They are: 55 * A MIME message transporting an RFC1421 PEM message which itself 56 contains an RFC822 message (Content-Domain: RFC822). 58 * A MIME message transporting an RFC1421 PEM message which itself 59 contains a MIME object (Content-Domain: MIME). 61 Network Working Group Internet Engineering Task Force 62 Internet Draft Privacy Enhanced Mail Working Group 63 J. I. Schiller 64 MIT 65 October 1993 67 * A PEM message which contains a RFC822 message (as specified by 68 RFC1421). 70 * A PEM message which contains a MIME message or object (Content- 71 Domain: MIME). 73 Definition of "Content-Domain: MIME" within an RFC1421 PEM message 75 When a PEM message contains a MIME object, as opposed to a simple 76 text message, the value of the Content-Domain field of the PEM 77 headers shall be the string "MIME". 79 An RFC1421 PEM message of Content-Domain "MIME" shall contain a MIME 80 "object" that begins with a "Content-Type" MIME header. The PEM body, 81 upon completion of successful PEM processing is handed to a MIME 82 interpreter for further processing. Content-Domain "MIME" messages 83 may be protected with either ENCRYPTED, MIC-ONLY or MIC-CLEAR PEM 84 services. However if MIC-CLEAR is chosen, the MIME content should be 85 in a canonical 7bit form. 87 In other words, if the enclosed MIME object is encoded in such 88 fashion as to be 7bit transportable, then MIC-CLEAR may be (and 89 perhaps should be) used. Other non-encrypted messages should be 90 encoded via the MIC-ONLY mechanism. 92 Enclosing a PEM message within a MIME object 94 An RFC1421 PEM message may be enclosed in a MIME message by defining 95 it to be of Content Type "application/pem-1421" by preceding the PEM 96 processed body with: 98 Content-Type: application/pem-1421 100 Note that the application subtype is defined to be "pem-1421" and 101 that the representation *must* be text/plain; charset=us-ascii. This 102 is because these are correct characterizations of what a RFC1421 103 message appears as. 105 The behavior of a MIME mail reader with PEM capability 107 A MIME mail reader with PEM capability will be able to fully process 108 a MIME message which includes a PEM portion (which may either be the 109 entire message or only part of a multi-part message). 111 The MIME reader will process a message which contains a PEM portion 112 as it would any other MIME message. Upon encountering a 113 "application/pem-1421" body part, it will invoke PEM processing on 114 the enclosed PEM message. If the PEM message contains a Content- 115 Domain "MIME" body, it will invoke MIME recursively on the 116 successfully processed PEM body. If the Content-Domain is RFC822, the 117 PEM software will either display the enclosed text, or prepend the 118 necessary headers such that it can be fed to a MIME reader which will 119 treat it as an RFC822 mail message. 121 Network Working Group Internet Engineering Task Force 122 Internet Draft Privacy Enhanced Mail Working Group 123 J. I. Schiller 124 MIT 125 October 1993 127 The behavior of a MIME mail reader without PEM capability 129 A MIME mail reader will process a MIME message with PEM contents as 130 any other MIME message. If an application/pem-1421 object is found 131 and the MIME reader does not support PEM, then the MIME reader may 132 handle the enclosed PEM message in the same or similar fashion as it 133 handles any other application subtype for which it has no support 134 software. 136 The behavior of a non-MIME but PEM capable mail reader 138 A PEM mail reader that does not understand MIME will be able to 139 process a MIME/PEM message provided that the message itself is a PEM 140 message. In other words, if the whole message is PEM processed as the 141 last step prior to transmission, then a PEM capable, but non-MIME 142 capable mail reader will be able to process the PEM message and then 143 display the enclosed MIME object in the same fashion that a non-MIME 144 mail reader handles a MIME (but non-PEM) message today. 146 It is likely that a non-MIME compliant mail reading agent may not be 147 able to parse a MIME message in order to discover an enclosed 148 "application/pem-1421" component containing a PEM message. However an 149 end-user may be able to manually reformat the incoming message so as 150 to make it amenable to PEM processing. 152 Discussion 154 Prior approaches to integrating PEM and MIME have suggested a 155 significant departure from the RFC1421 PEM encapsulation mechanism. 156 Specifically it has been recommended that PEM messages be represented 157 as MIME multi-part messages. One part of the multi-part would contain 158 what in RFC1421 is described as the PEM headers, and the other would 159 contain the PEM body that is protected by the PEM mechanisms 160 specified in the PEM header part. 162 This document intentionally does not recommend such an approach. This 163 is because it is important for MIME interpreters to *not* reach down 164 into the structure of a PEM body until PEM processing has been 165 performed. The reason for this requirement has to do with the 166 requirement that PEM body parts be immutable so that digital 167 signatures computed on them can be verified. If a PEM body part is 168 decomposeable by MIME readers, then it is quite possible that MIME 169 gateways could reassemble PEM body parts in a fashion semantically 170 equivalent to the original message, but sufficiently different (i.e., 171 different in one bit is sufficient) to cause signature verification 172 to later fail. 174 It is important to understand that the signature verification 175 requirement mandates that PEM messages be carried within MIME as 176 "application" objects and not as "message", "multipart" or other 177 types of body parts. Once this is recognized, it no longer matters 178 whether or not the object within the "application" enclosure appears 179 to be a MIME object upon visual inspection, for it is now outside the 180 realm of what a MIME interpreter may attempt to parse without the aid 181 of the application processor (PEM in this case). 183 Network Working Group Internet Engineering Task Force 184 Internet Draft Privacy Enhanced Mail Working Group 185 J. I. Schiller 186 MIT 187 October 1993 189 By using the RFC1421 based encapsulation technology we benefit from 190 the experience gained in debugging existing PEM implementations as 191 well as ease backward compatibility with non-MIME based PEM agents. 193 Examples 195 Date: Sun, 30 May 93 23:59:39 EST 196 From: jis@MIT.EDU (Jeffrey I. Schiller) 197 To: pem-dev@tis.com 198 Subject: Example PEM MIME Interaction 199 MIME-Version: 1.0 200 Content-Type: application/pem-1421 202 -----BEGIN PRIVACY-ENHANCED MESSAGE----- 203 Proc-Type: 4,MIC-CLEAR 204 Content-Domain: MIME 205 Originator-Certificate: MIIB+jCCAWMCAQIwDQYJKoZIhvcNAQECBQAwSj... 206 Issuer-Certificate: MIIB+jCCAWMCAQQwDQYJKoZIhvcNAQECBQAwRDELMA... 207 MIC-Info: RSA-MD5,RSA,dlSRMLFiwcK7FDvFef8gJfLWwMM4uxMSNtKGlLz9xxw 208 fAyvaFuzp85davcwX4q7EImDs4K46Uwh0oL2GueLnv6b4s1gg25mMg/Y5Bd7/HaE 209 cvkV77tKWGXZrDGEgGSDA 211 Content-Type: text/plain; charset=us-ascii 213 This is a test message. 214 -----END PRIVACY-ENHANCED MESSAGE----- 216 Author's Address 218 Jeffrey I. Schiller 219 Massachusetts Institute of Technology 220 MIT Room E40-311 221 1 Amherst Street 222 Cambridge, MA 02139 223 U.S.A. 224 Tel: +1 (617) 253-0161 225 Fax: +1 (617) 258-8736 226 Email: jis@mit.edu