Skip to main content

Extensions to Automatic Certificate Management Environment for End-User S/MIME Certificates
draft-ietf-acme-email-smime-14

Revision differences

Document history

Date Rev. By Action
2024-01-26
14 Gunter Van de Velde Request closed, assignment withdrawn: Jouni Korhonen Last Call OPSDIR review
2024-01-26
14 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'Overtaken by Events': Cleaning up stale OPSDIR queue
2021-04-17
14 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2021-03-31
14 (System) RFC Editor state changed to AUTH48
2021-03-02
14 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2021-02-17
14 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2021-02-17
14 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2021-02-17
14 (System) IANA Action state changed to In Progress from Waiting on Authors
2021-02-17
14 (System) IANA Action state changed to Waiting on Authors from In Progress
2021-02-16
14 (System) RFC Editor state changed to EDIT
2021-02-16
14 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2021-02-16
14 (System) Announcement was received by RFC Editor
2021-02-15
14 (System) IANA Action state changed to In Progress
2021-02-15
14 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2021-02-15
14 Cindy Morgan IESG has approved the document
2021-02-15
14 Cindy Morgan Closed "Approve" ballot
2021-02-15
14 Cindy Morgan Ballot approval text was generated
2021-02-15
14 Roman Danyliw IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2021-02-15
14 Alexey Melnikov New version available: draft-ietf-acme-email-smime-14.txt
2021-02-15
14 (System) New version accepted (logged-in submitter: Alexey Melnikov)
2021-02-15
14 Alexey Melnikov Uploaded new revision
2021-01-13
13 Benjamin Kaduk
[Ballot comment]
Thanks for the updates to get to the -13; they look really good.

The new text did inspire one further comment, though I …
[Ballot comment]
Thanks for the updates to get to the -13; they look really good.

The new text did inspire one further comment, though I don't see a
particular text change that might result, plus I spotted a few editorial nits.

Section 1

  1.  A Mail User Agent (MUA) which has built in ACME client aware of
      the extension described in this document.  (We will call such
      ACME clients "ACME-email-aware") Such MUA can present nice User
      Interface to the user and automate certificate issuance.

(nit?) In the parenthetical, are we calling the ACME clients or the MUA
"ACME-email-aware"?  Also, full stop for the end of the sentence.

Section 3

(nit?) In step 8, the MUST-level requirement in the last sentence probably
promotes it into not being a parenthetical.

Section 3.1

          If S/MIME signing is used, the certificate corresponding to
          the signer MUST have rfc822Name subjectAltName extension with
          the value equal to the From header field email address of the
          "challenge" email.

A strict equality requirement might make it operationally challenging to
use a unique "from" challenge for each request.  I don't see any
feasible alternative, though, as getting into + suffixes in the local
part seems like a non-starter for this document.

Also, nit: s/subjectAltName extension/a subjectAltName extension/
2021-01-13
13 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to Yes from Discuss
2020-11-20
13 Alexey Melnikov New version available: draft-ietf-acme-email-smime-13.txt
2020-11-20
13 (System) New version accepted (logged-in submitter: Alexey Melnikov)
2020-11-20
13 Alexey Melnikov Uploaded new revision
2020-11-18
12 Barry Leiba
[Ballot comment]
Thanks for discussing things with me and addressing my comments.  Version -12 takes care of all my comments except for the one in …
[Ballot comment]
Thanks for discussing things with me and addressing my comments.  Version -12 takes care of all my comments except for the one in Section 2:  Please use the new BCP 14 boilerplate and add a normative reference to RFC 8174.

The changes from version -10 do introduce a few typos and nits, so I'll record them here; please consider fixing them, but there's no need to respond further.

— Section 1 —

  This document aims to support both:

I suggest saying what it does, rather than what it aims to do.  Also (nit), as the two numbered items are each multiple sentences, the intro is better worded thus:

NEW
  This document supports both of the following:
END

  Such MUA can present nice User
  Interface to the user and automate certificate issuance.

Nits: there are articles missing, “user interface” doesn’t need capitalization, and “user interface to the user” is redundant:

NEW
  Such an MUA can present a nice
  interface to the user and automate certificate issuance.
END

In the second bullet, make it “An MUA”, as we pronounce it “em-yoo-ay”, not “moo-ah”.

