Extensions to Automatic Certificate Management Environment for end user S/MIME certificates
Isode Ltd
14 Castle Mews
Hampton
Middlesex
TW12 2NP
UK
Alexey.Melnikov@isode.com
ACME
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.
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:
[[Very rough outline follows]]
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 MUST have
a single text/plain MIME body part .
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 .
[[This section should be empty before publication]]
Do we need to handle text/html or multipart/alternative in email challenge? Simplicity suggests "no".
Do we need a proof that ACME client can submit email on behalf of the user,
not just read the challenge using IMAP? Alexey: probably yes, because intercepting somebody's
email is easier than generating email on the user's behalf.
IANA is requested to register a new Identifier Type "email" which corresponds to an (all ASCII) email address .
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.
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