draft-ietf-acme-email-smime-11.txt   draft-ietf-acme-email-smime-12.txt 
Network Working Group A. Melnikov Network Working Group A. Melnikov
Internet-Draft Isode Ltd Internet-Draft Isode Ltd
Intended status: Informational November 17, 2020 Intended status: Informational November 18, 2020
Expires: May 21, 2021 Expires: May 22, 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-11 draft-ietf-acme-email-smime-12
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 21, 2021. This Internet-Draft will expire on May 22, 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
skipping to change at page 2, line 10 skipping to change at page 2, line 10
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 . . . . . . . . . . . . . . 2
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 . . . . . . . . . . . . . . . . . . 4 3.1. ACME challenge email . . . . . . . . . . . . . . . . . . 5
3.2. ACME response email . . . . . . . . . . . . . . . . . . . 6 3.2. ACME response email . . . . . . . . . . . . . . . . . . . 7
4. Internationalization Considerations . . . . . . . . . . . . . 8 4. Internationalization Considerations . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5.1. ACME Identifier Type . . . . . . . . . . . . . . . . . . 8 5.1. ACME Identifier Type . . . . . . . . . . . . . . . . . . 9
5.2. ACME Challenge Type . . . . . . . . . . . . . . . . . . . 8 5.2. ACME Challenge Type . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
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 47 skipping to change at page 3, line 47
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". See
Section 7.4 of [RFC8555] for more details. 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 "email-
reply-00" challenge as specified in Section 7.5 of [RFC8555]. reply-00" challenge as specified in Section 7.5 of [RFC8555].
The "token" field of the corresponding "challenges" array element The "token" field of the corresponding challenge object (from the
(which contains "type": "email-reply-00" as another field) "challenges" array) contains token-part2. token-part2 should
contains token-part2. token-part2 should contain at least 128 contain at least 128 bits of entropy. The "type" field of the
bits of entropy. 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.
An example Challenge object might look like this:
{
"type": "email-reply-00",
"url": "https://example.com/acme/chall/ABprV_B7yEyA4f",
"from": "acme-challenge+2i211oi1204310@example.com",
"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. The 5. The MUA retrieves and parses the "challenge" email message. If
ACME client concatenates "token-part1" (received over email) and the MUA is ACME-email-aware, it ignores any "challenge" email
"token-part2" (received over HTTPS [RFC2818]) to create the ACME that is not expected, e.g. if there is no ACME certificate
"token", calculates keyAuthorization (as per Section 8.1 of issuance pending. The ACME-email-aware MUA also ignores any
"challenge" email that has the Subject header field which
indicates that it is an email reply, e.g. a subject starting with
the reply prefix "Re:".
6. The ACME client concatenates "token-part1" (received over email)
and "token-part2" (received over HTTPS [RFC2818]) to create the
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 in
the body of a response email message. The response email message the body of a "response" email message. The "response" email
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
"challenge" email more than once.
6. Once the MUA sends the response email, the ACME client can start 7. Once the MUA sends the "response" email, the ACME client notifies
polling the authorization URL (using POST-as-GET requests) to see the ACME server by POST to the challenge URL ("url" field).
if the ACME server received and validated the response email
message. (See Section 7.5.1 of [RFC8555] for more details.) If 8. The ACME client can start polling the authorization URL (using
the "status" field of the challenge switches to "valid", then the POST-as-GET requests) to see if the ACME server received and
ACME client can proceed with request finalization. The validated the "response" email message. (See Section 7.5.1 of
Certificate Signing Request (CSR) MUST indicate the exact same
set of requested identifiers as the initial newOrder request. [RFC8555] for more details.) If the "status" field of the
For an identifier of type "email", the PKCS#10 [RFC2986] CSR MUST challenge switches to "valid", then the ACME client can proceed
contain the requested email address in an extensionRequest with request finalization. The Certificate Signing Request (CSR)
attribute [RFC2985] requesting a subjectAltName extension. If a MUST indicate the exact same set of requested identifiers as the
request to finalize an order is successful, the ACME server will initial newOrder request. For an identifier of type "email", the
return a 200 (OK) with an updated order object. If 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.) If
a request to finalize an order is successful, the ACME server
will return a 200 (OK) with an updated order object. If the
certificate is issued successfully, i.e. if the order "status" is certificate is issued successfully, i.e. if the order "status" is
"valid", then the ACME client can download the issued S/MIME "valid", then the ACME client can download the issued S/MIME
certificate from the URL specified in the "certificate" field. 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
78-octet line length limit in [RFC5322], the subject line can be 78-octet line length limit in [RFC5322], the subject line can be
folded, so whitespaces (if any) within the <token-part1> MUST be folded, so whitespaces (if any) within the <token-part1> MUST be
ignored. [RFC2231] encoding of the message Subject header field ignored. [RFC2231] encoding of the message Subject header field
MUST be supported, and when used, only the "UTF-8" and "US-ASCII" MUST be supported, and when used, only the "UTF-8" and "US-ASCII"
charsets are allowed: other charsets MUST NOT be used. US-ASCII charsets are allowed: other charsets MUST NOT be used. US-ASCII
charset SHOULD be used. charset SHOULD be used.
2. The To header field MUST be the email address of the entity that 2. The From header field MUST be the same email address as specified
in the "from" field of the challange object.
3. The To header field MUST be the email address of the entity that
requested the S/MIME certificate to be generated. requested the S/MIME certificate to be generated.
3. The message MAY contain a Reply-To header field. 4. The message MAY contain a Reply-To and/or CC header fields.
4. The message MUST include the "Auto-Submitted: auto-generated" 5. The message MUST include the "Auto-Submitted: auto-generated"
header field [RFC3834]. To aid in debugging (and in for some header field [RFC3834]. To aid in debugging (and in for some
implementations to make automated processing easier) the "Auto- implementations to make automated processing easier) the "Auto-
Submitted" header field SHOULD include the "type=acme" parameter. Submitted" header field SHOULD include the "type=acme" parameter.
It MAY include other optional parameters as allowed by the syntax It MAY include other optional parameters as allowed by the syntax
of the Auto-Submitted header field. of the Auto-Submitted header field.
5. In order to prove authenticity of a challenge message, it MUST be 6. In order to prove authenticity of a challenge message, it MUST be
signed using either DKIM [RFC6376] or S/MIME [RFC8551]. signed using either DKIM [RFC6376] or S/MIME [RFC8551].
If DKIM signing is used, the resulting DKIM-Signature header If DKIM signing is used, the resulting DKIM-Signature header
field MUST contain the "h=" tag that includes at least "From", field MUST contain the "h=" tag that includes at least "From",
"Sender", "Reply-To", "To", "CC", "Subject", "Date", "In- "Sender", "Reply-To", "To", "CC", "Subject", "Date", "In-
Reply-To", "References", "Message-ID", "Auto-Submitted", Reply-To", "References", "Message-ID", "Auto-Submitted",
"Content-Type", and "Content-Transfer-Encoding" header fields. "Content-Type", and "Content-Transfer-Encoding" header fields.
The domain from the "d=" tag of DKIM-Signature header field The DKIM-Signature header field's "h=" tag SHOULD also include
MUST be the same as the domain from the From header field of "Resent-Date", "Resent-From", "Resent-To", "Resent-Cc", "List-
the challenge email. Id", "List-Help", "List-Unsubscribe", "List-Subscribe", "List-
Post", "List-Owner", "List-Archive" and "List-Unsubscribe-
Post" header fields. The domain from the "d=" tag of DKIM-
Signature header field MUST be the same as the domain from the
From header field of the "challenge" email.
If S/MIME signing is used, the certificate corresponding to If S/MIME signing is used, the certificate corresponding to
the signer MUST have rfc822Name subjectAltName extension with the signer MUST have rfc822Name subjectAltName extension with
the value equal to the From header field email address of the the value equal to the From header field email address of the
challenge email. "challenge" email.
6. The body of the challenge message is not used for automated 7. The body of the challenge message is not used for automated
processing, so it can be any media type. (However there are processing, so it can be any media type. (However there are
extra requirements on S/MIME signing, if used. See below.) extra requirements on S/MIME signing, if used. See below.)
Typically it is text/plain or text/html containing a human- Typically it is text/plain or text/html containing a human-
readable explanation of the purpose of the message. If S/MIME readable explanation of the purpose of the message. If S/MIME
signing is used to prove authenticity of the challenge message, signing is used to prove authenticity of the challenge message,
then the multipart/signed or "application/pkcs7-mime; smime- then the multipart/signed or "application/pkcs7-mime; smime-
type=signed-data;" media type should be used. Either way, it type=signed-data;" media type should be used. Either way, it
MUST use S/MIME header protection. MUST use S/MIME header protection.
An email client compliant with this specification that detects that a An email client compliant with this specification that detects that a
particular challenge email fails validation described above MUST particular "challenge" email fails validation described above MUST
ignore the challenge and thus will not generate any response email. ignore the challenge and thus will not generate any "response" email.
To aid in debugging such failed validations SHOULD be logged. To aid in debugging such failed validations SHOULD be logged.
An example ACME "challenge" email (note that for simplicity DKIM An example ACME "challenge" email (note that for simplicity DKIM
related header fields are not included). related header fields are not included).
Auto-Submitted: auto-generated; type=acme Auto-Submitted: auto-generated; type=acme
Date: Sat, 5 Dec 2020 10:08:55 +0100 Date: Sat, 5 Dec 2020 10:08:55 +0100
Message-ID: <A2299BB.FF7788@example.org> Message-ID: <A2299BB.FF7788@example.org>
From: acme-generator@example.org From: acme-generator@example.org
To: alexey@example.com To: alexey@example.com
skipping to change at page 6, line 31 skipping to change at page 7, line 31
this request automatically, or you might have to paste the first this request automatically, or you might have to paste the first
token part into an external program. token part into an external program.
Figure 1 Figure 1
3.2. ACME response email 3.2. ACME response email
A valid "response" email message MUST have the following structure: A valid "response" email message MUST have the following structure:
1. The message Subject header field is formed as a reply to the ACME 1. The message Subject header field is formed as a reply to the ACME
challenge email (see Section 3.1). Its syntax is the same as "challenge" email (see Section 3.1). Its syntax is the same as
that of the challenge message except that it may be prefixed by a that of the challenge message except that it may be prefixed by a
US-ASCII reply prefix (typically "Re:") and folding white space US-ASCII reply prefix (typically "Re:") and folding white space
(FWS, see [RFC5322]), as is normal in reply messages. When (FWS, see [RFC5322]), as is normal in reply messages. When
parsing the subject, ACME servers MUST decode [RFC2231] encoding parsing the subject, ACME servers MUST decode [RFC2231] encoding
(if any) and then they can ignore any prefix before the "ACME:" (if any) and then they can ignore any prefix before the "ACME:"
label. label.
2. The From: header field contains the email address of the user 2. The From: header field contains the email address of the user
that is requesting S/MIME certificate issuance. that is requesting S/MIME certificate issuance.
skipping to change at page 7, line 39 skipping to change at page 8, line 39
8. There is no need to use any Content-Transfer-Encoding other than 8. There is no need to use any Content-Transfer-Encoding other than
7bit for the text/plain body part. Use of Quoted-Printable or 7bit for the text/plain body part. Use of Quoted-Printable or
base64 in a "response" email message is not necessary and should base64 in a "response" email message is not necessary and should
be avoided, though it is permitted. be avoided, though it is permitted.
9. In order to prove authenticity of a response message, it MUST be 9. In order to prove authenticity of a response message, it MUST be
DKIM [RFC6376] signed. The resulting DKIM-Signature header field DKIM [RFC6376] signed. The resulting DKIM-Signature header field
MUST contain the "h=" tag that includes at least "From", MUST contain the "h=" tag that includes at least "From",
"Sender", "Reply-To", "To", "CC", "Subject", "Date", "In-Reply- "Sender", "Reply-To", "To", "CC", "Subject", "Date", "In-Reply-
To", "References", "Message-ID", "Content-Type", and "Content- To", "References", "Message-ID", "Content-Type" and "Content-
Transfer-Encoding" header fields. The domain from the "d=" tag Transfer-Encoding" header fields. The DKIM-Signature header
of DKIM-Signature header field MUST be the same as the domain field's "h=" tag SHOULD also include "Resent-Date", "Resent-
from the From header field of the response email. From", "Resent-To", "Resent-Cc", "List-Id", "List-Help", "List-
Unsubscribe", "List-Subscribe", "List-Post", "List-Owner", "List-
Archive" and "List-Unsubscribe-Post" header fields. The domain
from the "d=" tag of DKIM-Signature header field MUST be the same
as the domain from the From header field of the "response" email.
Example ACME "response" email (note that for simplicity DKIM related Example ACME "response" email (note that for simplicity DKIM related
header fields are not included). header fields are not included).
Date: Sat, 5 Dec 2020 12:01:45 +0100 Date: Sat, 5 Dec 2020 12:01:45 +0100
Message-ID: <111-22222-3333333@example.com> Message-ID: <111-22222-3333333@example.com>
In-Reply-To: <A2299BB.FF7788@example.org> In-Reply-To: <A2299BB.FF7788@example.org>
From: alexey@example.com From: alexey@example.com
To: acme-generator@example.org To: acme-generator@example.org
Subject: Re: ACME: LgYemJLy3F1LDkiJrdIGbEzyFJyOyf6vBdyZ1TG3sME= Subject: Re: ACME: LgYemJLy3F1LDkiJrdIGbEzyFJyOyf6vBdyZ1TG3sME=
skipping to change at page 10, line 20 skipping to change at page 11, line 20
it easy to spoof DNS records affecting email system. However use of it easy to spoof DNS records affecting email system. However use of
DNSSEC is not ubiquitous at the time of publishing of this document, DNSSEC is not ubiquitous at the time of publishing of this document,
so it is not required here. Also, many existing systems that rely on so it is not required here. Also, many existing systems that rely on
verification of ownership of an email address, for example 2 factor verification of ownership of an email address, for example 2 factor
authentication systems used by banks or traditional certificate authentication systems used by banks or traditional certificate
issuance systems send email messages to email addresses, expecting issuance systems send email messages to email addresses, expecting
the owner to click on the link supplied in them (or to reply to a the owner to click on the link supplied in them (or to reply to a
message), without requiring use of DNSSEC. So the risk of not message), without requiring use of DNSSEC. So the risk of not
requiring DNSSEC is presumed acceptable in this document. requiring DNSSEC is presumed acceptable in this document.
An ACME email challenge message can be forged by an attacker. As per
requirements on an ACME-email-aware MUA specified in Section 3, the
MUA will not respond to requests it is not expecting. Even if the
attacker causes the erroneous "response" email to go to an attacker-
controlled email address, very little information is leaked -- the
SHA-256 hash of the key authorization, not the key authorization
itself, so no parts of the token or the the account key thumbprint
are leaked.
An attacker that can read the "response" email has only one chance to
guess the token-part2. Even if the attacker can guess it right, it
still needs to know the ACME account key to be able to make use of
the intercepted SHA-256 hash of the key authorization.
Also see Security Considerations section of [RFC6376] for details on Also see Security Considerations section of [RFC6376] for details on
how DKIM depends on the DNS and the respective vulnerabilities this how DKIM depends on the DNS and the respective vulnerabilities this
dependence has. dependence has.
7. References 7. References
7.1. Normative References 7.1. Normative References
[FIPS180-4] [FIPS180-4]
National Institute of Standards and Technology, "Secure National Institute of Standards and Technology, "Secure
 End of changes. 20 change blocks. 
56 lines changed or deleted 109 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/