Hi Roman,
Thank you for your detailed review.
On 22/05/2020 15:54, Roman Danyliw wrote:
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?
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 be used", is there is a reason that this
should is not normative (i.e., 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.
** Section 6.
-- Recommend explicitly naming the registries being updated
-- 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.
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/
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.
-- 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)
Done.
Best Regards,
Alexey
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
