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

<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" docName='draft-ietf-acme-email-smime-14'> consensus="true" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3">

  <!-- xml2rfc v2v3 conversion 3.5.0 -->
  <front>
    <title abbrev="ACME for S/MIME">
      Extensions to Automatic Certificate Management Environment for end-user End-User S/MIME certificates Certificates
    </title>
    <seriesInfo name="RFC" value="8823"/>
    <author initials="A." surname="Melnikov" fullname="Alexey Melnikov">
      <organization>Isode Ltd</organization>
      <address>
        <postal>
          <street>14 Castle Mews</street>
	        <city>Hampton</city>
	        <region>Middlesex</region>
          <city>Hampton, Middlesex</city>
          <code>TW12 2NP</code>
	        <country>UK</country>
          <country>United Kingdom</country>
        </postal>
        <email>alexey.melnikov@isode.com</email>
      </address>
    </author>
    <date year="2021" month="April" />
    <keyword>ACME</keyword>
    <keyword>S/MIME</keyword>
    <abstract>
      <t>
    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.
      </t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>
        ACME <xref target="RFC8555"/> target="RFC8555" format="default"/> is a mechanism for automating certificate
        management on the Internet.  It enables administrative entities to
        prove effective control over resources like domain names, and it
        automates the process of generating and issuing certificates.
      </t>
      <t>
        This document describes an extension to ACME for use by S/MIME.
        <xref target="smime"/> target="smime" format="default"/> defines extensions for issuing end-user S/MIME <xref target="RFC8550"/> target="RFC8550" format="default"/> certificates.
      </t>
      <t>
        This document aims to support both:

          <list style='numbers'>
            <t>A both:</t>
      <ol spacing="normal" type="1">
	<li>A Mail User Agent (MUA) which that has a built-in ACME client which that is aware
	of the extension described in this document. (We will call such MUAs "ACME-email-aware".)
	Such an MUA can present a nice User Interface user interface to the user and automate certificate issuance.</t>

            <t>A issuance.</li>
        <li>An MUA which that is not ACME aware, with a separate ACME client implemented in a command line 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.</t>

          </list>
        </t>

      <!--
        <t>
        </t>
        --> minimal.</li>
      </ol>
    </section>
    <section title="Conventions numbered="true" toc="default">
      <name>Conventions Used in This Document">

      <t>The Document</name>        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP&nbsp;14 <xref target="RFC2119"/>.</t> target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.
        </t>
    </section>
    <section title="Use anchor="smime" numbered="true" toc="default">
      <name>Use of ACME for issuing end-user Issuing End-User S/MIME certificates" anchor="smime"> Certificates</name>
      <t>
      ACME <xref target="RFC8555"/> target="RFC8555" format="default"/> defines a "dns" Identifier Type 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 identifier type that
      proves ownership of an email address.
      </t>
      <t>
      This document defines a new Identifier Type "email" identifier type, "email", which corresponds to an email address.
      The address can be all ASCII <xref target="RFC5321"/> target="RFC5321" format="default"/> or internationalized <xref target="RFC6531"/>; target="RFC6531" format="default"/>;
      when an internationalized email address is used, the domain part can contain both U-labels and A-labels <xref target="RFC5890"/>. target="RFC5890" format="default"/>.
      This can be used with S/MIME or other another similar service that requires possession of a certificate tied to an email address.
      </t>
      <t>
      Any identifier of type "email" in a newOrder request MUST NOT <bcp14>MUST NOT</bcp14> have a wildcard ("*") character in its value.
      </t>
      <t>
      A new challenge type "email-reply-00" type, "email-reply-00", is used with the "email" Identifier Type, identifier type,
      which provides proof that an ACME client has control over an email address.
      </t>

      <!--///Alexey: Describe how the process described below is updated
      if multiple email addresses are specified in a single newOrder request!-->
      <t>
      The process of issing issuing 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.
        <list style='numbers'>

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

          <t>
          </li>
        <li>
          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 <xref target='RFC8555'/> target="RFC8555" sectionFormat="of" section="7.4"/> for more details.
          </t>
          </li>
        <li>
          <t>
          The ACME server<!--(run by the Certificate Authority or their authorized third party)--> 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 challenge,
          as specified in Section 7.5 of <xref target='RFC8555'/>. target="RFC8555" sectionFormat="of" section="7.5"/>.
          The "token" field of the corresponding challenge object (from the "challenges" array)
          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 challenge object
          <!--///Also say something about unique from email address per challenge?-->
          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).

          <list style="empty">

            <t>
