Re: [auth48] AUTH48: RFC-to-be 9448 <draft-ietf-acme-authority-token-tnauthlist-13> for your review

[Mary Barnes <[e-mail]>]

Hi Alanna,

Thanks for the reminder.  It looks good to me.

Mary.

On Tue, Aug 8, 2023 at 10:39 AM Alanna Paloma <[e-mail]> wrote:

> David, Mary, and Jon,
>
> This is a friendly reminder that we await your reviews and approvals prior
> to moving this document forward in the publication process.
>
> The files have been posted here (please refresh):
> https://www.rfc-editor.org/authors/rfc9448.xml
> https://www.rfc-editor.org/authors/rfc9448.txt
> https://www.rfc-editor.org/authors/rfc9448.html
> https://www.rfc-editor.org/authors/rfc9448.pdf
>
> The relevant diff files have been posted here:
> https://www.rfc-editor.org/authors/rfc9448-diff.html (comprehensive diff)
> https://www.rfc-editor.org/authors/rfc9448-auth48diff.html (AUTH48
> changes)
>
> For the AUTH48 status of this document, please see:
> https://www.rfc-editor.org/auth48/rfc9448
>
> Thank you,
> RFC Editor/ap
>
> > On Aug 1, 2023, at 4:00 PM, Alanna Paloma <[e-mail]> wrote:
> >
> > Hi Chris,
> >
> > Thank you for your reply. Your approval has been noted on the AUTH48
> status page:
> > https://www.rfc-editor.org/auth48/rfc9448
> >
> > Once we have received approvals from David, Mary, and Jon, we will move
> this document forward in the publication process.
> >
> > Best regards,
> > RFC Editor/ap
> >
> >> On Aug 1, 2023, at 1:14 PM, Chris Wendt <[e-mail]>
> wrote:
> >>
> >> Hi Alanna,
> >>
> >> I reviewed the changes and everything looks good to me.
> >>
> >> Thanks.
> >>
> >> -Chris
> >>
> >>> On Jul 28, 2023, at 7:33 PM, Alanna Paloma <[e-mail]> wrote:
> >>>
> >>> Hi Chris,
> >>>
> >>> Thank you for your reply. We have updated as requested.
> >>>
> >>>>> b) Throughout the text, "TNBlock" and "TN Block" appear to be used
> >>>>> inconsistently. Please review these occurrences and let us know
> if/how they
> >>>>> may be made consistent.
> >>>>
> >>>> I would correct it with the following text:
> >>>> Original
> >>>> … with a particular set of different TN Blocks and/or TNs.
> TNAuthList can be constructed to define a limited scope of the TNBlocks or
> TNs either associated with an SPC or with the scope of TN Blocks or TNs the
> client has authority over.
> >>>>
> >>>> Modified
> >>>> … with a particular set of different telephone number ranges and/or
> telephone numbers.  TNAuthList can be constructed to define a limited scope
> of the TelephoneNumberRanges or TelephoneNumbers [RFC8226] Section 9 either
> associated with an SPC or with the scope of telephone number ranges or
> telephone numbers the client has authority over.
> >>>>
> >>>> TN Block and telephone number range are essentially equivalent terms.
> >>>
> >>> The files have been updated with your modified text. In Section 5.7,
> we have additionally updated “TNBlock” and “TNs" to be “telephone number
> ranges” and “telephone numbers”, respectively. Please review and let us
> know if further updates are necessary.
> >>>
> >>> Original:
> >>> Because this specification specifically involves the TNAuthList
> >>> defined in [RFC8226] which involves SPC, TNBlock, and individual TNs...
> >>>
> >>> Current:
> >>> Because this specification specifically involves the TNAuthList
> >>> defined in [RFC8226], which involves SPC, telephone number ranges,
> >>> and individual telephone numbers...
> >>>
> >>> The files have been posted here (please refresh):
> >>> https://www.rfc-editor.org/authors/rfc9448.xml
> >>> https://www.rfc-editor.org/authors/rfc9448.txt
> >>> https://www.rfc-editor.org/authors/rfc9448.html
> >>> https://www.rfc-editor.org/authors/rfc9448.pdf
> >>>
> >>> The relevant diff files have been posted here:
> >>> https://www.rfc-editor.org/authors/rfc9448-diff.html (comprehensive
> diff)
> >>> https://www.rfc-editor.org/authors/rfc9448-auth48diff.html (AUTH48
> changes)
> >>>
> >>> Please review the document carefully as documents do not change once
> published as RFCs.
> >>>
> >>> We will await any further changes you may have and approvals from each
> author prior to moving forward in the publication process.
> >>>
> >>> For the AUTH48 status of this document, please see:
> >>> https://www.rfc-editor.org/auth48/rfc9448
> >>>
> >>> Thank you,
> >>> RFC Editor/ap
> >>>
> >>>> On Jul 26, 2023, at 8:53 AM, Chris Wendt <[e-mail]>
> wrote:
> >>>>
> >>>> Inline:
> >>>>
> >>>>> On Jul 24, 2023, at 10:58 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] We note the profile name is expanded in Section 5.
> >>>>> Would you like to expand it in the title and abstract as well,
> >>>>> or leave it as simply "TNAuthList"?
> >>>>>
> >>>>> Original (Title):
> >>>>> TNAuthList profile of ACME Authority Token
> >>>>>
> >>>>> Perhaps:
> >>>>> Telephone Number Authorization List (TNAuthList) Profile
> >>>>> of Automated Certificate Management Environment (ACME) Authority
> Token
> >>>>>
> >>>>>
> >>>>> Original (Abstract):
> >>>>> ...using the TNAuthList defined  by STI certificates.
> >>>>>
> >>>>> Perhaps:
> >>>>> ... using the Telephone Number Authorization List (TNAuthList)
> defined by
> >>>>> STI certificates.
> >>>>> -->
> >>>>
> >>>> I think i’d actually like to do the opposite and not expand it in
> Section 5.
> >>>>
> >>>> So for Section 5:
> >>>>
> >>>> Original:
> >>>> The Telephone Number Authority List Authority Token (TNAuthList
> Authority Token) is a profile instance …
> >>>>
> >>>> Modified:
> >>>> The TNAuthList Authority Token is a profile instance …
> >>>>
> >>>> My justification for that is that i looked at RFC8226 and TNAuthList
> is just defined and never expanded.  I’m up for discussion on that
> conclusion, but i think that is probably the correct thing to do.
> >>>>
> >>>>>
> >>>>>
> >>>>> 2) <!--[rfced] Please clarify this sentence, in particular
> >>>>> from "as per" onward. It doesn't parse. Is citing
> >>>>> "[RFC8555]" as an adjective necessary?
> >>>>>
> >>>>> Original:
> >>>>> The format of the string that represents the TNAuthList MUST be
> >>>>> constructed using base64url encoding, as per [RFC8555] base64url
> >>>>> encoding described in Section 5 of [RFC4648] according to the profile
> >>>>> specified in JSON Web Signature in Section 2 of [RFC7515].
> >>>>>
> >>>>> Perhaps:
> >>>>> The string that represents the TNAuthList MUST be
> >>>>> constructed using base64url encoding, as described in
> >>>>> Section 5 of [RFC4648] and as defined in Section 2
> >>>>> of JSON Web Signature [RFC7515].
> >>>>> -->
> >>>>>
> >>>>
> >>>> Yes, much cleaner
> >>>>
> >>>>>
> >>>>> 3) <!--[rfced] Should it be "Telephone Number Authority List" or
> >>>>> "Telephone Number Authorization List"? Both forms are used within
> >>>>> this document.
> >>>>>
> >>>>> Original (Section 3):
> >>>>> the TN Authorization List
> >>>>>
> >>>>> vs.
> >>>>>
> >>>>> Original (Section 5):
> >>>>> The Telephone Number Authority List Authority Token (TNAuthList
> >>>>> Authority Token) is a profile instance of ...
> >>>>> -->
> >>>>
> >>>> Similar to answer for comment 1 above, we should only use TNAuthList
> >>>>
> >>>>>
> >>>>>
> >>>>> 4) <!--[rfced] Are these terms equivalent? If so, should Section 5.4
> >>>>> be updated to use the shorter form?
> >>>>>
> >>>>> Original (Section 3):
> >>>>> the TNAuthList ASN.1 object
> >>>>>
> >>>>> vs.
> >>>>>
> >>>>> Original (Section 5.4):
> >>>>> the TN Authorization List certificate extension ASN.1 object
> >>>>> -->
> >>>>>
> >>>>
> >>>> Yes please make Section 5.4 say “the TNAuthList certificate extension
> ASN.1 object
> >>>>
> >>>>>
> >>>>> 5) <!--[rfced] It does not appear that "Protected header" is defined
> in RFC 9447.
> >>>>> Please review and let us know if/how this citation should be
> updated. Additionally,
> >>>>> may we make "Protected" lowercase?
> >>>>>
> >>>>> Original:
> >>>>> The TNAuthList Authority Token Protected header MUST comply with the
> >>>>> Authority Token Protected header as defined in
> >>>>> [I-D.ietf-acme-authority-token].
> >>>>> -->
> >>>>
> >>>> Protected header (and more specifically JWS Protected Header) is
> originally defined in RFC7515.  It does seem that whenever it’s referred to
> in 7515 or related documents it is all capitalized.
> >>>> That said, if I look at RFC8555 (ACME) it has both capitalized and
> non-capitalized (without JWS prefix) references.
> >>>> I think colloquially people generally say just “protected header”.
> >>>>
> >>>> We inherit the use of protected header through RFC8555 usage, so I
> think the right reference is RFC8555 Section 6.2.
> >>>>
> >>>> You are correct that authority token draft focuses on “atc" as a new
> identifier for inclusion in the protected header, but doesn’t mention
> protected header other than showing an example.
> >>>>
> >>>> So, my proposed fix would be the following:
> >>>> The TNAuthList Authority Token protected header MUST comply with
> [RFC8555] Section 6.2 Request Authentication.
> >>>>
> >>>> The following paragraph includes the MUST for including “atc” which
> is the authority token draft requirement being referred to.
> >>>>
> >>>> A second option would be to remove the sentence, it is perhaps
> redundant since the MUST compliance with 8555 might be a bit redundant.
> Feedback is welcome.
> >>>>
> >>>>>
> >>>>>
> >>>>> 6) <!--[rfced] We note that RFC 7231 does not contain a Section
> 14.8.
> >>>>> Also, RFC 7231 has been obsoleted by RFC 9110; may we replace this
> >>>>> reference to RFC 7231 with one to RFC 9110? If so, please provide
> >>>>> the accurate section number.
> >>>>>
> >>>>> Original:
> >>>>> For example, an HTTP authorization header containing a
> >>>>> valid authorization credentials as defined in [RFC7231] Section 14.8.
> >>>>> -->
> >>>>>
> >>>>
> >>>> Yes, RFC9110 Section 11.6.2 Authorization Header.
> >>>>
> >>>>>
> >>>>> 7) <!--[rfced] In Section 6, are the steps listed meant to occur in
> a specific order?
> >>>>> Should the list be converted to a numbered list?
> >>>>> -->
> >>>>>
> >>>>
> >>>> Yes i think that would be appropriate.
> >>>>
> >>>>>
> >>>>> 8) <!--[rfced] Should "JWS signature" be updated to simply "JWS" to
> avoid redundancy
> >>>>> (if expanded, "JWS signature" would read "JSON Web Signature
> signature"). Please review
> >>>>> and let us know if any updates are needed.
> >>>>>
> >>>>> Original:
> >>>>> JSON Web Signature (JWS, [RFC7515]) objects can include an "x5u"
> >>>>> header parameter to refer to a certificate that is used to validate
> >>>>> the JWS signature.
> >>>>>
> >>>>> Perhaps:
> >>>>> JSON Web Signature (JWS) [RFC7515] objects can include an "x5u"
> >>>>> header parameter to refer to a certificate that is used to validate
> >>>>> the JWS.
> >>>>> -->
> >>>>
> >>>> RFC7515 Section 5.1 refers to JWS Signature as well.  Basically a JWS
> object contains a signature section and that is what we are referring to in
> the last part of the sentence.  So i think it’s correct as is.
> >>>>
> >>>>>
> >>>>>
> >>>>> 9) <!-- [rfced] In the reference below, the URL provided returns a
> >>>>> "document not found" error. We have updated the URL as follows,
> >>>>> and the other information accordingly. Please review and let us
> >>>>> know any updates.
> >>>>>
> >>>>> Original:
> >>>>> [ATIS-1000080]
> >>>>>          ATIS/SIP Forum NNI Task Group, "Signature-based Handling
> >>>>>          of Asserted information using toKENs (SHAKEN) Governance
> >>>>>          Model and Certificate Management
> >>>>>          <https://access.atis.org/apps/group_public/
> >>>>>          download.php/32237/ATIS-1000080.pdf>", July 2017.
> >>>>>
> >>>>> Current:
> >>>>> [ATIS-1000080]
> >>>>>          ATIS, "Signature-based Handling of Asserted information
> >>>>>          using toKENs (SHAKEN): Governance Model and Certificate
> >>>>>          Management", ATIS-1000080.v005, December 2022,
> >>>>>          <https://access.atis.org/apps/group_public/
> >>>>>          download.php/69428/ATIS-1000080.v005.pdf>.
> >>>>> -->
> >>>>>
> >>>>
> >>>> Yes, this is an unfortunate thing with ATIS document links, but the
> update is fine.  An alternative would be to remove the URL and just refer
> to the document.  I am ok either way.
> >>>>
> >>>>>
> >>>>> 10) <!--[rfced] Terminology
> >>>>>
> >>>>> a) We see that "CA" was expanded as both "certificate authority"
> >>>>> (1 instance) and "certification authority". FYI, we have updated
> >>>>> this term to the latter. (This matches the guidance received from
> >>>>> experts in the past and matches usage in RFC 9447.) Please let us
> >>>>> know if you object.
> >>>>>
> >>>>> Original:
> >>>>> This section defines
> >>>>> an optional mechanism for the Certificate Authority (CA) to host the
> >>>>> certificate directly and provide a URL that the ACME client owner can
> >>>>> directly reference in the "x5u" of their signed PASSporTs.
> >>>>>
> >>>>> Current:
> >>>>> This section defines
> >>>>> an optional mechanism for the certification authority (CA) to host
> the
> >>>>> certificate directly and provide a URL that the ACME client owner can
> >>>>> directly reference in the "x5u" of their signed PASSporTs.
> >>>>
> >>>> Yes, certification authority is good.
> >>>>
> >>>>>
> >>>>> b) Throughout the text, "TNBlock" and "TN Block" appear to be used
> >>>>> inconsistently. Please review these occurrences and let us know
> if/how they
> >>>>> may be made consistent.
> >>>>
> >>>> I would correct it with the following text:
> >>>> Original
> >>>> … with a particular set of different TN Blocks and/or TNs.
> TNAuthList can be constructed to define a limited scope of the TNBlocks or
> TNs either associated with an SPC or with the scope of TN Blocks or TNs the
> client has authority over.
> >>>>
> >>>> Modified
> >>>> … with a particular set of different telephone number ranges and/or
> telephone numbers.  TNAuthList can be constructed to define a limited scope
> of the TelephoneNumberRanges or TelephoneNumbers [RFC8226] Section 9 either
> associated with an SPC or with the scope of telephone number ranges or
> telephone numbers the client has authority over.
> >>>>
> >>>> TN Block and telephone number range are essentially equivalent terms.
> >>>>
> >>>>>
> >>>>> c) FYI, we have added expansions for the following abbreviations
> >>>>> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
> >>>>> expansion in the document carefully to ensure correctness.
> >>>>>
> >>>>> Certificate Signing Request (CSR)
> >>>>> Personal Assertion Token (PASSporT)
> >>>>> Signature-based Handling of Asserted information using ToKENs
> (SHAKEN)
> >>>>> Secure Telephone Identity Revisited (STIR)
> >>>>> Voice over IP (VoIP)
> >>>>> —>
> >>>>>
> >>>>
> >>>> Yes those are correct.
> >>>>
> >>>>>
> >>>>> 11) <!--[rfced] Please review the "Inclusive Language" portion of
> the online
> >>>>> Style Guide <
> https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
> >>>>> and let us know if any changes are needed.
> >>>>>
> >>>>> Note that our script did not flag any words in particular, but this
> should still
> >>>>> be reviewed as a best practice.
> >>>>> -->
> >>>>
> >>>> Reviewed and didn’t find anything.
> >>>>
> >>>>>
> >>>>>
> >>>>> Thank you.
> >>>>>
> >>>>> RFC Editor/ar/ap
> >>>>>
> >>>>>
> >>>>> On Jul 24, 2023, [e-mail] wrote:
> >>>>>
> >>>>> *****IMPORTANT*****
> >>>>>
> >>>>> Updated 2023/07/24
> >>>>>
> >>>>> RFC Author(s):
> >>>>> --------------
> >>>>>
> >>>>> Instructions for Completing AUTH48
> >>>>>
> >>>>> Your document has now entered AUTH48.  Once it has been reviewed and
> >>>>> approved by you and all coauthors, it will be published as an RFC.
> >>>>> If an author is no longer available, there are several remedies
> >>>>> available as listed in the FAQ (https://www.rfc-editor.org/faq/).
> >>>>>
> >>>>> You and you coauthors are responsible for engaging other parties
> >>>>> (e.g., Contributors or Working Group) as necessary before providing
> >>>>> your approval.
> >>>>>
> >>>>> Planning your review
> >>>>> ---------------------
> >>>>>
> >>>>> Please review the following aspects of your document:
> >>>>>
> >>>>> *  RFC Editor questions
> >>>>>
> >>>>> Please review and resolve any questions raised by the RFC Editor
> >>>>> that have been included in the XML file as comments marked as
> >>>>> follows:
> >>>>>
> >>>>> <!-- [rfced] ... -->
> >>>>>
> >>>>> These questions will also be sent in a subsequent email.
> >>>>>
> >>>>> *  Changes submitted by coauthors
> >>>>>
> >>>>> Please ensure that you review any changes submitted by your
> >>>>> coauthors.  We assume that if you do not speak up that you
> >>>>> agree to changes submitted by your coauthors.
> >>>>>
> >>>>> *  Content
> >>>>>
> >>>>> Please review the full content of the document, as this cannot
> >>>>> change once the RFC is published.  Please pay particular attention
> to:
> >>>>> - IANA considerations updates (if applicable)
> >>>>> - contact information
> >>>>> - references
> >>>>>
> >>>>> *  Copyright notices and legends
> >>>>>
> >>>>> Please review the copyright notice and legends as defined in
> >>>>> RFC 5378 and the Trust Legal Provisions
> >>>>> (TLP – https://trustee.ietf.org/license-info/).
> >>>>>
> >>>>> *  Semantic markup
> >>>>>
> >>>>> Please review the markup in the XML file to ensure that elements of
> >>>>> content are correctly tagged.  For example, ensure that <sourcecode>
> >>>>> and <artwork> are set correctly.  See details at
> >>>>> <https://authors.ietf.org/rfcxml-vocabulary>.
> >>>>>
> >>>>> *  Formatted output
> >>>>>
> >>>>> Please review the PDF, HTML, and TXT files to ensure that the
> >>>>> formatted output, as generated from the markup in the XML file, is
> >>>>> reasonable.  Please note that the TXT will have formatting
> >>>>> limitations compared to the PDF and HTML.
> >>>>>
> >>>>>
> >>>>> Submitting changes
> >>>>> ------------------
> >>>>>
> >>>>> To submit changes, please reply to this email using ‘REPLY ALL’ as
> all
> >>>>> the parties CCed on this message need to see your changes. The
> parties
> >>>>> include:
> >>>>>
> >>>>> *  your coauthors
> >>>>>
> >>>>> *  [e-mail] (the RPC team)
> >>>>>
> >>>>> *  other document participants, depending on the stream (e.g.,
> >>>>> IETF Stream participants are your working group chairs, the
> >>>>> responsible ADs, and the document shepherd).
> >>>>>
> >>>>> *  [e-mail], which is a new archival mailing
> list
> >>>>> to preserve AUTH48 conversations; it is not an active discussion
> >>>>> list:
> >>>>>
> >>>>> *  More info:
> >>>>>
> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
> >>>>>
> >>>>> *  The archive itself:
> >>>>>   https://mailarchive.ietf.org/arch/browse/auth48archive/
> >>>>>
> >>>>> *  Note: If only absolutely necessary, you may temporarily opt out
> >>>>>   of the archiving of messages (e.g., to discuss a sensitive matter).
> >>>>>   If needed, please add a note at the top of the message that you
> >>>>>   have dropped the address. When the discussion is concluded,
> >>>>>   [e-mail] will be re-added to the CC list and
> >>>>>   its addition will be noted at the top of the message.
> >>>>>
> >>>>> You may submit your changes in one of two ways:
> >>>>>
> >>>>> An update to the provided XML file
> >>>>> — OR —
> >>>>> An explicit list of changes in this format
> >>>>>
> >>>>> Section # (or indicate Global)
> >>>>>
> >>>>> OLD:
> >>>>> old text
> >>>>>
> >>>>> NEW:
> >>>>> new text
> >>>>>
> >>>>> You do not need to reply with both an updated XML file and an
> explicit
> >>>>> list of changes, as either form is sufficient.
> >>>>>
> >>>>> We will ask a stream manager to review and approve any changes that
> seem
> >>>>> beyond editorial in nature, e.g., addition of new text, deletion of
> text,
> >>>>> and technical changes.  Information about stream managers can be
> found in
> >>>>> the FAQ.  Editorial changes do not require approval from a stream
> manager.
> >>>>>
> >>>>>
> >>>>> Approving for publication
> >>>>> --------------------------
> >>>>>
> >>>>> To approve your RFC for publication, please reply to this email
> stating
> >>>>> that you approve this RFC for publication.  Please use ‘REPLY ALL’,
> >>>>> as all the parties CCed on this message need to see your approval.
> >>>>>
> >>>>>
> >>>>> Files
> >>>>> -----
> >>>>>
> >>>>> The files are available here:
> >>>>> https://www.rfc-editor.org/authors/rfc9448.xml
> >>>>> https://www.rfc-editor.org/authors/rfc9448.html
> >>>>> https://www.rfc-editor.org/authors/rfc9448.pdf
> >>>>> https://www.rfc-editor.org/authors/rfc9448.txt
> >>>>>
> >>>>> Diff file of the text:
> >>>>> https://www.rfc-editor.org/authors/rfc9448-diff.html
> >>>>> https://www.rfc-editor.org/authors/rfc9448-rfcdiff.html (side by
> side)
> >>>>>
> >>>>> Diff of the XML:
> >>>>> https://www.rfc-editor.org/authors/rfc9448-xmldiff1.html
> >>>>>
> >>>>> The following files are provided to facilitate creation of your own
> >>>>> diff files of the XML.
> >>>>>
> >>>>> Initial XMLv3 created using XMLv2 as input:
> >>>>> https://www.rfc-editor.org/authors/rfc9448.original.v2v3.xml
> >>>>>
> >>>>> XMLv3 file that is a best effort to capture v3-related format
> updates
> >>>>> only:
> >>>>> https://www.rfc-editor.org/authors/rfc9448.form.xml
> >>>>>
> >>>>>
> >>>>> Tracking progress
> >>>>> -----------------
> >>>>>
> >>>>> The details of the AUTH48 status of your document are here:
> >>>>> https://www.rfc-editor.org/auth48/rfc9448
> >>>>>
> >>>>> Please let us know if you have any questions.
> >>>>>
> >>>>> Thank you for your cooperation,
> >>>>>
> >>>>> RFC Editor
> >>>>>
> >>>>> --------------------------------------
> >>>>> RFC9448 (draft-ietf-acme-authority-token-tnauthlist-13)
> >>>>>
> >>>>> Title            : TNAuthList profile of ACME Authority Token
> >>>>> Author(s)        : C. Wendt, D. Hancock, M. Barnes, J. Peterson
> >>>>> WG Chair(s)      : Deb Cooley, Deb Cooley, Yoav Nir
> >>>>> Area Director(s) : Roman Danyliw, Paul Wouters
> >>>
> >>
> >
>
>