Subject: [Acme] I-D Action: draft-ietf-acme-email-smime-05.txt

From: [email-masked]
Date: Mon, 08 Jul 2019 08:51:38 -0700

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-05.txt
	Pages           : 8
	Date            : 2019-07-08

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 IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-acme-email-smime/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-acme-email-smime-05
https://datatracker.ietf.org/doc/html/draft-ietf-acme-email-smime-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-email-smime-05

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "A. Schulze" <[email-masked]>
Date: Tue, 9 Jul 2019 23:37:33 +0200

> https://tools.ietf.org/html/draft-ietf-acme-email-smime-05

Hello,

certification based on messages require confidence the messages aren't tampered.
To assure that I suggest to require some properties that make the messages more robust
against modification.

messages sent by the CA

 - message content MUST be 7 bit before signing
   -> https://tools.ietf.org/html/rfc6376#section-5.3

   The draft mention 7 bit only for response messages (Section 3.2 6.)

 - DKIM signatures MUST be creates in a way that allow detection
   of header addition.
   -> https://tools.ietf.org/html/rfc6376#section-5.4

   while RFC 6376 don't name it "oversigning" it's a common
   phrase for OpenDKIM users...

messages send back to the CA:

  the CA MAY require same DKIM properties for the messages they
  expect from the user.

Andreas

---

From: "Gerd v. Egidy" <[email-masked]>
Date: Mon, 15 Jul 2019 15:01:38 +0200

Hi Alexey,

thanks for continuing your work on the smime draft.

> 1.  Do we need to handle text/html or multipart/alternative in email
>       challenge?  Simplicity suggests "no".  However, for automated
>       processing it might be better to use at least multipart/mixed
>       with a special MIME type.

hmm. I guess with "automated processing" you mean an acme client on the user 
side. 

How would a multipart/mixed with a special MIME type help implementing the 
client?

The client just needs to detect the challenge email and extract <token-part1> 
from the Subject:-Header. What other data, that could be in the part with the 
special mime type, would help implementing such a client?

An ACME CA might want to include multipart/alternative and text/html to 
present nicely formatted usage instructions to the user when the ACME client 
is not integrated into the MUA. Automated clients should not be confused by 
such messages.

The same is true for the challenge response:

When the user manully copies the response from his ACME client program into 
his regular MUA, the MUA may compose a multipart/alternative mail with text/
html and text/plain or even just text/html. Also some company disclaimers and 
so on could be added automatically.

How about using something like in RFC 7468?

-----BEGIN ACME RESPONSE-----
LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowy
jxAjEuX0.9jg46WB3rR_AHD-EBXdN7cBkH1WOu0tA3M9
fm21mqTI
-----END ACME RESPONSE-----

This would allow the ACME server to extract the relevant data from most of 
such emails by stripping all html tags and ignoring everything outside the 
BEGIN/END block.

We also should not force the response email to use a subject of "Re: ACME: 
<token-part1>", just "<something>ACME: <token-part1>" because MUAs with non-
english language settings may use something else than "Re:" to denote a reply.

Kind regards,

Gerd