Subject: [Acme] Benjamin Kaduk's Discuss on draft-ietf-acme-email-smime-10: (with DISCUSS and COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Thu, 05 Nov 2020 00:03:18 -0800

Benjamin Kaduk has entered the following ballot position for
draft-ietf-acme-email-smime-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-acme-email-smime/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I have one point that I am not sure of the significance of and would
like to discuss further, and one point that I think has a fairly
clear/straightforward resolution.

One of the key properties of ACME is that its authenticator provides
assurance that both a party controlling the identifier to be certified
and the ACME client jointly assent to the certification request of that
identifier.  I'm trying to explore a bit more the "jointly assent" part,
and whether it is clear that all steps of the challenge/validation flow
are ultimatetly tied to the same order request.
In the validation flows for the challenge types from 8555, the full
token is returned to the ACME client, which then provides the token to
the entity that controls the identifier being certified, in order to set
up state to expect a verification attempt using that token.  In this
email validation flow, though, the token-part1 is *only* present in the
challenge email, so there is no thread of continuity that allows the
email account holder to tie the validation attempt to the specific
request (i.e., token).  Any message that comes in claiming to be an ACME
challenge would end up being treated as a validation attempt for the
pending request, so the ACME server (or a party pretending to be one)
does not have to provide any proof of knowledge of the pending
validation before the response email is generated.  Some key properties
here seem to include: there is a portion (token-part2) to the response
email that can only be provided by the ACME client, there is a part
(token-part1) to the response email that can only be provided by an
entity that can receive email at the email address being validated, and
that the validation attempt, response email, and ACME order request can
be tied together by unique identifiers.  It seems that we could achieve
all three of these by having the HTTPS response to the ACME client
include a token-part0 as well as the token-part2, with token-part0 being
used as the subject line of the challenge email and token-part1 being
conveyed in some fashion (whether body or headers) of the challenge
email.  Does such a scheme provide any useful properties that are not
provided by the current scheme?

The more straightforward point is that the procedure in section 3
indicates that token-part2 is returned to the ACME client over HTTPS,
but the stated procedure does not otherwise involve an ACME client in
initiating the newOrder request.  I think we need to clarify the
interaction/relationship between end-user/email client UI/etc and the
ACME client in step 1.  In particular, I think that "[t]his document
doesn't prescribe how exactly S/MIME certificate issuance is initiated"
seems incompatible with requiring there to be an ACME client involved
(and the presumed newOrder ACME request, etc.) unless the "initiate"
operation is supposed to be the way by which the ACME client is
triggered to start the request.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

The discuss point notwithstanding, if we assume that the current
validation process does provide the necessary linkage across steps, it
seems that the procedure would provide only similar properties to the
RFC 8555 validation flows -- I am having a hard time convincing myself
that we definitely have the 128-bit security level for all the
information paths at play.  It seems like having both token-part1 and
token-part2 each be 128+ bits would be fairly low-cost and would give
greater peace of mind that we are not opening up any 64-bit attacks.

Using "ACME:" as the Subject: marker for both challenge mail and
response mail potentially sets us up for various reflection/janus-like
attacks.  We could give some warnings about this in the security
considerations, or just indicate in-band whether it is a challenge or a
response...

Section 3

       contains at least 64 bits of entropy.  (ACME server MUST generate
       token afresh for each S/MIME issuance request.)  The challenge

nit: missing article ("the"), twice ("The ACME server", "the token").

   2.  The To header field MUST be the email address of the entity that
       requested the S/MIME certificate to be generated.

Is this required to be the same email address that is in the CSR?
How does it relate to the identity of the ACME client involved in the
process (to the extent that an ACME client has an identity).

Section 3.1

   5.  In order to prove authenticity of a challenge message, it MUST be
       either DKIM [RFC6376] signed or S/MIME [RFC8551] signed.  If DKIM

