Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.
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.
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: <A2299BB.FF7788@example.org> We might consider moderninzing the date to something closer to the time of final publication. Subject: ACME: <base64url-encoded-token-with-64-bits-of-entropy> I feel like it might be more illustrative to just include some random base64. E.g., LgYemJLy3F1LDkiJrdIGbEzyFJyOyf6vBdyZ1TG3sME= should be sufficiently random (and, fortuitously, this invocation of base64(1) did not emit any non-URL-safe characters!). this request automatically, or you might have to paste the first token part into an external program. (side note) "subject line" might be more accessible for an ordinary user of such a service than "first token part". Section 3.2 2. The From: header field contains the email address of the user that is requesting S/MIME certificate issuance. Again, is this required to match the rfc822Name SAN in the CSR? 9. In order to prove authenticity of a response message, it MUST be DKIM [RFC6376] signed. The resulting DKIM-Signature header field MUST contain the "h=" tag that includes at least "From", "Sender", "Reply-To", "To", "CC", "Subject", "Date", "In-Reply- To", "References", "Message-ID", "Content-Type", and "Content- Transfer-Encoding" header fields. The message MUST also pass DMARC validation [RFC7489], which implies DKIM and SPF validation [RFC7208]. [same comments as for the challenge message] Date: Sat, 1 Sep 2018 11:12:00 +0100 Message-ID: <email@example.com> From: firstname.lastname@example.org To: email@example.com Subject: Re: ACME: <base64url-encoded-token-with-enough-entropy> We should probably have an In-Reply-To to tie us to the challenge example, and the same date and token1 updates as for the challenge example. -----BEGIN ACME RESPONSE----- LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowy jxAjEuX0.9jg46WB3rR_AHD-EBXdN7cBkH1WOu0tA3M9 fm21mqTI -----END ACME RESPONSE----- I see that Barry already noted the non-base64url '.' character, and also fail to understand the explanation about JWS. (It okay to hit me over the head with it, too.) The content here also does not seem to be JWS itself, since the base64 of both components decodes to non-ASCII stuff, and JWS would have a JSON header (and two '.'s). Section 4 [RFC8616] updated/clarified use of DKIM/SPF/DMARC with Internationalized Email addresses [RFC6531]. Please consult RFC 8616 in regards to any changes that need to be implemented. Changes with respect to what baseline? Section 6 Related to my discuss point, it may be worth saying something about how clients should not provide any special treatment to messages with "ACME:" in the subject if they are not aware of any pending ACME email validations. 3. protocol specified in this document is not suitable for use with nit: "the protocol" Use of DNSSEC by email system administrators is recommended to avoid making it easy to spoof DNS records affecting email system. However use of DNSSEC is not ubiquitous at the time of publishing of this document, so it is not required here. [...] That's a fairly weak justification; we should prioritize doing the right thing if it is in conflict with what is currently deployed. I'd almost prefer to just drop this justification and leave the subsequent comparison to other existing ("trustworthy enough") systems to stand on its own merits. [...] So the risk of not requiring DNSSEC is presumed acceptable in this document. I suggest adding "at the time of this writing" (or similar). Section 7 RFC 6234 would work just as well as FIPS180-4 for a SHA256 reference, right? RFCs 4021 and 8058 are cited as things that you MUST NOT use, which does not normally require them to be normative references. RFC 8550 is cited only in the introductory remarks and may not need to be normative.
[ section 2 ] * Use the 8174 text? [ section 6 ] * I think it's fair to all-caps RECOMMENDED the use of DNSSEC.
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.
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.
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