idnits 2.17.1 draft-melnikov-acme-email-smime-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (June 7, 2017) is 2507 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'FIPS180-4' is mentioned on line 102, but not defined == Unused Reference: 'RFC7515' is defined on line 149, 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 (~~), 5 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 June 7, 2017 5 Expires: December 9, 2017 7 Extensions to Automatic Certificate Management Environment for end user 8 S/MIME certificates 9 draft-melnikov-acme-email-smime-00 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 for email recipients 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 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 December 9, 2017. 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 (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. 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 email 68 services. Section 3 defines extensions for issuing end user S/MIME 69 [RFC5751] 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]. This can be used with 87 S/MIME or other similar service that requires posession of a 88 certificate tied to an email address. 90 A new challenge type "email-reply-00" is used with "email" Identifier 91 Type, which provides proof that an ACME client has control over an 92 email address: [[Very rough outline follows]] 94 1. ACME server generates an email message with the subject 95 containing "ACME ", where is the 96 base64url encoded first part of the token, which contains at 97 least 64 bit of entropy. The second part of the token (token- 98 part2, which also contains at least 64 bit of entropy) is 99 returned over HTTPS to the ACME client. ACME client concatenates 100 "token-part1" and "token-part2" to create "token", calculates 101 key-authz (as per Section 8.1 of [I-D.ietf-acme-acme]), then 102 included the base64url encoded SHA-256 digest [FIPS180-4] of the 103 key authorization in a response email message. The response 104 email message has a single text/plain MIME body part. [[Do we 105 need to handle text/html or multipart/alternative? Simplicity 106 suggests "no".]] 108 [[Do we need a proof that ACME client can submit email on behalf of 109 the user, not just read the challenge using IMAP?]] 111 4. Open Issues 113 [[This section should be empty before publication]] 115 5. IANA Considerations 117 IANA is requested to register a new Identifier Type "email" which 118 corresponds to an (all ASCII) email address [RFC5321]. 120 And finally, IANA is requested to register the following ACME 121 challenge types that are used with Identifier Type "email": "email- 122 reply". The reference for it is this document. 124 6. Security Considerations 126 TBD. 128 7. Normative References 130 [I-D.ietf-acme-acme] 131 Barnes, R., Hoffman-Andrews, J., and J. Kasten, "Automatic 132 Certificate Management Environment (ACME)", draft-ietf- 133 acme-acme-06 (work in progress), March 2017. 135 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 136 Requirement Levels", BCP 14, RFC 2119, 137 DOI 10.17487/RFC2119, March 1997, 138 . 140 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 141 DOI 10.17487/RFC5321, October 2008, 142 . 144 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 145 Mail Extensions (S/MIME) Version 3.2 Message 146 Specification", RFC 5751, DOI 10.17487/RFC5751, January 147 2010, . 149 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 150 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 151 2015, . 153 Author's Address 155 Alexey Melnikov 156 Isode Ltd 157 14 Castle Mews 158 Hampton, Middlesex TW12 2NP 159 UK 161 EMail: Alexey.Melnikov@isode.com