Hi Alexey!
> -----Original Message-----
> From: Acme <[email protected]> On Behalf Of Alexey Melnikov
> Sent: Friday, May 29, 2020 12:39 PM
> To: Roman Danyliw <[email protected]>
> Cc: IETF ACME <[email protected]>
> Subject: Re: [Acme] AD Review of draft-ietf-acme-email-smime-07
>
> 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.
I see this is being discussed on a separate thread. My thinking is that if
there is ambiguity on what should done here then informational makes sense.
> > ** 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.
Thanks.
> 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?
Specifying the To is the one that matters. I might repeat what you said above
that the From is an implementation choice. I just wouldn't leave it unsaid.
> > ** 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.
Understood. That makes sense.
> > ** 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.
Thanks.
> > -- 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.
Thanks.
> > 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"?
Any thoughts on this one?
> > ** 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.
Thanks.
Regards,
Roman
>
> Best Regards,
>
> Alexey
>
> _______________________________________________
> Acme mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/acme
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
