idnits 2.17.1 draft-ietf-acme-email-smime-01.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 (October 29, 2017) is 2364 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC7515' is defined on line 170, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-acme-acme-06 ** Obsolete normative reference: RFC 5751 (Obsoleted by RFC 8551) Summary: 1 error (**), 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 October 29, 2017 5 Expires: May 2, 2018 7 Extensions to Automatic Certificate Management Environment for end user 8 S/MIME certificates 9 draft-ietf-acme-email-smime-01 11 Abstract 13 This document specifies identifiers and challenges required to enable 14 the Automated Certificate Management Environment (ACME) to issue 15 certificates for use by email users that want to use S/MIME. 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 2, 2018. 34 Copyright Notice 36 Copyright (c) 2017 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 2. Conventions Used in This Document . . . . . . . . . . . . . . 2 53 3. Use of ACME for issuing end user S/MIME certificates . . . . 2 54 4. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 56 6. Security Considerations . . . . . . . . . . . . . . . . . . . 3 57 7. Normative References . . . . . . . . . . . . . . . . . . . . 3 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1. Introduction 62 [I-D.ietf-acme-acme] is a mechanism for automating certificate 63 management on the Internet. It enables administrative entities to 64 prove effective control over resources like domain names, and 65 automates the process of generating and issuing certificates. 67 This document describes an extension to ACME for use by S/MIME. 68 Section 3 defines extensions for issuing end user S/MIME [RFC5751] 69 certificates. 71 2. Conventions Used in This Document 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in [RFC2119]. 77 3. Use of ACME for issuing end user S/MIME certificates 79 [I-D.ietf-acme-acme] defines "dns" Identifier Type that is used to 80 verify that a particular entity has control over a domain or specific 81 service associated with the domain. In order to be able to issue 82 end-user S/MIME certificates, ACME needs a new Identifier Type that 83 proves ownership of an email address. 85 This document defines a new Identifier Type "email" which corresponds 86 to an (all ASCII) email address [RFC5321] or Internationalized Email 87 addresses [RFC6531]. This can be used with S/MIME or other similar 88 service that requires posession of a certificate tied to an email 89 address. 91 A new challenge type "email-reply-00" is used with "email" Identifier 92 Type, which provides proof that an ACME client has control over an 93 email address: [[Very rough outline follows]] 95 1. ACME server generates a "challenge" email message with the 96 subject "ACME: ", where is the 97 base64url encoded first part of the token, which contains at 98 least 64 bit of entropy. The challenge email message MUST have a 99 single text/plain MIME body part [RFC2045]. The second part of 100 the token (token-part2, which also contains at least 64 bit of 101 entropy) is returned over HTTPS to the ACME client. ACME client 102 concatenates "token-part1" and "token-part2" to create "token", 103 calculates key-authz (as per Section 8.1 of 104 [I-D.ietf-acme-acme]), then includes the base64url encoded 105 SHA-256 digest [FIPS180-4] of the key authorization in the body 106 of a response email message containing a single text/plain MIME 107 body part [RFC2045]. 109 4. Open Issues 111 [[This section should be empty before publication]] 113 1. Do we need to handle text/html or multipart/alternative in email 114 challenge? Simplicity suggests "no". 116 2. Do we need a proof that ACME client can submit email on behalf of 117 the user, not just read the challenge using IMAP? Alexey: 118 probably yes, because intercepting somebody's email is easier 119 than generating email on the user's behalf. 121 5. IANA Considerations 123 IANA is requested to register a new Identifier Type "email" which 124 corresponds to an (all ASCII) email address [RFC5321]. 126 And finally, IANA is requested to register the following ACME 127 challenge types that are used with Identifier Type "email": "email- 128 reply". The reference for it is this document. 130 6. Security Considerations 132 TBD. 134 7. Normative References 136 [FIPS180-4] 137 National Institute of Standards and Technology, "Secure 138 Hash Standard (SHS)", FIPS PUB 180-4, August 2015, 139 . 142 [I-D.ietf-acme-acme] 143 Barnes, R., Hoffman-Andrews, J., and J. Kasten, "Automatic 144 Certificate Management Environment (ACME)", draft-ietf- 145 acme-acme-06 (work in progress), March 2017. 147 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 148 Extensions (MIME) Part One: Format of Internet Message 149 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 150 . 152 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 153 Requirement Levels", BCP 14, RFC 2119, 154 DOI 10.17487/RFC2119, March 1997, 155 . 157 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 158 DOI 10.17487/RFC5321, October 2008, 159 . 161 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 162 Mail Extensions (S/MIME) Version 3.2 Message 163 Specification", RFC 5751, DOI 10.17487/RFC5751, January 164 2010, . 166 [RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized 167 Email", RFC 6531, DOI 10.17487/RFC6531, February 2012, 168 . 170 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 171 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 172 2015, . 174 Author's Address 176 Alexey Melnikov 177 Isode Ltd 178 14 Castle Mews 179 Hampton, Middlesex TW12 2NP 180 UK 182 EMail: Alexey.Melnikov@isode.com