[Acme] Barry Leiba's Discuss on draft-ietf-acme-email-smime-10: (with DISCUSS and COMMENT)
Barry Leiba via Datatracker <noreply@ietf.org> Wed, 28 October 2020 16:59 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: acme@ietf.org
Delivered-To: acme@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CCF4B3A0062; Wed, 28 Oct 2020 09:59:19 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Barry Leiba via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-acme-email-smime@ietf.org, acme-chairs@ietf.org, acme@ietf.org, Rich Salz <rsalz@akamai.com>, rsalz@akamai.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.21.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Barry Leiba <barryleiba@computer.org>
Message-ID: <160390435981.31438.14845556125639932596@ietfa.amsl.com>
Date: Wed, 28 Oct 2020 09:59:19 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/eKTwcBkMdS3Dsnizg3YK1T6awB0>
Subject: [Acme] Barry Leiba's Discuss on draft-ietf-acme-email-smime-10: (with DISCUSS and COMMENT)
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Oct 2020 16:59:20 -0000
Barry Leiba has entered the following ballot position for draft-ietf-acme-email-smime-10: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-acme-email-smime/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (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? ---------------------------------------------------------------------- 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: <token-part1>", where <token-part1> 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: <token-part1>", where <token-part1> 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
- [Acme] Barry Leiba's Discuss on draft-ietf-acme-e… Barry Leiba via Datatracker