Subject: [Acme] draft-ietf-acme-email-smime-03 - comments

From: Yaron Sheffer <[email-masked]>
Date: Sat, 10 Nov 2018 23:49:48 +0200

Hi Alexey,

Overall, this seems to be workable and useful.

* In Sec. 3, definition of the format of the email address should
refer to RFC 5322 (specifically, Sec. 3.4.1) and not 5321.

* I've never seen "*" used to denote wildcards in the context of
email addresses, is this really a problem? "*" is nominally a legal
character in the local-part of an address.

* Is the email address allowed to contain a "+", which typically
introduces a subaddress
(https://en.wikipedia.org/wiki/Email_address#Subaddressing)? In
other words, do I need a different certificate for every subaddress?
RFC 5750 is silent on this.

* Token2 is "returned over HTTPS". Is it part of the ACME
protocol? Where exactly?

* I think we should say explicitly that both tokens are generated
freshly for each Order.

* Why include the SHA-256 digest of the key authz in the returned
email, rather than the key authz as-is? Please refer to Sec. 8.1 of
the base draft: key authz is token+"."+thumbprint.

* Can all mail clients generate emails that contain a single
text/plain MIME part? In other words, are there no browser-based
clients that insist on having an "alternative" HTML part? The CA
should be liberal enough to deal with their responses.

* "These identifiers may appear in any sort order" - could you
include an example of the CSR? I could not find an RFC that defines
it for S/MIME.

* 3.1: the subject header is often prepended with all sorts of
fluff, such as "[extern]". I don't know if people also append things
to the header, but if they do, you might want to facilitate parsing
by surrounding the token with some special characters, e.g. "ACME:
[1234abcd]" (note the brackets).

* Please specify that this is base64url without "=" padding.

* ‎The example response shows a key authorization
(digest+thumbprint), and not a sha-256 digest of a key authz which
the text says.

* Also, I suggest to add some boilerplate to the response to make it
easier to parse, e.g. prepend with "ACME:" similarly to the request
subject header.

* Open issue 1: yes, I think a special MIME type is much better than
having a client plug-in that needs to inspect ALL incoming emails.

* IANA Considerations: clarify which registries for each one.

Thanks,

Yaron