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
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
