Hi Andreas, Thank you for your comments. My answers below: On 17/10/2018 19:29, A. Schulze wrote: > > > 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.
That is fine, I don't mind requiring use of a single space. > > 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 " I mistakenly encoded < and > 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. > 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 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. > 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. I am concerned about automatic message filtering. Having a predictable way to identify challenges would help. > 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. I added this as an open issue, thank you. > 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 I've used some of your suggestions and created an open issue for the rest. Best Regards, Alexey _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