— Section 3 —

  The process of issing an S/MIME certificate works as follows.

Typo: make it “issuing”.

— Section 3.1 —

  To aid in debugging (and in for some

Typo: change “in for” to “for”.

— Section 3.2 —
In bullet 7:

      The text/plain body part (whether or not it is
      inside multipart/alternative) MUST contain a block of lines
      starting with the line "-----BEGIN ACME RESPONSE-----", followed
      by one or more line containing the base64url-encoded SHA-256
      digest [FIPS180-4] 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
      Section 3.

You changed this from “3rd bullet” to the new “5th bullet”, but I don’t understand why: it’s still the third bullet that talks about how the content is formed.
2020-11-18
12 Barry Leiba [Ballot Position Update] Position for Barry Leiba has been changed to No Objection from Discuss
2020-11-18
12 Alexey Melnikov New version available: draft-ietf-acme-email-smime-12.txt
2020-11-18
12 (System) New version accepted (logged-in submitter: Alexey Melnikov)
2020-11-18
12 Alexey Melnikov Uploaded new revision
2020-11-17
11 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-11-17
11 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2020-11-17
11 Alexey Melnikov New version available: draft-ietf-acme-email-smime-11.txt
2020-11-17
11 (System) New version accepted (logged-in submitter: Alexey Melnikov)
2020-11-17
11 Alexey Melnikov Uploaded new revision
2020-11-05
10 Tero Kivinen Request for Telechat review by SECDIR Completed: Ready. Reviewer: Hilarie Orman.
2020-11-05
10 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2020-11-05
10 Éric Vyncke
[Ballot comment]
Thank you for the work put behind this document, it could indeed be really useful.

My only comment is support to Barry's point …
[Ballot comment]
Thank you for the work put behind this document, it could indeed be really useful.

My only comment is support to Barry's point about the intended status of the document.

Regards

-éric
2020-11-05
10 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2020-11-05
10 Benjamin Kaduk
[Ballot discuss]
I have one point that I am not sure of the significance of and would
like to discuss further, and one point that …
[Ballot 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.
2020-11-05
10 Benjamin Kaduk
[Ballot comment]
The discuss point notwithstanding, if we assume that the current
validation process does provide the necessary linkage across steps, it
seems that the …
[Ballot 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:

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

    Subject: ACME:

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: <111-22222-3333333@example.com>
      From: alexey@example.com
      To: acme-generator@example.org
      Subject: Re: ACME:

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.
2020-11-05
10 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2020-11-04
10 Murray Kucherawy
[Ballot comment]
I support Barry's DISCUSS, especially the bit that references DMARC. 

You might mention in Security Considerations that the DKIM and DMARC RFCs discuss …
[Ballot comment]
I support Barry's DISCUSS, especially the bit that references DMARC. 

You might mention in Security Considerations that the DKIM and DMARC RFCs discuss their dependence on the DNS as well, and their respective vulnerabilities.

It seems to me that the second paragraph of Security Considerations says approximately the same thing that the (1) bullet does in the same section.
2020-11-04
10 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2020-11-04
10 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2020-11-04
10 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2020-11-04
10 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2020-11-03
10 Erik Kline
[Ballot comment]
[ section 2 ]

* Use the 8174 text?

[ section 6 ]

* I think it's fair to all-caps RECOMMENDED the use …
[Ballot comment]
[ section 2 ]

* Use the 8174 text?

[ section 6 ]

* I think it's fair to all-caps RECOMMENDED the use of DNSSEC.
2020-11-03
10 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2020-11-02
10 Martin Duke [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke
2020-10-30
10 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2020-10-29
10 Tero Kivinen Request for Telechat review by SECDIR is assigned to Hilarie Orman
2020-10-29
10 Tero Kivinen Request for Telechat review by SECDIR is assigned to Hilarie Orman
2020-10-28
10 Barry Leiba
[Ballot discuss]
(Sorry; I forgot to include the first item in my initial DISCUSS ballot.)

I question why this is Informational, and the shepherd writeup …
[Ballot discuss]
(Sorry; I forgot to include the first item in my initial DISCUSS ballot.)

I question why this is Informational, and the shepherd writeup doesn't really explain it.  I get that this fills a gap, and that the working group wants to see this adopted.  I don't get why, therefore, you aren't proposing a standard here.  What is the point of making this Informational, and not Proposed Standard... or Experimental, if you're less sure of whether it will work as expected?

— Section 3.1 —

      [RFC2231] encoding of the message Subject header field
      MUST be supported, but when used, only "UTF-8" and "US-ASCII"
      charsets MUST be used (i.e. other charsets MUST NOT be used).

NOT DISCUSS: I don’t like the second use of MUST: it’s confusing (for example, it’s not the case that you always MUST use both charsets).  I suggest this:

NEW
  [RFC2231] encoding 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.
END

DISCUSS: That said, I don’t understand the need to specifically allow UTF-8 here.  If the subject only contains “ACME:”, FWS, and a base64 string, it will always be ASCII.  Why are we talking about UTF-8 at all?

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

Two things here, which apply to bullet 9 in Section 3.2 also:

1. DMARC does not imply DKIM *and* SPF validation: DMARC uses DKIM *or* SPF to do Identifier Alignment.

2. I have an issue with requiring the use of DMARC at this point, as it’s specified only in an Informational document in the Independent stream.  In any case, what’s the point of requiring DMARC?  It seems to me that the authentication you need is provided by DKIM or S/MIME; what do you need from DMARC?
2020-10-28
10 Barry Leiba Ballot discuss text updated for Barry Leiba
2020-10-28
10 Barry Leiba
[Ballot discuss]
— Section 3.1 —

      [RFC2231] encoding of the message Subject header field
      MUST be supported, …
[Ballot discuss]
— Section 3.1 —

      [RFC2231] encoding of the message Subject header field
      MUST be supported, but when used, only "UTF-8" and "US-ASCII"
      charsets MUST be used (i.e. other charsets MUST NOT be used).

NOT DISCUSS: I don’t like the second use of MUST: it’s confusing (for example, it’s not the case that you always MUST use both charsets).  I suggest this:

NEW
  [RFC2231] encoding 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.
END

DISCUSS: That said, I don’t understand the need to specifically allow UTF-8 here.  If the subject only contains “ACME:”, FWS, and a base64 string, it will always be ASCII.  Why are we talking about UTF-8 at all?

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

Two things here, which apply to bullet 9 in Section 3.2 also:

1. DMARC does not imply DKIM *and* SPF validation: DMARC uses DKIM *or* SPF to do Identifier Alignment.

2. I have an issue with requiring the use of DMARC at this point, as it’s specified only in an Informational document in the Independent stream.  In any case, what’s the point of requiring DMARC?  It seems to me that the authentication you need is provided by DKIM or S/MIME; what do you need from DMARC?
2020-10-28
10 Barry Leiba
[Ballot comment]
— Section 2 —
Please use the new BCP 14 boilerplate and add a normative reference to RFC 8174.

— Section 3 …
[Ballot comment]
— Section 2 —
Please use the new BCP 14 boilerplate and add a normative reference to RFC 8174.

— Section 3 —

  This document defines a new Identifier Type "email" which corresponds
  to an (all ASCII) email address [RFC5321] or Internationalized Email
  addresses [RFC6531].  (When Internationalized Email addresses are
  used, both U-labels and A-labels [RFC5890] are allowed in the domain
  part.)

Why “an email address” (singular) when it’s ASCII and “email addresses” (plural) when they’re internationalized?  I think you mean for this to be a single address in either case.  Also, why capitalize “internationalized”, and why capitalize “email” only when it’s internationalized?  I’m also not fond of putting important things and normative requirements in parentheses.

I suggest this (and similar comments apply to Section 5.1):

NEW
  This document defines a new Identifier Type "email" that identifies
  an email address.  The address can be all ASCII [RFC5321] or
  internationalized [RFC6531]; when an internationalized email
  address is used, the domain part can contain both U-labels and
  A-labels [RFC5890].
END

  2.  The ACME server (run by the Certificate Authority or their
      authorized third party) generates a "challenge" email message
      with the subject "ACME: ", where  is
      the base64url encoded [RFC4648] first part of the token, which
      contains at least 64 bits of entropy.  (ACME server MUST generate
      token afresh for each S/MIME issuance request.)

When I get to “the token,” my first thought is “What token?”  And in the description that follows it isn’t clear whether the 64 bits of entropy applies to token-part1, or to the token itself.  I suggest this:

NEW
  2.  The ACME server (run by the Certificate Authority or their
      authorized third party) generates a token and a "challenge"
      email message with the subject "ACME: ", where
        is the base64url encoded [RFC4648] first part of
      the token.  The ACME server MUST generate a fresh token for each
      S/MIME issuance request, and token-part1 MUST contain at least
      64 bits of entropy.
END

— Section 3.1 —

  3.  The message MAY contain a Reply-To header field.

It seems odd to expliticly call this out without explanation.  It makes me wonder whether I should do that or not.  Is there a reason I’d want to?  Is there a reason I wouldn’t?

      The "Auto-Submitted" header field SHOULD
      include the "type=acme" parameter.

Why not MUST?  What are the consequences of not doing this, and why might it be hard to?

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

These should properly be “DKIM-signed” and “S/MIME-signed”, but the citations make that awkward.  I suggest instead, “MUST be signed using either DKIM [RFC6376] or S/MIME [RFC8551].”

      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.

Do you not also want to include “Auto-Submitted”, given that its inclusion in the message is a MUST?
     
  An example ACME "challenge" email (note that DKIM related header
  fields are not included for simplicity).

Make it “(note that for simplicity, DKIM-related header fields are not included).”

— Section 3.2 —

Bullet 1 seems a bit confusingly worded, and is anyway overspecified because it’s just formed as a reply to the incoming message.  I suggest simply referring to Section 3.1 bullet 1 for the format, something like this:

NEW
  1.  The message Subject header field is formed as a reply to the
      ACME challenge email (see Section 3.1).  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 [RFC5322]), as is normal in reply messages. When
      parsing the subject, ACME servers must decode [RFC2231] encoding
      (if any) and then they can ignore any prefix before the "ACME:"
      label.
END

  4.  The Cc: header field is ignored if present in the "response"
      email message.

Why is it necessary to say this?  And if it is, why is it not necessary to say it in Section 3.1?

  5.  The In-Reply-To: header field SHOULD be set to the Message-ID
      header field of the challenge message according to rules in
      Section 3.6.4 of [RFC5322].

As with an earlier comment: Why is this SHOULD and not MUST?

In bullet 7:

      See the 3rd bullet point in Section 3 for
      more details.

But there aren’t actually any more details there.  Maybe just append, “as outlined in the 3rd bullet point in Section 3,” to the previous sentence.

  8.  There is no need to use any Content-Transfer-Encoding other than
      7bit for the text/plain body part, however use of Quoted-
      Printable or base64 is not prohibited in a "response" email
      message.

Is the “is not prohibited” meant to discourage it?  If so, that should be done more directly.  In any case, we’re better off avoiding the use of two negatives to make a positive: “is permitted”.

For bullet 9, see my comments about bullet 5 in Section 3.1, with the additional concern that requiring DMARC on this side limits the end user, who has no control over whether her domain does or doesn’t publish DMARC policies.

  Example ACME "response" email (note that DKIM related header fields
  are not included for simplicity).

Same comment as in 3.1.

The example body contains a “.”, which is not a valid base64url character.

— Section 6 —

  Any claims about the correctness or
  fitness-for-purpose of the email address must be otherwise assured.
  I.e.  ACME server is only vouching that the requested email address
  seem to belong to the entity that requested the certificate.

The “i.e.” part doesn’t make sense to me: “seem to belong” is understating it, isn’t it?  The point of this is assurance, not “seem to”.  Maybe this?:

NEW
  The ACME server is confirming that the requested email address
  belongs to the entity that requested the certificate, but this
  makes no claim to correctness or fitness-for-purpose of the
  address.  It such claims are needed they must be obtained by
  some other mechanism.
END
2020-10-28
10 Barry Leiba [Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba
2020-10-28
10 Roman Danyliw IESG state changed to IESG Evaluation from Waiting for Writeup::AD Followup
2020-10-28
10 Amy Vezza Placed on agenda for telechat - 2020-11-05
2020-10-28
10 Rich Salz
Summary
This is the shepherd write-up for draft-ietf-acme-email-smime.

The shepherd is Rich Salz, who has been WG co-chair since the initial BoF. Roman is the …
Summary
This is the shepherd write-up for draft-ietf-acme-email-smime.

The shepherd is Rich Salz, who has been WG co-chair since the initial BoF. Roman is the responsible AD. The WG is moving this forward as a informational because, while there are many individual certificate enrollment procedures, none use ACME for email and we are interested in seeking this taken up; this addresses a gap. Quoting the abstract, “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.”

Review and Consensus
The document was first adopted by the WG in June 2017. It has been discussed in-person at several IETF’s, and there has been light email discussion in the 2.75 years since. There was never any discussion about not moving this work forward. During the meetings, and on the email list, several technical issuers were discussed, probably around a dozen WG participants total. Some of the discussions included “Should this just use HTML” and the interaction/dependency on DKIM header protection. Discussion was low-key and productive and resolving issues was non-controversial. Some participants were highly involved in email/applications area.

intellectual Property
No disclosures, no IP concerns. Confirmed by the author.

Other points
There are no downref’s.  There are no nits. There are some IANA registry actions, which are called out in the draft and straightforward.

There is detailed discussion of email headers; a close ART review would be helpful.

2020-10-28
10 Roman Danyliw Ballot has been issued
2020-10-28
10 Roman Danyliw [Ballot Position Update] New position, Yes, has been recorded for Roman Danyliw
2020-10-28
10 Roman Danyliw Created "Approve" ballot
2020-10-28
10 Roman Danyliw Ballot writeup was changed
2020-10-28
10 Roman Danyliw
Should be Informational per the text in the document.  This was confirmed with WG in discussion during AD review.  LC text was sent out as …
Should be Informational per the text in the document.  This was confirmed with WG in discussion during AD review.  LC text was sent out as Proposed Standard.
2020-10-28
10 Roman Danyliw Intended Status changed to Informational from Proposed Standard
2020-10-27
10 Alexey Melnikov New version available: draft-ietf-acme-email-smime-10.txt
2020-10-27
10 (System) New version accepted (logged-in submitter: Alexey Melnikov)
2020-10-27
10 Alexey Melnikov Uploaded new revision
2020-10-27
09 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-10-27
09 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2020-10-27
09 Alexey Melnikov New version available: draft-ietf-acme-email-smime-09.txt
2020-10-27
09 (System) New version accepted (logged-in submitter: Alexey Melnikov)
2020-10-27
09 Alexey Melnikov Uploaded new revision
2020-07-26
08 Roman Danyliw IESG state changed to Waiting for Writeup::Revised I-D Needed from Waiting for Writeup
2020-07-21
08 Sabrina Tanamal IANA Experts State changed to Expert Reviews OK
2020-07-21
08 Sabrina Tanamal IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2020-07-16
08 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Hilarie Orman.
2020-07-10
08 Tero Kivinen Request for Last Call review by SECDIR is assigned to Hilarie Orman
2020-07-10
08 Tero Kivinen Request for Last Call review by SECDIR is assigned to Hilarie Orman
2020-07-09
08 Peter Yee Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Peter Yee. Sent review to list.
2020-07-09
08 (System) IESG state changed to Waiting for Writeup from In Last Call
2020-07-08
08 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2020-07-08
08 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-acme-email-smime-08. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-acme-email-smime-08. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

In the ACME Identifier Types registry on the Automated Certificate Management Environment (ACME) Protocol registry page located at:

https://www.iana.org/assignments/acme/

a new registration is to be made as follows:

Label: email
Reference: [ RFC-to-be ], RFC5321, RFC6531

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Second, in the ACME Validation Methods registry also on the Automated Certificate Management Environment (ACME) Protocol registry page located at:

https://www.iana.org/assignments/acme/

a new registration is to be made as follows:

Label: email-reply-00
Identifier Type: email
ACME: Y
Reference: [ RFC-to-be ]

As this also requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2020-07-06
08 Adam Montville Assignment of request for Last Call review by SECDIR to Adam Montville was rejected
2020-07-02
08 Tero Kivinen Request for Last Call review by SECDIR is assigned to Adam Montville
2020-07-02
08 Tero Kivinen Request for Last Call review by SECDIR is assigned to Adam Montville
2020-07-02
08 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Jouni Korhonen
2020-07-02
08 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Jouni Korhonen
2020-06-26
08 Jean Mahoney Request for Last Call review by GENART is assigned to Peter Yee
2020-06-26
08 Jean Mahoney Request for Last Call review by GENART is assigned to Peter Yee
2020-06-25
08 Cindy Morgan IANA Review state changed to IANA - Review Needed
2020-06-25
08 Cindy Morgan
The following Last Call announcement was sent out (ends 2020-07-09):

From: The IESG
To: IETF-Announce
CC: acme@ietf.org, acme-chairs@ietf.org, rsalz@akamai.com, Rich Salz , …
The following Last Call announcement was sent out (ends 2020-07-09):

From: The IESG
To: IETF-Announce
CC: acme@ietf.org, acme-chairs@ietf.org, rsalz@akamai.com, Rich Salz , draft-ietf-acme-email-smime@ietf.org, rdd@cert.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Extensions to Automatic Certificate Management Environment for end user S/MIME certificates) to Proposed Standard


The IESG has received a request from the Automated Certificate Management
Environment WG (acme) to consider the following document: - 'Extensions to
Automatic Certificate Management Environment for end
  user S/MIME certificates'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-07-09. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  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.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-acme-email-smime/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) (Informational - Independent Submission Editor stream)



2020-06-25
08 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2020-06-25
08 Roman Danyliw Last call was requested
2020-06-25
08 Roman Danyliw Last call announcement was generated
2020-06-25
08 Roman Danyliw Ballot approval text was generated
2020-06-25
08 Roman Danyliw Ballot writeup was generated
2020-06-25
08 Roman Danyliw IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2020-06-16
08 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-06-16
08 Alexey Melnikov New version available: draft-ietf-acme-email-smime-08.txt
2020-06-16
08 (System) New version accepted (logged-in submitter: Alexey Melnikov)
2020-06-16
08 Alexey Melnikov Uploaded new revision
2020-05-22
07 Roman Danyliw IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2020-05-22
07 Roman Danyliw AD Review: https://mailarchive.ietf.org/arch/msg/acme/OI3zdTCsxlytWgu3F72mNNmvBgY/
2020-05-13
07 Roman Danyliw IESG state changed to AD Evaluation from Publication Requested
2020-05-02
07 Alexey Melnikov New version available: draft-ietf-acme-email-smime-07.txt
2020-05-02
07 (System) New version accepted (logged-in submitter: Alexey Melnikov)
2020-05-02
07 Alexey Melnikov Uploaded new revision
2020-03-24
06 Rich Salz Changed consensus to Yes from Unknown
2020-03-24
06 Rich Salz Intended Status changed to Proposed Standard from Informational
2020-03-24
06 Cindy Morgan Intended Status changed to Informational from None
2020-03-24
06 Rich Salz
Summary
This is the shepherd write-up for draft-ietf-acme-email-smime.

The shepherd is Rich Salz, who has been WG co-chair since the initial BoF. Roman is the …
Summary
This is the shepherd write-up for draft-ietf-acme-email-smime.

The shepherd is Rich Salz, who has been WG co-chair since the initial BoF. Roman is the responsible AD. The WG is moving this forward as a proposed standard because, while there are many individual certificate enrollment procedures, none use ACME for email; this addresses a gap. Quoting the abstract, “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.”

Review and Consensus
The document was first adopted by the WG in June 2017. It has been discussed in-person at several IETF’s, and there has been light email discussion in the 2.75 years since. There was never any discussion about not moving this work forward. During the meetings, and on the email list, several technical issuers were discussed, probably around a dozen WG participants total. Some of the discussions included “Should this just use HTML” and the interaction/dependency on DKIM header protection. Discussion was low-key and productive and resolving issues was non-controversial. Some participants were highly involved in email/applications area.

intellectual Property
No disclosures, no IP concerns. Confirmed by the author.

Other points
There are no downref’s.  There are no nits. There are some IANA registry actions, which are called out in the draft and straightforward.

There is detailed discussion of email headers; a close ART review would be helpful.

2020-03-24
06 Rich Salz Responsible AD changed to Roman Danyliw
2020-03-24
06 Rich Salz IETF WG state changed to Submitted to IESG for Publication from WG Document
2020-03-24
06 Rich Salz IESG state changed to Publication Requested from I-D Exists
2020-03-24
06 Rich Salz IESG process started in state Publication Requested
2020-03-24
06 Rich Salz
Summary
This is the shepherd write-up for draft-ietf-acme-email-smime.

The shepherd is Rich Salz, who has been WG co-chair since the initial BoF. Roman is the …
Summary
This is the shepherd write-up for draft-ietf-acme-email-smime.

The shepherd is Rich Salz, who has been WG co-chair since the initial BoF. Roman is the responsible AD. The WG is moving this forward as a proposed standard because, while there are many individual certificate enrollment procedures, none use ACME for email; this addresses a gap. Quoting the abstract, “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.”

Review and Consensus
The document was first adopted by the WG in June 2017. It has been discussed in-person at several IETF’s, and there has been light email discussion in the 2.75 years since. There was never any discussion about not moving this work forward. During the meetings, and on the email list, several technical issuers were discussed, probably around a dozen WG participants total. Some of the discussions included “Should this just use HTML” and the interaction/dependency on DKIM header protection. Discussion was low-key and productive and resolving issues was non-controversial. Some participants were highly involved in email/applications area.

intellectual Property
No disclosures, no IP concerns. Confirmed by the author.

Other points
There are no downref’s.  There are no nits. There are some IANA registry actions, which are called out in the draft and straightforward.

There is detailed discussion of email headers; a close ART review would be helpful.

2020-03-24
06 Rich Salz Notification list changed to Rich Salz <rsalz@akamai.com>
2020-03-24
06 Rich Salz Document shepherd changed to Rich Salz
2019-11-01
06 Alexey Melnikov New version available: draft-ietf-acme-email-smime-06.txt
2019-11-01
06 (System) New version accepted (logged-in submitter: Alexey Melnikov)
2019-11-01
06 Alexey Melnikov Uploaded new revision
2019-07-08
05 Alexey Melnikov New version available: draft-ietf-acme-email-smime-05.txt
2019-07-08
05 (System) New version approved
2019-07-08
05 (System) Request for posting confirmation emailed to previous authors: Alexey Melnikov
2019-07-08
05 Alexey Melnikov Uploaded new revision
2019-04-22
04 (System) Document has expired
2018-10-19
04 Alexey Melnikov New version available: draft-ietf-acme-email-smime-04.txt
2018-10-19
04 (System) New version approved
2018-10-19
04 (System) Request for posting confirmation emailed to previous authors: Alexey Melnikov
2018-10-19
04 Alexey Melnikov Uploaded new revision
2018-09-01
03 Alexey Melnikov New version available: draft-ietf-acme-email-smime-03.txt
2018-09-01
03 (System) New version approved
2018-09-01
03 (System) Request for posting confirmation emailed to previous authors: Alexey Melnikov
2018-09-01
03 Alexey Melnikov Uploaded new revision
2018-03-04
02 Alexey Melnikov New version available: draft-ietf-acme-email-smime-02.txt
2018-03-04
02 (System) New version approved
2018-03-04
02 (System) Request for posting confirmation emailed to previous authors: Alexey Melnikov , acme-chairs@ietf.org
2018-03-04
02 Alexey Melnikov Uploaded new revision
2017-10-29
01 Alexey Melnikov New version available: draft-ietf-acme-email-smime-01.txt
2017-10-29
01 (System) New version approved
2017-10-29
01 (System) Request for posting confirmation emailed to previous authors: Alexey Melnikov , acme-chairs@ietf.org
2017-10-29
01 Alexey Melnikov Uploaded new revision
2017-06-22
00 Alexey Melnikov This document now replaces draft-melnikov-acme-email-smime instead of None
2017-06-19
00 Alexey Melnikov New version available: draft-ietf-acme-email-smime-00.txt
2017-06-19
00 (System) WG -00 approved
2017-06-19
00 Alexey Melnikov Set submitter to "Alexey Melnikov ", replaces to (none) and sent approval email to group chairs: acme-chairs@ietf.org
2017-06-19
00 Alexey Melnikov Uploaded new revision