S/MIME brings in X.509 and a PKI.  Is there anything useful to say about
the nature of that PKI (e.g., chaining to the same CA that would issue
the ACME cert, etc.)?  In general, on some intuitive sense, it seems
like we might want to say more about who is doing the signing (of
whichever form) and have that relate to the CA and/or ACME server in
some specific fashion, so the absence of such discussion in the document
suggests that there are some previous discussions of this topic in the
acme list archives; a pointer thereto would be welcome.

   5.  In order to prove authenticity of a challenge message, it MUST be
       either DKIM [RFC6376] signed or S/MIME [RFC8551] signed.  If DKIM
       signing is used, the resulting DKIM-Signature header field MUST
       contain the "h=" tag that includes at least "From", "Sender",
       "Reply-To", "To", "CC", "Subject", "Date", "In-Reply-To",
       "References", "Message-ID", "Content-Type", and "Content-
       Transfer-Encoding" header fields.  [...]

Cross-referencing this against
https://tools.ietf.org/html/rfc6376#section-5.4.1, do we want to say
anything about Resent-* and/or List-*?

                                          The message MUST also pass
       DMARC validation [RFC7489], which implies DKIM and SPF validation
       [RFC7208].

I don't see a need to duplicate the content, but am very interested in
the outcome of Barry's thread about DMARC/etc.

We should probably also say somewhere that challenge emails that fail
validation are ignored with no response generated.

     Auto-Submitted: auto-generated; type=acme
     Date: Sat, 1 Sep 2018 10:08:55 +0100
     Message-ID: <[email-masked]>

We might consider moderninzing the date to something closer to the time
of final publication.

     Subject: ACME: <base64url-encoded-token-with-64-bits-of-entropy>

I feel like it might be more illustrative to just include some random
base64.  E.g., LgYemJLy3F1LDkiJrdIGbEzyFJyOyf6vBdyZ1TG3sME= should be
sufficiently random (and, fortuitously, this invocation of base64(1) did
not emit any non-URL-safe characters!).

     this request automatically, or you might have to paste the first
     token part into an external program.

(side note) "subject line" might be more accessible for an ordinary user
of such a service than "first token part".

Section 3.2

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

Again, is this required to match the rfc822Name SAN in the CSR?

   9.  In order to prove authenticity of a response message, it MUST be
       DKIM [RFC6376] signed.  The resulting DKIM-Signature header field
       MUST contain the "h=" tag that includes at least "From",
       "Sender", "Reply-To", "To", "CC", "Subject", "Date", "In-Reply-
       To", "References", "Message-ID", "Content-Type", and "Content-
       Transfer-Encoding" header fields.  The message MUST also pass
       DMARC validation [RFC7489], which implies DKIM and SPF validation
       [RFC7208].

[same comments as for the challenge message]

      Date: Sat, 1 Sep 2018 11:12:00 +0100
      Message-ID: <[email-masked]>
      From: [email-masked]
      To: [email-masked]
      Subject: Re: ACME: <base64url-encoded-token-with-enough-entropy>

We should probably have an In-Reply-To to tie us to the challenge
example, and the same date and token1 updates as for the challenge
example.

      -----BEGIN ACME RESPONSE-----
      LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowy
      jxAjEuX0.9jg46WB3rR_AHD-EBXdN7cBkH1WOu0tA3M9
      fm21mqTI
      -----END ACME RESPONSE-----

I see that Barry already noted the non-base64url '.' character, and
also fail to understand the explanation about JWS.  (It okay to hit me
over the head with it, too.)
The content here also does not seem to be JWS itself, since the base64
of both components decodes to non-ASCII stuff, and JWS would have a JSON
header (and two '.'s).

Section 4

   [RFC8616] updated/clarified use of DKIM/SPF/DMARC with
   Internationalized Email addresses [RFC6531].  Please consult RFC 8616
   in regards to any changes that need to be implemented.

Changes with respect to what baseline?

Section 6

Related to my discuss point, it may be worth saying something about how
clients should not provide any special treatment to messages with
"ACME:" in the subject if they are not aware of any pending ACME
email validations.

   3.  protocol specified in this document is not suitable for use with

nit: "the protocol"

   Use of DNSSEC by email system administrators is recommended to avoid
   making it easy to spoof DNS records affecting email system.  However
   use of DNSSEC is not ubiquitous at the time of publishing of this
   document, so it is not required here.  [...]

