Hi Peter,
Thank you for your detailed review. My answers/comments are below:
On 09/07/2020 09:21, Peter Yee via Datatracker wrote:
Reviewer: Peter Yee
Review result: Ready with Issues
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more information, please see the FAQ at
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
Document: draft-ietf-acme-email-smime-08
Reviewer: Peter Yee
Review Date: 2020-07-09
IETF LC End Date: 2020-07-09
IESG Telechat date: Not scheduled for a telechat
Summary: This Informational Track draft defines an ACME challenge to be used in
the issuance of S/MIME certificates. I have points I'd like to see clarified as
well as some nits that need to be cleaned up before I would declare it ready.
[Ready with Issues]
Major issues: None
Minor issues:
General: this draft doesn’t frame the operation of the ACME request that uses
this challenge. It mentions a token-part2 that magically arrives over HTTPS,
but gives no indication of why this happened or what causes the generation of
the email challenge. Some context around when this challenge is invoked and
what signals the ACME server that this challenge is required would be helpful.
Good point. I've added a paragraph on this.
Page 3, 1st enumerated item: I find the definition of “first part of the token”
to be far looser than it needs to be. You merely say that it needs to contain
64 bits of entropy. Is there an upper bound?
No. I don't believe base ACME has upper bound on tokens either.
Do you need to say anything about it not being reused in another challenge?
This was the intent and I clarified that.
Page 4, example Subject header field: it would be much better if you gave an
actual example of a base64url-encoded value here rather than some explanatory
text in much the same way you have given actual, legal values for Date,
Message-ID, etc.
Ok.
Page 5, section 3.2, 1st enumerated item, 1st sentence: it doesn’t seem like
you particularly care what is in front of “ACME:”. While you say it’s typically
“Re:” , it could be anything. Would there ever be a case to reject a response
message based on what appears before “ACME:”? I’d like to see a little more
rigor here on what’s required. Some characters followed by a colon and a white
space before the “ACME:” suffices?
I would like for email to use standardardized reply prefix, but there
are variations. E.g. using "Re[<number>]". And don't get me started on
localized versions, which should be banned from the face of the Earth ;-).
You do have a point that probably anything before "ACME:" can be
allowed. I will clarify that.
Page 5, section 3.2, 6th enumerated item, 2nd sentence: where it says
“calculated based on”…, it would be preferable to point back to page 3, 2nd
enumerated item where you explicitly indicate that the two token parts are
concatenated.
I clarified that.
Page 5, section 3.2, 6th enumerated item, last sentence: I’m assuming that
ACME-unaware clients are only receiving this email in the case of the email
being bounced to an administrator or returned to the user.
I suppose ACME server processing can be manual, but this is more likely
to be a misconfiguration.
In either case, it’s
not the client that will be reading this outside-the-block text, it’s a user.
There’s no processing to be done on that text.
Yes, it will be read by a user. I am not sure what needs changing in the
text.
Page 7, example Subject header field: use a real value here, please.
Nits/editorial comments:
I've applied these and the changes will appear in -09. Use of English
language articles is not my strong point :-)
Best Regards,
Alexey
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
