idnits 2.17.1 draft-melnikov-iana-reg-forwarded-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 04, 2019) is 1628 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-birk-pep-04 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Melnikov 3 Internet-Draft Isode Ltd 4 Intended status: Informational B. Hoeneisen 5 Expires: May 7, 2020 pEp Foundation 6 November 04, 2019 8 IANA Registration of Content-Type Header Field Parameter 'forwarded' 9 draft-melnikov-iana-reg-forwarded-00 11 Abstract 13 This document defines a new Content-Type header field parameter named 14 "forwarded" for "message/rfc822" and "message/global" media types, 15 and its registration with IANA. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on May 7, 2020. 34 Copyright Notice 36 Copyright (c) 2019 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.2. Implementations . . . . . . . . . . . . . . . . . . . . . 3 54 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 3 55 1.4. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Specification . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 59 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 61 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 62 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 64 8.2. Informative References . . . . . . . . . . . . . . . . . 6 65 Appendix A. Additional Example (pEp) . . . . . . . . . . . . . . 6 66 Appendix B. Document Changelog . . . . . . . . . . . . . . . . . 8 67 Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 8 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 70 1. Introduction 72 This document defines a new Content-Type header field parameter 73 [RFC2045] for "message/rfc822" and "message/global" [RFC6532] media 74 types with name "forwarded". The parameter value is case- 75 insensitive and can be either "yes" or "no". Setting the value to 76 "no" is meaningful when used within S/MIME or PGP/MIME signed or 77 encrypted body parts (cf. 78 [I-D.ietf-lamps-header-protection-requirements]. The value "yes" 79 means that the message nested inside "message/rfc822" (or "message/ 80 global") is a simple forwarded message. If the parameter is missing, 81 the default assumption is the message has been forwarded. 83 1.1. Use Cases 85 Two use cases have been discovered so far: 87 1. This parameter indicates whether a nested message is signed and/ 88 or encrypted (S/MIME or PGP/MIME), which tells the receiving side 89 how to display the message to the user. Currently, many email 90 clients display "weird artefacts" to users due to this missing 91 information. 93 2. This parameter indicates to mailing lists which email messages 94 are forwarded, and which are signed and/or encrypted (S/MIME or 95 PGP/MIME), and how to handle these respective messages. 97 1.2. Implementations 99 At this time, there are two known email systems which use this 100 Content-Type header field parameter: 102 1. Isode with S/MIME [RFC8551] 104 2. pEp with PGP/MIME [I-D.birk-pep] 106 1.3. Requirements Language 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [RFC2119]. 112 1.4. Terms 114 The following terms are defined for the scope of this document: 116 o Header Field (HF): cf. [RFC5322] 118 o Header Section (HS): cf. [RFC5322] 120 2. Specification 122 This section defines the new "forwarded" Content-Type header field 123 parameter. 125 The Content-Type header field parameter "forwarded" may assume three 126 values: 128 o "yes": The email message contained in the MIME part is a forwarded 129 message. A MUA (Mail User Agent) that is forwarding a message 130 should add a Content-Type header field parameter "forwarded=yes". 132 o "no": The email message contained in the MIME part is a 133 encapsulated email message that has been signed and/or encrypted 134 for header protection. MUAs SHOULD add a Content-Type header 135 field parameter "forwarded=no" to indicate the message is not 136 forwarded, but encapsulated for header protection (cf. 137 [I-D.ietf-lamps-header-protection-requirements]). 139 o absent: If the MUA has no information to determine whether an 140 email message is forwarded or encapsulated, it omits the 141 "forwarded" Content-Type header field parameter. A receiving MUAs 142 default behavior is to assume the email message contained in the 143 MIME part is a forwarded message. 145 3. Example 147 The following example shows the usage of the Content-Type header 148 field parameter "forwarded" for an email message that is not 149 forwarded, but encapsulated in another email message. 151 Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time) 152 Message-ID: 153 Subject: Meeting at my place 154 From: "Alexey Melnikov" 155 MIME-Version: 1.0 156 Content-Type: multipart/signed; charset=us-ascii; micalg=sha1; 157 protocol="application/pkcs7-signature"; 158 boundary=.cbe16d2a-e1a3-4220-b821-38348fc97237 160 This is a multipart message in MIME format. 161 --.cbe16d2a-e1a3-4220-b821-38348fc97237 162 Content-Type: message/rfc822; forwarded=no 164 Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time) 165 From: "Alexey Melnikov" 166 Message-ID: 167 MIME-Version: 1.0 168 MMHS-Primary-Precedence: 3 169 Subject: Meeting at my place 170 To: somebody@example.net 171 X-Mailer: Example Mailer 172 Content-Type: text/plain; charset=us-ascii 174 This is an important message that I don't want to be modified. 176 --.cbe16d2a-e1a3-4220-b821-38348fc97237 177 Content-Transfer-Encoding: base64 178 Content-Type: application/pkcs7-signature 180 [[base-64 encoded signature]] 182 --.cbe16d2a-e1a3-4220-b821-38348fc97237-- 184 Appendix A contains an additional example on the usage of the 185 Content-Type header field parameter "forwarded" as used by pEp 186 [I-D.birk-pep]. 188 4. Security Considerations 190 This document does not define a new protocol, and thus does not 191 create new security concerns in and of itself. 193 5. Privacy Considerations 195 This document does not introduce any new issues regarding Privacy. 197 6. IANA Considerations 199 This document requests IANA to register the Content-Type header field 200 parameter [RFC2045] with name "forwarded" for "message/rfc822" and 201 "message/global" media types as specified in Section 2 of this 202 document. 204 7. Acknowledgments 206 The authors would like to thank the following people who have 207 provided helpful comments and suggestions for this document: David 208 Wilson, Kelly Bristol, Krista Bennett, Robert Williams, Steve Kille, 209 and Wei Chuang. 211 David Wilson came up with the idea of defining a new Content-Type 212 header field parameter to distinguish forwarded messages from inner 213 header field protection constructs. 215 8. References 217 8.1. Normative References 219 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 220 Extensions (MIME) Part One: Format of Internet Message 221 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 222 . 224 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 225 Requirement Levels", BCP 14, RFC 2119, 226 DOI 10.17487/RFC2119, March 1997, 227 . 229 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 230 DOI 10.17487/RFC5322, October 2008, 231 . 233 [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 234 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 235 Message Specification", RFC 8551, DOI 10.17487/RFC8551, 236 April 2019, . 238 8.2. Informative References 240 [I-D.birk-pep] 241 Marques, H., Luck, C., and B. Hoeneisen, "pretty Easy 242 privacy (pEp): Privacy by Default", draft-birk-pep-04 243 (work in progress), July 2019. 245 [I-D.ietf-lamps-header-protection-requirements] 246 Melnikov, A. and B. Hoeneisen, "Problem Statement and 247 Requirements for Header Protection", draft-ietf-lamps- 248 header-protection-requirements-01 (work in progress), 249 October 2019. 251 [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized 252 Email Headers", RFC 6532, DOI 10.17487/RFC6532, February 253 2012, . 255 Appendix A. Additional Example (pEp) 257 The following example shows the usage of the Content-Type header 258 field parameter "forwarded" as used by pEp [I-D.birk-pep] in an email 259 message (after decryption). The inner email message was not 260 forwarded, but encapsulated in another email message. 262 Message-ID: 263 From: Alice Spivak Hyatt 264 To: Carol Burnett 265 Subject: pEp 266 [...] 267 MIME-Version: 1.0 268 Content-Type: multipart/mixed; 269 boundary="238e1f2946e87ccd3d1b58ba507ed7ab" 271 --238e1f2946e87ccd3d1b58ba507ed7ab 272 Content-Type: text/plain; charset="utf-8" 273 Content-Disposition: inline; filename="msg.txt" 275 [[ User-Information, e.g. "If you are seeing this message, your 276 client does not support raising message attachments. Please click 277 on the message attachment to view it!" ]] 279 --238e1f2946e87ccd3d1b58ba507ed7ab 280 Content-Type: message/rfc822; forwarded="no" 282 Message-ID: 283 From: Alice Spivak Hyatt 284 To: Carol Burnett 285 Subject: Boom shaka laka 286 [...] 287 MIME-Version: 1.0 288 Content-Type: text/plain; charset="utf-8" 289 Content-Transfer-Encoding: quoted-printable 290 Content-Disposition: inline; filename="msg.txt" 292 Don't you get sick of these=3F 293 --238e1f2946e87ccd3d1b58ba507ed7ab 294 Content-Type: application/pgp-keys 295 Content-Disposition: attachment; filename="pEpkey.asc" 297 -----BEGIN PGP PUBLIC KEY BLOCK----- 299 xsBNBFV4PbEBCADTmjGDsoti/VPoZ3w2oCjLBNq1jWIGMkbiUgCGUQjVsNrSZ80U 300 [...] 301 q46bEcclS/gTGHtFweVOiqRnR4H5YEjurCd84h8zF8MAArhxBhAtbg1nYgeHjkKX 302 =t2WB 303 -----END PGP PUBLIC KEY BLOCK----- 305 --238e1f2946e87ccd3d1b58ba507ed7ab-- 307 Appendix B. Document Changelog 309 [[ RFC Editor: This section is to be removed before publication ]] 311 o draft-melnikov-iana-reg-forwarded-00 313 o Initial version derived from draft-ietf-lamps-header-protection- 314 requirements-01 316 Appendix C. Open Issues 318 o Determine whether to add an option for "forwarded=unknown" to 319 indicate support for this Content-Type header field parameter. 321 [[ RFC Editor: This section should be empty and is to be removed 322 before publication. ]] 324 Authors' Addresses 326 Alexey Melnikov 327 Isode Ltd 328 14 Castle Mews 329 Hampton, Middlesex TW12 2NP 330 UK 332 Email: alexey.melnikov@isode.com 334 Bernie Hoeneisen 335 pEp Foundation 336 Oberer Graben 4 337 CH-8400 Winterthur 338 Switzerland 340 Email: bernie.hoeneisen@pep.foundation 341 URI: https://pep.foundation/