<figure><artwork>
An
          </t>
	  <t>An example Challenge challenge object might look like this: this:</t>
<sourcecode type=""><![CDATA[
    {
      "type": "email-reply-00",
      "url": "https://example.com/acme/chall/ABprV_B7yEyA4f",
      "from": "acme-challenge+2i211oi1204310@example.com",
      "token": "DGyRejmCefe7v4NfDGDKfA"
    }
</artwork></figure>
            </t>

          </list>

          </t>

          <t>
]]></sourcecode>
            </li>
        <li>
          After responding to the authorization request request, the ACME server
          generates another token and a "challenge" email message with the subject "ACME: &lt;token-part1&gt;",
          where &lt;token-part1&gt; is the base64url encoded base64url-encoded <xref target="RFC4648"/> target="RFC4648" format="default"/> form of the token.
          The ACME server MUST <bcp14>MUST</bcp14> generate a fresh token for each S/MIME issuance request (authorization request),
          and token-part1 MUST <bcp14>MUST</bcp14> contain at least 128 bits of entropy.
          The "challenge" email message structure is described in more details in <xref target="acme-smime-challenge-email"/>.
          </t>

          <t> target="acme-smime-challenge-email" format="default"/>.
          </li>
        <li>
          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,
          e.g.
          e.g., if there is no ACME certificate issuance pending.
          The ACME-email-aware MUA also ignores any "challenge" email that has the Subject header field
          which
          that indicates that it is an email reply, e.g. e.g., a subject starting with the reply prefix "Re:".
          </t>

          <t>
          </li>
        <li>
          The ACME client concatenates "token-part1" (received over email) and "token-part2"
          (received over HTTPS <xref target="RFC2818"/>) target="RFC2818" format="default"/>) to create the ACME "token", "token" and calculates
          keyAuthorization (as per Section 8.1 of <xref target="RFC8555"/>),
          then target="RFC8555" sectionFormat="of" section="8.1"/>).
          Then, it returns the base64url encoded base64url-encoded SHA-256 digest <xref target="FIPS180-4"/> target="RFC6234" format="default"/> of the key authorization.
          The MUA returns the base64url encoded 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 <xref target="acme-smime-response-email"/>. target="acme-smime-response-email" format="default"/>.
          If the MUA is ACME-email-aware, it MUST NOT <bcp14>MUST NOT</bcp14> respond to the same "challenge" email more than once.
          </t>

          <t>
          </li>
        <li>
          Once the MUA sends the "response" email, the ACME client notifies the ACME server
          by POST to the challenge URL ("url" field).
          </t>

          <t>
          </li>
        <li>
          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 <xref target="RFC8555"/> target="RFC8555" sectionFormat="of" section="7.5.1"/> 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 <bcp14>MUST</bcp14> indicate the exact same
          set of requested identifiers as the initial newOrder request.
          For an identifier of type "email", the PKCS#10 <xref target="RFC2986"/> target="RFC2986" format="default"/>
          CSR MUST <bcp14>MUST</bcp14> contain the requested email address <!--either in the commonName
          portion of the requested subject name, or--> in an extensionRequest
          attribute <xref target="RFC2985"/> target="RFC2985" format="default"/> requesting a subjectAltName extension.
          Such
          The email address MUST <bcp14>MUST</bcp14> also match the From header field value of the "response" email message.
          </t>

          <t>
          </li>
        <li>
          In order to request generation of signing only signing-only or encryption only encryption-only S/MIME certificates
          (as opposed to requesting generation of S/MIME certificates suitable for both),
          the CSR needs to include the key usage extension (see Section 4.4.2 of <xref target="RFC8550"/>. target="RFC8550" sectionFormat="of" section="4.4.2"/>).
          This is described in more details in <xref target="acme-smime-sign-or-encrypt-only"/>.
          </t>

          <t> target="acme-smime-sign-or-encrypt-only" format="default"/>.
          </li>
        <li>
          If a request to finalize an order is successful, the ACME server will
          return a 200 (OK) with an updated order object.
          <!--///Add text about downloading the certificate?-->
          If the certificate is issued successfully, i.e. 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.
          </t>

        </list>
      </t>

