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

[Orie Steele <[e-mail]>]

Inline:

On Mon, Oct 30, 2023 at 6:55 PM Peter Saint-Andre <[e-mail]>
wrote:

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


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


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


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

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

As Document Shepheard, I missed this, Section 3 of RFC 6066 seems like the
correct reference to me.


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

-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>