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 |