Extensions to Automatic Certificate Management Environment for end user S/MIME certificates
Isode Ltd14 Castle MewsHamptonMiddlesexTW12 2NPUKalexey.melnikov@isode.comACME
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.
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.
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
. defines "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 (all ASCII) email address or Internationalized Email addresses .
This can be used with S/MIME or other similar service that requires posession of a certificate tied to an email address.
Any identifier of type "email" in a new-order 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:
ACME server generates a "challenge" email message with the subject "ACME: <token-part1>",
where <token-part1> is the base64url encoded first part of the token,
which contains at least 64 bit of entropy. The challenge email message structure
is described in more details in .
The second part of the token (token-part2,
which also contains at least 64 bit of entropy) is returned over HTTPS to the ACME client.
ACME client concatenates "token-part1" and "token-part2" to create "token", calculates
key-authz (as per Section 8.1 of ),
then includes the base64url encoded SHA-256 digest
of the key authorization in the body of a response email message containing
a single text/plain MIME body part .
The response email message structure
is described in more details in
For an identifier of type "email", CSR MUST contain the request email address in an extensionRequest
attribute requesting a subjectAltName extension. (These
identifiers may appear in any sort order.)
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 at least one SP or TAB character.
<token-part1> is the base64url encoded first part of the ACME token.
The message MUST include the "Auto-Submitted: auto-generated" header field .
It MAY include optional parameters as allowed by syntax of Auto-Submitted header field.
The message MUST have a single text/plain MIME body part ,
that contains human readable explanation of the purpose of the message.
A "response" email message MUST have the following structure:
The message Subject header field has the following syntax: "Re: ACME: <token-part1>",
where the prefix "ACME:" is followed by at least one SP or TAB character.
<token-part1> is the base64url encoded first part of the ACME token.
The To: header field of the response contains the value from the From: header field of the challenge email.
The message MUST have a single text/plain MIME body part ,
containing base64url encoded SHA-256 digest
of the key authorization. Note that due to historic line length limitations
in email, line endings (CRLFs) can be freely inserted in the middle of the encoded digest,
so they need to be ignored when processing it.
[[This section should be empty before publication]]
Do we need to handle text/html or multipart/alternative in email challenge? Simplicity suggests "no".
However, for automated processing it might be better to use at least multipart/mixed with a special MIME type.
Define a new parameter to "Auto-Submitted: auto-generated", so that it is easier to figure out
that a particilar message is an ACME challenge message?
IANA is requested to register a new Identifier Type "email" which corresponds to an (all ASCII) email address
or Internationalized Email addresses .
And finally, IANA is requested to register the following ACME challenge types that are used with Identifier Type "email":
"email-reply". The reference for it is this document.
TBD.
Automatic Certificate Management Environment (ACME)
Certificates in PKI using X.509 (PKIX) are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certificate authorities in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. Today, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a certification authority (CA) and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation.
Secure Hash Standard (SHS)National Institute of Standards and Technology