draft-ietf-acme-email-smime-12.txt   draft-ietf-acme-email-smime-13.txt 
Network Working Group A. Melnikov Network Working Group A. Melnikov
Internet-Draft Isode Ltd Internet-Draft Isode Ltd
Intended status: Informational November 18, 2020 Intended status: Informational November 20, 2020
Expires: May 22, 2021 Expires: May 24, 2021
Extensions to Automatic Certificate Management Environment for end-user Extensions to Automatic Certificate Management Environment for end-user
S/MIME certificates S/MIME certificates
draft-ietf-acme-email-smime-12 draft-ietf-acme-email-smime-13
Abstract Abstract
This document specifies identifiers and challenges required to enable This document specifies identifiers and challenges required to enable
the Automated Certificate Management Environment (ACME) to issue the Automated Certificate Management Environment (ACME) to issue
certificates for use by email users that want to use S/MIME. certificates for use by email users that want to use S/MIME.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 33 skipping to change at page 1, line 33
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 22, 2021. This Internet-Draft will expire on May 24, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 2 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Use of ACME for issuing end-user S/MIME certificates . . . . 3 3. Use of ACME for issuing end-user S/MIME certificates . . . . 3
3.1. ACME challenge email . . . . . . . . . . . . . . . . . . 5 3.1. ACME challenge email . . . . . . . . . . . . . . . . . . 5
3.2. ACME response email . . . . . . . . . . . . . . . . . . . 7 3.2. ACME response email . . . . . . . . . . . . . . . . . . . 7
3.3. Generating encryption only or signing only S/MIME
certificates . . . . . . . . . . . . . . . . . . . . . . 9
4. Internationalization Considerations . . . . . . . . . . . . . 9 4. Internationalization Considerations . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
5.1. ACME Identifier Type . . . . . . . . . . . . . . . . . . 9 5.1. ACME Identifier Type . . . . . . . . . . . . . . . . . . 10
5.2. ACME Challenge Type . . . . . . . . . . . . . . . . . . . 9 5.2. ACME Challenge Type . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . 13 7.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
ACME [RFC8555] is a mechanism for automating certificate management ACME [RFC8555] is a mechanism for automating certificate management
on the Internet. It enables administrative entities to prove on the Internet. It enables administrative entities to prove
effective control over resources like domain names, and automates the effective control over resources like domain names, and automates the
process of generating and issuing certificates. process of generating and issuing certificates.
This document describes an extension to ACME for use by S/MIME. This document describes an extension to ACME for use by S/MIME.
Section 3 defines extensions for issuing end-user S/MIME [RFC8550] Section 3 defines extensions for issuing end-user S/MIME [RFC8550]
skipping to change at page 3, line 31 skipping to change at page 3, line 37
wildcard ("*") character in its value. wildcard ("*") character in its value.
A new challenge type "email-reply-00" is used with "email" Identifier A new challenge type "email-reply-00" is used with "email" Identifier
Type, which provides proof that an ACME client has control over an Type, which provides proof that an ACME client has control over an
email address. email address.
The process of issing an S/MIME certificate works as follows. Note The process of issing an S/MIME certificate works as follows. Note
that the ACME client can be a standalone application (if the MUA is that the ACME client can be a standalone application (if the MUA is
not ACME-email-aware) or can be a component of the MUA. not ACME-email-aware) or can be a component of the MUA.
1. An end-user initiates issuance of an S/MIME certificate for one 1. An end-user initiates issuance of an S/MIME certificate for one
of her email addresses. This might be done using email client of her email addresses. This might be done using email client
UI, by running a command line tool, by visiting a Certificate UI, by running a command line tool, by visiting a Certificate
Authority web page, etc. This document doesn't prescribe Authority web page, etc. This document doesn't prescribe
specific UI used to initiate S/MIME certificate issuance or where specific UI used to initiate S/MIME certificate issuance or
the ACME client is located. where the ACME client is located.
2. The ACME-email-aware client component begins the certificate 2. The ACME-email-aware client component begins the certificate
issuance process by sending a POST request to the server's issuance process by sending a POST request to the server's
newOrder resource, including the identifier of type "email". See newOrder resource, including the identifier of type "email".
Section 7.4 of [RFC8555] for more details. See Section 7.4 of [RFC8555] for more details.
3. The ACME server responds to the POST request, including an 3. The ACME server responds to the POST request, including an
"authorizations" URL for the requested email address. The ACME "authorizations" URL for the requested email address. The ACME
client then retrieves information about the corresponding "email- client then retrieves information about the corresponding
reply-00" challenge as specified in Section 7.5 of [RFC8555]. "email-reply-00" challenge as specified in Section 7.5 of
The "token" field of the corresponding challenge object (from the
"challenges" array) contains token-part2. token-part2 should
contain at least 128 bits of entropy. The "type" field of the
challenge object is "email-reply-00". The challenge object also
contains the "from" field, with the email address that would be
used in the From header field of the "challenge" email message
(see the next step).
1. [RFC8555]. The "token" field of the corresponding challenge
object (from the "challenges" array) contains token-part2.
token-part2 should contain at least 128 bits of entropy. The
"type" field of the challenge object is "email-reply-00". The
challenge object also contains the "from" field, with the email
address that would be used in the From header field of the
"challenge" email message (see the next step).
An example Challenge object might look like this: An example Challenge object might look like this:
{ {
"type": "email-reply-00", "type": "email-reply-00",
"url": "https://example.com/acme/chall/ABprV_B7yEyA4f", "url": "https://example.com/acme/chall/ABprV_B7yEyA4f",
"from": "acme-challenge+2i211oi1204310@example.com", "from": "acme-challenge+2i211oi1204310@example.com",
"token": "DGyRejmCefe7v4NfDGDKfA" "token": "DGyRejmCefe7v4NfDGDKfA"
} }
4. After responding to the authorization request the ACME server 4. After responding to the authorization request the ACME server
generates another token and a "challenge" email message with the generates another token and a "challenge" email message with the
subject "ACME: <token-part1>", where <token-part1> is the subject "ACME: <token-part1>", where <token-part1> is the
base64url encoded [RFC4648] form of the token. The ACME server base64url encoded [RFC4648] form of the token. The ACME server
MUST generate a fresh token for each S/MIME issuance request MUST generate a fresh token for each S/MIME issuance request
(authorization request), and token-part1 MUST contain at least (authorization request), and token-part1 MUST contain at least
128 bits of entropy. The "challenge" email message structure is 128 bits of entropy. The "challenge" email message structure is
described in more details in Section 3.1. described in more details in Section 3.1.
5. The MUA retrieves and parses the "challenge" email message. If 5. The MUA retrieves and parses the "challenge" email message. If
the MUA is ACME-email-aware, it ignores any "challenge" email the MUA is ACME-email-aware, it ignores any "challenge" email
that is not expected, e.g. if there is no ACME certificate that is not expected, e.g. if there is no ACME certificate
issuance pending. The ACME-email-aware MUA also ignores any issuance pending. The ACME-email-aware MUA also ignores any
"challenge" email that has the Subject header field which "challenge" email that has the Subject header field which
indicates that it is an email reply, e.g. a subject starting with indicates that it is an email reply, e.g. a subject starting
the reply prefix "Re:". with the reply prefix "Re:".
6. The ACME client concatenates "token-part1" (received over email) 6. The ACME client concatenates "token-part1" (received over email)
and "token-part2" (received over HTTPS [RFC2818]) to create the and "token-part2" (received over HTTPS [RFC2818]) to create the
ACME "token", calculates keyAuthorization (as per Section 8.1 of ACME "token", calculates keyAuthorization (as per Section 8.1 of
[RFC8555]), then returns the base64url encoded SHA-256 digest [RFC8555]), then returns the base64url encoded SHA-256 digest
[FIPS180-4] of the key authorization. The MUA returns the [FIPS180-4] of the key authorization. The MUA returns the
base64url encoded SHA-256 digest obtained from the ACME client in base64url encoded SHA-256 digest obtained from the ACME client
the body of a "response" email message. The "response" email in the body of a "response" email message. The "response" email
message structure is described in more details in Section 3.2. message structure is described in more details in Section 3.2.
If the MUA is ACME-email-aware, it MUST NOT respond to the same If the MUA is ACME-email-aware, it MUST NOT respond to the same
"challenge" email more than once. "challenge" email more than once.
7. Once the MUA sends the "response" email, the ACME client notifies 7. Once the MUA sends the "response" email, the ACME client
the ACME server by POST to the challenge URL ("url" field). notifies the ACME server by POST to the challenge URL ("url"
field).
8. The ACME client can start polling the authorization URL (using 8. The ACME client can start polling the authorization URL (using
POST-as-GET requests) to see if the ACME server received and POST-as-GET requests) to see if the ACME server received and
validated the "response" email message. (See Section 7.5.1 of validated the "response" email message. (See Section 7.5.1 of
[RFC8555] for more details.) If the "status" field of the
challenge switches to "valid", then the ACME client can proceed
with request finalization. The Certificate Signing Request
(CSR) MUST indicate the exact same set of requested identifiers
as the initial newOrder request. For an identifier of type
"email", the PKCS#10 [RFC2986] CSR MUST contain the requested
email address in an extensionRequest attribute [RFC2985]
requesting a subjectAltName extension. (Such email address MUST
also match the From header field value of the "response" email
message.)
[RFC8555] for more details.) If the "status" field of the 9. In order to request generation of signing only or encryption
challenge switches to "valid", then the ACME client can proceed only S/MIME certificates (as opposed to requesting generation of
with request finalization. The Certificate Signing Request (CSR) S/MIME certificates suitable for both), the CSR needs to include
MUST indicate the exact same set of requested identifiers as the the key usage extension (see Section 4.4.2 of [RFC8550]. This
initial newOrder request. For an identifier of type "email", the is described in more details in Section 3.3.
PKCS#10 [RFC2986] CSR MUST contain the requested email address in
an extensionRequest attribute [RFC2985] requesting a 10. If a request to finalize an order is successful, the ACME server
subjectAltName extension. (Such email address MUST also match will return a 200 (OK) with an updated order object. If the
the From header field value of the "response" email message.) If certificate is issued successfully, i.e. if the order "status"
a request to finalize an order is successful, the ACME server is "valid", then the ACME client can download the issued S/MIME
will return a 200 (OK) with an updated order object. If the certificate from the URL specified in the "certificate" field.
certificate is issued successfully, i.e. if the order "status" is
"valid", then the ACME client can download the issued S/MIME
certificate from the URL specified in the "certificate" field.
3.1. ACME challenge email 3.1. ACME challenge email
A "challenge" email message MUST have the following structure: A "challenge" email message MUST have the following structure:
1. The message Subject header field has the following syntax: "ACME: 1. The message Subject header field has the following syntax: "ACME:
<token-part1>", where the prefix "ACME:" is followed by folding <token-part1>", where the prefix "ACME:" is followed by folding
white space (FWS, see [RFC5322]) and then by <token-part1>, which white space (FWS, see [RFC5322]) and then by <token-part1>, which
is the base64url encoded first part of the ACME token that MUST is the base64url encoded first part of the ACME token that MUST
be at least 128 bits long after decoding. Due to the recommended be at least 128 bits long after decoding. Due to the recommended
skipping to change at page 9, line 24 skipping to change at page 9, line 24
Content-Type: text/plain Content-Type: text/plain
MIME-Version: 1.0 MIME-Version: 1.0
-----BEGIN ACME RESPONSE----- -----BEGIN ACME RESPONSE-----
LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowy LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowy
jxAjEuX0= jxAjEuX0=
-----END ACME RESPONSE----- -----END ACME RESPONSE-----
Figure 2 Figure 2
3.3. Generating encryption only or signing only S/MIME certificates
ACME extensions specified in this document can be used to request
signing only or encryption only S/MIME certificates.
In order to request signing only S/MIME certificate, the CSR MUST
include the key usage extension with digitalSignature and/or
nonRepudiation bits set.
In order to request encryption only S/MIME certificate, the CSR MUST
include the key usage extension with keyEncipherment and/or
keyAgreement bits set.
Presence of both of the above sets of key usage bits, as well as
absence of key usage extension in the CSR, signals to ACME server to
issue an S/MIME certificate suitable for both signing and encryption.
4. Internationalization Considerations 4. Internationalization Considerations
[RFC8616] updated/clarified use of DKIM with Internationalized Email [RFC8616] updated/clarified use of DKIM with Internationalized Email
addresses [RFC6531]. Please consult RFC 8616 in regards to any addresses [RFC6531]. Please consult RFC 8616 in regards to any
changes that need to be implemented. changes that need to be implemented.
Use of non ASCII characters in left hand sides of Internationalized Use of non ASCII characters in left hand sides of Internationalized
Email addresses requires putting Internationalized Email Addresses in Email addresses requires putting Internationalized Email Addresses in
X.509 Certificates [RFC8398]. X.509 Certificates [RFC8398].
skipping to change at page 14, line 9 skipping to change at page 15, line 9
[RFC8058] Levine, J. and T. Herkula, "Signaling One-Click [RFC8058] Levine, J. and T. Herkula, "Signaling One-Click
Functionality for List Email Headers", RFC 8058, Functionality for List Email Headers", RFC 8058,
DOI 10.17487/RFC8058, January 2017, DOI 10.17487/RFC8058, January 2017,
<https://www.rfc-editor.org/info/rfc8058>. <https://www.rfc-editor.org/info/rfc8058>.
Appendix A. Acknowledgements Appendix A. Acknowledgements
Thank you to Andreas Schulze, Gerd v. Egidy, James A. Baker, Ben Thank you to Andreas Schulze, Gerd v. Egidy, James A. Baker, Ben
Schwartz, Peter Yee, Hilarie Orman, Michael Jenkins, Barry Leiba, Schwartz, Peter Yee, Hilarie Orman, Michael Jenkins, Barry Leiba,
Fraser Tweedale and Benjamin Kaduk for suggestions, comments, and Fraser Tweedale, Daniel Kahn Gillmor and Benjamin Kaduk for
corrections on this document. suggestions, comments, and corrections on this document.
Author's Address Author's Address
Alexey Melnikov Alexey Melnikov
Isode Ltd Isode Ltd
14 Castle Mews 14 Castle Mews
Hampton, Middlesex TW12 2NP Hampton, Middlesex TW12 2NP
UK UK
EMail: alexey.melnikov@isode.com EMail: alexey.melnikov@isode.com
 End of changes. 19 change blocks. 
81 lines changed or deleted 107 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/