Alan,
We have marked your approval on the AUTH48 status page for this document
<http://www.rfc-editor.org/auth48/rfc9813>. We will now move this document
forward in the publication process at this time.
Thanks for your time and attention during AUTH48.
RFC Editor/kf
> On Jul 8, 2025, at 10:17 AM, Alan DeKok <alan.de...@inkbridge.io> wrote:
>
> I've reviewed the document, and it looks fine. It's approved for
> publication.
>
>> On Jul 8, 2025, at 10:08 AM, Kaelin Foody <kfo...@staff.rfc-editor.org>
>> wrote:
>>
>> Hi Alan,
>>
>> This is a friendly reminder that we await your approval regarding this
>> document’s readiness for publication. Please see our previous message to
>> review the updated files, and let us know if you have any further updates or
>> if you approve this document in its current form.
>>
>> Thank you,
>> RFC Editor/kf
>>
>>> On Jun 20, 2025, at 5:27 PM, Kaelin Foody <kfo...@staff.rfc-editor.org>
>>> wrote:
>>>
>>> Hi Alan,
>>>
>>> Thanks for your reply. We have updated our files accordingly.
>>>
>>> Per your reply we have not expanded the abbreviations below:
>>>
>>>>> c) Per Section 3.6 of RFC 7322 ("RFC Style Guide"), abbreviations should
>>>>> be
>>>>> expanded upon first use. How should "PSK-DH" and "ECDHE_PSK" be expanded
>>>>> below?
>>>>
>>>> Those terms are related to TLS, and are more "fixed names" than
>>>> abbreviations.
>>>>
>>>> PSK-DH is used in RFC9257 without expansion or definition. ECDHE_PSK is
>>>> used in RFC5489 without expansion or definition.
>>>>
>>>> On quick search, I can't find an RFC where those terms are defined.
>>>>
>>>> I'm not objecting to the proposed text, but I'm not sure we want to define
>>>> the terms here, when the referenced RFC doesn't define the terms.
>>>
>>>
>>> The updated files have been posted here (please refresh):
>>> https://www.rfc-editor.org/authors/rfc9813.txt
>>> https://www.rfc-editor.org/authors/rfc9813.pdf
>>> https://www.rfc-editor.org/authors/rfc9813.html
>>> https://www.rfc-editor.org/authors/rfc9813.xml
>>>
>>> The relevant diff files have been posted here (please refresh):
>>> https://www.rfc-editor.org/authors/rfc9813-diff.html (comprehensive diff)
>>> https://www.rfc-editor.org/authors/rfc9813-rfcdiff.html (side by side)
>>> https://www.rfc-editor.org/authors/rfc9813-auth48diff.html (AUTH48 changes
>>> only)
>>>
>>> Please review and let us know any further updates you may have or if you
>>> approve this document in its current form.
>>>
>>> Thank you,
>>> RFC Editor/kf
>>>
>>> On Jun 18, 2025, at 9:39 AM, Alan DeKok
>>> <alan.dekok=40inkbridge...@dmarc.ietf.org> wrote:
>>>>
>>>> On Jun 17, 2025, at 1:49 PM, rfc-edi...@rfc-editor.org wrote:
>>>>> 1) <!-- [rfced] The title of the document has been updated as follows.
>>>>> "TLS-PSK" has been expanded as "TLS Pre-Shared Key"; however, please
>>>>> let us know if it should be expanded otherwise both here and in the rest
>>>>> of the document.
>>>>>
>>>>> Original:
>>>>> Operational Considerations for RADIUS and TLS-PSK
>>>>>
>>>>> Option A (current title):
>>>>> Operational Considerations for RADIUS and TLS Pre-Shared Key (TLS-PSK)
>>>>>
>>>>> Option B (using the phrase from the abstract):
>>>>> Operational Considerations for Using TLS Pre-Shared Keys (TLS-PSKs) with
>>>>> RADIUS
>>>>>
>>>>> Option C (more similar to the title of RFC 4279):
>>>>> Operational Considerations for RADIUS and TLS Pre-Shared Key (TLS-PSK)
>>>>> Cipher Suites
>>>>>
>>>>> [Note: RFC 4279 has been cited for "TLS-PSK" in RFCs 6614, 6940, and
>>>>> 7593.]
>>>>> -->
>>>>
>>>> Option B seems best
>>>>
>>>>>
>>>>> 2) <!--[rfced] This document has been assigned a new BCP number. Please
>>>>> let us know
>>>>> if this is not correct (i.e., it should be part of an existing BCP).
>>>>>
>>>>> See the complete list of BCPs here: https://www.rfc-editor.org/bcps
>>>>> -->
>>>>
>>>> A new BCP is fine. We will likely be adding more RADIUS BCP specificatons
>>>> in the future. Perhaps they could all be put under a common "RADIUS
>>>> Operational Considerations" BCP?
>>>>
>>>>> 3) <!-- [rfced] Please insert any keywords (beyond those that appear in
>>>>> the title) for use on https://www.rfc-editor.org/search. -->
>>>>>
>>>>>
>>>>> 4) <!-- [rfced] What specific text does "base32 in the example below"
>>>>> refer to?
>>>>> May we update to provide a more clear pointer for the reader?
>>>>
>>>> It refers to the later sample commands:
>>>>
>>>> dd if=/dev/urandom bs=1 count=16 | base32
>>>>
>>>> Adding a clear pointer would help.
>>>>
>>>>> 5) <!-- [rfced] Section 4.2: We have made some updates to the numbered
>>>>> list
>>>>> at the end of this section, in order to make the list items more
>>>>> parallel. Please review and let us know any further updates. -->
>>>>
>>>> The changes are fine.
>>>>
>>>>> 6) <!-- [rfced] For readability, may we format this sentence as a list?
>>>>>
>>>>> Original:
>>>>> For example, the identity may have incorrect UTF-8 format; or it may
>>>>> contain data which forms an injection attack for SQL, LDAP, REST or shell
>>>>> meta characters; or it may contain embedded NUL octets which are
>>>>> incompatible with APIs which expect NUL terminated strings.
>>>>>
>>>>> Perhaps:
>>>>> For example, the identity may:
>>>>>
>>>>> * have an incorrect UTF-8 format,
>>>>>
>>>>> * contain data that forms an injection attack for SQL, the Lightweight
>>>>> Directory Access Protocol (LDAP), Representational State Transfer
>>>>> (REST), or shell meta characters, or
>>>>>
>>>>> * contain embedded NUL octets that are incompatible with APIs that
>>>>> expect NUL terminated strings.
>>>>> -->
>>>>
>>>> Yes, that's fine.
>>>>
>>>>>
>>>>> 7) <!-- [rfced] For clarity, may we update the second part of this
>>>>> sentence
>>>>> to repeat "expose"? This helps to avoid misreading "fields" as a verb.
>>>>>
>>>>> Original:
>>>>> The client implementation can then expose a user interface flag which is
>>>>> "TLS yes / no", and then also fields which ask for the PSK Identity and
>>>>> PSK
>>>>> itself.
>>>>>
>>>>> Perhaps:
>>>>> The client implementation can then expose a user interface flag that is
>>>>> "TLS yes / no", and also expose fields that ask for the PSK Identity and
>>>>> PSK
>>>>> itself.
>>>>> -->
>>>>
>>>> The proposal is good, but change "expose" to "provide", which is a little
>>>> more neutral.
>>>>
>>>>> 8) <!-- [rfced] Regarding this text in Section 5:
>>>>> a) May we update the first sentence to avoid repetition of "TLS 1.3"?
>>>>> b) This exact text appears again in Section 6 (i.e., for clients
>>>>> and servers). Please review and confirm it is correct for this text
>>>>> to appear twice in this document.
>>>>
>>>> The proposed text is fine. It's OK for the text to appear twice.
>>>>
>>>>> 9) <!-- [rfced] Is "clients" meant to be singular possessive or
>>>>> plural possessive in the text below?
>>>>
>>>> singular possesive.
>>>>
>>>>> 10) <!-- [rfced] Informative reference RFC 5077 has been obsoleted by
>>>>> RFC 8446. We recommend replacing RFC 5077 with RFC 8446. However, if RFC
>>>>> 5077 must be referenced, we suggest mentioning RFC 8446 (e.g., "RFC 5077
>>>>> has
>>>>> been obsoleted by RFC 8446.") See Section 4.8.6 in the RFC Style Guide
>>>>>
>>>>> (RFC 7322). -->
>>>>
>>>> We can change the reference from RFC 5077 Section 4, to RFC8446, Section
>>>> 4.6.1
>>>>
>>>>>
>>>>> 11) <!-- [rfced] Abbreviations and Terminology:
>>>>>
>>>>> a) We note "pre-shared key" appears frequently after the abbreviation
>>>>> "PSK"
>>>>> is introduced. May we update instances of "pre-shared key" to its
>>>>> abbreviation
>>>>> after it is first expanded?
>>>>
>>>> Yes.
>>>>
>>>>> b) FYI, we changed "PKSs" to "PSKs" in the text below. Please review
>>>>> whether this is correct.
>>>>
>>>> It's correct.
>>>>
>>>>
>>>>
>>>>> c) Per Section 3.6 of RFC 7322 ("RFC Style Guide"), abbreviations should
>>>>> be
>>>>> expanded upon first use. How should "PSK-DH" and "ECDHE_PSK" be expanded
>>>>> below?
>>>>
>>>> Those terms are related to TLS, and are more "fixed names" than
>>>> abbreviations.
>>>>
>>>> PSK-DH is used in RFC9257 without expansion or definition. ECDHE_PSK is
>>>> used in RFC5489 without expansion or definition.
>>>>
>>>> On quick search, I can't find an RFC where those terms are defined.
>>>>
>>>> I'm not objecting to the proposed text, but I'm not sure we want to define
>>>> the terms here, when the referenced RFC doesn't define the terms.
>>>>
>>>>> d) FYI, we added expansions upon first use for the abbreviations below.
>>>>> Please
>>>>> review each expansion in the document carefully to ensure correctness.
>>>>>
>>>>> Lightweight Directory Access Protocol (LDAP)
>>>>> Representational State Transfer (REST)
>>>>> Network Access Server (NAS)
>>>>> -->
>>>>
>>>> Yes, that's fine.
>>>>
>>>>>
>>>>> 12) <!-- [rfced] FYI, we fixed the links to the sections as follows.
>>>>> Please review to ensure these updates are correct.
>>>>>
>>>>> Original:
>>>>> Further discussion of this topic is contained in []{#sharing}.
>>>>>
>>>>> See {}(#resumption) below for more discussion of issues around resumption.
>>>>>
>>>>> Current:
>>>>> Further discussion of this topic is contained in Section 4.3.
>>>>>
>>>>> See Section 6.2.3 below for more discussion of issues around resumption.
>>>>> -->
>>>>
>>>> That's fine.
>>>>
>>>>>
>>>>> 13) <!-- [rfced] We updated artwork to sourcecode in Section 4.1.2.
>>>>> Please confirm
>>>>> that this is correct.
>>>>
>>>> That's fine.
>>>>
>>>>> In addition, please consider whether the "type" attribute of any
>>>>> sourcecode
>>>>> element should be set and/or has been set correctly. The current list of
>>>>> preferred values for "type" is available at
>>>>> <https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>. If
>>>>> the
>>>>> current list does not contain an applicable type, feel free to suggest
>>>>> additions for consideration. Note that it is also acceptable to leave the
>>>>> "type" attribute not set.
>>>>> -->
>>>>
>>>> The "type" here should be "shell"
>>>>
>>>> Alan DeKok.
>>>>
>>>
>>
>
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