<!--
      On receiving a response,
          </li>
      </ol>
      <section anchor="acme-smime-challenge-email" numbered="true" toc="default">
        <name>ACME "Challenge" Email</name>
        <t>
          A "challenge" email message <bcp14>MUST</bcp14> have the server constructs and stores following structure:

        </t>
        <ol spacing="normal" type="1">
	  <li>
            The Subject header field has the key
      authorization from following syntax: "ACME: &lt;token-part1&gt;",
            where the challenge "token" value prefix "ACME:" is followed by folding white space (FWS; see <xref target="RFC5322" format="default"/>)
            and then by &lt;token-part1&gt;, which is the current client
      account key.

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

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

      2.  Query for TXT records for the validation domain name

      3.  Verify ACME token
            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>
          A "challenge" email message MUST have the following structure:

          <list style='numbers'>
            <t>
            The message Subject header field has the following syntax: "ACME: &lt;token-part1&gt;",
            where the prefix "ACME:" is followed by folding white space (FWS, see <xref target='RFC5322'/>)
            and then by &lt;token-part1&gt;, which is the base64url encoded first 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: "&lt;prefix&gt;ACME: &lt;token-part1&gt;",
            where the optional prefix &lt;prefix&gt; 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 &lt;token-part1&gt; is the base64url encoded first part of the ACME token
            that MUST be at least 128 bits long after decoding.
          -->

            Due to <bcp14>MUST</bcp14> be at least 128 bits long after decoding.
            Due to the recommended 78-octet line length line-length limit
            in <xref target='RFC5322'/>, target="RFC5322" format="default"/>, the subject line can be folded, so whitespaces white spaces (if any) within
            the &lt;token-part1&gt; MUST <bcp14>MUST</bcp14> be ignored. <xref target='RFC2231'/> target="RFC2231" format="default"/> encoding of the message Subject header field MUST <bcp14>MUST</bcp14> be supported,
            and
            and, when used, only the "UTF-8" and "US-ASCII" charsets are allowed: allowed; other charsets MUST NOT <bcp14>MUST NOT</bcp14> be used. The US-ASCII charset SHOULD <bcp14>SHOULD</bcp14> be used.
            </t>

            <t>
            </li>
          <li>
            The From header field MUST <bcp14>MUST</bcp14> be the same email address as specified in the "from" field of the challange challenge object.
            </t>

            <t>
            </li>
          <li>
            The To header field MUST <bcp14>MUST</bcp14> be the email address of the entity that requested the S/MIME certificate to be generated.</t>

            <t>The generated.</li>
          <li>The message MAY <bcp14>MAY</bcp14> contain a Reply-To and/or CC header fields.</t>

            <t> field.</li>
          <li>
            The message MUST <bcp14>MUST</bcp14> include the "Auto-Submitted: auto-generated" Auto-Submitted header field with the value "auto-generated" <xref target="RFC3834"/>. target="RFC3834" format="default"/>.
            To aid in debugging (and in (and, for some implementations implementations, to make automated processing easier) easier), the "Auto-Submitted" Auto-Submitted header field SHOULD <bcp14>SHOULD</bcp14> include the "type=acme" parameter.
            It MAY <bcp14>MAY</bcp14> include other optional parameters parameters, as allowed by the syntax of the Auto-Submitted header field.</t> field.</li>
          <li>
            <t>
            In order to prove authenticity of a challenge message, it MUST <bcp14>MUST</bcp14> be signed using either DKIM DomainKeys Identified Mail (DKIM) <xref target="RFC6376"/> target="RFC6376" format="default"/>
            or S/MIME <xref target="RFC8551"/>.
            <!--Alexey: James suggested that PGP/MIME can also be used here. This might be introduced in a later version,
            but for simplicity there are only 2 options right now.-->
            <list style='bullets'>

              <t> target="RFC8551" format="default"/>.
            </t>
            <ul spacing="normal">
              <li>
              If DKIM signing is used, the resulting DKIM-Signature header field MUST <bcp14>MUST</bcp14> 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", the From, Sender, Reply-To, To, CC, Subject, Date, In-Reply-To, References,
              Message-ID, Auto-Submitted, Content-Type, and "Content-Transfer-Encoding" Content-Transfer-Encoding header fields.
              The DKIM-Signature header field's "h=" tag SHOULD <bcp14>SHOULD</bcp14> also include
              "Resent-Date", "Resent-From", "Resent-To", "Resent-Cc", "List-Id", "List-Help", "List-Unsubscribe",
              "List-Subscribe", "List-Post", "List-Owner", "List-Archive" the
              Resent-Date, Resent-From, Resent-To, Resent-Cc, List-Id, List-Help, List-Unsubscribe,
              List-Subscribe, List-Post, List-Owner, List-Archive, and "List-Unsubscribe-Post" List-Unsubscribe-Post header fields.

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

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

            </list>
            </t>

            <t>
              </li>
            </ul>
          </li>
          <li>
            The body of the challenge message is not used for automated processing, so it can be any media type.
            (However
            (However, there are extra requirements on S/MIME signing, if used. See below.)
            Typically
            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 <bcp14>MUST</bcp14> use S/MIME header protection. <!--/////Add a ref in the future-->
            </t>

        </list>

        </t>
            </li>
        </ol>
        <t>
        An email client compliant with this specification that detects that a particular "challenge" email
        fails the validation described above MUST <bcp14>MUST</bcp14> ignore the challenge and thus will not generate any a "response" email.
        To aid in debugging debugging, such failed validations SHOULD <bcp14>SHOULD</bcp14> be logged.
        </t>

        <figure title="Figure 1">
        <preamble>
          An
        <t keepWithNext="true">
          Here is an example of an ACME "challenge" email (note that that, for simplicity DKIM related simplicity, DKIM-related header fields are not included).
        </preamble>
<artwork>
  <![CDATA[
        </t>
        <figure>
<artwork name="" type="" align="left" alt=""><![CDATA[
  Auto-Submitted: auto-generated; type=acme
  Date: Sat, 5 Dec 2020 10:08:55 +0100
  Message-ID: <A2299BB.FF7788@example.org>
  From: acme-generator@example.org
  To: alexey@example.com
  Subject: ACME: LgYemJLy3F1LDkiJrdIGbEzyFJyOyf6vBdyZ1TG3sME=
  Content-Type: text/plain
  MIME-Version: 1.0

  This is an automatically generated ACME challenge for email address
  "alexey@example.com". If you haven't requested an S/MIME
  certificate generation for this email address, be very afraid.
  If you did request it, your email client might be able to process
  this request automatically, or you might have to paste the first
  token part into an external program.
]]></artwork>
        <postamble></postamble>
        </figure>
        <t keepWithPrevious="true"/>
      </section>
      <section title="ACME response email" anchor="acme-smime-response-email"> anchor="acme-smime-response-email" numbered="true" toc="default">
        <name>ACME "Response" Email</name>
        <t>
          A valid "response" email message MUST <bcp14>MUST</bcp14> have the following structure:

          <list style='numbers'>
          <!--Original:
            <t>
            The message Subject header field has the following syntax: "&lt;Reply-prefix&gt; ACME: &lt;token-part1&gt;",
            where &lt;Reply-prefix&gt; 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 &lt;token-part1&gt;. &lt;token-part1&gt; is the base64url encoded first part of the ACME token
            (as received in the ACME challenge) that MUST be at least 128 bits long after decoding. Due to recommended 78 octet line length limit
            in <xref target='RFC5322'/>, the subject line can be folded, so whitespaces (if any) within
            the &lt;token-part1&gt; MUST be ignored. <xref target='RFC2231'/> encoding 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='RFC2231'/> encoding (if any) and
            then they can ignore any prefix before the "ACME:" label.

        </t>
            -->

            <t>
        <ol spacing="normal" type="1">
            <li>
            The message Subject header field is formed as a reply to the ACME "challenge" email
            (see <xref target="acme-smime-challenge-email"/>). target="acme-smime-challenge-email" format="default"/>).
            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 FWS (see <xref target="RFC5322"/>), target="RFC5322" format="default"/>), as is normal in reply messages. When
            parsing the subject, ACME servers MUST <bcp14>MUST</bcp14> decode <xref target='RFC2231'/> target="RFC2231" format="default"/> encoding (if any) any), and
            then they can ignore any prefix before the "ACME:" label.
            </t>

            <t>The From:
            </li>
          <li>The From header field contains the email address of the user that is requesting S/MIME certificate issuance.</t>

            <t>The To: issuance.</li>
          <li>The To header field of the response contains the value from the Reply-To: Reply-To header field from the
	  challenge message (if set)
            or set). Otherwise, it contains the value from the From: From header field of the
	  challenge message otherwise.</t>

            <t>The Cc: message.</li>
          <li>The Cc header field is ignored if present in the "response" email message.</t>

            <t>The In-Reply-To: message.</li>
          <li>The In-Reply-To header field SHOULD <bcp14>SHOULD</bcp14> be set to the Message-ID header field of the challenge message
            according to rules in Section 3.6.4 of <xref target="RFC5322"/>.</t>

            <t>List-* target="RFC5322" sectionFormat="of" section="3.6.4"/>.</li>
          <li>List-* header fields <xref target="RFC4021"/><xref target="RFC8058"/> MUST target="RFC4021" format="default"/><xref target="RFC8058" format="default"/> <bcp14>MUST</bcp14> be absent (i.e., the reply can't come from a mailing list)</t>

            <!--Alexey: not needed, as the message might not be generated automatically:
            <t>
            The message MAY include the "Auto-Submitted: auto-generated" header field <xref target="RFC3834"/>.
            It MAY include optional parameters as allowed by syntax of Auto-Submitted header field.</t>
            -->

            <t>
            <!--////Should we allow either new MIME type or text/plain?-->
            The list).</li>
            <li>
            <t>The media type of the "response" email message is either text/plain or multipart/alternative <xref target="RFC2046"/> target="RFC2046" format="default"/>, containing
            text/plain as one of the alternatives. (Note that the requirement to support multipart/alternative is to allow use of ACME-unaware MUAs MUAs,
            which can't always generate pure text/plain, e.g. e.g., if they reply to a text/html).
            The text/plain body part (whether or not it is inside multipart/alternative)
            MUST
            <bcp14>MUST</bcp14> contain a block of lines starting with the line "-----BEGIN ACME RESPONSE-----", followed by one
            or more line lines containing the base64url-encoded SHA-256 digest <xref target="FIPS180-4"/> target="RFC6234" format="default"/>
            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"/>. target="smime" format="default"/>.
            (Note that each line of text/plain is terminated by CRLF. Bare LFs or bare CRs are not allowed.)
            Due to historical line length line-length limitations in email, line endings (CRLFs)
            can be freely inserted in the middle of the encoded digest,
            so they MUST <bcp14>MUST</bcp14> be ignored when processing it.) it. The final line of the encoded digest
            is followed by a line containing "-----END containing:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
