Am 01.09.18 um 13:13 schrieb [email protected]:
>
> 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 "<" or ">"?
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
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
