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

[Alice Russo <[e-mail]>]

Authors,

Approvals are complete; however, we have a question regarding the SVG in Section 3:

The SVG has the width and height specified, which makes the artwork not scale. We suggest that scaling be enabled. Scaling will allow the figure to be resized when it is viewed on a mobile device; however, there may be aesthetic trade-offs (e.g., image may appear too large on a desktop screen). 

Please review Figure 1 in the HTML and PDF files and let us know if they may be updated.

The current document (SVG does not scale):
  https://www.rfc-editor.org/authors/rfc9538.html
  https://www.rfc-editor.org/authors/rfc9538.pdf
  https://www.rfc-editor.org/authors/rfc9538.xml (source)

vs. SVG without width and height:
  https://www.rfc-editor.org/authors/test9538.html  
  https://www.rfc-editor.org/authors/test9538.pdf 
  https://www.rfc-editor.org/authors/test9538.xml (source)

Thank you.
RFC Editor/ar

> On Feb 7, 2024, at 10:53 AM, [e-mail] wrote:
> 
> Hi Alice
>  
> I hope you are well.
>  
> I approve to the 4 new wording suggested below.
>  
> Tell me if you expect a more detailed answer.
>  
> Kind regards
> Emile
>  
>  
>  
> From: Mishra, Sanjay <[e-mail]> 
> Sent: mercredi 7 février 2024 18:31
> To: Alice Russo <[e-mail]>
> Cc: FIEAU Frédéric INNOV/NET <[e-mail]>; STEPHAN Emile INNOV/NET <[e-mail]>; Mishra, Sanjay <sanjay.mishra=[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; auth48archive <[e-mail]>
> Subject: Re: [E] Re: AUTH48: RFC-to-be 9538 <draft-ietf-cdni-delegation-acme-04> for your review
>  
> 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