Subject: [Acme] Last Call: <draft-ietf-acme-email-smime-08.txt> (Extensions to Automatic Certificate Management Environment for end user S/MIME certificates) to Proposed Standard

From: The IESG <[email-masked]>
Date: Thu, 25 Jun 2020 11:57:27 -0700

The IESG has received a request from the Automated Certificate Management
Environment WG (acme) to consider the following document: - 'Extensions to
Automatic Certificate Management Environment for end
   user S/MIME certificates'
  <draft-ietf-acme-email-smime-08.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2020-07-09. Exceptionally, comments may
be sent to [email-masked] instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract

   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.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-acme-email-smime/

No IPR declarations have been submitted directly on this I-D.

The document contains these normative downward references.
See RFC 3967 for additional information: 
    rfc7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) (Informational - Independent Submission Editor stream)

---

From: S Moonesamy <[email-masked]>
Date: Thu, 25 Jun 2020 12:56:05 -0700

Hi Alexey,
>comments on this action. Please send substantive comments to the

In Section 3.1, there is the following in Point 3 and 5: "The message 
MAY contain Reply-To header field."  Is the duplication a mistake?

Point 6 states that its purpose is to "prove authenticity of a 
challenge message".  How does DKIM prove authenticity [1]?

Why is there a requirement that the message has to pass DMARC 
validation?  Has forwarding been taken into account [2]?

Regards,
S. Moonesamy

1. Please see Section 5.4 of RFC 6376.
2. That does not work well with SPF.

---

From: "Sebastian Nielsen" <[email-masked]>
Date: Thu, 25 Jun 2020 23:40:43 +0200

1: Of course DKIM can be used to validate the authenticity of the email such
as it has been sent from the specified domain.

2: Validation response messages should NOT be forwarded! Normally, you would
send a response message like from [email-masked] to
[email-masked]
Of course, if ca.example.org is in full control of all email servers, they
can easily do the validation at the leaf server ca.example.org, and then
forward the email message to a internal server for SMIME issuance, for
example by adding a encrypted and signed header with the validation, or
communicating out-of-band - for example with a MySQL server, that the
message X is propely SPF and DKIM validated.

The type of forwarding SPF don't work with, would be if
[email-masked] was forwarded to lets say
[email-masked] then if I send a validation reponse to
[email-masked] from [email-masked] , validation would fail
@ GMAIL when they receive the message from ca.example.org which is a server
not on my authorization list.

And a CA running an email server that forwards to an server they are not in
full control of, is a HUGE security risk for SMIME issuance - unless they
have proper agreements in place - for example a subCA that forwards their
validations to the main CA, but still want a "branded" email adress for
their ACME validations - but then their agreements could easily include that
the subCA should do the validations at the leaf server, and then add
information to the email that allows the main CA to see that SPF and DKIM
was propely validated.
Or include the client IP in the message, signed securely, so the main CA can
validate SPF.

-----Ursprungligt meddelande-----
Från: [email-masked] <[email-masked]> För S Moonesamy
Skickat: den 25 juni 2020 21:59
Till: Alexey Melnikov <[email-masked]>
Kopia: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Ämne: Re: [Acme] Last Call: <draft-ietf-acme-email-smime-08.txt> (Extensions
to Automatic Certificate Mana

Hi Alexey,
At 11:57 AM 25-06-2020, The IESG wrote:
>The IESG has received a request from the Automated Certificate 
>Management Environment WG (acme) to consider the following document: - 
>'Extensions to Automatic Certificate Management Environment for end
>The IESG plans to make a decision in the next few weeks, and solicits 
>final comments on this action. Please send substantive comments to the

In Section 3.1, there is the following in Point 3 and 5: "The message MAY
contain Reply-To header field."  Is the duplication a mistake?

Point 6 states that its purpose is to "prove authenticity of a challenge
message".  How does DKIM prove authenticity [1]?

Why is there a requirement that the message has to pass DMARC validation?
Has forwarding been taken into account [2]?

Regards,
S. Moonesamy

_______________________________________________
Acme mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/acme

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 26 Jun 2020 10:05:00 +0100

> as it has been sent from the specified domain.

Right. And the list of header fields to sign in case DKIM is used 
protects most important header fields that must not be tempered with.

> Or include the client IP in the message, signed securely, so the main CA can

I basically agree with this.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 26 Jun 2020 10:14:33 +0100

Hi SM,

On 25/06/2020 20:56, S Moonesamy wrote:
>> Management
>> final
Yes, cut & paste error.
> challenge message".  How does DKIM prove authenticity [1]?
See my other reply.
> Why is there a requirement that the message has to pass DMARC validation?
Because this is the best mail indistry has to offer to prevent message 
spoofing.
>   Has forwarding been taken into account [2]?

I don't think my proposal is inteded to work with mailing list 
forwarding. This sounds pretty dangerous and defeats the prescribed 
recipient email validation check. Maybe the document should say 
something about this.

If you are thinking about recipient end alias-type forwarding, then I 
can add some text that validation has to happen before forwarding, but 
this ACME mechanism might still break if the From header field email 
address of the response message doesn't match the email address used to 
request the certificate for.

Best Regards,

Alexey