Re: [auth48] AUTH48: RFC-to-be 9538 <draft-ietf-cdni-delegation-acme-04> for your review

[Alice Russo <[e-mail]>]

Sanjay,
Thank you for your reply; we have updated the document accordingly. 

FYI, in addition to the update in #4, we have changed "the criticality around the protection of" to "that it is critical to protect the"; this text is shown below and in the files. Please review.

Section 5 (Security Considerations)
ORIGINAL:
   The reader is expected to understand the ACME delegation trust model
   (Section 7.1 of [RFC9115]) and security goal (Section 7.2 of
   [RFC9115]), in particular the criticality around the protection of
   the user account associated with the delegation, which authorizes all
   the security relevant operations between dCDN and uCDN over the ACME
   channel. 

CURRENT:
   The reader is expected to understand the ACME delegation trust model
   (Section 7.1 of [RFC9115]) and security goal (Section 7.2 of
   [RFC9115]).  In particular, the reader is expected to understand that 
   it is critical to protect the user account associated with the
   delegation; this account authorizes all the security-relevant
   operations between a dCDN and a uCDN over the ACME channel. 

The revised files are here (please refresh):
  https://www.rfc-editor.org/authors/rfc9538.html
  https://www.rfc-editor.org/authors/rfc9538.txt
  https://www.rfc-editor.org/authors/rfc9538.pdf
  https://www.rfc-editor.org/authors/rfc9538.xml

This diff file shows all changes from the approved I-D:
  https://www.rfc-editor.org/authors/rfc9538-diff.html
  https://www.rfc-editor.org/authors/rfc9538-rfcdiff.html (side by side)

This diff file shows the changes made during AUTH48 thus far:
  https://www.rfc-editor.org/authors/rfc9538-auth48diff.html

We will wait to hear from you again and from E. Stephan
before continuing the publication process. This page shows 
the AUTH48 status of your document:
  https://www.rfc-editor.org/auth48/rfc9538

Thank you.
RFC Editor/ar

