idnits 2.17.00 (12 Aug 2021) /tmp/idnits29577/draft-crocker-doseta-mimeauth-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 (February 23, 2011) is 4098 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'FWS' is mentioned on line 280, but not defined -- No information found for draft-ietf-crocker-doseta-base - is the name correct? ** Obsolete normative reference: RFC 4234 (ref. 'RFC5234') (Obsoleted by RFC 5234) -- Obsolete informational reference (is this intentional?): RFC 4871 (Obsoleted by RFC 6376) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Crocker 3 Internet-Draft Brandenburg InternetWorking 4 Intended status: Experimental M. Kucherawy 5 Expires: August 27, 2011 Cloudmark 6 February 23, 2011 8 MIME Content Authentication using DOSETA (MIMEAUTH) 9 draft-crocker-doseta-mimeauth-00 11 Abstract 13 MIME is a method of packaging and labeling aggregations of data; it 14 is used both for email and the Web. Many usage scenarios would 15 benefit by having an objective method of assessing the validity of 16 MIME data, based on an authenticated identity. MIMEAUTH leverages 17 technology developed for DKIM to provide such a method. Its use can 18 be extended to cover specific header-fields of a containing email 19 message or World Wide Web HTTP content. Existing authentication 20 mechanisms have achieved only limited success due to challenges with 21 administration and use. MIMEAUTH has very low administration and use 22 overhead, through self-certifying keys in the DNS and a labeling 23 method that can be transparent to end-users. For relayed and 24 mediated sequences, MIMEAUTH can be implemented within a service and 25 therefore can be transparent to end-system software. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on August 27, 2011. 44 Copyright Notice 46 Copyright (c) 2011 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Signing Identity . . . . . . . . . . . . . . . . . . . . . 4 63 1.2. Terminology and Definitions . . . . . . . . . . . . . . . 4 64 1.3. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 4 65 2. Signing and Verifying Protocol . . . . . . . . . . . . . . . . 5 66 3. Extensions to DOSETA Template . . . . . . . . . . . . . . . . 6 67 3.1. Signature Data Structure . . . . . . . . . . . . . . . . . 6 68 3.2. Email Signed Header Fields . . . . . . . . . . . . . . . . 7 69 4. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 8 70 4.1. Security Considerations . . . . . . . . . . . . . . . . . 8 71 4.2. IANA Considerations . . . . . . . . . . . . . . . . . . . 9 72 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 5.1. Normative References . . . . . . . . . . . . . . . . . . . 9 74 5.2. Informative References . . . . . . . . . . . . . . . . . . 10 75 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 10 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 78 1. Introduction 80 MIME is a core data-packaging mechanism for Internet applications; it 81 is used both for email and the Web. Many usage scenarios would 82 benefit by having an objective method of assessing the validity of 83 MIME data, based on an authenticated identity. Existing 84 authentication mechanisms have achieved only limited use. MIMEAUTH 85 is based on DOSETA [I-D.DOSETA] to provide such a method. Its use 86 can be extended to cover specific header-fields of a containing email 87 message or World Wide Web HTTP content. MIMEAUTH has very low 88 administration and use overhead, through self-certifying keys in the 89 DNS and a labeling method that can be transparent to end-users. For 90 relayed and mediated sequences, MIMEAUTH can be implemented within a 91 service and therefore can be transparent to end-system software. 93 The approach taken by MIMEAUTH differs from previous approaches to 94 message authentication, such as Secure/Multipurpose Internet Mail 95 Extensions (S/MIME) [RFC1847] and OpenPGP [RFC4880], in that: 97 o the signature is written as an associated attribute in a header 98 field, rather than being integrated into the data itself, so that 99 neither human recipients nor existing MUA (Mail User Agent) 100 software is confused by signature-related content appearing in the 101 data; 103 o there is no dependency on having public and private key pairs 104 being issued by well-known, trusted certificate authorities; 106 o there is no dependency on the deployment of any new Internet 107 protocols or services for public key distribution or revocation; 109 o authentication is distinct from encryption; 111 MIMEAUTH: 113 o is compatible with the existing email and Web infrastructure and 114 is transparent to it, to the fullest extent possible; 116 o requires minimal new infrastructure; 118 o can be implemented independently of clients in order to reduce 119 deployment time; 121 o can be deployed incrementally; 123 o allows delegation of signing to third parties. 125 1.1. Signing Identity 127 MIMEAUTH separates specification of the identity of the MIMEAUTH 128 signer from the purported author of the content. Verifiers can use 129 the signing information to decide how they want to process the data. 130 In particular, the authentication identity specified by a MIMEAUTH 131 signature is not required to match any other identifier the content 132 or the header. However when the identity does match other, specific 133 identities, specific semantics are assigned. 135 1.2. Terminology and Definitions 137 This specification incorporates the terminology defined in 138 [I-D.DOSETA]. 140 Syntax descriptions use Augmented BNF (ABNF) [RFC5234]. 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in [RFC2119]. 146 Additional terminology: 148 Internal IDentfier (IID): An optional textual literal token that 149 can be included with a signature and can be part of 150 communications back to the signer, as a reference to the 151 signature. For DOSETA processing, the domain name portion of 152 the IID has only basic domain name semantics; any possible 153 owner-specific semantics are outside the scope of DOSETA. That 154 is, for MIMEAUTH, the entire string is an undifferentiated 155 literal. It is specified in Section 3.1 . 157 1.3. Open Issues 159 Still to be resolved: 161 o Precise semantics of a signature. Does it merely declare 162 "responsibility" by the signer, or "validity" of the content, or 163 something else? 165 o Should there be a flag that differentiates among different 166 possible semantics, such as defaulting to "responsibility" but 167 able to flag assertion of validity? How dangerous would such a 168 flag be? 169 NOTE: A variety of assurances can be made about an email From: 170 field, such as validity of the domain portion, validity of the 171 entire email address, and validity of the 172 string. This, of course, is separate from whether to trust 173 /any/ assurances being made... 175 2. Signing and Verifying Protocol 177 MIMEAUTH uses the DOSETA "Generic Header/Content Signing Service 178 Template" [I-D.DOSETA] as its base. 180 The DOSETA Template specifies features labeled TEMPLATE that need to 181 be tailored to a specific signing service. For MIMEAUTH, the 182 tailored features are: 184 Signature Association: The DOSETA-Signature data are stored in a 185 MIME Content-Authentication: header field that is part of the 186 MIME object being authenticated. This contains all of the 187 signature and key-fetching data, per [I-D.DOSETA]. 189 Semantics Signaling: The presence of a MIME 190 Content-Authentication: header field signals the use of 191 MIMEAUTH. 193 Semantics: A MIMEAUTH signature means that the owner of the DDI 194 is taking direct responsibility for the signed content and for 195 the content of any referenced header fields, if present. 196 Hence, the payload, or output, of MIMEAUTH is: 198 + The DDI domain name, specifically the "d" parameter in the 199 MIME Content-Authentication: header field 201 + A list of referenced header fields 203 + An indication that the signature verified 205 NOTE: The semantics of this signature are much stronger than 206 the semantics of a DKIM signature and pertain to the 207 content, not merely the signing domain. [RFC4871] 209 Header/Content Mapping: MIMEAUTH maps the DOSETA header 210 processing to the cited header fields that are associated with 211 the MIME object. DOSETA Content maps to the MIME body, per 212 [RFC2045]. The Content-type: header field is always covered by 213 the signature. 215 When a MIMEAUTH signature lists additional header fields in the 216 "h" parameter, MIMEAUTH is asserting that these also have valid 217 data. By including other common header fields that are 218 associated with MIME usage, the scope of a MIMEAUTH signature 219 can apply to a containing protocol data unit, such as an email 220 message or a Web payload. Therefore, when the authentication 221 semantic is intended to assert validity of both the MIME data 222 and the context in which it occurs, a minimum set of additional 223 header fields SHOULD be included in the DOSETA "h" parameter. 224 This is discussed further in Section 3.2. 226 3. Extensions to DOSETA Template 228 This section contains specifications that are added to the basic 229 DOSETA H/C Signing Template. 231 3.1. Signature Data Structure 233 These are MIMEAUTH-specific tags: 235 i= This specifies an Internal Identifier (IID) token that can be 236 used when referring to the signed data, back to the signer. 237 Within the MIMEAUTH protocol, the string has no value except as 238 a literal token. Any conventions for the string that are 239 imposed by the signer are unknown to other MIMEAUTH 240 participants. 242 The syntax is the form of a standard email address where the 243 MAY be omitted. 245 Internationalized domain names MUST be converted using the 246 steps listed in Section 4 of [RFC5890] using the "ToASCII" 247 function. 249 ABNF: 250 sig-i-tag = %x69 [FWS] "=" [FWS] 251 [ local-part ] "@" domain-name 253 z= Copied header fields (DOSETA-quoted-printable, but see 254 description; OPTIONAL, default is null). A vertical-bar- 255 separated list of selected header fields present when the 256 message was signed, including both the field name and value. 257 It is not required to include all header fields present at the 258 time of signing. This field need not contain the same header 259 fields listed in the "h=" tag. The header field text itself 260 MUST encode the vertical bar ("|", %x7C) character. That is, 261 vertical bars in the "z=" text are meta-characters, and any 262 actual vertical bar characters in a copied header field MUST be 263 encoded. Note that all whitespace MUST be encoded, including 264 whitespace between the colon and the header field value. After 265 encoding, FWS MAY be added at arbitrary locations in order to 266 avoid excessively long lines; such whitespace is NOT part of 267 the value of the header field, and MUST be removed before 268 decoding. 270 Copied header field values are for diagnostic use. 272 Header fields with characters requiring conversion SHOULD be 273 converted as described in MIME Part Three [RFC2047]. 275 ABNF: 277 sig-z-tag = %x7A [FWS] "=" [FWS] 278 sig-z-tag-copy 279 *( "|" [FWS] sig-z-tag-copy ) 280 sig-z-tag-copy = hdr-name [FWS] ":" 281 qp-hdr-value 283 3.2. Email Signed Header Fields 285 Some header fields have semantics that are relevant to end users and 286 often are presented to them. If MIMEAUTH is used to sign an email 287 message, it is useful to cover such header fields, in addition to the 288 MIME content. This section provides a generic recommendation 289 intended to apply to the general case of signing a message; specific 290 senders might wish to modify these guidelines as required by their 291 unique situations. Verifiers MUST be capable of verifying signatures 292 even if one or more of the recommended header fields is not signed or 293 if one or more of the dis-recommended header fields is signed. Note 294 that verifiers do have the option of ignoring signatures that do not 295 cover a sufficient portion of the header or content, just as they 296 might ignore signatures from an identity they do not trust. 298 The signer is encouraged to consider carefully which fields are 299 important to the interpretation of the content and which ones are 300 not. As an example, note what fields are typically displayed to 301 recipients. The following header fields are listed as a default set 302 and SHOULD be included in the signature, if they are present in the 303 message being signed: 305 o From, Reply-To, Resent-From 307 o Subject 309 o Date, Message-ID, Resent-Date, Resent-Message-ID 311 o To, Cc, Resent-To, Resent-Cc 313 o Content-Type, Content-ID, Content- Description ) 315 o List-Id, List-Help, List-Unsubscribe, List-Subscribe, List-Post, 316 List-Owner, List-Archive 318 The following header fields SHOULD NOT be included in the signature: 320 o Return-Path 322 o Received 324 o Comments, Keywords 326 o Bcc, Resent-Bcc 328 o Content-Signature (MUST NOT include) 330 Optional header fields (those not mentioned above) normally SHOULD 331 NOT be included in the signature, due to the possibility of having 332 additional header fields, of the same name, that are added or 333 reordered legitimately, prior to verification. There are likely to 334 be reasonable exceptions to this rule, given the wide variety of 335 application-specific header fields that might be applied to a 336 message, some of which are unlikely to be duplicated, modified, or 337 reordered. 339 4. Considerations 341 4.1. Security Considerations 342 4.2. IANA Considerations 344 MIMEAUTH uses registries assigned to DOSETA [I-D.DOSETA]. This 345 section specifies additions to these registries. 347 4.2.1. Content-Authentication Tag Specifications 349 These values are added to the registry that is now defined in 350 [I-D.DOSETA]: 352 +------+------------------------------+ 353 | TYPE | REFERENCE | 354 +------+------------------------------+ 355 | i | (this document, Section 3.1) | 356 | z | (this document, Section 3.1) | 357 +------+------------------------------+ 359 Table 1: Content-Authentication Tag Initial Values 361 4.2.2. Content-Authentication Header Field 363 IANA has added MIME Content-Authentication: to the "Permanent Message 364 Header Fields" registry (see [RFC3864]) for the "mail" protocol, 365 using this document as the reference. 367 5. References 369 5.1. Normative References 371 [I-D.DOSETA] 372 Crocker, D., Ed. and M. Kucherawy, Ed., "DomainKeys 373 Security Tagging (DOSETA)", 374 I-D draft-ietf-crocker-doseta-base, 2011. 376 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 377 Extensions (MIME) Part One: Format of Internet Message 378 Bodies", RFC 2045, November 1996. 380 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 381 Part Three: Message Header Extensions for Non-ASCII 382 Content", RFC 2047, November 1996. 384 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 385 Requirement Levels", BCP 14, RFC 2119, March 1997. 387 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 388 Specifications: ABNF", RFC 4234, January 2008. 390 [RFC5890] Klensin, J., "Internationalizing Domain Names in 391 Applications (IDNA): Definitions and Document Framework", 392 RFC 5890, August 2010. 394 5.2. Informative References 396 [RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, 397 "Security Multiparts for MIME: Multipart/Signed and 398 Multipart/Encrypted", RFC 1847, October 1995. 400 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 401 Procedures for Message Header Fields", BCP 90, RFC 3864, 402 September 2004. 404 [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 405 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 406 Signatures", RFC 4871, May 2007. 408 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, 409 "OpenPGP Message Format", RFC 4880, November 2007. 411 Appendix A. Acknowledgements 413 Authors' Addresses 415 D. Crocker 416 Brandenburg InternetWorking 417 675 Spruce Dr. 418 Sunnyvale 419 USA 421 Phone: +1.408.246.8253 422 Email: dcrocker@bbiw.net 423 URI: http://bbiw.net 425 M. Kucherawy 426 Cloudmark 427 128 King St., 2nd Floor 428 San Francisco, CA 94107 429 USA 431 Email: msk@cloudmark.com