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

["Mishra, Sanjay" <[e-mail]>]

Hi Alice - My response is embedded below:

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.


I approve the updated text as shown under the heading "CURRENT:".

Thank you
Sanjay

On Wed, Feb 7, 2024 at 1:29 PM Alice Russo <[e-mail]> wrote:

> 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://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=_eC8KjZOk1YId1fkVvAsVysA35JB3U7OmhLa-AmUzzOxeU4SxVw76JWIcuNoI7mw&s=E0Q8NM6I8ufQHDRhTm8_VeImKZJNrHkjxJInRWSCBtE&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=_eC8KjZOk1YId1fkVvAsVysA35JB3U7OmhLa-AmUzzOxeU4SxVw76JWIcuNoI7mw&s=v9FTF2kQ7z6fqEBstv4mq5xN3Ru3v1U4m6zf4RGRSYc&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=_eC8KjZOk1YId1fkVvAsVysA35JB3U7OmhLa-AmUzzOxeU4SxVw76JWIcuNoI7mw&s=p1rEiF-o7SG2ZBTAy9uqAneR6K67l9FHLHMLlx-Kba8&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=_eC8KjZOk1YId1fkVvAsVysA35JB3U7OmhLa-AmUzzOxeU4SxVw76JWIcuNoI7mw&s=qvzEYEAlql0snTgBwuJwK7iEinYdUFvCxiJGj0cbRhk&e=
>
> This diff file shows all changes from the approved I-D:
>
> 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=_eC8KjZOk1YId1fkVvAsVysA35JB3U7OmhLa-AmUzzOxeU4SxVw76JWIcuNoI7mw&s=bwF_Xs_TLLrud7_ElXMop1z4rwrqnoVaiR5RXnWHZzA&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=_eC8KjZOk1YId1fkVvAsVysA35JB3U7OmhLa-AmUzzOxeU4SxVw76JWIcuNoI7mw&s=BqSehRro2UUPIDvoNlbyf4cOUmtsufrPvZR9D5wxtuY&e=
> (side by side)
>
> This diff file shows the changes made during AUTH48 thus far:
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9538-2Dauth48diff.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=_eC8KjZOk1YId1fkVvAsVysA35JB3U7OmhLa-AmUzzOxeU4SxVw76JWIcuNoI7mw&s=6u-wQ70ZCGxlnRoWTz4HyI9wAqoXlOeayWT-5-h74Sw&e=
>
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_auth48_rfc9538&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=_eC8KjZOk1YId1fkVvAsVysA35JB3U7OmhLa-AmUzzOxeU4SxVw76JWIcuNoI7mw&s=ZbxziP9AHqv7JJep4ZIZe0hlCIvtuEdtrznS5wvMNuE&e=
>
> 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://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=_eC8KjZOk1YId1fkVvAsVysA35JB3U7OmhLa-AmUzzOxeU4SxVw76JWIcuNoI7mw&s=E0Q8NM6I8ufQHDRhTm8_VeImKZJNrHkjxJInRWSCBtE&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=_eC8KjZOk1YId1fkVvAsVysA35JB3U7OmhLa-AmUzzOxeU4SxVw76JWIcuNoI7mw&s=p1rEiF-o7SG2ZBTAy9uqAneR6K67l9FHLHMLlx-Kba8&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=_eC8KjZOk1YId1fkVvAsVysA35JB3U7OmhLa-AmUzzOxeU4SxVw76JWIcuNoI7mw&s=v9FTF2kQ7z6fqEBstv4mq5xN3Ru3v1U4m6zf4RGRSYc&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=_eC8KjZOk1YId1fkVvAsVysA35JB3U7OmhLa-AmUzzOxeU4SxVw76JWIcuNoI7mw&s=qvzEYEAlql0snTgBwuJwK7iEinYdUFvCxiJGj0cbRhk&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=_eC8KjZOk1YId1fkVvAsVysA35JB3U7OmhLa-AmUzzOxeU4SxVw76JWIcuNoI7mw&s=bwF_Xs_TLLrud7_ElXMop1z4rwrqnoVaiR5RXnWHZzA&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=_eC8KjZOk1YId1fkVvAsVysA35JB3U7OmhLa-AmUzzOxeU4SxVw76JWIcuNoI7mw&s=BqSehRro2UUPIDvoNlbyf4cOUmtsufrPvZR9D5wxtuY&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=_eC8KjZOk1YId1fkVvAsVysA35JB3U7OmhLa-AmUzzOxeU4SxVw76JWIcuNoI7mw&s=ZbxziP9AHqv7JJep4ZIZe0hlCIvtuEdtrznS5wvMNuE&e=
> >
> > 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
> >> >
>
>