That's a fairly weak justification; we should prioritize doing the right
thing if it is in conflict with what is currently deployed.  I'd almost
prefer to just drop this justification and leave the subsequent
comparison to other existing ("trustworthy enough") systems to stand on
its own merits.

   [...]                                                  So the risk of
   not requiring DNSSEC is presumed acceptable in this document.

I suggest adding "at the time of this writing" (or similar).

Section 7

RFC 6234 would work just as well as FIPS180-4 for a SHA256 reference,
right?

RFCs 4021 and 8058 are cited as things that you MUST NOT use, which does
not normally require them to be normative references.

RFC 8550 is cited only in the introductory remarks and may not need to
be normative.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 5 Nov 2020 11:07:02 +0000

Hi Ben,

I am sending you a partial reply, as I am still editing the document 
based on some of your more detailed comments:

We might need to have a conference call, as I don't fully understand 
your concerns here. But let me think about this a bit more.
> triggered to start the request.
Yes. When I wrote this text I was thinking either user pushing a button 
on a CA's website saying "initiate S/MIME certificate issuance for me", 
running a command line tool a la Let's Encrypt or pushing a button in an 
ACME-aware MUA. Can you suggest how to clarify this?
Making them both 128 bits is fine with me.
> attacks.
Can you elaborate on this? Responses would have some kind of prefix in 
front of "ACME" (e.g. "Re: ACME: ..."), so they will never be the same 
subjects as in challenges.
> We could give some warnings about this in the security

Already fixed in my copy due to other comments.

Best Regards,

Alexey

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 6 Nov 2020 14:29:40 -0800

Hi Alexey,

> based on some of your more detailed comments:

Sure, happy to handle things in batches.

> your concerns here. But let me think about this a bit more.

[We have scheduled a call, out of band.]

Maybe I can try to step through the http case and the email case.
I am sure I will miss some steps since the distinction between user, web
server/email operator, ACME client, and possibly other entities, can be
fuzzy at times.

For HTTP, it's something like:

1) user wants a cert
2) user makes ACME client create a new order
3) ACME server creates the order+challenge, returning token to ACME client
4) user gets token from ACME client and provisions the webserver to handle
  a challenge with that token
5) ACME server makes an HTTP validation query using the token value
6) webserver responds to challenge using key authorization
7) success

Note that in (4) the webserver knows what token to expect, so the
challenge/response are tightly tied to the particular order (because the
token value is tied to the order).

For email, it seems like we're proposing:

1) user wants a cert
2) user directs email client to direct ACME client to create a new order
3) ACME server creates the order+challenge, returns token-part2 to ACME
  client
4) user directs email client or other infrastructure to expect a challenge
  (including token-part2)
5) ACME server sends challenge email with token-part1
6) email client notes that an ACME challenge arrived, searches for
  information about any pending expected challenges, and finds token-part2
7) user/email client produces challenge response including key
  authorization (using token-part1 and token-part2)

The part in (6) where the email client has to search for all/any pending
expected challenges seems much weaker than in the HTTP case, as *any*
incoming message formatted like an ACME challenge could elicit the response
message.  This would not directly leak token-part2 (IIUC -- there would be
a pretty straightforward copy/paste attack if we did!) since we hash the
key authorization before transport, but it still seems problematic (and
could, e.g., reveal that the client is expecting an incoming ACME
challenge).  It seems "safer" in some intuitive sense if the email client
knows exactly what challenge to expect and that is tied to a specific
order.  The challenge does need to include some information that is not
obtained in any other way, though, of course.

> ACME-aware MUA. Can you suggest how to clarify this?

I am not sure how the "button on CA's website" would work -- you need a
full ACME client with registered key/etc. in order for the ACME order flow
to work.  I am pretty sure that the architecture assumes that the ACME
client is associated with the entity receiving the cert (often, but not
always, colocated), not with the CA.

My current best thought is that we say up front that there is an ACME
client involved in the issuance process, which could be integrated into a
MUA, a local command-line command, etc.  Then the subsequent steps that
involve that ACME client have more context.

