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

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

Thanks for working on this document. Comments inline, areas of agreement 
elided.

On 10/30/23 10:15 AM, [e-mail] wrote:

> 5) <!--[rfced] In the following, should "component" be plural since it's
> referring to "parameters"?
> 
> Original:
>     Other aspects of a service such as a specific resource (the URI
>     "path" component) or parameters (the URI "query" component) are
>     the responsibility of specific protocols or URI schemes.
> 
> Perhaps:
>     Other aspects of a service such as a specific resource (the URI
>     "path" component) or parameters (the URI "query" components) are
>     the responsibility of specific protocols or URI schemes.
> -->

Here 'component' should be singular - there's only one query component 
in a URI, but it can include multiple parameters.

> 6) <!-- [rfced] In the html and pdf outputs, the text enclosed in <tt> is output in
> fixed-width font. In the txt output, there are no changes to the font,
> and the quotation marks have been removed.
> 
> In the html and pdf outputs, the text enclosed in <em> is output in
> italics. In the txt output, the text enclosed in <em> appears with an
> underscore before and after.
> 
> Please review carefully and let us know if the output is acceptable or if any
> updates are needed.
> -->

That looks fine to me.

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

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.

> 8) <!--[rfced] We notice inconsistent use of quote marks and angle
> brackets for example URIs/URLs. Are any updates needed for
> consistency?
> 
> Some examples:
>     <sip:voice.college.example>
>     <sip:[e-mail]>
>     "www.bigcompany.example"
>     www.bigcompany.example
>     https://www.bigcompany.example/
> -->

I'd put them all in angle brackets.

> 9) <!--[rfced] May we rephrase this sentence as follows in order to
> expand the first mention of "XMPP"? Also, what is discoverable
> via DNS SRV lookups - is it the server (option A) or the IM
> addresses (option B)?
> 
> Original:
>     Consider an XMPP-compatible instant messaging (IM) server at the host
>     messenger.example servicing IM addresses of the form
>     [e-mail] and discoverable via DNS SRV lookups on the
>     messenger.example domain.
> 
> Perhaps:
> A) Consider an instant messaging (IM) server that is compatible with
>     the Extensible Messaging and Presence Protocol (XMPP) at the host
>     messenger.example that services IM addresses of the form
>     [e-mail] and is discoverable via DNS SRV lookups
>     on the messenger.example domain.

I like (A) but I would say "and that is discoverable"; this document is 
about the verification of services discovered via DNS (mostly), so in 
this case and all cases it is the services we care about, not the 
addresses serviced there.

> or
> 
> B) Consider an instant messaging (IM) server that is compatible with
>     the Extensible Messaging and Presence Protocol (XMPP) at the host
>     messenger.example that services IM addresses of the form
>     [e-mail], which are discoverable via DNS SRV lookups
>     on the messenger.example domain.
> -->
> 
> 
> 10) <!--[rfced] To avoid personification, can the protocol "specify" or
> "require" instead of "insist" in the following context?
> 
> Original:
>     Similarly, it could insist that a domain name or IP address
>     taken as input to the reference identifier must be obtained
>     in a secure context such as...
> 
> Perhaps:
>     Similarly, it could specify that a domain name or an IP address
>     taken as input to the reference identifier must be obtained
>     in a secure context such as...
> -->

Protocols are people too! ;-)

I think "specify" is good here (and consistent with the previous sentence).

> 11) <!--[rfced] Since nouns with "(s)" are read as singular, please let us
> know if you prefer the text to reflect option A or B below.
> 
> Original:
>     Using the combination of FQDN(s) or IP address(es), plus optionally
>     an application service type, the client MUST construct its list of
>     reference identifiers in accordance with the following rules:
> 
> Perhaps:
> A) Using the combination of an FQDN(s) or an IP address(es), plus
>     optionally an application service type, the client MUST construct
>     its list of reference identifiers in accordance with the following
>     rules:
> or
> 
> B) Using the combination of one or more FQDNs or IP addresses, plus
>     optionally an application service type, the client MUST construct
>     its list of reference identifiers in accordance with the following
>     rules:
> -->

I think (B) reads more smoothly.

> 12) <!--[rfced] To be "equal" means to be of the same amount or number, so
> could "exactly equal" be updated as "equal" to reduce redundancy?
> Note that there are two instances. Please clarify.
> 
> Original:
>     An IP-ID reference identifier MUST be exactly equal to the value
>     of a iPAddress entry in subjectAltName, with no partial (e.g.,
>     network-level) matching.  There is no application service type.
> 
>     A wildcard in a presented identifier can only match exactly one label
>     in a reference identifier.
> 
> Perhaps:
>     An IP-ID reference identifier MUST be equal to the value of
>     an iPAddress entry in subjectAltName, with no partial (e.g.,
>     network-level) matching.  There is no application service
>     type.
> 
>     A wildcard in a presented identifier can only match one label
>     in a reference identifier.
> -->

I might say "MUST exactly match".

> 13) <!--[rfced] Does an IP-ID perform matches, or is an IP-ID considered
> a match based on certain criteria? Please let us know if/how we
> can clarify this sentence.
> 
> Original:
>     An IP-ID matches based on an octet-for-octet comparison of the bytes
>     of the reference identity with the bytes contained in the iPAddress
>     subjectAltName.
> 
> Perhaps:
>     An IP-ID is considered a match based on an octet-for-octet comparison of
>     the bytes of the reference identity with the bytes contained in the
>     iPAddress subjectAltName.
> -->

I might say "Matching of an IP-ID is based on..."

