Security review of Extensions to Automatic Certificate Management Environment for end user S/MIME certificates draft-ietf-acme-email-smime-08 Do not be alarmed. I generated this review of this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving security requirements and considerations in IETF drafts. Comments not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. The abstract states: "This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificates for use by email users that want to use S/MIME." I would restate this as "a specification of a challenge/response protocol that is part of issuing ACME certificates to email accounts." There doesn't seem to be anything in particular that ties this document to S/MIME. It would certainly be useful for using S/MIME, but it is not necessary to have it in the title. The protocol under discussion is a small part of ACME, and it appears to be what results immediately from a request for a certificate. In section 3, last paragraph, there is a brief allusion to this context, in the mention of the email address in a "CSR". This would be usefully augmented by using the text as in ACME, i.e., "a PKCS#10 [RFC2986] Certificate Signing Request (CSR)." There's an assumption that the ability to reply to a challenge email from the certificate server demonstrates "control" of the email account, and therefore the possession of the private key for the certificate demonstrates to a third party the "control" of the email account. The security considerations note that the requester's email system might not be secure, and that email accounts might be shared, but there is reference to the "account owner". I don't think that there is a formal notion of an account owner for email, perhaps it shouldn't be mentioned. The protocol demonstrates that an entity can see email sent to the email address and can respond from that email address. That is not necessarily "control", so I would replace that term with something more neutral, like "access". The challenge message must be protected with S/MIME signing or DKIM signing, and pass DMARC validation. The response message must be DKIM signed. Are there any requirements on the the certificate issuer's or requester's policy for DKIM/SPF/DMARC? This layering of security mechanisms raises the question of what do they accomplish? The document recommends that email system administrators use DNSSEC to protect records that protect email, but it isn't required. Under what circumstances should the email user feel confident in the issued certificate? If it is used with S/MIME, how much confidence should the recipient have in the certificate? The answer depends on a lot of factors in the details of DNS and email infrastructure for the certificate issuer and the certificate requester. The ACME specification has a detailed discussion of security. By introducing email into protocol, this extension seems to raise new security considerations that should be addressed in similar detail. Hilarie