Hello and thanks for the early review.
I've provided a few comments inline.
On 12/16/22 4:09 AM, Qin Wu via Datatracker wrote:
Reviewer: Qin Wu
Review result: Has Nits
I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written with the intent of improving the operational aspects of the IETF
drafts. Comments that are not addressed in last call may be included in AD
reviews during the IESG review. Document editors and WG chairs should treat
these comments just like any other last call comments.
This document specifies procedures for representing and verifying the
application services identity in TLS interaction with PKI X.509 certificates.
I believe this document is well written and ready for publication.
Major issue:
No
Minor issues:
1.Section 1.2 Applicability
s/ cetrificate/certificate
Already noted:
https://github.com/richsalz/draft-ietf-uta-rfc6125bis/issues/69
2. Delegated domain definition
“ For example, a server at mail.example.net could be a delegated domain for
connecting to an IMAP server hosting an email address of [email protected]. ” I
can not parse this sentence, is the server a delegated domain? Which domain is
the source domain? Which domain is delegated domain ? please make this clear in
the example.
Yes, this could be clearer. In this case the source domain is
example.net (i.e., the `domain` portion of the `addr-spec` construct
defined in RFC 5322).
3.Section 2 Identifying Application Service What is meaning
difference between _direct_ and direct or _indirect_ and indirect? In section
2, sometimes _direct_/_indirect_ is used, sometimes direct/indirect is used.
There is no semantic difference between the two - apparently in 6125bis
we added the underscores to indicate a kind of emphasis, but we did not
follow that convention in RFC 6125.
4.Section 2 said:
“ We can categorize the three identifier types as follows:
* A DNS-ID is direct and unrestricted.
* An IP-ID is direct and unrestricted.
* An SRV-ID is typically indirect but can be direct, and is
restricted.
* A URI-ID is direct and restricted.
”
Three identifier types or four identifier types? My impression is the latter.
There are four - we added IP-ID recently and neglected to update that text.
5.Section 2
s/possibile/possible
Noted.
6.Section 3 said:
“In this case, applications need
to be aware that the textual representation of an IPv4 address can
appear to be a valid DNS name, though it is not. ”
it in the text ‘though it is not’ is referred to digit representation of an
IPv4 address? Or not?
Because Martin Thomson provided that text, perhaps he can clarify his
intent.
7.Section 7.1
I am surprised there is no protection measures to mitigate risk of vouching for
rogue or buggy hosts in this document?
It seems to me that methods for mitigating the attacks described in
[Defeating-SSL] and [HTTPSbytes] are probably out of scope for this
document.
The [HTTPSbytes] attack depends on cross-site scripting, and thus I
think that mitigations should be explained in web-specific
specifications (e.g., JavaScript, HTML input validation, cookies).
The [Defeating-SSL] attack depends on starting with plaintext HTTP (not
HTTPS) and of course no certificate checking happens over plaintext
HTTP. The attack also includes further trickery involving UX differences
between U-labels and A-labels as well as confusable characters, but in
Section 6.3 we already specify that domains must be checked as A-labels
and in Section 7.2 we point to relevant specifications regarding
internationalized domain names. These matters are notoriously thorny and
difficult to solve, so it's not clear to me how much more we can say.
Naturally, suggestions are welcome.
Peter
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
