Hi Alexey, > > SMTP does allow choosing an arbitrary "From:" address, so just being able > > to send an email with a specific "From:" address alone doesn't prove > > anything. > This is true, the document needs to add some text about some form of > validation. Possibly DKIM/DMARC.
fair enough. > > Couldn't the token just be transmitted back to the CA via HTTPS like the > > rest of the ACME protocol? > > As per above, I think this is not good enough. But wouldn't that create two different levels of validation? Let's consider user Alice. She, or her domain admin, has set up DNSSEC, DKIM, SPF and DMARC. When she does the email-reply-00 challenge, mail reception and sending is proven properly. But user Bob has none of that, just a basic domain with one A record, no DNSSEC and nothing else. When he does the email-reply-00 challenge, essentially just mail reception is proven, as sending could be forged without issue. The CA would hand out the same kind of certificates to both of them and a third party won't know which level of validation was done. Querying the dns data of Bob won't help, because he could have changed it after the certificate was issued. Is a CA like Let's Encrypt ok with such a difference? Or do you want to make the use of DKIM and DMARC mandatory for a user before he can use the email-reply-00 challenge? > DKIM/DMARC already deal with some of this, so I think they should be > encouraged in this context. (They are easy to handle in MTAs, as more > support is available). > > Supporting S/MIME might be a reasonable alternative as well. I'm ok with both of these mechanisms, they would both solve the issue. I just think if we allow a CA to send S/MIME, there should be something like "a client MUST support decoding MIME emails" in the RFC so that there is no surprise if a CA suddenly starts using it. Kind regards, Gerd _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
