Re: [auth48] AUTH48: RFC-to-be 9525 <draft-ietf-uta-rfc6125bis-15> for your review

[Karen Moore <[e-mail]>]

Hi Peter,

We have noted your approval on the AUTH48 status page (https://www.rfc-editor.org/auth48/rfc9525). We now await Rich’s approval prior to moving forward with publication. 

Best regards,
RFC Editor/kc

> On Nov 6, 2023, at 12:43 PM, Peter Saint-Andre <[e-mail]> wrote:
> 
> Thanks, Karen and Alanna.
> 
> I approve of publication.
> 
> Peter
> 
> On 11/6/23 1:27 PM, Karen Moore wrote:
>> Hi Peter, Rich, and *Paul (AD),
>> Thank you for the updated XML file and your comments.  Our files now reflect these changes. Please review and let us know if any additional updates are needed or if you approve the document in its current form. We will await approvals from each author prior to moving forward in the publication process.
>> *Paul, thank you for confirming that the most recent changes submitted by Peter (on 11/3/23) are okay; we noted your approval on the AUTH48 status page for this document.
>>> On Nov 4, 2023, at 2:58 PM, Paul Wouters <paul.wouters=[e-mail]> wrote:
>>> 
>>> Thanks did the explanations Peter.
>>> 
>>> All changes Peter proposed are fine with me then.
>>> 
>>> Paul
>> FILES (please refresh)
>> The updated XML file is here:
>> https://www.rfc-editor.org/authors/rfc9525.xml
>> The updated output files are here:
>>  https://www.rfc-editor.org/authors/rfc9525.txt
>>  https://www.rfc-editor.org/authors/rfc9525.pdf
>>  https://www.rfc-editor.org/authors/rfc9525.html
>> This diff file shows all changes made during AUTH48:
>>  https://www.rfc-editor.org/authors/rfc9525-auth48diff.html
>> These diff files show only the changes made during the last editing round:
>>  https://www.rfc-editor.org/authors/rfc9525-lastdiff.html
>>  https://www.rfc-editor.org/authors/rfc9525-lastrfcdiff.html
>> This diff file shows all changes made to date:
>>  https://www.rfc-editor.org/authors/rfc9525-diff.html
>> For the AUTH48 status of this document, please see:
>>  https://www.rfc-editor.org/auth48/rfc9525
>> Best regards,
>> RFC Editor/kc
>>> On Nov 3, 2023, at 5:16 PM, Peter Saint-Andre <[e-mail]> wrote:
>>> 
>>> Hi everyone,
>>> 
>>> I've completed a final reading of the document. I would like to make the following small stylistic and consistency changes, which are reflected in the attached XML file.
>>> 
>>> OLD
>>> 
>>>   This document defines procedures for how clients do this
>>>   verification.  It therefore defines requirements on other parties,
>>>   such as the certification authorities that issue certificates, the
>>>   service administrators requesting them, and the protocol designers
>>>   defining how things are named.
>>> 
>>> NEW
>>> 
>>>   This document defines procedures for how clients perform this
>>>   verification.  It therefore defines requirements on other parties,
>>>   such as the certification authorities that issue certificates, the
>>>   service administrators requesting them, and the protocol designers
>>>   defining interactions between clients and servers.
>>> 
>>> OLD
>>> 
>>>   reference identifier:  An identifier used by the client when
>>>      examining presented identifiers.  It is constructed from the
>>>      source domain and, optionally, an application service type.
>>> 
>>> NEW
>>> 
>>>   reference identifier:  An identifier expected by the client when
>>>      examining presented identifiers.  It is constructed from the
>>>      source domain and, optionally, an application service type.
>>> 
>>> OLD
>>> 
>>>   The Common Name RDN MUST NOT be used to identify a service because it
>>>   is not strongly typed (essentially free-form text) and therefore
>>>   suffers from ambiguities in interpretation.
>>> 
>>> NEW
>>> 
>>>   The Common Name RDN MUST NOT be used to identify a service because it
>>>   is not strongly typed (it is essentially free-form text) and
>>>   therefore suffers from ambiguities in interpretation.
>>> 
>>> OLD
>>> 
>>>   An IP address that is the result of a DNS query is not direct.  Use
>>>   of IP-IDs that are not direct is out of scope for this document.
>>> 
>>> NEW
>>> 
>>>   An IP address that is the result of a DNS query is indirect.  Use
>>>   of IP-IDs that are indirect is out of scope for this document.
>>> 
>>> OLD
>>> 
>>>   This section defines how protocol designers should reference this
>>>   document, which would typically be a normative reference in their
>>>   specification.  Its specification MAY choose to allow only one of the
>>>   identifier types defined here.
>>> 
>>> NEW
>>> 
>>>   This section defines how protocol designers should reference this
>>>   document, which would typically be a normative reference in their
>>>   specification.
>>> 
>>>   A specification MAY choose to allow only one of the identifier
>>>   types defined here.
>>> 
>>> OLD
>>> 
>>>   If the technology does not use DNS SRV records to resolve the DNS
>>>   domain names of application services, then its specification MUST
>>> 
>>> NEW
>>> 
>>>   If the technology does not use DNS SRV records to resolve the DNS
>>>   domain names of application services, then the specification MUST
>>> 
>>> OLD
>>> 
>>>   If the technology does not use URIs to identify application services,
>>>   then its specification MUST state that URI-ID as defined in this
>>> 
>>> NEW
>>> 
>>>   If the technology does not use URIs to identify application services,
>>>   then the specification MUST state that URI-ID as defined in this
>>> 
>>> OLD
>>> 
>>>   3.  If the service using the certificate deploys a technology for
>>>       which the relevant specification stipulates that certificates
>>>       should include identifiers of type SRV-ID (e.g., this is true as
>>>       described in [XMPP]), then the certificate SHOULD include an SRV-
>>> 
>>> NEW
>>> 
>>>   3.  If the service using the certificate deploys a technology for
>>>       which the relevant specification stipulates that certificates
>>>       should include identifiers of type SRV-ID (e.g., this is true of
>>>       the Extensible Messaging and Presence Protocol (XMPP) as
>>>       described in [XMPP]), then the certificate SHOULD include an SRV-
>>> 
>>> OLD
>>> 
>>>   4.  If the service using the certificate deploys a technology for
>>>       which the relevant specification stipulates that certificates
>>>       should include identifiers of type URI-ID (e.g., this is true of
>>>       [SIP] as specified by [SIP-CERTS]), then the certificate SHOULD
>>> 
>>> NEW
>>> 
>>>   4.  If the service using the certificate deploys a technology for
>>>       which the relevant specification stipulates that certificates
>>>       should include identifiers of type URI-ID (e.g., this is true of
>>>       the Session Initiation Protocol [SIP] as specified by [SIP-
>>>       CERTS]), then the certificate SHOULD
>>> 
>>> OLD
>>> 
>>>   Consider an instant messaging (IM) server that is compatible with the
>>>   Extensible Messaging and Presence Protocol (XMPP) at the host
>>> 
>>> NEW
>>> 
>>>   Consider an XMPP-compatible instant messaging (IM) server at the host
>>> 
>>> OLD
>>> 
>>>   If a service provider offers multiple application service types and
>>>   wishes to limit the applicability of certificates using SRV-IDs or
>>>   URI-IDs, they SHOULD request that multiple certificates rather than a
>>> 
>>> NEW
>>> 
>>>   If a service provider offers multiple application service types and
>>>   wishes to limit the applicability of certificates using SRV-IDs or
>>>   URI-IDs, it SHOULD request that multiple certificates rather than a
>>> 
>>> OLD
>>> 
>>>   If a service provider offers multiple application service types and
>>>   wishes to limit the applicability of certificates using SRV-IDs or
>>>   URI-IDs, they SHOULD request that multiple certificates rather than a
>>>   single certificate containing multiple SRV-IDs or URI-IDs each
>>>   identify a different application service type.  This rule does not
>>> 
>>> NEW
>>> 
>>>   If a service provider offers multiple application service types and
>>>   wishes to limit the applicability of certificates using SRV-IDs or
>>>   URI-IDs, they SHOULD request multiple certificates rather than a
>>>   single certificate containing multiple SRV-IDs or URI-IDs that each
>>>   identify a different application service type.  This rule does not
>>> 
>>> OLD
>>> 
>>>   2.  The server provides its identifiers in the form of a PKIX
>>>       certificate.
>>> 
>>> NEW
>>> 
>>>   2.  The server provides its presented identifiers in the form of a
>>>       PKIX certificate.
>>> 
>>> OLD
>>> 
>>>   3.  The client checks each of its reference identifiers against the
>>>       presented identifiers for the purpose of finding a match.  When
>>> 
>>> NEW
>>> 
>>>   3.  The client checks each of its reference identifiers against the
>>>       server's presented identifiers for the purpose of finding a
>>>       match.  When
>>> 
>>> OLD
>>> 
>>>   The client MUST construct a list of acceptable reference identifiers
>>>   and MUST do so independently of the identifiers presented by the
>>>   service.
>>> 
>>> NEW
>>> 
>>>   The client MUST construct a list of acceptable reference identifiers
>>>   and MUST do so independently of the identifiers presented by the
>>>   server.
>>> 
>>> OLD
>>> 
>>> For example, a protocol or application could specify
>>>   that the application service type is obtained through a one-to-one
>>>   mapping of URI schemes to service types or supports only a restricted
>>>   set of URI schemes.
>>> 
>>> NEW
>>> 
>>> For example, a protocol or application could specify
>>>   that the application service type is obtained through a one-to-one
>>>   mapping of URI schemes to service types or that the protocol or
>>>   application supports only a restricted set of URI schemes.
>>> 
>>> OLD
>>> 
>>>   As one example of the process of generating a reference identifier,
>>>   from the user input of the URI <sip:[e-mail]>, a client
>>>   could derive the application service type sip from the URI scheme and
>>>   parse the domain name college.example from the "host" component.
>>> 
>>> NEW
>>> 
>>>   As one example of the process of generating a reference identifier,
>>>   from the user input of the URI <sip:[e-mail]>, a
>>>   client could derive the application service type sip from the URI
>>>   scheme and parse the domain name voice.college.example from the
>>>   "host" component.
>>> 
>>> In Section 6.1.2, for the sake of consistency I've added and removed some angle brackets (URIs should have brackets, whereas domain names, IP addresses, and various IDs should not).
>>> 
>>> OLD
>>> 
>>>   *  An IP-ID reference identifier MUST exactly match to the value of
>>> 
>>> NEW
>>> 
>>>   *  An IP-ID reference identifier MUST exactly match the value of
>>> 
>>> OLD
>>> 
>>>   These identifiers provide an application service type portion to be
>>>   checked, but that portion is combined only with the DNS domain name
>>>   portion of the SRV-ID or URI-ID itself.  For example, if a client's
>>>   list of reference identifiers includes an SRV-ID of _xmpp-
>>>   client.messenger.example and a DNS-ID of app.example, the client MUST
>>>   check both the combination of an application service type of xmpp-
>>>   client and a DNS domain name of messenger.example and, separately, a
>>>   DNS domain name of app.example.  However, the client MUST NOT check
>>>   the combination of an application service type of xmpp-client and a
>>>   DNS domain name of app.example because it does not have an SRV-ID of
>>>   _xmpp-client.app.example in its list of reference identifiers.
>>> 
>>> NEW
>>> 
>>>   These identifiers provide an application service type portion to be
>>>   checked, but that portion is combined only with the DNS domain name
>>>   portion of the SRV-ID or URI-ID itself.  Consider the example of a
>>>   messaging client that has two reference identifiers: (1) an SRV-ID of
>>>   _xmpp-client.messenger.example and (2) a DNS-ID of app.example. The
>>>   client MUST check (1) the combination of (a) an application
>>>   service type of xmpp-client and (b) a DNS domain name of
>>>   messenger.example as well as (2) a DNS domain name of app.example.
>>>   However, the client MUST NOT check the combination of an application
>>>   service type of xmpp-client and a DNS domain name of app.example
>>>   because it does not have an SRV-ID of _xmpp-client.app.example in its
>>>   list of reference identifiers.
>>> 
>>> OLD
>>> 
>>>   [DNS-SRV].  Note that per [SRVNAME], the _ character is part of the
>>> 
>>> NEW
>>> 
>>>   [DNS-SRV].  Note that per [SRVNAME], the underscore "_" is part of the
>>> 
>>> 
>>> OLD
>>> 
>>>   that the : character is a separator between the scheme name and the
>>> 
>>> NEW
>>> 
>>>   that the colon ":" is a separator between the scheme name and the
>>> 
>>> OLD
>>> 
>>>   If the client does not find a presented identifier matching any of
>>>   the reference identifiers, then the client MUST proceed as described
>>>   as follows.
>>> 
>>> NEW
>>> 
>>>   If the client does not find a presented identifier matching any of
>>>   the reference identifiers, then the client MUST proceed as follows.
>>> 
>>> OLD
>>> 
>>>   The textual representation of an IPv4 address might be misinterpreted
>>>   as a valid FQDN in some contexts.  This can result in different
>>>   security treatment that might cause different components of a system
>>>   to classify the value differently, which might lead to
>>>   vulnerabilities.  For example, one system component enforces a
>>>   security rule that is conditional on the type of identifier.  This
>>>   component misclassifies an IP address as an FQDN.  A different
>>>   component correctly classifies the identifier but might incorrectly
>>>   assume that rules regarding IP addresses have been enforced.
>>>   Consistent classification of identifiers avoids this problem.
>>> 
>>> NEW
>>> 
>>>   The textual representation of an IPv4 address might be misinterpreted
>>>   as a valid FQDN in some contexts.  This can result in different
>>>   security treatment that might cause different components of a system
>>>   to classify the value differently, which might lead to
>>>   vulnerabilities.  Consider a system in which one component enforces a
>>>   security rule that is conditional on the type of identifier but
>>>   misclassifies an IP address as an FQDN, whereas a second component
>>>   correctly classifies the identifier but incorrectly assumes that
>>>   rules regarding IP addresses have been enforced by the first
>>>   component.  As a result, the system as a whole might behave in an
>>>   insecure manner.  Consistent classification of identifiers avoids
>>>   this problem.
>>> 
>>> Peter
>>> 
>>> On 11/2/23 5:51 PM, Peter Saint-Andre wrote:
>>>> Thanks, Alanna. Before replying again, I will read the full document.
>>>> On 11/2/23 3:04 PM, Alanna Paloma wrote:
>>>>> Hi Peter, Orie, and Rich,
>>>>> 
>>>>> Thank you for your replies and the XML files. We have updated our files accordingly.
>>>>> 
>>>>> The updated XML file is here:
>>>>> https://www.rfc-editor.org/authors/rfc9525.xml
>>>>> 
>>>>> The updated output files are here:
>>>>> https://www.rfc-editor.org/authors/rfc9525.txt
>>>>> https://www.rfc-editor.org/authors/rfc9525.pdf
>>>>> https://www.rfc-editor.org/authors/rfc9525.html
>>>>> 
>>>>> This diff file shows all changes made during AUTH48:
>>>>> https://www.rfc-editor.org/authors/rfc9525-auth48diff.html
>>>>> 
>>>>> This diff file shows all changes made to date:
>>>>> https://www.rfc-editor.org/authors/rfc9525-diff.html
>>>>> 
>>>>> Note that it may be necessary for you to refresh your browser to view the most recent version. Please review the document carefully to ensure satisfaction as we do not make changes once it has been published as an RFC.
>>>>> 
>>>>> Please contact us with any further updates or with your approval of the document in its current form.  We will await 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/rfc9525
>>>>> 
>>>>> Best regards,
>>>>> RFC Editor/ap
>>>>> 
>>>>> 
>>>>>> On Oct 31, 2023, at 10:07 AM, Peter Saint-Andre <[e-mail]> wrote:
>>>>>> 
>>>>>> I've attached an XML file with further updates.
>>>>>> 
>>>>>> Further comments inline, areas of agreement elided.
>>>>>> 
>>>>>> Note: to ease my own mind about changes to this file, I've checked it into source control:
>>>>>> 
>>>>>> https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/115
>>>>>> 
>>>>>> On 10/31/23 8:57 AM, Salz, Rich wrote:
>>>>>>> Sigh.
>>>>>>> I followed the instructions and updated the XML.  Here it is attached.  I believe that we are in agreement  but I leave it to you petty criminals to figure out.  As a hint, search for “rfced” in the XML and then see my comments that immediately follow those.
>>>>>>> *From: *Orie Steele <[e-mail]>
>>>>>>> *Date: *Tuesday, October 31, 2023 at 10:05 AM
>>>>>>> *To: *Peter Saint-Andre <[e-mail]>
>>>>>>> *Cc: *"[e-mail]" <[e-mail]>, Rich Salz <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
>>>>>>> *Subject: *Re: AUTH48: RFC-to-be 9525 <draft-ietf-uta-rfc6125bis-15> for your review
>>>>>>> Inline:
>>>>>>> On Mon, Oct 30, 2023 at 6:55 PM Peter Saint-Andre <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>>>     Thanks for working on this document. Comments inline, areas of
>>>>>>>     agreement
>>>>>>>     elided.
>>>>>>>     On 10/30/23 10:15 AM, [e-mail]
>>>>>>>     <mailto:[e-mail]> wrote:
>>>>>> 
>>>>>> <snip/>
>>>>>> 
>>>>>>>      > 7) <!--[rfced] RFC 2818 [HTTP-OVER-TLS] has been obsoleted by RFC
>>>>>>>     9110
>>>>>>>      > [HTTP]. Please let us know if we can replace "[HTTP-OVER-TLS]"
>>>>>>>      > with "[HTTP]" in the following and also remove the
>>>>>>>      > "[HTTP-OVER-TLS]" entry from the References section since it is
>>>>>>>      > not cited elsewhere.
>>>>>>> I think this should be done, but would like to hear from Rich.
>>>>>>>     That's acceptable to me. Rich, do you have concerns?
>>>>>>>      > In addition, please clarify "when the client uses [SVCB-FOR-HTTPS] or
>>>>>>>      > [SVCB-FOR-DNS]" - what is the client using or applying the PKIX
>>>>>>>      > validation rules to in these documents? Or is the intent to state
>>>>>>>      > that the PKIX validation rules are the same as described in these
>>>>>>>      > documents? Please clarify.
>>>>>>>      >
>>>>>>>      > Original:
>>>>>>>      >     For example, the PKIX validation rules for [HTTP-OVER-TLS] and
>>>>>>>      >     [DNS-OVER-TLS] do not change when the client uses
>>>>>>>     [SVCB-FOR-HTTPS]
>>>>>>>      >     or [SVCB-FOR-DNS].
>>>>>>>      >
>>>>>>>      > Perhaps:
>>>>>>>      >     For example, the PKIX validation rules described in [HTTP] and
>>>>>>>      >     [DNS-OVER-TLS] are the same as described in [SVCB-FOR-HTTPS] and
>>>>>>>      >     [SVCB-FOR-DNS].
>>>>>>>      > -->
>>>>>>>     I believe the meaning is explained in the previous sentence; this
>>>>>>>     sentence is merely an example that points to several of the
>>>>>>>     documents in
>>>>>>>     progress regarding SVCB.
>>>>>>> I agree, but to answer the question directly I believe the intention is to communicate that the PKIX validation rules are the same,
>>>>>>> as of now, and warn that they might not be in the future.
>>>>>> 
>>>>>> OK, I propose the following modified text (also inside a comment in the XML file):
>>>>>> 
>>>>>>    For example, the PKIX validation rules for [HTTP-OVER-TLS] and
>>>>>>    [DNS-OVER-TLS] do not change when the client uses the DNS resource
>>>>>>    records defined in [SVCB-FOR-HTTPS] or [SVCB-FOR-DNS] to look up
>>>>>>    connection information.
>>>>>> 
>>>>>>>      > 19) <!-- [rfced] Please review the "Inclusive Language" portion
>>>>>>>     of the online
>>>>>>>      > Style Guide
>>>>>>>     <https://www.rfc-editor.org/styleguide/part2/#inclusive_language
>>>>>>>    <https://urldefense.com/v3/__https:/www.rfc-editor.org/styleguide/part2/*inclusive_language__;Iw!!GjvTz_vk!QdpBBBfoK53ywTtBS24JUSgsd2iO6awbK8himXieJFxEDdi9ri9V_tuSZ4ggGXxFRzWarWtbDLbcFFvJN1c$>>
>>>>>>>      > and let us know if any changes are needed.
>>>>>>>      >
>>>>>>>      > For example, please consider whether "tradition" should be
>>>>>>>     updated for
>>>>>>>      > clarity.  While the NIST website
>>>>>>>      >
>>>>>>>     <https://www.nist.gov/nist-research-library/nist-technical-series-
>>>>>>>    <https://urldefense.com/v3/__https:/www.nist.gov/nist-research-library/nist-technical-series-__;!!GjvTz_vk!QdpBBBfoK53ywTtBS24JUSgsd2iO6awbK8himXieJFxEDdi9ri9V_tuSZ4ggGXxFRzWarWtbDLbcNDEGmAk$>
>>>>>>>      > publications-author-instructions#table1> indicates that this term is
>>>>>>>      > potentially biased, it is also ambiguous. "Tradition" is a subjective
>>>>>>>      > term, as it is not the same for everyone.
>>>>>>>      > -->
>>>>>>>     Well, fully qualified domain names conforming to "preferred name
>>>>>>>     syntax"
>>>>>>>     as described in Section 3.5 of RFC 1034 were, in fact, the same for
>>>>>>>     everyone! So I don't consider the use of "traditional" here to be
>>>>>>>     biased
>>>>>>>     or ambiguous - that's just how the Internet was defined in IETF RFCs.
>>>>>> 
>>>>>> In the XML file, Rich neatly sidestepped this issue by making this change:
>>>>>> 
>>>>>> OLD
>>>>>> 
>>>>>>    If the DNS domain name portion of a reference identifier is a
>>>>>>    "traditional domain name"
>>>>>> 
>>>>>> NEW:
>>>>>> 
>>>>>>    If the DNS domain name portion of a reference identifier
>>>>>>    is not an internationalized domain name
>>>>>> 
>>>>>> That's fine with me.
>>>>>> 
>>>>>> Peter
>>>>>> 
>>>>>> <rfc9525.xml>
>>>>> 
>>> <rfc9525.xml>
>