Subject: [Acme] AD Review of draft-ietf-acme-email-smime-07

From: Roman Danyliw <[email-masked]>
Date: Fri, 22 May 2020 14:54:38 +0000

Hi!

I completed my AD review of draft-ietf-acme-email-smime-07.  Thanks for the work on this document.  Here is my feedback:

** What was the thinking behind the document status being informational?

** Section 3.1.  This section has no (normative) guidance on populating the To and From fields.

** Section 3.1.  Step 5.  Per "If S/MIME signing is used to prove authenticity of the challenge message, then multipart/signed or "application/pkcs7-mime; smime-type=signed-data;" media type should  be used", is there is a reason that this should is not normative (i.e., SHOULD)?

** Section 6.  

-- Recommend explicitly naming the registries being updated
-- Per the challenge type, all of the fields in the registry aren't described here
-- Per the challenge type, the text in Section 3 says that the challenge type is "email-reply-00" (not "email-reply" as described here)

I recommend something like the following:
NEW:
6.1.  Identifier Type

Per this document, a new type has been added to the "ACME Identifier Types" registry defined in Section 9.7.7 of [RFC8555] with Label "email" and a Reference to this document.

6.2.  Challenge Types

Per this document, a new entry have been added to the "ACME Validation Methods" registry defined in Section 9.7.8 of [RFC8555].  This entry is as follows:

           +-------------+-----------------+------+-----------+
           | Label       | Identifier Type | ACME | Reference |
           +=============+=================+======+===========+
           | email-reply-00 | email              | Y    | This document  |
           +-------------+-----------------+------+-----------+

** Section 7.  Per "Any claims about the correctness or    fitness-for-purpose of the email address must be otherwise assured", I don't follow the intent of this text.  For example, what is the "correctness ... of the email address"?  What is meant by "assurances"?

** Editorial nits:
-- Section 3.  Typo. s/posession/posession/

-- Section 4.  As this document is now headed out of the WG, it seems like it should be removed.

-- Section 7.  Typo. s/can can/can/

-- Section 7. Editorial.  For readability, I would avoid nested parentheses.

OLD
(by posessing user's password or a secret derived from it that can give read and reply access ("password equivalent" information), or by being given permissions to act on user's behalf using email delegation feature)

NEW
(by possessing a user's password or a secret derived from it that can give read and reply access, such as "password equivalent" information; or by being given permissions to act on user's behalf using email delegation feature)

Regards,
Roman

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 29 May 2020 17:38:33 +0100

Hi Roman,

Thank you for your detailed review.

> ** What was the thinking behind the document status being informational?
I don't think there was much thought or discussion of this point. I am 
flexible. I think when I started it was not very clear how much 
support/interest there were in this, but I noticed more interest over time.
> ** Section 3.1.  This section has no (normative) guidance on populating the To and From fields.

The To is the email address of the entity which requested S/MIME 
certificate issuance. I will clarify that.

There is no guidance regarding the From, as it is implementation choice. 
(I am not a fan of mandating specific email address for this, like 
postmaster@<domain>) Do you think this needs to be stated explicitly?

> ** Section 3.1.  Step 5.  Per "If S/MIME signing is used to prove authenticity of the challenge message, then multipart/signed or "application/pkcs7-mime; smime-type=signed-data;" media type should…
This is just restating requirements from other documents, but also 
emphasizing that both common alternatives are allowed here. I don't 
think this needs normative language.
> -- Per the challenge type, all of the fields in the registry aren't described here
I will have a look at these.
> -- Per the challenge type, the text in Section 3 says that the challenge type is "email-reply-00" (not "email-reply" as described here)
Thank you for spotting this, I need to make sure that it is the same 
everywhere. I've  changed the document to say "email-reply" everywhere.
> Per this document, a new entry have been added to the "ACME Validation Methods" registry defined in Section 9.7.8 of [RFC8555].  This entry is as follows:
I think you meant "possession". Fixed.
> -- Section 4.  As this document is now headed out of the WG, it seems like it should be removed.
Removed.
> -- Section 7.  Typo. s/can can/can/
Fixed.
> (by possessing a user's password or a secret derived from it that can give read and reply access, such as "password equivalent" information; or by being given permissions to act on user's behalf us…

Done.

Best Regards,

Alexey

---

From: Russ Housley <[email-masked]>
Date: Fri, 29 May 2020 13:07:44 -0400

> On May 29, 2020, at 12:38 PM, Alexey Melnikov <[email-masked]> wrote:
> 
> Hi Roman,
> 
> I don't think there was much thought or discussion of this point. I am flexible. I think when I started it was not very clear how much support/interest there were in this, but I noticed more interest over time.

I would like to see standards track.  I wonder what other in the ACME WG think.

Russ

---

From: Ryan Sleevi <[email-masked]>
Date: Fri, 29 May 2020 13:27:20 -0400

> I would like to see standards track.  I wonder what other in the ACME WG think.

With my acknowledged bias towards thinking about policies around CAs
trusted in my employer's products, I think Informational makes sense.

I mention this largely because work is still ongoing within the
broader CA/Root Store industry around establishing requirements around
the issuance and validation of S/MIME certificates, and it's not at
all inconceivable to think things may need to change or be adjusted to
be used within those PKIs. The issuance practices and required level
of validation / validation process are not as well or widely
established and documented, nor are the expectations across vendors as
consistent, and so it's difficult to see that there's a lot of
"running code" for this model, in terms of CAs or Root Stores.

It's also not inconceivable that this may be fine as-is. I'll be the
first to readily admit that while I've read the document, I've not
read it to a degree that I'd be fully comfortable allowing it for use
by CAs that I might delegate to. While I don't for a second think that
alone is somehow reasonable to suggest Informational, when I look at
the broader sector of folks who have engaged within ACME on the draft,
I don't see a a wide variety of participants on the list or in the
minutes, and that makes me think that the lack of detailed review by
existing industry implementers may be a bit more wide-spread.

At the end of the day, I take the view that the question about whether
this provides "sufficient" assurance is going to be situational; it
depends on the needs and policies of the mail provider, the CAs, the
relying parties, MTAs, and root stores. That may be reason to think of
this on the "Experimental" or "Informational" spectrum, or it may be
that folks believe the particular mechanism is well-specified enough
that it deserves to be on the "Standards" track, and whether or not
parties implement or adopt that standard is entirely orthogonal.

Given that this spec describes a very specific method of providing
assurance, and not just a general protocol for assurance
establishment, I do lean towards Informational/Experimental.