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

[Peter Saint-Andre <[e-mail]>]

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>
>>
>