-----END ACME RESPONSE-----".
            Any RESPONSE-----
]]></artwork>
            <t>Any text before and after this block is ignored. For example example, such text might explain what
            to do with it for ACME-unaware clients.
            </t>

			      <t>There clients.</t>
            </li>
          <li>There is no need to use any Content-Transfer-Encoding other than 7bit for the text/plain body part.
            Use of Quoted-Printable quoted-printable or base64 in a "response" email message is not necessary and should be avoided,
            though it is permitted.
            </t>

            <t>
            <!--Can't use S/MIME signing here, as the whole point and should be avoided,
            though it is to issue an S/MIME certificate for the user.--> permitted.
            </li>
          <li>
            In order to prove authenticity of a response message, it MUST <bcp14>MUST</bcp14> be DKIM <xref target="RFC6376"/> target="RFC6376" format="default"/>
            signed. The resulting DKIM-Signature header field MUST <bcp14>MUST</bcp14> contain the "h=" tag that includes
            at least "From", "Sender", "Reply-To", "To", "CC", "Subject", "Date", "In-Reply-To", "References",
            "Message-ID", "Content-Type" the From, Sender, Reply-To, To, CC, Subject, Date, In-Reply-To, References,
            Message-ID, Content-Type, and "Content-Transfer-Encoding" Content-Transfer-Encoding header fields.
            <!--Should the following just be MUSTs as well? Does it make it the list too long?-->
            The DKIM-Signature header field's "h=" tag SHOULD <bcp14>SHOULD</bcp14> also include
            "Resent-Date", "Resent-From", "Resent-To", "Resent-Cc", "List-Id", "List-Help", "List-Unsubscribe",
            "List-Subscribe", "List-Post", "List-Owner", "List-Archive" the
            Resent-Date, Resent-From, Resent-To, Resent-Cc, List-Id, List-Help, List-Unsubscribe,
            List-Subscribe, List-Post, List-Owner, List-Archive, and "List-Unsubscribe-Post" List-Unsubscribe-Post header fields.
            The domain from the "d=" tag of DKIM-Signature header field MUST <bcp14>MUST</bcp14> be the same as the domain from
            the From header field of the "response" email<!--RFC5322.From domain-->.
            </t>

          </list>

        </t>

      <figure title="Figure 2">
        <preamble>
          Example email.
            </li>
        </ol>
        <t keepWithNext="true">
          Here is an example of an ACME "response" email (note that that, for simplicity DKIM related simplicity, DKIM-related header fields are not included).
        </preamble>
