idnits 2.17.1 draft-melnikov-authentication-results-smime-09.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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 23, 2014) is 3687 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5083' is defined on line 372, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 7001 (Obsoleted by RFC 7601) ** Obsolete normative reference: RFC 5751 (Obsoleted by RFC 8551) Summary: 3 errors (**), 0 flaws (~~), 3 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 March 23, 2014 5 Expires: September 24, 2014 7 Authentication-Results Registration for S/MIME signature verification 8 draft-melnikov-authentication-results-smime-09 10 Abstract 12 RFC 7001 specifies the Authentication-Results header field for 13 conveying results of message authentication checks. This document 14 defines a new authentication method to be used in the Authentication- 15 Results header field for S/MIME related signature checks. 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 http://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 September 24, 2014. 34 Copyright Notice 36 Copyright (c) 2014 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 (http://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 2. Conventions Used in This Document . . . . . . . . . . . . . . 2 53 3. "smime" Authentication Method . . . . . . . . . . . . . . . . 2 54 3.1. S/MIME Results . . . . . . . . . . . . . . . . . . . . . 2 55 3.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 4 56 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 57 4.1. body.smime-part . . . . . . . . . . . . . . . . . . . . . 8 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 59 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 60 6.1. Normative References . . . . . . . . . . . . . . . . . . 10 61 6.2. Informative References . . . . . . . . . . . . . . . . . 10 62 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 64 1. Introduction 66 [RFC7001] specifies the Authentication-Results header field for 67 conveying results of message authentication checks. As S/MIME 68 signature verification (and alteration) is sometimes implemented in 69 border message transfer agents, guards and gateways (for example see 70 [RFC3183]), there is a need to convey signature verification status 71 to Mail User Agents (MUA) and downstream filters. This document 72 defines a new authentication method to be used in the Authentication- 73 Results header field for S/MIME related signature checks. 75 2. Conventions Used in This Document 77 The formal syntax uses the Augmented Backus-Naur Form (ABNF) 78 [RFC5234] notation including the core rules defined in Appendix B of 79 RFC 5234 [RFC5234]. 81 3. "smime" Authentication Method 83 S/MIME signature and countersignature verification is represented by 84 the "smime" method and is defined in [RFC5751]. 86 3.1. S/MIME Results 88 The result values used by S/MIME [RFC5751] are as follows: 90 +-----------+-------------------------------------------------------+ 91 | Result | Meaning | 92 | code | | 93 +-----------+-------------------------------------------------------+ 94 | none | The message was not signed. | 95 | | | 96 | pass | The message was signed, the signature or signatures | 97 | | were acceptable to the verifier, and the signature(s) | 98 | | passed verification tests. | 99 | | | 100 | fail | The message was signed and the signature or | 101 | | signatures were acceptable to the verifier, but they | 102 | | failed the verification test(s). | 103 | | | 104 | policy | The message was signed, signature(s) passed | 105 | | verification tests, but the signature or signatures | 106 | | were not acceptable to the verifier. | 107 | | | 108 | neutral | The message was signed but the signature or | 109 | | signatures contained syntax errors or were not | 110 | | otherwise able to be processed. This result is also | 111 | | be used for other failures not covered elsewhere in | 112 | | this list. | 113 | | | 114 | temperror | The message could not be verified due to some error | 115 | | that is likely transient in nature, such as a | 116 | | temporary inability to retrieve a certificate or CRL. | 117 | | A later attempt may produce a final result. | 118 | | | 119 | permerror | The message could not be verified due to some error | 120 | | that is unrecoverable, such as a required header | 121 | | field being absent or the signer's certificate not | 122 | | being available. A later attempt is unlikely to | 123 | | produce a final result. | 124 +-----------+-------------------------------------------------------+ 126 A signature is "acceptable to the verifier" if it passes local policy 127 checks (or there are no specific local policy checks). For example, 128 a verifier might require that the domain in the rfc822Name 129 subjectAltName in the signing certificate matches the domain in the 130 address of the sender of the message (value of the Sender header 131 field, if present. Value of the From header field otherwise), thus 132 making third-party signatures unacceptable. [RFC5751] advises that 133 if a message fails verification, it should be treated as an unsigned 134 message. A report of "fail" here permits the receiver of the report 135 to decide how to handle the failure. A report of "neutral" or "none" 136 preempts that choice, ensuring the message will be treated as if it 137 had not been signed. 139 3.2. Examples 140 Return-Path: 141 Authentication-Results: example.net; 142 smime=fail (certificate is revoked by CRL) 143 body.smime-identifier=aliceDss@example.com 144 body.smime-part=2 145 Received: from ietfa.example.com (localhost [IPv6:::1]) 146 by ietfa.example.com (Postfix) with ESMTP id 2875111E81A0; 147 Fri, 06 Sep 2002 00:35:14 -0700 (PDT) 148 MIME-Version: 1.0 149 To: User2@example.com 150 From: aliceDss@example.com 151 Subject: Example 4.8 152 Message-Id: <020906002550300.249@example.com> 153 Date: Fri, 06 Sep 2002 00:25:21 -0700 154 Content-Type: multipart/signed; 155 micalg=SHA1; 156 boundary="----=_NextBoundry____Fri,_06_Sep_2002_00:25:21"; 157 protocol="application/pkcs7-signature" 159 This is a multi-part message in MIME format. 161 ------=_NextBoundry____Fri,_06_Sep_2002_00:25:21 163 This is some sample content. 164 ------=_NextBoundry____Fri,_06_Sep_2002_00:25:21 165 Content-Type: application/pkcs7-signature; name=smime.p7s 166 Content-Transfer-Encoding: base64 167 Content-Disposition: attachment; filename=smime.p7s 169 MIIDdwYJKoZIhvcNAQcCoIIDaDCCA2QCAQExCTAHBgUrDgMCGjALBgkqhkiG9w0BBwGgggL 170 gMIIC3DCCApugAwIBAgICAMgwCQYHKoZIzjgEAzASMRAwDgYDVQQDEwdDYXJsRFNTMB4XDT 171 k5MDgxNzAxMTA0OVoXDTM5MTIzMTIzNTk1OVowEzERMA8GA1UEAxMIQWxpY2VEU1MwggG2M 172 IIBKwYHKoZIzjgEATCCAR4CgYEAgY3N7YPqCp45PsJIKKPkR5PdDteoDuxTxauECE//lOFz 173 SH4M1vNESNH+n6+koYkv4dkwyDbeP5u/t0zcX2mK5HXQNwyRCJWb3qde+fz0ny/dQ6iLVPE 174 /sAcIR01diMPDtbPjVQh11Tl2EMR4vf+dsISXN/LkURu15AmWXPN+W9sCFQDiR6YaRWa4E8 175 baj7g3IStii/eTzQKBgCY40BSJMqo5+z5t2UtZakx2IzkEAjVc8ssaMMMeUF3dm1nizaoFP 176 VjAe6I2uG4Hr32KQiWn9HXPSgheSz6Q+G3qnMkhijt2FOnOLl2jB80jhbgvMAF8bUmJEYk2 177 RL34yJVKU1a14vlz7BphNh8Rf8K97dFQ/5h0wtGBSmA5ujY5A4GEAAKBgFzjuVp1FJYLqXr 178 d4z+p7Kxe3L23ExE0phaJKBEj2TSGZ3V1ExI9Q1tv5VG/+onyohs+JH09B41bY8i7RaWgSu 179 OF1s4GgD/oI34a8iSrUxq4Jw0e7wi/ZhSAXGKsZfoVi/G7NNTSljf2YUeyxDKE8H5BQP1Gp 180 2NOM/Kl4vTyg+W4o4GBMH8wDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBsAwHwYDVR0j 181 BBgwFoAUcEQ+gi5vh95K03XjPSC8QyuT8R8wHQYDVR0OBBYEFL5sobPjwfftQ3CkzhMB4v3 182 jl/7NMB8GA1UdEQQYMBaBFEFsaWNlRFNTQGV4YW1wbGUuY29tMAkGByqGSM44BAMDMAAwLQ 183 IUVQykGR9CK4lxIjONg2q1PWdrv0UCFQCfYVNSVAtcst3a53Yd4hBSW0NevTFjMGECAQEwG 184 DASMRAwDgYDVQQDEwdDYXJsRFNTAgIAyDAHBgUrDgMCGjAJBgcqhkjOOAQDBC4wLAIUM/mG 185 f6gkgp9Z0XtRdGimJeB/BxUCFGFFJqwYRt1WYcIOQoGiaowqGzVI 187 ------=_NextBoundry____Fri,_06_Sep_2002_00:25:21-- 189 4. IANA Considerations 191 IANA is requested to add the the following entries to the "Email 192 Authentication Methods" subregistry of the "Email Authentication 193 Parameters" registry: 195 +-------+----------+-------+------------------+---------------------+ 196 | Metho | Defined | ptype | property | value | 197 | d | | | | | 198 +-------+----------+-------+------------------+---------------------+ 199 | smime | [RFC5751 | body | smime-part | A reference to the | 200 | | ] | | | MIME body part that | 201 | | | | | contains the | 202 | | | | | signature, as | 203 | | | | | defined in Section | 204 | | | | | 4.1. | 205 | | | | | | 206 | smime | [RFC5751 | body | smime-identifier | The email address | 207 | | ] | | | [RFC5322] | 208 | | | | | associated with the | 209 | | | | | S/MIME signature. | 210 | | | | | The email address | 211 | | | | | can be specified | 212 | | | | | explicitly or | 213 | | | | | derived from the | 214 | | | | | identity of the | 215 | | | | | signer. Note that | 216 | | | | | this email address | 217 | | | | | can correspond to a | 218 | | | | | counter signature. | 219 | | | | | | 220 | smime | [RFC5751 | body | smime-serial | serialNumber of the | 221 | | ] | | | certificate | 222 | | | | | associated with the | 223 | | | | | S/MIME signature | 224 | | | | | (see section | 225 | | | | | 4.1.2.2 of | 226 | | | | | [RFC5280]. | 227 | | | | | | 228 | smime | [RFC5751 | body | smime-issuer | Issuer name DN | 229 | | ] | | | (e.g. "CN=CA1,ST=BC | 230 | | | | | ,c=CA") of the | 231 | | | | | certificate | 232 | | | | | associated with the | 233 | | | | | S/MIME signature | 234 | | | | | (see section | 235 | | | | | 4.1.2.4 of | 236 | | | | | [RFC5280]. | 237 +-------+----------+-------+------------------+---------------------+ 239 Either both or neither of body.smime-serial and body. smime-issuer 240 should be present in an Authentication-Results header field. body 241 .smime-serial and body.smime-issuer are used for cases when body 242 .smime-identifier (email address) can't be derived by the entity 243 adding the corresponding Authentication-Results header field. For 244 example this can be used when gatewaying from X.400. 246 IANA is requested to add the the following entries to the "Email 247 Authentication Result Names" subregistry of the "Email Authentication 248 Parameters" registry: 250 +-----------+-------------+-----------+--------------------+--------+ 251 | Code | Defined | Auth | Meaning | Status | 252 | | | Method | | | 253 +-----------+-------------+-----------+--------------------+--------+ 254 | none | this | smime | [this memo] | active | 255 | | document | | Section 3.1 | | 256 | | | | | | 257 | pass | this | smime | [this memo] | active | 258 | | document | | Section 3.1 | | 259 | | | | | | 260 | fail | this | smime | [this memo] | active | 261 | | document | | Section 3.1 | | 262 | | | | | | 263 | policy | this | smime | [this memo] | active | 264 | | document | | Section 3.1 | | 265 | | | | | | 266 | neutral | this | smime | [this memo] | active | 267 | | document | | Section 3.1 | | 268 | | | | | | 269 | temperror | this | smime | [this memo] | active | 270 | | document | | Section 3.1 | | 271 | | | | | | 272 | permerror | this | smime | [this memo] | active | 273 | | document | | Section 3.1 | | 274 +-----------+-------------+-----------+--------------------+--------+ 276 4.1. body.smime-part 278 body.smime-part contains the MIME body part reference which contains 279 the S/MIME signature. Syntax of this property is described by the 280 smime-part ABNF production below. application/pkcs7-signature or 281 application/pkcs7-mime (containing SignedData) media type body parts 282 are references using the
syntax (see Section 6.4.5 of 283 [RFC3501]). If the signature being verified is encapsulated by 284 another CMS content type (e.g. application/pkcs7-mime containing 285 EnvelopedData, which contains SignedData), such inner signature body 286 part can be references using "section[/section..." syntax. 288 smime-part = section ["/" smime-subpart] 289 smime-subpart = smime-part 290 section = 292 5. Security Considerations 294 This document doesn't add new security considerations not already 295 covered by [RFC7001] and [RFC5751]. In particular security 296 considerations related to use of weak cryptography over plaintext, 297 weakening and breaking of cryptographic algorithms over time, as well 298 as changing the behavior of message processing based on presence of a 299 signature specified in [RFC5751] are relevant to this document. 300 Similarly, the following security considerations specified in 301 [RFC7001] are particularly relevant to this document: Forged Header 302 Fields, Misleading Results, Internal MTA Lists and Compromised 303 Internal Hosts. 305 To repeat something already mentioned in RFC 7001, Section 7.1: 307 An MUA or filter that accesses a mailbox whose messages are 308 handled by a non-conformant MTA, and understands Authentication- 309 Results header fields, could potentially make false conclusions 310 based on forged header fields. A malicious user or agent could 311 forge a header field using the DNS domain of a receiving ADMD as 312 the authserv-id token in the value of the header field and, with 313 the rest of the value, claim that the message was properly 314 authenticated. The non- conformant MTA would fail to strip the 315 forged header field, and the MUA could inappropriately trust it. 317 For this reason, it is best not to have processing of the 318 Authentication-Results header field enabled by default; instead, 319 it should be ignored, at least for the purposes of enacting 320 filtering decisions, unless specifically enabled by the user or 321 administrator after verifying that the border MTA is compliant. 322 It is acceptable to have an MUA aware of this specification but 323 have an explicit list of hostnames whose Authentication-Results 324 header fields are trustworthy; however, this list should initially 325 be empty. 327 So to emphasize this point: whenever possible, MUAs should implement 328 their own S/MIME signature verification instead of implementing this 329 specification. 331 Note that agents adding Authentication-Results header fields 332 containing S/MIME Authentication Method might be unable to verify 333 S/MIME signatures inside encrypted CMS content types such as 334 EnvelopedData [RFC5652]. So agents processing Authentication-Results 335 header fields can't treat lack of an Authentication-Results header 336 field with S/MIME Authentication Method as an indication that the 337 corresponding S/MIME signature is missing, invalid or valid. 339 6. References 341 6.1. Normative References 343 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 344 4rev1", RFC 3501, March 2003. 346 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 347 Specifications: ABNF", STD 68, RFC 5234, January 2008. 349 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 350 October 2008. 352 [RFC7001] Kucherawy, M., "Message Header Field for Indicating 353 Message Authentication Status", RFC 7001, September 2013. 355 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 356 Housley, R., and W. Polk, "Internet X.509 Public Key 357 Infrastructure Certificate and Certificate Revocation List 358 (CRL) Profile", RFC 5280, May 2008. 360 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 361 Mail Extensions (S/MIME) Version 3.2 Message 362 Specification", RFC 5751, January 2010. 364 6.2. Informative References 366 [RFC3183] Dean, T. and W. Ottaway, "Domain Security Services using S 367 /MIME", RFC 3183, October 2001. 369 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 370 RFC 5652, September 2009. 372 [RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) 373 Authenticated-Enveloped-Data Content Type", RFC 5083, 374 November 2007. 376 Appendix A. Acknowledgements 378 Thank you to Murray S. Kucherawy, David Wilson, Jim Schaad, SM and 379 Steve Kille for comments and corrections on this document. 381 Author's Address 383 Alexey Melnikov 384 Isode Ltd 385 5 Castle Business Village 386 36 Station Road 387 Hampton, Middlesex TW12 2BX 388 UK 390 EMail: Alexey.Melnikov@isode.com