> 14) <!--[rfced] Should this reference be to "Section 6.3" instead of
> "Section 6" since "A-labels" are not specifically mentioned in
> Section 6?
> 
> Original:
>     More specifically, matching of internationalized domain
>     names is performed on A-labels only Section 6.
> 
> Perhaps:
>     Specifically, the matching of internationalized domain
>     names is performed on A-labels only (Section 6.3).
> -->

WFM.

> 15) <!--[rfced] Section 4.4.2.2 of RFC 8446 does not mention "SNI"; is
> another section intended? Note that in Section 4.2.11, "SNI" is
> discussed and expanded as "Server Name Identification (SNI)", but
> in Section 9.2, "Server Name Indication" is included in the list
> of TLS extensions. Given this, please let us know if any updates
> are needed to the section reference and expansion of "SNI" in
> the text below.
> 
> Original:
>     TLS Extensions such as TLS Server Name Indication (SNI), discussed
>     in [TLS], Section 4.4.2.2, and Application Layer Protocol Negotiation
>     (ALPN), discussed in [ALPN], provide a way for the application to
>     indicate the desired identifier and protocol to the server, which
>     it can then use to select the most appropriate certificate.
> -->

I'm not sure how we ended up including such an incorrect citation. The 
best reference is Section 3 of RFC 6066. That's what we cited as 
[TLS-EXT] in RFC 6125.

> 16) <!--[rfced] References
> 
> a) FYI: There was a duplicate reference entry for RFC 3986 with
> one citation name displayed as "[RFC3986]" and the other as
> "[URI]". We kept the "URI" naming scheme. If you prefer to use
> the RFC number instead, please let us know.

[URI] is good.

> b) There is a more recent version of [US-ASCII].  Please
> confirm if the reference entry should be updated to reflect "ANSI
> INCITS 4-1986 (R2007)" (see http://sliderule.mraiow.com/
> w/images/7/73/ASCII.pdf) instead of "ANSI X3.4-1986".
> 
> Original:
>     [US-ASCII] American National Standards Institute,
>                "Coded Character Set - 7-bit American
>                Standard Code for Information
>                Interchange", ANSI X3.4, 1986.
> 
> Perhaps:
>     [US-ASCII] American National Standards Institute,
>                "Coded Character Sets - 7-bit American
>                Standard Code for Information
>                Interchange (7-Bit ASCII)", ANSI INCITS
>                4-1986 (R2007), June 2007.

Is it IETF or RPC preference to cite RFC 20? If not, the more recent 
reference seems good.

> c) The 2005 version of reference X.509 has been superseded
> (see https://www.itu.int/rec/T-REC-X.509). Would you like to
> point to the most current version (2019) as follows or keep the
> entry the same?
> 
> Current:
>   [X.509]  ITU-T, "Information Technology - Open Systems
>            Interconnection - The Directory: Public-key and
>            attribute certificate frameworks", ISO/IEC 9594-8,
>            ITU-T Recommendation X.509, August 2005.
> 
> Perhaps:
>   [X.509]  ITU-T, "Information Technology - Open Systems
>            Interconnection - The Directory: Public-key and
>            attribute certificate frameworks", ISO/IEC 9594-8,
>            ITU-T Recommendation X.509, October 2019.

The more recent reference is likely preferable.

> d)  The 2008 version of reference X.690 has been superseded
> (see https://www.itu.int/rec/T-REC-X.690). Would you like to
> point to the most current version (2021) as follows or keep the
> entry the same?
> 
> Current:
>    [X.690]  ITU-T, "Information Technology - ASN.1 encoding rules:
>             Specification of Basic Encoding Rules (BER), Canonical
>             Encoding Rules (CER) and Distinguished Encoding Rules
>             (DER)", ISO/IEC 8825-1, ITU-T Recommendation X.690,
>             November 2008.
> 
> Perhaps:
>    [X.690]  ITU-T, "Information Technology - ASN.1 encoding rules:
>             Specification of Basic Encoding Rules (BER), Canonical
>             Encoding Rules (CER) and Distinguished Encoding Rules
>             (DER)", ISO/IEC 8825-1:2021 (E), ITU-T Recommendation
>             X.690, February 2021.
> -->

Ditto.

> 17) <!--[rfced] In the Acknowledgements, we updated "Ines Robles" to
> "Maria Ines Robles". If that is not correct, please let us know.

Thanks.

> Also, would you like to add the name of the mailing list here?
> 
> Original:
>     In addition to discussion on the mailing list, the following people
>     provided official reviews or especially significant feedback:
> -->

I might say "discussion within the UTA WG".

> 18) <!-- [rfced] Acronym Expansions
> 
> a) Throughout the text, the following expansion appears to be used
> inconsistently. Please review these occurrences and let us know
> if/how they may be made consistent.
> 
>    certificate authority (CA) (this doc) vs.
>    certification authority (CA) (per RFCs 5280, 6125, and 9345)
> 
>      Note: In addition, we see the following:
>        - "certification authority" in Section 1.4.2
>        - "certificate authority" in Section 4.1

Since we used "certification authority" in RFC 6125, I'd prefer to 
consistently use it here again.

> b) FYI: We updated the text to reflect the latter form for
> consistency per RFCs 5280 and 6125:
> 
>    Public Key Infrastructure Using X.509 (PKIX) ->
>    Public Key Infrastructure using X.509 (PKIX)
> -->

Thanks.

> 19) <!-- [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.
> 
> 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-
> 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.

Thanks again for your careful attention to this document.

Peter