Re: [Acme] Genart last call review of draft-ietf-acme-email-smime-08

[Alexey Melnikov <[e-mail]>]

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