Subject: Re: [Acme] I-D Action: draft-ietf-acme-email-smime-03.txt

From: "A. Schulze" <[email-masked]>
Date: Wed, 17 Oct 2018 20:29:00 +0200

Am 01.09.18 um 13:13 schrieb [email-masked]:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Automated Certificate Management Environment WG of the IETF.
> 
>         Title           : Extensions to Automatic Certificate Management Environment for end user S/MIME certificates
>         Author          : Alexey Melnikov
> 	Filename        : draft-ietf-acme-email-smime-03.txt
> 	Pages           : 7
> 	Date            : 2018-09-01

Hello,

some comments on the draft:

1.
Section 3.1
> the prefix "ACME:" is followed by at least one SP or TAB character.

That makes parser unnecessary complex and offer obfuscation: How will common MUA show messages with 10 TAB characters?

my suggestion:
Require exactly one SPACE between "ACME:" and "<token-part1>"
Best, one could translate this into correct ABNF notation.

2.
The example in section 3.1 show a simple plain text message. Why would we use HTML encoded entities like "&lt;" or "&gt;"?
I suggest to simply quote the email address using ' or "

Also I think there should be a header "MIME-Version: 1.0", as required by https://tools.ietf.org/html/rfc2045#section-4
But I may be wrong ...

3.
Section 4.1
Again, text/html or multipart/alternative makes parser more complex.
I'm against such a requirement. I also don't see a need for a special MIME type.
ACME challenge message should be as simple as possible and readable by users.
text/plain fit this requirements.

Section 4.2
the identifier for an ACME challenge message is a specific subject.
with a fixed, probably exact known length.
That should be enough.

new Section 4.3
Should the draft REQUIRE challenge message to be S/MIME signed?
It's really not a big deal for a CA to send such messages and allow receivers
a much better authentication. The signed content should again as simple as possible
as mentioned above.

4.
to circumvent some concerns about weakness, we may introduce limitations:
 - the CA MUST send from a subdomain that
   * propagate -all as default SPF policy
   * send DKIM signed messages
   * propagate p=reject as DMARC policy.
 - RFC5322.To MUST be exactly the certificate object. The header MUST be protected by oversigning by a proper DKIM signature.
 - the message MUST not include RFC5322.Cc Header
 - automatic clients MUST validate this requirements

 - the response message MUST have a RFC5322.From that match the certificate object.
 - the message recieved by CA's MX MUST compare, RFC5321.MailFrom match the certificate object (From == MailFrom)
 - the message MUST not contain RFC5322.Cc
 - the CA MUST validate this requirements

Andreas

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 19 Oct 2018 19:51:32 +0100

Hi Andreas,
Thank you for your comments. My answers below:

> Best, one could translate this into correct ABNF notation.

That is fine, I don't mind requiring use of a single space.
> I suggest to simply quote the email address using ' or "

I mistakenly encoded &lt; and &gt; in XML CDATA. You are right that this
is not needed.

> Also I think there should be a header "MIME-Version: 1.0", as required by https://tools.ietf.org/html/rfc2045#section-4

Good point, I will add.

> I'm against such a requirement.

I think I agree, but I was wondering if some clients can't control this
and just do this automatically.

> I also don't see a need for a special MIME type.

This might be convenient for automatic processing. But I don't have a
strong opinion.

> with a fixed, probably exact known length.
I am concerned about automatic message filtering. Having a predictable
way to identify challenges would help.

> a much better authentication. The signed content should again as simple as possible

I added this as an open issue, thank you.

>  - the CA MUST validate this requirements

I've used some of your suggestions and created an open issue for the rest.

Best Regards,
Alexey