idnits 2.17.1 draft-ietf-acme-email-smime-02.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 (March 4, 2018) is 2239 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == 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 (~~), 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 March 4, 2018 5 Expires: September 5, 2018 7 Extensions to Automatic Certificate Management Environment for end user 8 S/MIME certificates 9 draft-ietf-acme-email-smime-02 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 September 5, 2018. 34 Copyright Notice 36 Copyright (c) 2018 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: 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 5. IANA Considerations 118 IANA is requested to register a new Identifier Type "email" which 119 corresponds to an (all ASCII) email address [RFC5321]. 121 And finally, IANA is requested to register the following ACME 122 challenge types that are used with Identifier Type "email": "email- 123 reply". The reference for it is this document. 125 6. Security Considerations 127 TBD. 129 7. Normative References 131 [FIPS180-4] 132 National Institute of Standards and Technology, "Secure 133 Hash Standard (SHS)", FIPS PUB 180-4, August 2015, 134 . 137 [I-D.ietf-acme-acme] 138 Barnes, R., Hoffman-Andrews, J., and J. Kasten, "Automatic 139 Certificate Management Environment (ACME)", draft-ietf- 140 acme-acme-06 (work in progress), March 2017. 142 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 143 Extensions (MIME) Part One: Format of Internet Message 144 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 145 . 147 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 148 Requirement Levels", BCP 14, RFC 2119, 149 DOI 10.17487/RFC2119, March 1997, 150 . 152 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 153 DOI 10.17487/RFC5321, October 2008, 154 . 156 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 157 Mail Extensions (S/MIME) Version 3.2 Message 158 Specification", RFC 5751, DOI 10.17487/RFC5751, January 159 2010, . 161 [RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized 162 Email", RFC 6531, DOI 10.17487/RFC6531, February 2012, 163 . 165 Author's Address 167 Alexey Melnikov 168 Isode Ltd 169 14 Castle Mews 170 Hampton, Middlesex TW12 2NP 171 UK 173 EMail: Alexey.Melnikov@isode.com