Re: [Acme] Barry Leiba's Discuss on draft-ietf-acme-email-smime-10: (with DISCUSS and COMMENT)

[Alexey Melnikov <[e-mail]>]

Hi Barry,

Thank you for your comments.

Replying to all but a few of your comments below:

On 28/10/2020 16:55, Barry Leiba via Datatracker wrote:
> ----------------------------------------------------------------------
> 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
Done.
> 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 idea is to be as compatible with existing software (e.g. MUAs and 
web mail clients). I did some tests and some implementations 
unconditionally use UTF-8 charset label even if the data is purely 
ASCII. Thus the text above.
>         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.
Sloppy wording on my part. Would something like "which implies 
compliance with DKIM [ref] and SPF [ref]" work better?
> 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.
This is an Informational document on IETF stream, so the bar is already 
pretty low ;-). Besides you know that that DMARC itself is being revised.
> 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?

We can't use S/MIME, as the whole point of this document is to get an 
S/MIME certificate.

I suppose just requiring DKIM is fine, but properly configured SPF will 
get an extra assurance that the domain owner has a properly (securely, 
for some definition of securely) configured email system. So I am open 
to suggestions.

> ----------------------------------------------------------------------
> 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.
Yes, good point.
> Also, why capitalize “internationalized”, and
> why capitalize “email” only when it’s internationalized?
Probably because I cut and pasted this from somewhere ;-).
> I’m also not fond of
> putting important things and normative requirements in parentheses.
Good point. Removed.
> 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
Changed, thank you.
>     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
This reads better, thank you.
> — 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?
Initially it hasn't occurred to me that this is sensible. Somebody 
suggested that, so I was pointing out that this is Ok.
>         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?

This is for backward compatibility with existing email/web mail clients. 
I don't really know how hard it would be for existing clients to have an 
extra parameter there.

Its presence would really help in debugging, but nothing should break if 
it is absent.

>     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].”
Sounds good, thank you.
>         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?
Good point, well presented. Added.
>     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).”
Ok.

  [snip]

>     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?
Because some email clients wouldn't set it and I would like to achieve 
highest compatibility with deployed MUA/web mail base.
> 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.
Ok.
>     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.
I would like to, but I don't control when MUAs/web mail would apply CTE 
to the body, thus the above text.
> In any case, we’re better off avoiding the use of two negatives
> to make a positive: “is permitted”.
Changed, thanks.
> 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.
Done.
> The example body contains a “.”, which is not a valid base64url character.
It is JWS, which contains a dot.
>
> — 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”.
The account could have been hijacked, so I was trying to avoid making 
overly strong claim. I have struggled with this text and your 
suggestions below is better.
> 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
>