> subjects as in challenges.

I guess I had not looked closely at this subtlety, but having done so, I am
not convinced that we can really rely on the "ACME:" in the challenge being
the start of the subject (nor do we imply that the client needs to be
enforcing this attribute!).  Consider, for example, how many "[BULK]",
"[EXTERNAL]", etc. tags are added in various environments.  So in practice,
I expect "Subject: <arbitrary stuff> ACME: <token-part1>" to match as both
a challenge and as a response.  I am not sure what cost there would be in a
client changing it to use (e.g.) "ACME-RESPONSE:" in the response, and not
having to worry about reflection or misbinding attacks seems like a
significant benefit, so the cost/benefit analysis seems pretty clear to me
so far :)

> Already fixed in my copy due to other comments.

Thanks!

-Ben

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 12 Nov 2020 10:33:37 +0000

Hi Ben,

>    authorization (using token-part1 and token-part2)
Thank you for this. I agree that this level of details is definitely 
missing from the current draft and I will expand on the above in the 
next version of the draft.
> message.
As a side note: the above ("expecting challenges") is true for 
ACME-aware email client, but not for the case of unaware email client.
> This would not directly leak token-part2 (IIUC -- there would be
Ok. I am open to suggestions about what should be included in the ACME 
email challenge.
> always, colocated), not with the CA.
For the button on the website case I was thinking about integrated web 
mail and hosted email. Think of Gmail or Fastmail case. The ACME client 
will be a part of the web mail client and will be preconfigured to talk 
to a specific ACME server.
> MUA, a local command-line command, etc.
Yes. I spent some time drawing diagrams for cases when ACME client is a 
part of MUA, as well as when ACME client is a stand alone command line 
tool or a web server. Luckily the workflow is pretty much the same in 
all these cases.
> Then the subsequent steps that
> "[EXTERNAL]", etc. tags are added in various environments.
Hmm, Ok. Can we describe generic structure of these exta tags in ABNF? 
(See why below.)
> So in practice,
Using ACME-RESPONSE would work for ACME-aware email clients, but doesn't 
work if one just wants to continue using their Thunderbird or Outlook. 
(Because telling users that they need to paste something in a reply AND 
they have to modify the subject of replies is just too error prone). I 
still want the case of ACME-unaware email client to be supported.

Best Regards,

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 12 Nov 2020 16:28:39 +0000

Hi Ben,

> triggered to start the request.

I propose the following new description to address your above DISCUSS 
points. This probably needs another editorial pass for readability, but 
I think the new description is much better for implementors:

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

    1.  An end-user initiates issuance of an S/MIME certificate for one
        of her email addresses.  This might be done using email client
        UI, by running a command line tool, by visiting a Certificate
        Authority web page, etc.  This document doesn't prescribe
        specific UI used to initiate S/MIME certificate issuance.

    2.  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 [RFC8555] for more details.

    3.  The ACME server responds to the POST request, including
        "authorizations" URL for the requested email address.  The ACME
        client then retrieves information about the corresponding "email-
        reply-00" challenge as specified in Section 7.5 of [RFC8555].
        The "token" field of the corresponding "challenges" array element
        (which contains "type": "email-reply-00" as another field)
        contains token-part2. token-part2 should contain at least 128
        bits of entropy.

    4.  After responding to the authorization request the ACME server
        generates another token and a "challenge" email message with the
        subject "ACME: <token-part1>", where <token-part1> is the
        base64url encoded [RFC4648] of the token.  The ACME server MUST
        generate a fresh token for each S/MIME issuance request
        (authorization request), and token-part1 MUST contain at least
        128 bits of entropy.  The challenge email message structure is
        described in more details in Section 3.1.

    5.  The MUA retrieves and parses the challenge email message. The
        ACME client concatenates "token-part1" (received over email) and
        "token-part2" (received over HTTPS [RFC2818]) to create ACME
        "token", calculates keyAuthorization (as per Section 8.1 of
        [RFC8555]), then returns the base64url encoded SHA-256 digest
        [FIPS180-4] of the key authorization.  The MUA returns the
        base64url encoded SHA-256 digest obtained from the ACME client in
        the body of a response email message.  The response email message
        structure is described in more details in Section 3.2.

    6.  Once the MUA sends the response email, the ACME client can start
        polling the authorization URL (using POST-as-GET request) to see
        if the ACME server received and validated the response email
        message.  (See Section 7.5.1 of [RFC8555] for more details.)  If
        the "status" field of the challenge switches to "valid", then the
        ACME client can proceed with request finalization.  The
        Certificate Signing Request (CSR) MUST indicate the exact same
        set of requested identifiers as the initial newOrder request.
        For an identifier of type "email", the PKCS#10 [RFC2986] CSR MUST
        contain the requested email address in an extensionRequest
        attribute [RFC2985] requesting a subjectAltName extension. If a
        request to finalize an order is successful, the ACME server will
        return a 200 (OK) with an updated order object.  If the
        certificate is issued successfully, i.e. if the order "status" is
        "valid", then the ACME client can download the issued S/MIME
        certificate from the URL specified in the "certificate" field.

