Extensions to Automatic Certificate Management Environment for end-user S/MIME certificates
Isode Ltd14 Castle MewsHamptonMiddlesexTW12 2NPUKalexey.melnikov@isode.comACMES/MIME
This document specifies identifiers and challenges required to enable
the Automated Certificate Management Environment (ACME) to issue
certificates for use by email users
that want to use S/MIME.
ACME is a mechanism for automating certificate
management on the Internet. It enables administrative entities to
prove effective control over resources like domain names, and
automates the process of generating and issuing certificates.
This document describes an extension to ACME for use by S/MIME.
defines extensions for issuing end-user S/MIME certificates.
This document aims to support both:
A Mail User Agent (MUA) which has built in ACME client aware of the extension described in this document. (We will call such ACME clients "ACME-email-aware")
Such MUA can present nice User Interface to the user and automate certificate issuance.A MUA which is not ACME aware, with a separate ACME client implemented in a command line tool or as a part of a website.
While S/MIME certificate issuance is not going to be as painless as in the case of the ACME-email-aware MUA,
the extra burden on a user is going to be minimal.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in
.
ACME defines a "dns" Identifier Type that is used to verify that a particular entity
has control over a domain or specific service associated with the domain.
In order to be able to issue end-user S/MIME certificates, ACME needs a new Identifier Type that
proves ownership of an email address.
This document defines a new Identifier Type "email" which corresponds to an email address.
The address can be all ASCII or internationalized ;
when an internationalized email address is used, the domain part can contain both U-labels and A-labels .
This can be used with S/MIME or other similar service that requires possession of a certificate tied to an email address.
Any identifier of type "email" in a newOrder request MUST NOT have a wildcard ("*") character in its value.
A new challenge type "email-reply-00" is used with "email" Identifier Type,
which provides proof that an ACME client has control over an email address.
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 not ACME-email-aware) or can be a component of the MUA.
An end-user initiates issuance of an S/MIME certificate for one of her email addresses.
This might be done using email client UI, by running a command line tool, by
visiting a Certificate Authority web page, etc.
This document doesn't prescribe specific UI
used to initiate S/MIME certificate issuance or where the ACME client is located.
The ACME-email-aware client component begins the certificate issuance process by sending a POST
request to the server's newOrder resource, including the identifier of type "email".
See Section 7.4 of for more details.
The ACME server
responds to the POST request, including an "authorizations" URL for the requested email address.
The ACME client then retrieves information about the corresponding "email-reply-00" challenge
as specified in Section 7.5 of .
The "token" field of the corresponding "challenges" array element (which contains "type": "email-reply-00"
as another field) contains token-part2. token-part2 should contain at least 128 bits of entropy.
After responding to the authorization request the ACME server
generates another token and a "challenge" email message with the subject "ACME: <token-part1>",
where <token-part1> is the base64url encoded form of the token.
The ACME server MUST generate a fresh token for each S/MIME issuance request (authorization request),
and token-part1 MUST contain at least 128 bits of entropy.
The challenge email message structure is described in more details in .
The MUA retrieves and parses the challenge email message.
The ACME client concatenates "token-part1" (received over email) and "token-part2" (received over HTTPS ) to create the ACME "token", calculates
keyAuthorization (as per Section 8.1 of ),
then returns the base64url encoded SHA-256 digest of the key authorization.
The MUA returns the base64url encoded SHA-256 digest obtained from the ACME client
in the body of a response email message. The response email message structure
is described in more details in .
Once the MUA sends the response email, the ACME client can start polling the authorization URL
(using POST-as-GET requests) to see if the ACME server received and validated the response email message.
(See Section 7.5.1 of 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
CSR MUST contain the requested email address in an extensionRequest
attribute requesting a subjectAltName extension.
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 "valid", then the ACME client can download the issued S/MIME certificate
from the URL specified in the "certificate" field.
A "challenge" email message MUST have the following structure:
The message Subject header field has the following syntax: "ACME: <token-part1>",
where the prefix "ACME:" is followed by folding white space (FWS, see )
and then by <token-part1>, which is the base64url encoded first part of the ACME token
that MUST be at least 128 bits long after decoding.
Due to the recommended 78-octet line length limit
in , the subject line can be folded, so whitespaces (if any) within
the <token-part1> MUST be ignored. encoding of the message Subject header field MUST be supported,
and when used, only the "UTF-8" and "US-ASCII" charsets are allowed: other charsets MUST NOT be used. US-ASCII charset SHOULD be used.
The To header field MUST be the email address of the entity that requested the S/MIME certificate to be generated.The message MAY contain a Reply-To header field.
The message MUST include the "Auto-Submitted: auto-generated" header field .
To aid in debugging (and in for some implementations to make automated processing easier) the "Auto-Submitted" header field SHOULD include the "type=acme" parameter.
It MAY include other optional parameters as allowed by the syntax of the Auto-Submitted header field.
In order to prove authenticity of a challenge message, it MUST be signed using either DKIM
or S/MIME .
If DKIM signing is used, the resulting DKIM-Signature header field MUST contain the "h=" tag that includes
at least "From", "Sender", "Reply-To", "To", "CC", "Subject", "Date", "In-Reply-To", "References",
"Message-ID", "Auto-Submitted", "Content-Type", and "Content-Transfer-Encoding" 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 the signer MUST have rfc822Name subjectAltName extension
with the value equal to the From header field email address of the challenge email.
The body of the challenge message is not used for automated processing, so it can be any media type.
(However there are extra requirements on S/MIME signing, if used. See below.)
Typically it is text/plain or text/html containing a human-readable explanation of the purpose of the message.
If S/MIME signing is used to prove authenticity of the challenge message,
then the multipart/signed or "application/pkcs7-mime; smime-type=signed-data;" media type should be used.
Either way, it MUST use S/MIME header protection.
An email client compliant with this specification that detects that a particular challenge email
fails validation described above MUST ignore the challenge and thus will not generate any response email.
To aid in debugging such failed validations SHOULD be logged.
A valid "response" email message MUST have the following structure:
The message Subject header field is formed as a reply to the ACME challenge email
(see ).
Its syntax is the same as that of the challenge message except that it may be prefixed
by a US-ASCII reply prefix (typically "Re:") and folding white
space (FWS, see ), as is normal in reply messages. When
parsing the subject, ACME servers MUST decode encoding (if any) and
then they can ignore any prefix before the "ACME:" label.
The From: header field contains the email address of the user that is requesting S/MIME certificate issuance.The To: header field of the response contains the value from the Reply-To: header field from the challenge message (if set)
or from the From: header field of the challenge message otherwise.The Cc: header field is ignored if present in the "response" email message.The In-Reply-To: header field SHOULD be set to the Message-ID header field of the challenge message
according to rules in Section 3.6.4 of .List-* header fields MUST be absent (i.e., the reply can't come from a mailing list)
The media type of the "response" email message is either text/plain or multipart/alternative containing
text/plain as one of the alternatives. (Note that the requirement to support multipart/alternative is to allow use of ACME-unaware MUAs
which can't always generate pure text/plain, e.g. if they reply to a text/html).
The text/plain body part (whether or not it is inside multipart/alternative)
MUST contain a block of lines starting with the line "-----BEGIN ACME RESPONSE-----", followed by one
or more line containing the base64url-encoded SHA-256 digest
of the key authorization, calculated from concatenated token-part1 (received over email)
and token-part2 (received over HTTPS), as outlined in the 5th bullet in .
(Note that each line of text/plain is terminated by CRLF. Bare LFs or bare CRs are not allowed.)
Due to historical line length limitations in email, line endings (CRLFs)
can be freely inserted in the middle of the encoded digest,
so they MUST be ignored when processing it.) The final line of the encoded digest
is followed by a line containing "-----END ACME RESPONSE-----".
Any text before and after this block is ignored. For example such text might explain what
to do with it for ACME-unaware clients.
There is no need to use any Content-Transfer-Encoding other than 7bit for the text/plain body part.
Use of Quoted-Printable or base64 in a "response" email message is not necessary and should be avoided,
though it is permitted.
In order to prove authenticity of a response message, it MUST be DKIM
signed. The resulting DKIM-Signature header field MUST contain the "h=" tag that includes
at least "From", "Sender", "Reply-To", "To", "CC", "Subject", "Date", "In-Reply-To", "References",
"Message-ID", "Content-Type", and "Content-Transfer-Encoding" 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.
updated/clarified use of DKIM with Internationalized Email addresses .
Please consult RFC 8616 in regards to any changes that need to be implemented.
Use of non ASCII characters in left hand sides of Internationalized Email addresses requires putting
Internationalized Email Addresses in X.509 Certificates .
IANA is requested to register a new Identifier type in the "ACME Identifier Types" registry
defined in Section 9.7.7 of with Label "email" and a Reference to [RFCXXXX],
and .
The new Identifier Type corresponds to an (all ASCII) email address
or Internationalized Email addresses .
IANA is also requested to register a new entry in the "ACME Validation Methods" registry
defined in Section 9.7.8 of .
This entry is as follows:
LabelIdentifier TypeACMEReferenceemail-reply-00emailY[RFCXXXX]
Please see Security Considerations of for general security considerations
related to use of ACME. This challenge/response protocol demonstrates that an entity that controls
the private key (corresponding to the public key in the certificate) also controls the named email
account.
The ACME server is confirming that the requested email address
belongs to the entity that requested the certificate, but this
makes no claim to correctness or fitness-for-purpose of the
address. It such claims are needed they must be obtained by
some other mechanism.
The security of the "email-reply-00" challenge type depends on the security of the email system.
A third party that can read and reply to user's email messages (by possessing a user's password
or a secret derived from it that can give read and reply access, such as "password equivalent" information;
or by being given permissions to act on a user's behalf using email delegation feature common
in some email systems) can request S/MIME certificates using the protocol specified in this document
and is indistinguishable from the email account owner.
This has several possible implications:
an entity that compromised an email account would be able to request S/MIME certificates
using the protocol specified in this document and such entity couldn't be distinguished from
the legitimate email account owner (unless some external sources of information are consulted);for email addresses with legitimate shared access/control by multiple users, any such user
would be able to request S/MIME certificates using the protocol specified in this document
and such requests can't be attributed to a specific user without consulting external systems
(such as IMAP/SMTP access logs);the protocol specified in this document is not suitable for use with email addresses
associated with mailing lists . While it is not always
possible to guarantee that a particular S/MIME certificate request is not from a mailing list
address, prohibition on inclusion of List-* header fields helps Certificate Issuers
to handle most common cases.
An email system in its turn depends on DNS. A third party that can manipulate DNS MX records
for a domain might be able to redirect email and can get (at least temporary) read and reply access to it.
Similar considerations apply to DKIM TXT records in DNS.
Use of DNSSEC by email system administrators is recommended to avoid making it easy to spoof
DNS records affecting email system. However use of 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 verification of ownership of an email address,
for example 2 factor authentication systems used by banks or traditional certificate issuance
systems send email messages to email addresses, expecting 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 requiring
DNSSEC is presumed acceptable in this document.
Also see Security Considerations section of for details on how DKIM depends
on the DNS and the respective vulnerabilities this dependence has.
Secure Hash Standard (SHS)National Institute of Standards and TechnologyThank you to Andreas Schulze, Gerd v. Egidy, James A. Baker, Ben Schwartz,
Peter Yee, Hilarie Orman, Michael Jenkins, Barry Leiba, Fraser Tweedale and Benjamin Kaduk
for suggestions, comments, and corrections on this document.