Subject: Re: [Acme] AD Review of draft-ietf-acme-email-smime-07

From: Roman Danyliw <[email-masked]>
Date: Tue, 2 Jun 2020 20:38:33 +0000

Hi Alexey!

> -----Original Message-----
> From: Acme <[email-masked]> On Behalf Of Alexey Melnikov
> Sent: Friday, May 29, 2020 12:39 PM
> To: Roman Danyliw <[email-masked]>
> Cc: IETF ACME <[email-masked]>
> 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-masked]
> https://www.ietf.org/mailman/listinfo/acme

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 16 Jun 2020 16:37:30 +0100

Hi Roman,

On 22/05/2020 15:54, Roman Danyliw wrote:
> -- Per the challenge type, the text in Section 3 says that the challenge type is "email-reply-00" (not "email-reply" as described here)
>
> 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:
>
Thank you for this. I've used some of your suggested text and kept some 
of mine, where I think it was important.
> ** 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"?

This was based on feedback from one of reviewers. It is basically saying 
that issued ACME certificates don't vouch for anything other than "this 
email seems to belong to the entity that requested it". Does this make 
sense?

Best Regards,

Alexey

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 25 Jun 2020 18:48:00 +0000

Hi Alexey!

Thanks for making the updated in -08.

> were in this, but I noticed more interest over time.

Given very limited support to elevate this to PS, and the limited certainty that there is agreement that this is the canonical way from Cas, let's proceed with informational.

If you have strong a opinion to change the document's track, please say so during IETC LC.

> permissions to act on user's behalf using email delegation feature)

Thanks for making these edits and publishing -08.  They address my feedback. 

Regards,
Roman

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 25 Jun 2020 18:48:08 +0000

Hi Alexey!

> Sent: Tuesday, June 16, 2020 11:38 AM
> To: Roman Danyliw <[email-masked]>; IETF ACME <[email-masked]>

[snip]

> email seems to belong to the entity that requested it". Does this make

This cautionary clarification makes more sense to me.  Can you fold in some language to that effect into a revision.

Given that this is the last of that changes, this update can be made with other IETF LC feedback.

Thanks,
Roman

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 26 Jun 2020 10:17:07 +0100

> Given that this is the last of that changes, this update can be made with other IETF LC feedback.
Ok, I will do this in -09.