Best Regards,

Alexey

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 12 Nov 2020 15:48:25 -0800

Hi Alexey,

Part of what I include below is trying to summarize what we talked about on
our call earlier today; this will both help get our thoughts organized in a
semi-coherent fashion and let them get broader visibility.

> ACME-aware email client, but not for the case of unaware email client.

Yes.  (In theory a user intermediating between a MUA and standalone ACME
client could also play this role, but it is hard to actually expect the
user to do so.)

On a related note, the thread with Fraser, combined with our live
discussion earlier today, made me realize that we really should say what
the contents of the 'url' field of the challenge object are.  I know Fraser
wanted it to be an HTTPS resource, but it seems like a mailto: URL might
make more sense.  A mailto: URL could also (in some cases) play the role of the
"token-part0" I had pondered about previously, in that if the ACME server
uses a challenge-specific address with sufficient entropy, and that is
the From: line of the challenge email, then a sufficiently aware MUA/client
can use that address to link the incoming challenge email with the pending
ACME challenge. (More below.)

> Ok. I am open to suggestions about what should be included in the ACME 

As we discussed on our call, it's unusual to have information be both in
the Subject and body of the automated (challenge) email, so my initial
strawman doesn't look so great.  It's also good to think about what risks
this mechanism would be protecting against -- it seems that, in the absence
of such a linkage mechanisms, the risk is that a MUA+client would
(potentially automatically) produce a response email in response to a
forged challenge email.  The From: line of the forged message could, of
cousre, 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.
Furthermore, if the attacker causes the erroneous response email to go to
an attacker-controlled address, very little information is leaked -- we
send only the SHA256 hash of the key authorization, not the key
authorization itself, so no parts of the token or the the account key
thumbprint are leaked.  In effect, the attacker has one chance to guess the
token-part1, and that's about it, and there's still the issue of the
account key thumbprint to consider as well.

Given this level of risk, just checking the challenge email's From address
against the challenge url may be a sufficient defense, even if the email
address in question does not contain much entropy.

> Hmm, Ok. Can we describe generic structure of these exta tags in ABNF? 

I am not confident that we can do so to any real degree of reliability.

> still want the case of ACME-unaware email client to be supported.

That's a worthy goal.

Let's consider what the risks are if such an attack occurs.  A legitimate
client can limit itself to sending only one response email per ACME
challenge, and can treat messages that look like replies as not being valid
challenge emails, so any given misdirected response email will produce at
most one additional/reflected response email from any given client.
Furthermore, a closed loop of self-sustaining reflections is not possible
because nobody is going to inadvertently strip the reply prefix, and any
given node will reject the reply prefix it adds.  So perhaps a chain of a
few reflections might be possible if there are some clients that use
different reply-prefix tags and the To/From/Reply-To works out (which I
didn't even try to think through), but it will stop pretty fast.
Furthermore, there's not much information leakage from a reflected
response, since you can't learn a valid token-part1 with it (you'd have to
spoof the message that introduces the token-part1, and thus guess the
token-part1 at the same time), and the other body content (the PEM-like
ACME RESPONSE) is a SHA256 output that is also fairly hard to attack, with
a lot of its input being unpredictable.  On the whole, these risks don't
seem to be terribly significant, so a countermeasure that only mostly works
may be good enough, which is basically what the reply-prefix tagging is
doing.  I expect that MUAs can use reasonable heuristics for what is or
isn't a reply prefix and act accordingly.