<artwork>
  <![CDATA[
        </t>
        <figure>
<artwork name="" type="" align="left" alt=""><![CDATA[
   Date: Sat, 5 Dec 2020 12:01:45 +0100
   Message-ID: <111-22222-3333333@example.com>
   In-Reply-To: <A2299BB.FF7788@example.org>
   From: alexey@example.com
   To: acme-generator@example.org
   Subject: Re: ACME: LgYemJLy3F1LDkiJrdIGbEzyFJyOyf6vBdyZ1TG3sME=
   Content-Type: text/plain
   MIME-Version: 1.0

   -----BEGIN ACME RESPONSE-----
   LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowy
   jxAjEuX0=
   -----END ACME RESPONSE-----
]]></artwork>
        <postamble></postamble>
        </figure>
        <t keepWithPrevious="true"/>
      </section>
      <section title="Generating encryption only anchor="acme-smime-sign-or-encrypt-only" numbered="true" toc="default">
        <name>Generating Encryption-Only or signing only Signing-Only S/MIME certificates" anchor="acme-smime-sign-or-encrypt-only"> Certificates</name>
        <t>
          ACME extensions specified in this document can be used to request signing only signing-only or
          encryption only
          encryption-only S/MIME certificates.
        </t>
        <t>
          In order to request signing only signing-only S/MIME certificate, certificates, the CSR MUST <bcp14>MUST</bcp14> include the key usage
          extension with digitalSignature and/or nonRepudiation bits set and no other bits set.
        </t>
        <t>
          <!--///What about dataEncipherment?-->
          In order to request encryption only encryption-only S/MIME certificate, certificates, the CSR MUST <bcp14>MUST</bcp14> include the key usage
          extension with keyEncipherment or keyAgreement bits set and no other bits set.
        </t>
        <t>
          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,
          signals to the ACME server to issue an S/MIME certificate suitable for both signing
          and encryption.
        </t>
      </section>
    </section>
    <section title="Internationalization Considerations"> numbered="true" toc="default">
      <name>Internationalization Considerations</name>
      <t>
      <xref target="RFC8616"/> target="RFC8616" format="default"/> updated/clarified use of DKIM with Internationalized Email internationalized email addresses <xref target="RFC6531"/>. target="RFC6531" format="default"/>.
        Please consult RFC 8616 <xref target="RFC8616" format="default"/> in regards to any changes that need to be implemented.
      </t>
      <t>
        Use of non ASCII non-ASCII characters in left hand left-hand sides of Internationalized Email internationalized email addresses requires putting
        Internationalized Email Addresses
        internationalized email addresses in X.509 Certificates certificates <xref target="RFC8398"/>. target="RFC8398" format="default"/>.
      </t>
    </section>
    <section title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <section title="ACME numbered="true" toc="default">
        <name>ACME Identifier Type"> Type</name>
        <t>
        IANA is requested to register has registered a new Identifier identifier type in the "ACME Identifier
        Types" registry defined in Section 9.7.7 of <xref target="RFC8555"/> target="RFC8555" sectionFormat="of"
        section="9.7.7"/> with Label "email" and a Reference to [RFCXXXX], this document,
        <xref target="RFC5321"/> target="RFC5321" format="default"/>, and <xref target="RFC6531"/>. target="RFC6531"
        format="default"/>.  The new Identifier Type identifier type corresponds to an (all
        ASCII) email address <xref target="RFC5321"/> target="RFC5321" format="default"/> or Internationalized Email
        internationalized email addresses <xref target="RFC6531"/>. target="RFC6531"
        format="default"/>.
        </t>
      </section>
      <section title="ACME numbered="true" toc="default">
        <name>ACME Challenge Type"> Type</name>
        <t>
          IANA is also requested to register has registered a new entry in the "ACME Validation Methods" registry
          defined in Section 9.7.8 of <xref target="RFC8555"/>. target="RFC8555" sectionFormat="of" section="9.7.8"/>.
          This entry is as follows:
        </t>

        <texttable>
          <!--
          <preamble></preamble>
          -->

          <ttcol align='center'>Label</ttcol>
          <ttcol align='center'>Identifier Type</ttcol>
          <ttcol align='center'>ACME</ttcol>
          <ttcol align='center'>Reference</ttcol>

          <c>email-reply-00</c>
          <c>email</c>
          <c>Y</c>
          <c>[RFCXXXX]</c>

          <!--<postamble></postamble>-->
        </texttable>
        <table align="center">
          <thead>
            <tr>
              <th align="center">Label</th>
              <th align="center">Identifier Type</th>
              <th align="center">ACME</th>
              <th align="center">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="center">email-reply-00</td>
              <td align="center">email</td>
              <td align="center">Y</td>
              <td align="center">RFC 8823</td>
            </tr>
          </tbody>
        </table>
      </section>
    </section>
    <section title="Security Considerations" anchor="seccons"> anchor="seccons" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
        Please see the Security Considerations section of <xref target="RFC8555"/>
        target="RFC8555" format="default"/> for general security
        considerations related to the 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 address correctness or fitness-for-purpose of the
        address.  It fitness for purpose.
        If such claims are needed needed, they must be obtained by some other
        mechanism.
      </t>
      <t>
        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; information,
        or by being given permissions to act on a user's behalf using email delegation feature features 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:

        <list style='numbers'>

          <t>an

      </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 document, and such entity couldn't be distinguished from
          the legitimate email account owner (unless some external sources of information are consulted);</t>

          <t>for 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
          and document; such
        requests can't be attributed to a specific user without consulting
        external systems (such as IMAP/SMTP access logs);</t>

          <t>the logs).</li>
        <li>The protocol specified in this document is not suitable for use with email addresses
          associated with mailing lists <xref target="RFC5321"/>. 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 Certificate Issuers certificate issuers
          to handle most common cases.</t>

        </list>

      </t> cases.</li>
      </ol>
      <t>
        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 an email and can get (at least temporary) read and reply access to it.
        Similar considerations apply to <!--SPF and -->DKIM DKIM TXT records in DNS.
        Use of DNSSEC by email system administrators is recommended to avoid making it easy to spoof
        DNS records affecting an email system. However 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, address --
        for example 2 factor 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.
      </t>
      <t>
      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"/>, target="smime" format="default"/>,
      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
      an attacker-controlled email address, very little information is leaked --
      the SHA-256 hash of the key authorization, authorization would be leaked, not the key
      authorization itself, so no parts of the token or the the account key
      thumbprint are leaked.
      </t>
      <t>
      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.
      </t>
      <t>
        Also see the Security Considerations section of <xref target="RFC6376"/> target="RFC6376" format="default"/> for details on how DKIM depends
        on the DNS and the respective vulnerabilities this dependence has.
      </t>
    </section>
  </middle>
  <back>
    <references title="Normative References">
      <!--<?rfc include="reference.RFC.2045"?>--> <!-- MIME, part 1 -->
      <?rfc include="reference.RFC.2046"?> <!-- MIME, part 2 -->
      <?rfc include="reference.RFC.2119"?> <!-- Keywords -->
      <?rfc include="reference.RFC.2231"?> <!-- RFC 2231 parameter encoding -->
      <?rfc include="reference.RFC.2818"?> <!-- HTTPS -->
      <?rfc include="reference.RFC.2985"?> <!-- PKCS #9: Selected Object Classes and Attribute Types Version 2.0 -->
      <?rfc include="reference.RFC.2986"?> <!-- PKCS #10: Certification Request Syntax Specification -->
      <?rfc include="reference.RFC.3834"?> <!-- Auto-Submitted header field -->
      <?rfc include="reference.RFC.4648"?> <!-- base64url -->
      <?rfc include="reference.RFC.5321"?> <!-- SMTP -->
      <?rfc include="reference.RFC.5322"?> <!-- Email Format -->
      <?rfc include="reference.RFC.5890"?> <!-- IDNA -->
      <?rfc include="reference.RFC.6376"?> <!-- DKIM -->
      <?rfc include="reference.RFC.6531"?> <!-- Internationalized Email Addresses (SMTP Extension) -->
      <!--<?rfc include="reference.RFC.7208"?>--> <!-- SPF -->
      <!--<?rfc include="reference.RFC.7489"?>--> <!-- DMARC -->
      <?rfc include="reference.RFC.8398"?> <!-- Internationalized Email Addresses in X.509 Certificates -->
      <?rfc include="reference.RFC.8550"?> <!-- S/MIME Certificate Handling -->
      <?rfc include="reference.RFC.8551"?> <!-- S/MIME Message Format -->
      <?rfc include="reference.RFC.8555"?> <!-- ACME -->
      <?rfc include="reference.RFC.8616"?> <!-- Email Authentication for Internationalized Mail -->

      <!--Note for RFC Editor: you can use RFC 6234 reference here instead-->
      <reference anchor="FIPS180-4" target="https://csrc.nist.gov/publications/detail/fips/180/4/final">
        <front>
          <title>Secure Hash Standard (SHS)</title>
          <author>
            <organization>National Institute of Standards and Technology</organization>
          </author>
          <date month="August" year="2015"/>
        </front>
        <seriesInfo name="FIPS" value="PUB 180-4"/>
      </reference>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2046.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2231.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2818.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2985.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2986.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3834.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5321.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5322.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5890.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6376.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6531.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8398.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8550.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8551.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8555.xml"/>
      <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.RFC.4021.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8058.xml"/>

    </references>

    <references title="Informative References">

      <?rfc include="reference.RFC.4021"?> <!-- Registration of Mail and MIME Header Fields -->
      <?rfc include="reference.RFC.8058"?> <!-- Signaling One-Click Functionality for List Email Headers -->
    </references>
    <section title="Acknowledgements"> numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>Thank you to Andreas Schulze, Gerd <contact fullname="Andreas Schulze"/>, <contact fullname="Gerd v. Egidy, James Egidy"/>,
      <contact fullname="James A. Baker, Ben Schwartz,
      Peter Yee, Hilarie Orman, Michael Jenkins, Barry Leiba, Fraser Tweedale,
      Daniel Baker"/>, <contact fullname="Ben Schwartz"/>,
      <contact fullname="Peter Yee"/>, <contact fullname="Hilarie Orman"/>,
      <contact fullname="Michael Jenkins"/>, <contact fullname="Barry Leiba"/>,
      <contact fullname="Fraser Tweedale"/>, <contact fullname="Daniel Kahn Gillmor Gillmor"/>, and Benjamin Kaduk
      <contact fullname="Benjamin Kaduk"/> for their suggestions, comments, and corrections on of this document.</t>
    </section>
  </back>
</rfc>