Diff: rfc8823xml2.original.xml

	rfc8823xml2.original.xml	rfc8823.xml

	<?xml version="1.0" encoding="US-ASCII"?>	<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd">	<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
	<?rfc toc="yes"?>
	<?rfc rfcedstyle="yes"?>
	<?rfc subcompact="no"?>
	<?rfc symrefs="yes"?>
	<?rfc comments="yes" ?>
	<?rfc inline="yes" ?>


	<rfc ipr="trust200902" category="info" docName='draft-ietf-acme-email-smime-14'>	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
		-ietf-acme-email-smime-14" number="8823" obsoletes="" updates="" submissionType=
		"IETF" category="info" consensus="true" xml:lang="en" tocInclude="true" symRefs=
		"true" sortRefs="true" version="3">

		<!-- xml2rfc v2v3 conversion 3.5.0 -->
	<front>	<front>
	<title abbrev="ACME for S/MIME">	<title abbrev="ACME for S/MIME">

	Extensions to Automatic Certificate Management Environment for end-user S/ MIME certificates	Extensions to Automatic Certificate Management Environment for End-User S/ MIME Certificates
	</title>	</title>

		<seriesInfo name="RFC" value="8823"/>
	<author initials="A." surname="Melnikov" fullname="Alexey Melnikov">	<author initials="A." surname="Melnikov" fullname="Alexey Melnikov">
	<organization>Isode Ltd</organization>	<organization>Isode Ltd</organization>
	<address>	<address>
	<postal>	<postal>

	<street>14 Castle Mews</street>	<street>14 Castle Mews</street>
	<city>Hampton</city>	<city>Hampton, Middlesex</city>
	<region>Middlesex</region>	<code>TW12 2NP</code>
	<code>TW12 2NP</code>	<country>United Kingdom</country>
	<country>UK</country>
	</postal>	</postal>

	<email>alexey.melnikov@isode.com</email>	<email>alexey.melnikov@isode.com</email>
	</address>	</address>
	</author>	</author>

		<date year="2021" month="April" />
	<date year="2021" />

	<keyword>ACME</keyword>	<keyword>ACME</keyword>
	<keyword>S/MIME</keyword>	<keyword>S/MIME</keyword>


	<abstract>	<abstract>

		<t>
	<t>
	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	certificates for use by email users
	that want to use S/MIME.	that want to use S/MIME.

	</t>	</t>

	</abstract>	</abstract>


	</front>	</front>
	<middle>	<middle>

		<section numbered="true" toc="default">
	<section title="Introduction">	<name>Introduction</name>
		<t>
	<t>	ACME <xref target="RFC8555" format="default"/> is a mechanism for automa
	ACME <xref target="RFC8555"/> is a mechanism for automating certificate	ting certificate
	management on the Internet. It enables administrative entities to	management on the Internet. It enables administrative entities to

	prove effective control over resources like domain names, and	prove effective control over resources like domain names, and it
	automates the process of generating and issuing certificates.	automates the process of generating and issuing certificates.

	</t>	</t>
		<t>
	<t>
	This document describes an extension to ACME for use by S/MIME.	This document describes an extension to ACME for use by S/MIME.

	<xref target="smime"/> defines extensions for issuing end-user S/MIME <x	<xref target="smime" format="default"/> defines extensions for issuing e
	ref target="RFC8550"/> certificates.	nd-user S/MIME <xref target="RFC8550" format="default"/> certificates.
	</t>	</t>
		<t>
	<t>	This document aims to support both:</t>
	This document aims to support both:	<ol spacing="normal" type="1">
		<li>A Mail User Agent (MUA) that has a built-in ACME client that is aware
	<list style='numbers'>	of the extension described in this document. (We will call such MUAs "ACM
	<t>A Mail User Agent (MUA) which has built-in ACME client which is a	E-email-aware".)
	ware of the extension described in this document. (We will call such MUAs "ACME-	Such an MUA can present a nice user interface to the user and automate ce
	email-aware".)	rtificate issuance.</li>
	Such MUA can present nice User Interface to the user and automate	<li>An MUA that is not ACME aware, with a separate ACME client implement
	certificate issuance.</t>	ed in a command-line tool or as a part of a website. While S/MIME certificate is
		suance is not going to
	<t>A MUA which is not ACME aware, with a separate ACME client implem	be as painless as in the case of the ACME-email-aware MUA, the extra burd
	ented in a command line tool or as a part of a website.	en on a user is
	While S/MIME certificate issuance is not going to be as painless	going to be minimal.</li>
	as in the case of the ACME-email-aware MUA,	</ol>
	the extra burden on a user is going to be minimal.</t>

	</list>
	</t>

	<!--
	<t>
	</t>
	-->

	</section>	</section>

		<section numbered="true" toc="default">
	<section title="Conventions Used in This Document">	<name>Conventions Used in This Document</name> <t>
		The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",	IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
	this document are to be interpreted as described in	RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	<xref target="RFC2119"/>.</t>	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
		be interpreted as
		described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
		when, and only when, they appear in all capitals, as shown here.
		</t>
	</section>	</section>

		<section anchor="smime" numbered="true" toc="default">
	<section title="Use of ACME for issuing end-user S/MIME certificates" anchor	<name>Use of ACME for Issuing End-User S/MIME Certificates</name>
	="smime">

	<t>	<t>

	ACME <xref target="RFC8555"/> defines a "dns" Identifier Type that is used to verify that a particular entity	ACME <xref target="RFC8555" format="default"/> 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.	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 ne w Identifier Type that	In order to be able to issue end-user S/MIME certificates, ACME needs a ne w identifier type that
	proves ownership of an email address.	proves ownership of an email address.
	</t>	</t>


	<t>	<t>

	This document defines a new Identifier Type "email" which corresponds to a	This document defines a new identifier type, "email", which corresponds to
	n email address.	an email address.
	The address can be all ASCII <xref target="RFC5321"/> or internationalized	The address can be all ASCII <xref target="RFC5321" format="default"/> or
	<xref target="RFC6531"/>;	internationalized <xref target="RFC6531" format="default"/>;
	when an internationalized email address is used, the domain part can conta	when an internationalized email address is used, the domain part can conta
	in both U-labels and A-labels <xref target="RFC5890"/>.	in both U-labels and A-labels <xref target="RFC5890" format="default"/>.
	This can be used with S/MIME or other similar service that requires posses	This can be used with S/MIME or another similar service that requires poss
	sion of a certificate tied to an email address.	ession of a certificate tied to an email address.
	</t>	</t>


	<t>	<t>

	Any identifier of type "email" in a newOrder request MUST NOT have a wildc ard ("*") character in its value.	Any identifier of type "email" in a newOrder request <bcp14>MUST NOT</bcp1 4> have a wildcard ("*") character in its value.
	</t>	</t>


	<t>	<t>

	A new challenge type "email-reply-00" is used with "email" Identifier Type ,	A new challenge type, "email-reply-00", is used with the "email" identifie r type,
	which provides proof that an ACME client has control over an email address .	which provides proof that an ACME client has control over an email address .
	</t>	</t>


	<!--///Alexey: Describe how the process described below is updated
	if multiple email addresses are specified in a single newOrder request!-->

	<t>	<t>

	The process of issing an S/MIME certificate works as follows. Note that th e ACME client can be a standalone	The process of issuing an S/MIME certificate works as follows. Note that t he ACME client can be a standalone
	application (if the MUA is not ACME-email-aware) or can be a component of the MUA.	application (if the MUA is not ACME-email-aware) or can be a component of the MUA.

	<list style='numbers'>	</t>
		<ol spacing="normal" type="1">
	<t>An end-user initiates issuance of an S/MIME certificate for one of	<li>An end user initiates issuance of an S/MIME certificate for one of th
	her email addresses.	eir email addresses.
	This might be done using email client UI, by running a command line to	This might be done by using an email client UI, by running a command-l
	ol, by	ine tool, by
	visiting a Certificate Authority web page, etc.	visiting a certificate authority web page, etc.
	<!--The following might not actually work: or by sending an email to a	This document doesn't prescribe a specific UI
	well known
	Certificate Authority's email address--> This document doesn't prescri
	be specific UI
	used to initiate S/MIME certificate issuance or where the ACME client is located.	used to initiate S/MIME certificate issuance or where the ACME client is located.

	</t>	</li>
		<li>
	<t>
	The ACME-email-aware client component begins the certificate issuance process by sending a POST	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".	request to the server's newOrder resource, including the identifier of type "email".

	See Section 7.4 of <xref target='RFC8555'/> for more details.	See <xref target="RFC8555" sectionFormat="of" section="7.4"/> for more
	</t>	details.
		</li>
		<li>
	<t>	<t>

	The ACME server<!--(run by the Certificate Authority or their authoriz ed third party)-->	The ACME server
	responds to the POST request, including an "authorizations" URL for th e requested email address.	responds to the POST request, including an "authorizations" URL for th e requested email address.

	The ACME client then retrieves information about the corresponding "em	The ACME client then retrieves information about the corresponding "em
	ail-reply-00" challenge	ail-reply-00" challenge,
	as specified in Section 7.5 of <xref target='RFC8555'/>.	as specified in <xref target="RFC8555" sectionFormat="of" section="7.5
		"/>.
	The "token" field of the corresponding challenge object (from the "cha llenges" array)	The "token" field of the corresponding challenge object (from the "cha llenges" array)
	contains token-part2. token-part2 should contain at least 128 bits of entropy.	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 chal lenge object	The "type" field of the challenge object is "email-reply-00". The chal lenge object

	<!--///Also say something about unique from email address per challeng e?-->
	also contains the "from" field, with the email address that would be u sed in the From header field	also contains the "from" field, with the email address that would be u sed in the From header field
	of the "challenge" email message (see the next step).	of the "challenge" email message (see the next step).

		</t>
	<list style="empty">	<t>An example challenge object might look like this:</t>
		<sourcecode type=""><![CDATA[
	<t>
	<figure><artwork>
	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"
	}	}

	</artwork></figure>	]]></sourcecode>
	</t>	</li>
		<li>
	</list>	After responding to the authorization request, the ACME server

	</t>

	<t>
	After responding to the authorization request the ACME server
	generates another token and a "challenge" email message with the subje ct "ACME: <token-part1>",	generates another token and a "challenge" email message with the subje ct "ACME: <token-part1>",

	where <token-part1> is the base64url encoded <xref target="RFC46	where <token-part1> is the base64url-encoded <xref target="RFC46
	48"/> form of the token.	48" format="default"/> form of the token.
	The ACME server MUST generate a fresh token for each S/MIME issuance r	The ACME server <bcp14>MUST</bcp14> generate a fresh token for each S/
	equest (authorization request),	MIME issuance request (authorization request),
	and token-part1 MUST contain at least 128 bits of entropy.	and token-part1 <bcp14>MUST</bcp14> contain at least 128 bits of entro
	The "challenge" email message structure is described in more details i	py.
	n <xref target="acme-smime-challenge-email"/>.	The "challenge" email message structure is described in more details i
	</t>	n <xref target="acme-smime-challenge-email" format="default"/>.
		</li>
	<t>	<li>
	The MUA retrieves and parses the "challenge" email message.	The MUA retrieves and parses the "challenge" email message.

	If the MUA is ACME-email-aware, it ignores any "challenge" email that is not expected,	If the MUA is ACME-email-aware, it ignores any "challenge" email that is not expected,

	e.g. if there is no ACME certificate issuance pending.	e.g., if there is no ACME certificate issuance pending.
	The ACME-email-aware MUA also ignores any "challenge" email that has t he Subject header field	The ACME-email-aware MUA also ignores any "challenge" email that has t he Subject header field

	which indicates that it is an email reply, e.g. a subject starting wit	that indicates that it is an email reply, e.g., a subject starting wit
	h the reply prefix "Re:".	h the reply prefix "Re:".
	</t>	</li>
		<li>
	<t>
	The ACME client concatenates "token-part1" (received over email) and " token-part2"	The ACME client concatenates "token-part1" (received over email) and " token-part2"

	(received over HTTPS <xref target="RFC2818"/>) to create the ACME "tok	(received over HTTPS <xref target="RFC2818" format="default"/>) to cre
	en", calculates	ate the ACME "token" and calculates
	keyAuthorization (as per Section 8.1 of <xref target="RFC8555"/>),	keyAuthorization (as per <xref target="RFC8555" sectionFormat="of" sec
	then returns the base64url encoded SHA-256 digest <xref target="FIPS18	tion="8.1"/>).
	0-4"/> of the key authorization.	Then, it returns the base64url-encoded SHA-256 digest <xref target="RF
	The MUA returns the base64url encoded SHA-256 digest obtained from the	C6234" format="default"/> of the key authorization.
	ACME client	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 messag e structure	in the body of a "response" email message. The "response" email messag e structure

	is described in more details in <xref target="acme-smime-response-emai	is described in more details in <xref target="acme-smime-response-emai
	l"/>.	l" format="default"/>.
	If the MUA is ACME-email-aware, it MUST NOT respond to the same "chall	If the MUA is ACME-email-aware, it <bcp14>MUST NOT</bcp14> respond to
	enge" email more than once.	the same "challenge" email more than once.
	</t>	</li>
		<li>
	<t>
	Once the MUA sends the "response" email, the ACME client notifies the ACME server	Once the MUA sends the "response" email, the ACME client notifies the ACME server
	by POST to the challenge URL ("url" field).	by POST to the challenge URL ("url" field).

	</t>	</li>
		<li>
	<t>
	The ACME client can start polling the authorization URL	The ACME client can start polling the authorization URL

	(using POST-as-GET requests) to see if the ACME server received and va	(using POST-as-GET requests) to see if the ACME server received and va
	lidated the "response" email message.	lidated the "response" email message. (See <xref target="RFC8555" sectionFormat=
	(See Section 7.5.1 of <xref target="RFC8555"/> for more details.)	"of" section="7.5.1"/> for more details.)

	If the "status" field of the challenge switches to "valid",	If the "status" field of the challenge switches to "valid",
	then the ACME client can proceed with request finalization.	then the ACME client can proceed with request finalization.

	The Certificate Signing Request (CSR) MUST indicate the exact same	The Certificate Signing Request (CSR) <bcp14>MUST</bcp14> indicate the exact same
	set of requested identifiers as the initial newOrder request.	set of requested identifiers as the initial newOrder request.

	For an identifier of type "email", the PKCS#10 <xref target="RFC2986"/	For an identifier of type "email", the PKCS#10 <xref target="RFC2986"
	>	format="default"/>
	CSR MUST contain the requested email address <!--either in the commonN	CSR <bcp14>MUST</bcp14> contain the requested email address in an exte
	ame	nsionRequest
	portion of the requested subject name, or--> in an extensionRequest	attribute <xref target="RFC2985" format="default"/> requesting a subje
	attribute <xref target="RFC2985"/> requesting a subjectAltName extensi	ctAltName extension.
	on.	The email address <bcp14>MUST</bcp14> also match the From header field
	Such email address MUST also match the From header field value of the	value of the "response" email message.
	"response" email message.	</li>
	</t>	<li>
		In order to request generation of signing-only or encryption-only S/MI
	<t>	ME certificates
	In order to request generation of signing only or encryption only S/MI
	ME certificates
	(as opposed to requesting generation of S/MIME certificates suitable f or both),	(as opposed to requesting generation of S/MIME certificates suitable f or both),

	the CSR needs to include the key usage extension (see Section 4.4.2 of	the CSR needs to include the key usage extension (see <xref target="RF
	<xref target="RFC8550"/>.	C8550" sectionFormat="of" section="4.4.2"/>).
	This is described in more details in <xref target="acme-smime-sign-or-	This is described in more details in <xref target="acme-smime-sign-or-
	encrypt-only"/>.	encrypt-only" format="default"/>.
	</t>	</li>
		<li>
	<t>
	If a request to finalize an order is successful, the ACME server will	If a request to finalize an order is successful, the ACME server will
	return a 200 (OK) with an updated order object.	return a 200 (OK) with an updated order object.

	<!--///Add text about downloading the certificate?-->	If the certificate is issued successfully, i.e., if the order "status"

	If the certificate is issued successfully, i.e. if the order "status"
	is "valid", then the ACME client can download the issued S/MIME certif icate	is "valid", then the ACME client can download the issued S/MIME certif icate
	from the URL specified in the "certificate" field.	from the URL specified in the "certificate" field.

	</t>	</li>
		</ol>
	</list>	<section anchor="acme-smime-challenge-email" numbered="true" toc="default"
	</t>	>
		<name>ACME "Challenge" Email</name>
	<!--
	On receiving a response, the server constructs and stores the key
	authorization from the challenge "token" value and the current client
	account key.

	To validate a DNS challenge, the server performs the following steps:

	1. Compute the SHA-256 digest [FIPS180-4] of the stored key
	authorization

	2. Query for TXT records for the validation domain name

	3. Verify that the contents of one of the TXT records match the
	digest value

	If all of the above verifications succeed, then the validation is
	successful. If no DNS record is found, or DNS record and response
	payload do not pass these checks, then the validation fails.

	<!--
	<figure title="Figure 1">
	<preamble>
	For example, if the ACME client were to respond to the "email-reply-00
	" challenge,
	it would send the following request to the ACME server:
	</preamble>
	<artwork><![CDATA[
	POST /acme/authz/asdf/0 HTTP/1.1
	Host: example.com
	Content-Type: application/jose+json

	{
	"protected": base64url({
	"alg": "ES256",
	"kid": "https://example.com/acme/acct/1",
	"nonce": "Q_s3MWoqT05TrdkM2MTDcw",
	"url": "https://example.com/acme/authz/asdf/0"
	}),
	"payload": base64url({
	"type": "email-reply-00",
	"keyAuthorization": "IlirfxKKXA...vb29HhjjLPSggQiE"
	}),
	"signature": "7cbg5JO1Gf5YLjjF...SpkUfcdPai9uVYYU"
	}
	]]></artwork>
	<postamble>Note that "..." in keyAuthorization and signature attributes
	above denote omitted part of base64 data.</postamble>
	</figure>

	<section title="ACME challenge email" anchor="acme-smime-challenge-email">

	<t>	<t>

	A "challenge" email message MUST have the following structure:	A "challenge" email message <bcp14>MUST</bcp14> have the following str
		ucture:
	<list style='numbers'>
	<t>
	The message Subject header field has the following syntax: "ACME: &l
	t;token-part1>",
	where the prefix "ACME:" is followed by folding white space (FWS, se
	e <xref target='RFC5322'/>)
	and then by <token-part1>, which is the base64url encoded firs
	t part of the ACME token
	that MUST be at least 128 bits long after decoding.

	<!--Alternative to allow for arbitrary prefix, if needed:
	The message Subject header field has the following syntax: "<pref
	ix>ACME: <token-part1>",
	where the optional prefix <prefix> contain any text (it SHOULD
	be omitted), which is then
	followed by the literal string "ACME:", which in turn is followed by
	a folding white space (FWS, see <xref target='RFC5322'/>)
	and then by <token-part1> 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 <xref target='RFC5322'/>, the subject line can be folded, so whit
	espaces (if any) within
	the <token-part1> MUST be ignored. <xref target='RFC2231'/> en
	coding 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.
	</t>


		</t>
		<ol spacing="normal" type="1">
		<li>
		The Subject header field has the following syntax: "ACME: <token-
		part1>",
		where the prefix "ACME:" is followed by folding white space (FWS; se
		e <xref target="RFC5322" format="default"/>)
		and then by <token-part1>, which is the base64url-encoded firs
		t part of the ACME token
		that <bcp14>MUST</bcp14> be at least 128 bits long after decoding.
		Due to the recommended 78-octet line-length limit
		in <xref target="RFC5322" format="default"/>, the subject line can b
		e folded, so white spaces (if any) within
		the <token-part1> <bcp14>MUST</bcp14> be ignored. <xref target
		="RFC2231" format="default"/> encoding of the Subject header field <bcp14>MUST</
		bcp14> be supported,
		and, when used, only the "UTF-8" and "US-ASCII" charsets are allowed
		; other charsets <bcp14>MUST NOT</bcp14> be used. The US-ASCII charset <bcp14>SH
		OULD</bcp14> be used.
		</li>
		<li>
		The From header field <bcp14>MUST</bcp14> be the same email address
		as specified in the "from" field of the challenge object.
		</li>
		<li>
		The To header field <bcp14>MUST</bcp14> be the email address of the
		entity that requested the S/MIME certificate to be generated.</li>
		<li>The message <bcp14>MAY</bcp14> contain a Reply-To and/or CC header
		field.</li>
		<li>
		The message <bcp14>MUST</bcp14> include the Auto-Submitted header fi
		eld with the value "auto-generated" <xref target="RFC3834" format="default"/>.
		To aid in debugging (and, for some implementations, to make automate
		d processing easier), the Auto-Submitted header field <bcp14>SHOULD</bcp14> incl
		ude the "type=acme" parameter.
		It <bcp14>MAY</bcp14> include other optional parameters, as allowed
		by the syntax of the Auto-Submitted header field.</li>
		<li>
	<t>	<t>

	The From header field MUST be the same email address as specified in	In order to prove authenticity of a challenge message, it <bcp14>MUS
	the "from" field of the challange object.	T</bcp14> be signed using either DomainKeys Identified Mail (DKIM) <xref target=
		"RFC6376" format="default"/>
		or S/MIME <xref target="RFC8551" format="default"/>.
	</t>	</t>

		<ul spacing="normal">
	<t>	<li>
	The To header field MUST be the email address of the entity that req	If DKIM signing is used, the resulting DKIM-Signature header field
	uested the S/MIME certificate to be generated.</t>	<bcp14>MUST</bcp14> contain the "h=" tag that includes
		at least the From, Sender, Reply-To, To, CC, Subject, Date, In-Rep
	<t>The message MAY contain a Reply-To and/or CC header fields.</t>	ly-To, References,
		Message-ID, Auto-Submitted, Content-Type, and Content-Transfer-Enc
	<t>	oding header fields.
	The message MUST include the "Auto-Submitted: auto-generated" header	The DKIM-Signature header field's "h=" tag <bcp14>SHOULD</bcp14> a
	field <xref target="RFC3834"/>.	lso include the
	To aid in debugging (and in for some implementations to make automat	Resent-Date, Resent-From, Resent-To, Resent-Cc, List-Id, List-Help
	ed processing easier) the "Auto-Submitted" header field SHOULD include the "type	, List-Unsubscribe,
	=acme" parameter.	List-Subscribe, List-Post, List-Owner, List-Archive, and List-Unsu
	It MAY include other optional parameters as allowed by the syntax of	bscribe-Post header fields.
	the Auto-Submitted header field.</t>	The domain from the "d=" tag of the DKIM-Signature header field <b
		cp14>MUST</bcp14> be the same as the domain from
	<t>	the From header field of the "challenge" email.
	In order to prove authenticity of a challenge message, it MUST be si	</li>
	gned using either DKIM <xref target="RFC6376"/>	<li>
	or S/MIME <xref target="RFC8551"/>.	If S/MIME signing is used, the certificate corresponding to the si
	<!--Alexey: James suggested that PGP/MIME can also be used here. Thi	gner <bcp14>MUST</bcp14> have an rfc822Name subjectAltName extension
	s might be introduced in a later version,
	but for simplicity there are only 2 options right now.-->
	<list style='bullets'>

	<t>
	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", "Dat
	e", "In-Reply-To", "References",
	"Message-ID", "Auto-Submitted", "Content-Type", and "Content-Trans
	fer-Encoding" header fields.
	The DKIM-Signature header field's "h=" tag SHOULD also include
	"Resent-Date", "Resent-From", "Resent-To", "Resent-Cc", "List-Id",
	"List-Help", "List-Unsubscribe",
	"List-Subscribe", "List-Post", "List-Owner", "List-Archive" and "L
	ist-Unsubscribe-Post" header fields.

	<!--The following is basically strict identifier alignment for DKI
	M from the DMARC spec:-->
	The domain from the "d=" tag of DKIM-Signature header field MUST b
	e the same as the domain from
	the From header field of the "challenge" email<!--RFC5322.From dom
	ain-->.
	</t>

	<t>
	<!--///Alexey: Say something about how TA for the S/MIME cert shou
	ld relate to the TA used for issuing the end user S/MIME certificate.-->
	If S/MIME signing is used, the certificate corresponding to the si
	gner MUST have an rfc822Name subjectAltName extension
	with the value equal to the From header field email address of the "challenge" email.	with the value equal to the From header field email address of the "challenge" email.

	</t>	</li>
		</ul>
	</list>	</li>
	</t>	<li>

	<t>
	The body of the challenge message is not used for automated processi ng, so it can be any media type.	The body of the challenge message is not used for automated processi ng, so it can be any media type.

	(However there are extra requirements on S/MIME signing, if used. Se	(However, there are extra requirements on S/MIME signing, if used. S
	e below.)	ee below.)
	Typically it is text/plain or text/html containing a human-readable	Typically, it is text/plain or text/html containing a human-readable
	explanation of the purpose of the message.	explanation of the purpose of the message.
	If S/MIME signing is used to prove authenticity of the challenge mes sage,	If S/MIME signing is used to prove authenticity of the challenge mes sage,
	then the multipart/signed or "application/pkcs7-mime; smime-type=sig ned-data;" media type should be used.	then the multipart/signed or "application/pkcs7-mime; smime-type=sig ned-data;" media type should be used.

	Either way, it MUST use S/MIME header protection. <!--/////Add a ref	Either way, it <bcp14>MUST</bcp14> use S/MIME header protection.
	in the future-->	</li>
	</t>	</ol>

	</list>

	</t>

	<t>	<t>
	An email client compliant with this specification that detects that a pa rticular "challenge" email	An email client compliant with this specification that detects that a pa rticular "challenge" email

	fails validation described above MUST ignore the challenge and thus will	fails the validation described above <bcp14>MUST</bcp14> ignore the chal
	not generate any "response" email.	lenge and thus will not generate a "response" email.
	To aid in debugging such failed validations SHOULD be logged.	To aid in debugging, such failed validations <bcp14>SHOULD</bcp14> be lo
		gged.
	</t>	</t>

		<t keepWithNext="true">
	<figure title="Figure 1">	Here is an example of an ACME "challenge" email (note that, for simpli
	<preamble>	city, DKIM-related header fields are not included).
	An example ACME "challenge" email (note that for simplicity DKIM relat	</t>
	ed header fields are not included).	<figure>
	</preamble>	<artwork name="" type="" align="left" alt=""><![CDATA[
	<artwork>
	<![CDATA[
	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
	Subject: ACME: LgYemJLy3F1LDkiJrdIGbEzyFJyOyf6vBdyZ1TG3sME=	Subject: ACME: LgYemJLy3F1LDkiJrdIGbEzyFJyOyf6vBdyZ1TG3sME=
	Content-Type: text/plain	Content-Type: text/plain
	MIME-Version: 1.0	MIME-Version: 1.0

	This is an automatically generated ACME challenge for email address	This is an automatically generated ACME challenge for email address
	"alexey@example.com". If you haven't requested an S/MIME	"alexey@example.com". If you haven't requested an S/MIME
	certificate generation for this email address, be very afraid.	certificate generation for this email address, be very afraid.
	If you did request it, your email client might be able to process	If you did request it, your email client might be able to process
	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.
	]]></artwork>	]]></artwork>

	<postamble></postamble>	</figure>
	</figure>	<t keepWithPrevious="true"/>

	</section>	</section>

		<section anchor="acme-smime-response-email" numbered="true" toc="default">
	<section title="ACME response email" anchor="acme-smime-response-email">	<name>ACME "Response" Email</name>

	<t>	<t>

	A valid "response" email message MUST have the following structure:	A valid "response" email message <bcp14>MUST</bcp14> have the followin
		g structure:
	<list style='numbers'>
	<!--Original:
	<t>
	The message Subject header field has the following syntax: "<Repl
	y-prefix> ACME: <token-part1>",
	where <Reply-prefix> is typically the reply prefix "Re:" and
	the string "ACME:" is preceded and followed by folding white space (
	FWS, see <xref target='RFC5322'/>)
	and then by <token-part1>. <token-part1> is the base64ur
	l encoded first part of the ACME token
	(as received in the ACME challenge) that MUST be at least 128 bits l
	ong after decoding. Due to recommended 78 octet line length limit
	in <xref target='RFC5322'/>, the subject line can be folded, so whit
	espaces (if any) within
	the <token-part1> MUST be ignored. <xref target='RFC2231'/> en
	coding of the 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.
	When parsing subjects, ACME servers must decode <xref target='RFC223
	1'/> encoding (if any) and
	then they can ignore any prefix before the "ACME:" label.
	</t>
	-->


	<t>	</t>
	The message Subject header field is formed as a reply to the ACME "c	<ol spacing="normal" type="1">
	hallenge" email	<li>
	(see <xref target="acme-smime-challenge-email"/>).	The Subject header field is formed as a reply to the ACME "challenge
		" email
		(see <xref target="acme-smime-challenge-email" format="default"/>).
	Its syntax is the same as that of the challenge message except that it may be prefixed	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	by a US-ASCII reply prefix (typically "Re:") and FWS (see <xref targ
	space (FWS, see <xref target="RFC5322"/>), as is normal in reply mes	et="RFC5322" format="default"/>), as is normal in reply messages. When
	sages. When	parsing the subject, ACME servers <bcp14>MUST</bcp14> decode <xref t
	parsing the subject, ACME servers MUST decode <xref target='RFC2231'	arget="RFC2231" format="default"/> encoding (if any), and
	/> encoding (if any) and
	then they can ignore any prefix before the "ACME:" label.	then they can ignore any prefix before the "ACME:" label.

	</t>	</li>
		<li>The From header field contains the email address of the user that
	<t>The From: header field contains the email address of the user tha	is requesting S/MIME certificate issuance.</li>
	t is requesting S/MIME certificate issuance.</t>	<li>The To header field of the response contains the value from the Re
		ply-To header field from the
	<t>The To: header field of the response contains the value from the	challenge message (if set). Otherwise, it contains the value from the F
	Reply-To: header field from the challenge message (if set)	rom header field of the
	or from the From: header field of the challenge message otherwise.</	challenge message.</li>
	t>	<li>The Cc header field is ignored if present in the "response" email
		message.</li>
	<t>The Cc: header field is ignored if present in the "response" emai	<li>The In-Reply-To header field <bcp14>SHOULD</bcp14> be set to the M
	l message.</t>	essage-ID header field of the challenge message
		according to rules in <xref target="RFC5322" sectionFormat="of" sect
	<t>The In-Reply-To: header field SHOULD be set to the Message-ID hea	ion="3.6.4"/>.</li>
	der field of the challenge message	<li>List-* header fields <xref target="RFC4021" format="default"/><xre
	according to rules in Section 3.6.4 of <xref target="RFC5322"/>.</t>	f target="RFC8058" format="default"/> <bcp14>MUST</bcp14> be absent (i.e., the r
		eply can't come from a mailing list).</li>
	<t>List-* header fields <xref target="RFC4021"/><xref target="RFC805	<li>
	8"/> MUST be absent (i.e., the reply can't come from a mailing list)</t>	<t>The media type of the "response" email message is either text/pla
		in or multipart/alternative <xref target="RFC2046" format="default"/>, containin
	<!--Alexey: not needed, as the message might not be generated automa	g
	tically:	text/plain as one of the alternatives. (Note that the requirement to
	<t>	support multipart/alternative is to allow use of ACME-unaware MUAs,
	The message MAY include the "Auto-Submitted: auto-generated" header	which can't always generate pure text/plain, e.g., if they reply to
	field <xref target="RFC3834"/>.	a text/html).
	It MAY include optional parameters as allowed by syntax of Auto-Subm
	itted header field.</t>
	-->

	<t>
	<!--////Should we allow either new MIME type or text/plain?-->
	The media type of the "response" email message is either text/plain
	or multipart/alternative <xref target="RFC2046"/> 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/alte rnative)	The text/plain body part (whether or not it is inside multipart/alte rnative)

	MUST contain a block of lines starting with the line "-----BEGIN ACM	<bcp14>MUST</bcp14> contain a block of lines starting with the line
	E RESPONSE-----", followed by one	"-----BEGIN ACME RESPONSE-----", followed by one
	or more line containing the base64url-encoded SHA-256 digest <xref t	or more lines containing the base64url-encoded SHA-256 digest <xref
	arget="FIPS180-4"/>	target="RFC6234" format="default"/>
	of the key authorization, calculated from concatenated token-part1 ( received over email)	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 <xref target="smime"/>.	and token-part2 (received over HTTPS), as outlined in the 5th bullet in <xref target="smime" format="default"/>.
	(Note that each line of text/plain is terminated by CRLF. Bare LFs o r bare CRs are not allowed.)	(Note that each line of text/plain is terminated by CRLF. Bare LFs o r bare CRs are not allowed.)

	Due to historical line length limitations in email, line endings (CR LFs)	Due to historical line-length limitations in email, line endings (CR LFs)
	can be freely inserted in the middle of the encoded digest,	can be freely inserted in the middle of the encoded digest,

	so they MUST be ignored when processing it.) The final line of the e	so they <bcp14>MUST</bcp14> be ignored when processing it. The final
	ncoded digest	line of the encoded digest
	is followed by a line containing "-----END ACME RESPONSE-----".	is followed by a line containing:</t>
	Any text before and after this block is ignored. For example such te	<artwork name="" type="" align="left" alt=""><![CDATA[
	xt might explain what	-----END ACME RESPONSE-----
	to do with it for ACME-unaware clients.	]]></artwork>
	</t>	<t>Any text before and after this block is ignored. For example, suc
		h text might explain what
	<t>There is no need to use any Content-Transfer-Enc	to do with it for ACME-unaware clients.</t>
	oding other than 7bit for the text/plain body part.	</li>
	Use of Quoted-Printable or base64 in a "response" email message is n	<li>There is no need to use any Content-Transfer-Encoding other than 7
	ot necessary and should be avoided,	bit for the text/plain body part.
		Use of quoted-printable or base64 in a "response" email message is n
		ot necessary and should be avoided,
	though it is permitted.	though it is permitted.

	</t>	</li>
		<li>
	<t>	In order to prove authenticity of a response message, it <bcp14>MUST
	<!--Can't use S/MIME signing here, as the whole point is to issue an	</bcp14> be DKIM <xref target="RFC6376" format="default"/>
	S/MIME certificate for the user.-->	signed. The resulting DKIM-Signature header field <bcp14>MUST</bcp14
	In order to prove authenticity of a response message, it MUST be DKI	> contain the "h=" tag that includes
	M <xref target="RFC6376"/>	at least the From, Sender, Reply-To, To, CC, Subject, Date, In-Reply
	signed. The resulting DKIM-Signature header field MUST contain the "	-To, References,
	h=" tag that includes	Message-ID, Content-Type, and Content-Transfer-Encoding header field
	at least "From", "Sender", "Reply-To", "To", "CC", "Subject", "Date"	s.
	, "In-Reply-To", "References",	The DKIM-Signature header field's "h=" tag <bcp14>SHOULD</bcp14> als
	"Message-ID", "Content-Type" and "Content-Transfer-Encoding" header	o include the
	fields.	Resent-Date, Resent-From, Resent-To, Resent-Cc, List-Id, List-Help,
	<!--Should the following just be MUSTs as well? Does it make it the	List-Unsubscribe,
	list too long?-->	List-Subscribe, List-Post, List-Owner, List-Archive, and List-Unsubs
	The DKIM-Signature header field's "h=" tag SHOULD also include	cribe-Post header fields.
	"Resent-Date", "Resent-From", "Resent-To", "Resent-Cc", "List-Id", "	The domain from the "d=" tag of DKIM-Signature header field <bcp14>M
	List-Help", "List-Unsubscribe",	UST</bcp14> be the same as the domain from
	"List-Subscribe", "List-Post", "List-Owner", "List-Archive" and "Lis	the From header field of the "response" email.
	t-Unsubscribe-Post" header fields.	</li>
	The domain from the "d=" tag of DKIM-Signature header field MUST be	</ol>
	the same as the domain from	<t keepWithNext="true">
	the From header field of the "response" email<!--RFC5322.From domain	Here is an example of an ACME "response" email (note that, for simplic
	-->.	ity, DKIM-related header fields are not included).
	</t>

	</list>

	</t>	</t>

		<figure>
	<figure title="Figure 2">	<artwork name="" type="" align="left" alt=""><![CDATA[
	<preamble>
	Example ACME "response" email (note that for simplicity DKIM related h
	eader fields are not included).
	</preamble>
	<artwork>
	<![CDATA[
	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=
	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-----
	]]></artwork>	]]></artwork>

	<postamble></postamble>	</figure>
	</figure>	<t keepWithPrevious="true"/>
	</section>	</section>

		<section anchor="acme-smime-sign-or-encrypt-only" numbered="true" toc="def
	<section title="Generating encryption only or signing only S/MIME certific	ault">
	ates" anchor="acme-smime-sign-or-encrypt-only">	<name>Generating Encryption-Only or Signing-Only S/MIME Certificates</na
		me>
	<t>	<t>
	ACME extensions specified in this document can be used to request sign	ACME extensions specified in this document can be used to request sign
	ing only or	ing-only or
	encryption only S/MIME certificates.	encryption-only S/MIME certificates.
	</t>	</t>
		<t>
	<t>	In order to request signing-only S/MIME certificates, the CSR <bcp14>M
	In order to request signing only S/MIME certificate, the CSR MUST incl	UST</bcp14> include the key usage
	ude the key usage
	extension with digitalSignature and/or nonRepudiation bits set and no other bits set.	extension with digitalSignature and/or nonRepudiation bits set and no other bits set.

	</t>	</t>
		<t>
	<t>	In order to request encryption-only S/MIME certificates, the CSR <bcp1
	<!--///What about dataEncipherment?-->	4>MUST</bcp14> include the key usage
	In order to request encryption only S/MIME certificate, the CSR MUST i
	nclude the key usage
	extension with keyEncipherment or keyAgreement bits set and no other b its set.	extension with keyEncipherment or keyAgreement bits set and no other b its set.

	</t>	</t>
		<t>
	<t>
	Presence of both of the above sets of key usage bits in the CSR,	Presence of both of the above sets of key usage bits in the CSR,

	<!--///Is the following right?-->	as well as absence of the key usage extension in the CSR,
	as well as absence of key usage extension in the CSR,	signals to the ACME server to issue an S/MIME certificate suitable for
	signals to ACME server to issue an S/MIME certificate suitable for bot	both signing
	h signing
	and encryption.	and encryption.

	</t>	</t>

	</section>	</section>


	</section>	</section>

		<section numbered="true" toc="default">
	<section title="Internationalization Considerations">	<name>Internationalization Considerations</name>
	<t>	<t>

	<xref target="RFC8616"/> updated/clarified use of DKIM with Internationali	<xref target="RFC8616" format="default"/> updated/clarified use of DKIM wi
	zed Email addresses <xref target="RFC6531"/>.	th internationalized email addresses <xref target="RFC6531" format="default"/>.
	Please consult RFC 8616 in regards to any changes that need to be implem	Please consult <xref target="RFC8616" format="default"/> in regards to a
	ented.	ny changes that need to be implemented.
	</t>	</t>


	<t>	<t>

	Use of non ASCII characters in left hand sides of Internationalized Emai	Use of non-ASCII characters in left-hand sides of internationalized emai
	l addresses requires putting	l addresses requires putting
	Internationalized Email Addresses in X.509 Certificates <xref target="RF	internationalized email addresses in X.509 certificates <xref target="RF
	C8398"/>.	C8398" format="default"/>.
	</t>	</t>


	</section>	</section>

		<section numbered="true" toc="default">
	<section title="IANA Considerations">	<name>IANA Considerations</name>
		<section numbered="true" toc="default">
	<section title="ACME Identifier Type">	<name>ACME Identifier Type</name>

	<t>	<t>

	IANA is requested to register a new Identifier type in the "ACME Identif	IANA has registered a new identifier type in the "ACME Identifier
	ier Types" registry	Types" registry defined in <xref target="RFC8555" sectionFormat="of"
	defined in Section 9.7.7 of <xref target="RFC8555"/> with Label "email"	section="9.7.7"/> with Label "email" and a Reference to this document,
	and a Reference to [RFCXXXX],	<xref target="RFC5321" format="default"/>, and <xref target="RFC6531"
	<xref target="RFC5321"/> and <xref target="RFC6531"/>.	format="default"/>. The new identifier type corresponds to an (all
	The new Identifier Type corresponds to an (all ASCII) email address <xre	ASCII) email address <xref target="RFC5321" format="default"/> or
	f target="RFC5321"/>	internationalized email addresses <xref target="RFC6531"
	or Internationalized Email addresses <xref target="RFC6531"/>.	format="default"/>.
	</t>	</t>


	</section>	</section>

		<section numbered="true" toc="default">
	<section title="ACME Challenge Type">	<name>ACME Challenge Type</name>

	<t>	<t>

	IANA is also requested to register a new entry in the "ACME Validation	IANA has registered a new entry in the "ACME Validation Methods" regis
	Methods" registry	try
	defined in Section 9.7.8 of <xref target="RFC8555"/>.	defined in <xref target="RFC8555" sectionFormat="of" section="9.7.8"/>
		.
	This entry is as follows:	This entry is as follows:
	</t>	</t>

		<table align="center">
	<texttable>	<thead>
	<!--	<tr>
	<preamble></preamble>	<th align="center">Label</th>
	-->	<th align="center">Identifier Type</th>
		<th align="center">ACME</th>
	<ttcol align='center'>Label</ttcol>	<th align="center">Reference</th>
	<ttcol align='center'>Identifier Type</ttcol>	</tr>
	<ttcol align='center'>ACME</ttcol>	</thead>
	<ttcol align='center'>Reference</ttcol>	<tbody>
		<tr>
	<c>email-reply-00</c>	<td align="center">email-reply-00</td>
	<c>email</c>	<td align="center">email</td>
	<c>Y</c>	<td align="center">Y</td>
	<c>[RFCXXXX]</c>	<td align="center">RFC 8823</td>
		</tr>
	<!--<postamble></postamble>-->	</tbody>
	</texttable>	</table>

	</section>	</section>


	</section>	</section>

		<section anchor="seccons" numbered="true" toc="default">
	<section title="Security Considerations" anchor="seccons">	<name>Security Considerations</name>

	<t>	<t>

	Please see Security Considerations of <xref target="RFC8555"/> for gener	Please see the Security Considerations section of <xref
	al security considerations	target="RFC8555" format="default"/> for general security
	related to use of ACME. This challenge/response protocol demonstrates th	considerations related to the use of ACME. This challenge/response
	at an entity that controls	protocol demonstrates that an entity that controls the private key
	the private key (corresponding to the public key in the certificate) als	(corresponding to the public key in the certificate) also controls the
	o controls the named email	named email account. The ACME server is confirming that the requested
	account.	email address belongs to the entity that requested the certificate,
	The ACME server is confirming that the requested email address	but this makes no claim to address correctness or fitness for purpose.
	belongs to the entity that requested the certificate, but this	If such claims are needed, they must be obtained by some other
	makes no claim to correctness or fitness-for-purpose of the	mechanism.
	address. It such claims are needed they must be obtained by
	some other mechanism.
	</t>	</t>


	<t>	<t>
	The security of the "email-reply-00" challenge type depends on the secur ity of the email system.	The security of the "email-reply-00" challenge type depends on the secur ity of the email system.
	A third party that can read and reply to user's email messages (by posse ssing a user's password	A third party that can read and reply to user's email messages (by posse ssing a user's password

	or a secret derived from it that can give read and reply access, such as	or a secret derived from it that can give read and reply access, such as
	"password equivalent" information;	"password equivalent" information,
	or by being given permissions to act on a user's behalf using email dele	or by being given permissions to act on a user's behalf using email dele
	gation feature common	gation features common
	in some email systems) can request S/MIME certificates using the protoco l specified in this document	in some email systems) can request S/MIME certificates using the protoco l specified in this document
	and is indistinguishable from the email account owner.	and is indistinguishable from the email account owner.
	This has several possible implications:	This has several possible implications:


	<list style='numbers'>

	<t>an entity that compromised an email account would be able to reques
	t 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 in
	formation are consulted);</t>

	<t>for email addresses with legitimate shared access/control by multip
	le users, any such user
	would be able to request S/MIME certificates using the protocol specif
	ied in this document
	and such requests can't be attributed to a specific user without consu
	lting external systems
	(such as IMAP/SMTP access logs);</t>

	<t>the protocol specified in this document is not suitable for use wit
	h email addresses
	associated with mailing lists <xref target="RFC5321"/>. While it is no
	t 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 Certif
	icate Issuers
	to handle most common cases.</t>

	</list>

	</t>	</t>

		<ol spacing="normal" type="1">
		<li>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 in
		formation are consulted).</li>
		<li>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; such
		requests can't be attributed to a specific user without consulting
		external systems (such as IMAP/SMTP access logs).</li>
		<li>The protocol specified in this document is not suitable for use with
		email addresses
		associated with mailing lists <xref target="RFC5321" format="default"/
		>. 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 certif
		icate issuers
		to handle most common cases.</li>
		</ol>
	<t>	<t>
	An email system in its turn depends on DNS. A third party that can manip ulate DNS MX records	An email system in its turn depends on DNS. A third party that can manip ulate DNS MX records

	for a domain might be able to redirect email and can get (at least tempo	for a domain might be able to redirect an email and can get (at least te
	rary) read and reply access to it.	mporary) read and reply access to it.
	Similar considerations apply to <!--SPF and -->DKIM TXT records in DNS.	Similar considerations apply to DKIM TXT records in DNS.
	Use of DNSSEC by email system administrators is recommended to avoid mak ing it easy to spoof	Use of DNSSEC by email system administrators is recommended to avoid mak ing it easy to spoof

	DNS records affecting email system. However use of DNSSEC is not ubiquit ous at the time of	DNS records affecting an email system. However, use of DNSSEC is not ubi quitous at the time of
	publishing of this document, so it is not required here.	publishing of this document, so it is not required here.


	Also, many existing systems that rely on verification of ownership of an	Also, many existing systems that rely on verification of ownership of an
	email address,	email address --
	for example 2 factor authentication systems used by banks or traditional	for example, 2-factor authentication systems used by banks or traditiona
	certificate issuance	l certificate issuance
	systems send email messages to email addresses, expecting the owner to c	systems -- send email messages to email addresses, expecting the owner t
	lick on the link supplied	o click on the link supplied
	in them (or to reply to a message), without requiring use of DNSSEC. So the risk of not requiring	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.	DNSSEC is presumed acceptable in this document.
	</t>	</t>


	<t>	<t>
	An ACME email challenge message can be forged by an attacker.	An ACME email challenge message can be forged by an attacker.


	As per requirements on an ACME-email-aware MUA specified in <xref target=" smime"/>,	As per requirements on an ACME-email-aware MUA specified in <xref target=" smime" format="default"/>,
	the MUA will not respond to requests it is not expecting.	the MUA will not respond to requests it is not expecting.


	<!--///Even if it does:
	(Ben wrote:) The From: header field value of the forged message could, of
	course, be forged, so this would be a potential backscatter vector, but I
	don't think there would be much amplification per message, and probably the
	client would only produce one "response" email and then try to poll the ACME
	order, so there would only be one forgery possible per ACME request.

	Even if the attacker causes the erroneous "response" email to go to	Even if the attacker causes the erroneous "response" email to go to
	an attacker-controlled email address, very little information is leaked --	an attacker-controlled email address, very little information is leaked --

	the SHA-256 hash of the key authorization, not the key	the SHA-256 hash of the key authorization would be leaked, not the key
	authorization itself, so no parts of the token or the the account key	authorization itself, so no parts of the token or the account key
	thumbprint are leaked.	thumbprint are leaked.
	</t>	</t>


	<t>	<t>
	An attacker that can read the "response" email has only one chance to gues s the	An attacker that can read the "response" email has only one chance to gues s the
	token-part2. Even if the attacker can guess it right, it still needs to kn ow	token-part2. Even if the attacker can guess it right, it still needs to kn ow
	the ACME account key to be able to make use of the intercepted SHA-256 has h of	the ACME account key to be able to make use of the intercepted SHA-256 has h of
	the key authorization.	the key authorization.
	</t>	</t>


	<t>	<t>

	Also see Security Considerations section of <xref target="RFC6376"/> for details on how DKIM depends	Also see the Security Considerations section of <xref target="RFC6376" f ormat="default"/> for details on how DKIM depends
	on the DNS and the respective vulnerabilities this dependence has.	on the DNS and the respective vulnerabilities this dependence has.
	</t>	</t>


	</section>	</section>


	</middle>	</middle>
	<back>	<back>

	<references title="Normative References">	<references>
	<!--<?rfc include="reference.RFC.2045"?>--> <!-- MIME, part 1 -->	<name>References</name>
	<?rfc include="reference.RFC.2046"?> <!-- MIME, part 2 -->	<references>
	<?rfc include="reference.RFC.2119"?> <!-- Keywords -->	<name>Normative References</name>
	<?rfc include="reference.RFC.2231"?> <!-- RFC 2231 parameter encoding -->	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	<?rfc include="reference.RFC.2818"?> <!-- HTTPS -->	.2046.xml"/>
	<?rfc include="reference.RFC.2985"?> <!-- PKCS #9: Selected Object Classes	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	and Attribute Types Version 2.0 -->	.2119.xml"/>
	<?rfc include="reference.RFC.2986"?> <!-- PKCS #10: Certification Request	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	Syntax Specification -->	.2231.xml"/>
	<?rfc include="reference.RFC.3834"?> <!-- Auto-Submitted header field -->	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	<?rfc include="reference.RFC.4648"?> <!-- base64url -->	.2818.xml"/>
	<?rfc include="reference.RFC.5321"?> <!-- SMTP -->	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	<?rfc include="reference.RFC.5322"?> <!-- Email Format -->	.2985.xml"/>
	<?rfc include="reference.RFC.5890"?> <!-- IDNA -->	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	<?rfc include="reference.RFC.6376"?> <!-- DKIM -->	.2986.xml"/>
	<?rfc include="reference.RFC.6531"?> <!-- Internationalized Email Addresse	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	s (SMTP Extension) -->	.3834.xml"/>
	<!--<?rfc include="reference.RFC.7208"?>--> <!-- SPF -->	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	<!--<?rfc include="reference.RFC.7489"?>--> <!-- DMARC -->	.4648.xml"/>
	<?rfc include="reference.RFC.8398"?> <!-- Internationalized Email Addresse	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	s in X.509 Certificates -->	.5321.xml"/>
	<?rfc include="reference.RFC.8550"?> <!-- S/MIME Certificate Handling -->	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	<?rfc include="reference.RFC.8551"?> <!-- S/MIME Message Format -->	.5322.xml"/>
	<?rfc include="reference.RFC.8555"?> <!-- ACME -->	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	<?rfc include="reference.RFC.8616"?> <!-- Email Authentication for Interna	.5890.xml"/>
	tionalized Mail -->	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
		.6376.xml"/>
	<!--Note for RFC Editor: you can use RFC 6234 reference here instead-->	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	<reference anchor="FIPS180-4" target="https://csrc.nist.gov/publications/d	.6531.xml"/>
	etail/fips/180/4/final">	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	<front>	.8174.xml"/>
	<title>Secure Hash Standard (SHS)</title>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	<author>	.8398.xml"/>
	<organization>National Institute of Standards and Technology</organi	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	zation>	.8550.xml"/>
	</author>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	<date month="August" year="2015"/>	.8551.xml"/>
	</front>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	<seriesInfo name="FIPS" value="PUB 180-4"/>	.8555.xml"/>
	</reference>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
		.8616.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
		.6234.xml"/>
		</references>
		<references>
		<name>Informative References</name>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.4021.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
		.8058.xml"/>

	</references>	</references>


	<references title="Informative References">

	<?rfc include="reference.RFC.4021"?> <!-- Registration of Mail and MIME He
	ader Fields -->
	<?rfc include="reference.RFC.8058"?> <!-- Signaling One-Click Functionalit
	y for List Email Headers -->

	</references>	</references>

		<section numbered="false" toc="default">
	<section title="Acknowledgements">	<name>Acknowledgements</name>
		<t>Thank you to <contact fullname="Andreas Schulze"/>, <contact fullname="
	<t>Thank you to Andreas Schulze, Gerd v. Egidy, James A. Baker, Ben Schwar	Gerd v. Egidy"/>,
	tz,	<contact fullname="James A. Baker"/>, <contact fullname="Ben Schwartz"/>,
	Peter Yee, Hilarie Orman, Michael Jenkins, Barry Leiba, Fraser Tweedale,	<contact fullname="Peter Yee"/>, <contact fullname="Hilarie Orman"/>,
	Daniel Kahn Gillmor and Benjamin Kaduk	<contact fullname="Michael Jenkins"/>, <contact fullname="Barry Leiba"/>,
	for suggestions, comments, and corrections on this document.</t>	<contact fullname="Fraser Tweedale"/>, <contact fullname="Daniel Kahn Gill
		mor"/>, and
		<contact fullname="Benjamin Kaduk"/> for their suggestions, comments, and
		corrections of this document.</t>
	</section>	</section>


	</back>	</back>
	</rfc>	</rfc>

End of changes. 109 change blocks.
	714 lines changed or deleted	512 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/