> On Feb 7, 2024, at 9:31 AM, Mishra, Sanjay <sanjay.mishra=[e-mail]> wrote:
> 
> Hi Alice - Thank you and please see response below for the 4 questions:
> 
> 1) <!--[rfced] May this be rephrased as follows for readability?
> 
> Original:
>    RFC9115 allows delegating entities to remain in
>    full control of the delegation and be able to revoke it any time and
>    this avoids the need to share private cryptographic key material
>    between the involved entities.
> 
> Perhaps:
>    Per RFC 9115, delegating entities can remain in
>    full control of the delegation and can revoke it at any time.
>    This avoids the need to share private cryptographic key material
>    between the involved entities.
> -->
> Yes, I approve the new wording as suggested above
>  
> 
> 
> 2) <!--[rfced] FYI, in Section 1.1, we added mention of "STAR" so that it
> is expanded upon first use. Please let us know if you prefer otherwise.
> (In the original, the first use was in Section 3 - "ACME STAR delegation"
> was followed by explanation but was without a direct expansion.)
> 
> Original:
>    It also uses
>    terminology from Section 1.2 of [RFC8739] and Section 1.1 of
>    [RFC9115].
> 
> Current:
>    It also uses
>    terminology from Section 1.2 of [RFC8739] and Section 1.1 of
>    [RFC9115], including Short-Term, Automatically Renewed (STAR),
>    as applied to X.509 certificates.
> -->
> 
> Yes, I approve of the new wording as above. 
> 
> 3) <!--[rfced] How may this sentence be rephrased for clarity? In particular,
> "allows to specify" is not clear. Also, Section 2.3.1.3 of RFC 9115
> indicates that the CNAME mapping is optional; should this sentence be
> updated to reflect that?
> 
> Original:
>       |   Note: The delegation object defined in Section 2.3.1.3 of
>       |  [RFC9115] only allows to specify DNS mappings using CNAME RRs.
> 
> Perhaps:
>       |   Note: The delegation object defined in Section 2.3.1.3 of
>       |  [RFC9115] only allows DNS mappings to be specified using CNAME RRs.
> 
> Yes, I approve the above wording as suggested
>  
> Or:
>       |   Note: The delegation object defined in Section 2.3.1.3 of
>       |  [RFC9115] allows DNS mappings to be specified using only CNAME RRs.
> -->
> 
> 
> 4) <!--[rfced] FYI, for readability and precision, we have made the following
> updates: split this into two sentences, changed "criticality around"
> to "criticality of", and changed "which" to "this account".
> Please review and let us know if you prefer otherwise.
> 
> Original:
>    The reader is expected to understand the ACME delegation trust model
>    (Section 7.1 of [RFC9115]) and security goal (Section 7.2 of
>    [RFC9115]), in particular the criticality around the protection of
>    the user account associated with the delegation, which authorizes all
>    the security relevant operations between dCDN and uCDN over the ACME
>    channel.
> 
> Current:
>    The reader is expected to understand the ACME delegation trust model
>    (Section 7.1 of [RFC9115]) and security goal (Section 7.2 of
>    [RFC9115]).  In particular, the reader is expected to understand the
>    criticality of the protection of the user account associated with the
>    delegation; this account authorizes all the security-relevant
>    operations between a dCDN and a uCDN over the ACME channel.
> 
> Yes, I approve of the suggested text.
> 
> Thank you very much
> Best
> Sanjay
> 
> On Wed, Feb 7, 2024 at 12:17 PM Alice Russo <[e-mail]> wrote:
> Authors,
> 
> Sanjay, thank you for your reply and for letting us know about Frederic's reply to the CDNI mailing list.
> 
> Please reply to the 4 questions below regarding changes to the text.
> 
> The edited document is here:
>   https://www.rfc-editor.org/authors/rfc9538.html
>   https://www.rfc-editor.org/authors/rfc9538.pdf
>   https://www.rfc-editor.org/authors/rfc9538.txt
>   https://www.rfc-editor.org/authors/rfc9538.xml (source)
> 
> Diff files of all changes from the approved Internet-Draft:
>   https://www.rfc-editor.org/authors/rfc9538-diff.html 
>   https://www.rfc-editor.org/authors/rfc9538-rfcdiff.html (side by side)
> 
> This page shows the AUTH48 status of your document:
>   https://www.rfc-editor.org/auth48/rfc9538
> 
> In addition to the authors' responses to the questions, we hope to hear from Emile Stephan, as an approval is needed from each author listed in the first-page header of the RFC.
> 
> Thank you.
> RFC Editor/ar
> 
>> On Feb 7, 2024, at 7:21 AM, Mishra, Sanjay <sanjay.mishra=[e-mail]> wrote:
>> 
>> Hi Alice - My co-author Frederic Fieau responded approving this drafts, however, it is a different email thread addressed to [e-mail] so I as confirmation, I'm responding to this thread, I as a co-author along with Emile Stephan and Frederic Fieau have reviewed all changes and approve publication of this document as RFC 9538.
>> 
>> We are thankful to co-chair Kevin Ma for his guidance and the AD, Francesca Palombini and everyone that contributed and commented to this draft and of course a big thanks to the editorial team.
>> 
>> Regards
>> Sanjay Mishra
>> 
>> snippet of email from Fred is below:
>> [e-mail]
>> 9:41 AM (37 minutes ago)
>> to [e-mail], me, STEPHAN
>> 
>> Dear all,
>>  
>> I have reviewed all changes in draft-ietf-cdni-delegation-acme and concur with them. On behalf of the authors, I approve the document for publication as RFC9538.
>> 
>> I would like to thank the CDNI WG and all individuals who participated for their valuable contributions throughout the process which has now reached its conclusion for this draft.
>> 
>> Regards,
>> Frederic
>> 
>> On Tue, Feb 6, 2024 at 6:12 PM Alice Russo <[e-mail]> wrote:
>> Authors,
>> 
>> This is a reminder that we await word from you regarding the questions below and this document's readiness for publication as an RFC. The files are here:
>> 
>>   https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9538.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=_uLNEDcaPBsFXYMA8j5oRepqfLBtLE6RKluO5xkPC-kqNuhB9LwWEVarzV9IR2tN&s=5TzFzGWGUvYktrbM8hNWTP8hhGH7e5HbSUIxNf_TLA0&e= 
>>   https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9538.pdf&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=_uLNEDcaPBsFXYMA8j5oRepqfLBtLE6RKluO5xkPC-kqNuhB9LwWEVarzV9IR2tN&s=-ES9wp1LnU6Q7BFV8U-fcv_gUpKgEg8ECmuutDUGb9w&e= 
>>   https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9538.txt&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=_uLNEDcaPBsFXYMA8j5oRepqfLBtLE6RKluO5xkPC-kqNuhB9LwWEVarzV9IR2tN&s=6vBNFP8MiPXcTbSU4PnBrPvuXbyaL7ysXKxiedlaDGc&e= 
>>   https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9538.xml&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=_uLNEDcaPBsFXYMA8j5oRepqfLBtLE6RKluO5xkPC-kqNuhB9LwWEVarzV9IR2tN&s=QyfJ3JEyXCJaYC3zyThHRZBmzKiYNACxoJ4MArXCUK8&e=  (source)
>> 
>> Diff files of all changes from the approved Internet-Draft:
>>   https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9538-2Ddiff.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=_uLNEDcaPBsFXYMA8j5oRepqfLBtLE6RKluO5xkPC-kqNuhB9LwWEVarzV9IR2tN&s=lHSovOjBUHrLUveLLyMBUoqm_IlAWXB37E8HMdIUZ68&e=  
>>   https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9538-2Drfcdiff.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=_uLNEDcaPBsFXYMA8j5oRepqfLBtLE6RKluO5xkPC-kqNuhB9LwWEVarzV9IR2tN&s=MjAFFfiY9fQr9Bv5FYsBigSAzexwRe3sL6KOEbvy7PM&e=  (side by side)
>> 
>> This page shows the AUTH48 status of your document:
>>   https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_auth48_rfc9538&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=_uLNEDcaPBsFXYMA8j5oRepqfLBtLE6RKluO5xkPC-kqNuhB9LwWEVarzV9IR2tN&s=-577wxpatCuL4syt5zliTCPSry6dSb98RzaRlHqLg10&e= 
>> 
>> Thank you.
>> RFC Editor/ar
>> 
>> > On Jan 22, 2024, at 10:57 PM, [e-mail] wrote:
>> > 
>> > Authors,
>> > 
>> > While reviewing this document during AUTH48, please resolve (as necessary) the
>> > following questions, which are also in the XML file.
>> > 
>> > 1) <!--[rfced] May this be rephrased as follows for readability?
>> > 
>> > Original:
>> >   RFC9115 allows delegating entities to remain in
>> >   full control of the delegation and be able to revoke it any time and
>> >   this avoids the need to share private cryptographic key material
>> >   between the involved entities.
>> > 
>> > Perhaps:
>> >   Per RFC 9115, delegating entities can remain in
>> >   full control of the delegation and can revoke it at any time.
>> >   This avoids the need to share private cryptographic key material
>> >   between the involved entities.
>> > -->
>> > 
>> > 
>> > 2) <!--[rfced] FYI, in Section 1.1, we added mention of "STAR" so that it
>> > is expanded upon first use. Please let us know if you prefer otherwise.
>> > (In the original, the first use was in Section 3 - "ACME STAR delegation"
>> > was followed by explanation but was without a direct expansion.)
>> > 
>> > Original:
>> >   It also uses
>> >   terminology from Section 1.2 of [RFC8739] and Section 1.1 of
>> >   [RFC9115].
>> > 
>> > Current:
>> >   It also uses
>> >   terminology from Section 1.2 of [RFC8739] and Section 1.1 of
>> >   [RFC9115], including Short-Term, Automatically Renewed (STAR),
>> >   as applied to X.509 certificates.
>> > -->
>> > 
>> > 
>> > 3) <!--[rfced] How may this sentence be rephrased for clarity? In particular,
>> > "allows to specify" is not clear. Also, Section 2.3.1.3 of RFC 9115
>> > indicates that the CNAME mapping is optional; should this sentence be
>> > updated to reflect that?
>> > 
>> > Original:
>> >      |   Note: The delegation object defined in Section 2.3.1.3 of
>> >      |  [RFC9115] only allows to specify DNS mappings using CNAME RRs.
>> > 
>> > Perhaps:
>> >      |   Note: The delegation object defined in Section 2.3.1.3 of
>> >      |  [RFC9115] only allows DNS mappings to be specified using CNAME RRs.
>> > 
>> > Or:
>> >      |   Note: The delegation object defined in Section 2.3.1.3 of
>> >      |  [RFC9115] allows DNS mappings to be specified using only CNAME RRs.
>> > -->
>> > 
>> > 
>> > 4) <!--[rfced] FYI, for readability and precision, we have made the following
>> > updates: split this into two sentences, changed "criticality around"
>> > to "criticality of", and changed "which" to "this account".
>> > Please review and let us know if you prefer otherwise.
>> > 
>> > Original:
>> >   The reader is expected to understand the ACME delegation trust model
>> >   (Section 7.1 of [RFC9115]) and security goal (Section 7.2 of
>> >   [RFC9115]), in particular the criticality around the protection of
>> >   the user account associated with the delegation, which authorizes all
>> >   the security relevant operations between dCDN and uCDN over the ACME
>> >   channel.
>> > 
>> > Current:
>> >   The reader is expected to understand the ACME delegation trust model
>> >   (Section 7.1 of [RFC9115]) and security goal (Section 7.2 of
>> >   [RFC9115]).  In particular, the reader is expected to understand the
>> >   criticality of the protection of the user account associated with the
>> >   delegation; this account authorizes all the security-relevant
>> >   operations between a dCDN and a uCDN over the ACME channel.
>> > -->
>> > 
>> > 
>> > Thank you.
>> > 
>> > RFC Editor/ar
>> >