So, in summary, we should add text recommending (or requiring?) that an
ACME client does add some kind of (nonempty) reply prefix to its response
subject line, that it treat messages containing that reply prefix before
"ACME:" as invalid challenges, ideally that it has stronger heuristics than
that about reply prefixes, and that it produce at most one response email
per ACME challenge.

Does that seem reasonable?

Thanks,

Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 12 Nov 2020 15:56:23 -0800

Hi Alexey,

> I think the new description is much better for implementors:

Yes, I like it.  Editorial notes inline...

>         specific UI used to initiate S/MIME certificate issuance.

Maybe also add "or where the ACME client is located" or similar at the end
of the sentence?

>     3.  The ACME server responds to the POST request, including

nit: "an"

>         contains token-part2. token-part2 should contain at least 128

Per my other message, we should talk about the "url" contents as well.

>         base64url encoded [RFC4648] of the token.  The ACME server MUST

nit: missing word ("form" or "version" or something, for "encoded version
of the token")

>         described in more details in Section 3.1.

We might also note that the "From:" line matches the "url" field of the
challenge object.

>         "token-part2" (received over HTTPS [RFC2818]) to create ACME

(We might in theory length-prefix the token parts before concatenating for
hygiene purposes, but the way they are generated doesn't really seem to
open any attacks.)

nit: "the ACME"

>         polling the authorization URL (using POST-as-GET request) to see

nit: "requests" plural

Many thanks,

Ben

---

From: Fraser Tweedale <[email-masked]>
Date: Sat, 14 Nov 2020 14:47:03 +1000

> ACME challenge. (More below.)

Hi Benjamin,

It is an interesting idea.  A mailto: challenge URL seems
technically feasible but has some consequences:

- RFC 8555 says that the client POSTs to that URL, implying HTTPS.
  We can define a different semantics for a different challenge
  types, but...

- POST to an HTTPS URL, after email was sent, should work fine for
  the "email-reply-00" validation method.  It is coherent with other
  challenge types (prepare HTTP resource then notify; create DNS
  records then notify; etc).  I don't think we should forfeit this
  cohesion lightly; it will aid implementors of both clients and
  servers to keep the mental model for difference challenge types as
  close as possible.

- And, as I discussed in the other thread, NOT having the client
  POST to notify the server that challenge email was sent does
  restrict the ways you could implement the server.  Specifically,
  the Mail Delivery Agent would have to _proactively_ perform
  ACME-related processing of received messages.  Compare to a server
  implementation where the MDA can just store mail somewhere, and
  the ACME server can search for the reply after client has POSTed
  that the mail was sent.  This maintains a nice separation between
  mail delivery, and ACME server behaviour.  If I were implementing
  the server side, this is how I would prefer to do it.

Cheers,
Fraser

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 16 Nov 2020 04:11:19 -0800

Hi Fraser,

>   We can define a different semantics for a different challenge

Ah, you're quite right.  I apparently jumped to the line "[t]he URL to
which a response can be posted" and missed the previous "the client
responds by sending a response object in a POST request to a challenge
URL."

So it seems we may want to reiterate these URL semantics and add a
different field to convey the email address associated with the response
email.

(I read the stuff below and can't argue with it.)

Thanks!

Ben

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 17 Nov 2020 12:49:52 +0000

Hi Ben,

> Maybe also add "or where the ACME client is located" or similar at the end
Yes. Good idea. I included all of your editorial suggestions in the 
upcoming -12. Also see my comment below.
> Per my other message, we should talk about the "url" contents as well.
Yes, I will post -12 shortly and I will address this change in -13.