Service Identity in TLS
draft-ietf-uta-rfc6125bis-15

Sadly, I support Lars' Worst DISCUSS Ever.

Thanks for doing the work here.  It's quite well done.  Just a couple of comments:

In Section 2, I find it weird to use SHOULD and MUST language to establish BCP 14 style interoperability requirements on future documents.

Section 1.5 defines "delegated domain" but doesn't use that term anywhere.

Thank you to Derrell Piper for the SECDIR review.

Thank you for this critical maintenance to RFC6125. 

** Section 5.

   If the certificate will be used for only a single type of application
   service, the service provider SHOULD request a certificate that
   includes DNS-ID or IP-ID values that identify that service or, if
   appropriate for the application service type, SRV-ID or URI-ID values
   that limit the deployment scope of the certificate to only the
   defined application service type.

Given the scope of the document being restricted to DNS-, IP-, SRV-, and URI-ID, what is the circumstances under which this “SHOULD” guidance would NOT be followed?
   
   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 each
   identifying a different application service type. 

The SHOULD in this text implies there is an alternative to requesting multiple certificates?  What is that?

** Section 6.1.1
   *  If a server for the application service type is typically
      associated with a URI for security purposes (i.e., a formal
      protocol document specifies the use of URIs in server
      certificates), then the reference identifier SHOULD be a URI-ID.

I appreciate that this is unchanged language from RFC6125.  If the application service is using a URI, under what circumstances would the reference identifier NOT be a URI-ID?

** Section 6.2
   The
   search succeeds if any presented identifier matches one of the
   reference identifiers, at which point the client SHOULD stop the
   search.

What is the standardized behavior if the client keeps looking after the first match (i.e., it is a SHOULD, not a MUST to stop)?

** From idnits:

  == Outdated reference: draft-ietf-tls-subcerts has been published as RFC
     9345

Thanks for working on this necessary protocol maintenance.

Even though mentioning QUIC (multiple times) triggered TSV AD's bells I don't have any TSV related comments here. Thanks for Joe Touch for his TSVART review.

# Éric Vyncke, INT AD, comments for draft-ietf-uta-rfc6125bis-14

Thank you for the work put into this document. 

I find this document update useful ***BUT*** it lacks the support of the new SVCB (draft-ietf-dnsop-svcb-https)... May I recommend that this document is sent back to the WG in order to incorporate the SCVB (it is very similar to SRV IMHO)? I appreciate that the SVCB started in a different WG hence the disconnect even if some authors of the two I-Ds have the same affiliation ;-) I added the SVCB authors in copy to this ballot, just in case.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Orie Steele for the shepherd's detailed write-up including the WG consensus, *but it lacks* the justification of the intended status. 

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS

## Component or label ?

The text uses terms like `component of a domain name` while RFC 8499 (DNS terminology) would prefer to use `label of a domain name`. Most parts of the document correctly use 'labels' but there are some use of 'component'.

## Section 1.4.2

s/Certificates representing client identities other than as described above, such as rfc822Name, are beyond the scope of this document/Certificates representing client identities, such as rfc822Name, other than as described above are beyond the scope of this document/ to simplify the parsing ?

# NITS

## Section 1.4.2

`for our purposes we care`, RFCs usually do not use a personal voice. But this is a matter of taste.

# GEN AD review of draft-ietf-uta-rfc6125bis-14

CC @larseggert

Thanks to Maria Ines Robles for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/kKymWzL6jRgmCfLhf0A8IJATMMQ).

## Comments

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term `traditional`; alternatives might be `classic`, `classical`, `common`,
   `conventional`, `customary`, `fixed`, `habitual`, `historic`,
   `long-established`, `popular`, `prescribed`, `regular`, `rooted`,
   `time-honored`, `universal`, `widely used`, `widespread`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Outdated references

Document references `draft-ietf-tls-subcerts`, but that has been published as
`RFC9345`.

### URLs

These URLs in the document can probably be converted to HTTPS:

 * http://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf

### Grammar/style

#### Section 4.1, paragraph 1
```
SIP as described in [SIP-SIPS]). Typically this identifier type would supple
                                 ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Typically".

#### Section 4.2, paragraph 4
```
s or IP-IDs. Again, because of multi-protocol attacks this practice is discou
                               ^^^^^^^^^^^^^^
```
This word is normally spelled as one.

#### Section 6.2, paragraph 7
```
 DNS domain names more generally. Therefore the use of wildcard characters as
                                  ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Therefore".

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

thanks to Joe Touch for the TSVART review.