Code change:
with a set of trust anchors. In general, a client MUST verify the service identity using the <del> verification process defined in RFC6125 (for a reference identifier of type URI-ID) unless the client has been specifically configured to accept some other form of verification.  For example, a client might be connecting to a server whose address and hostname are dynamic, with an expectation that the service will present a specific certificate (or a certificate matching some externally defined reference identity) rather than one matching the dynamic URI's origin server identifier. </del> <ins> verification process defined in RFC6125.  The client MUST construct a reference identity from the service's host: if the host is a literal IP address (https.ip-id), the reference identity is an IP-ID, otherwise the host is a name and the reference identity is a DNS-ID. A reference identity of type CN-ID MUST NOT be used by clients.  As noted in RFC6125 a reference identity of type CN-ID might be used by older clients. A client might be specially configured to accept an alternative form of server identity verification.  For example, a client might be connecting to a server whose address and hostname are dynamic, with an expectation that the service will present a specific certificate (or a certificate matching some externally defined reference identity) rather than one matching the dynamic URI's origin server identifier. </ins> In special cases, it might be appropriate for a client to simply ignore the server's identity, but it must be understood that this

Related discussion:
text: This is how it works in practice. RFC 6125 is due for an update, I guess. iPAddress subjectAltName has been supported for years and years, but it never managed to capture it properly. This is definitely a big change in that it now outlaws CN-ID. And the definition of IP-ID here is probably overreach, but I don't see how we can avoid that. I don't want to update RFC 6125 here (as much as it needs updating), so making the definition standalone seemed like the right way to handle it.
Discovered via a question NAME asked; it appears that 8aa1781d4fa7d25ab946f6cb1dd1b337435e0a17 made the change to require looking for URI-IDs in the certificate and I don't see any follow-up discussion on that in . However, I've never seen a certificate that offers a URI-ID for an HTTP endpoint. Shouldn't this be a DNS-ID to match current usage? Or perhaps either, with URI-ID preferred, if we believe that's the future?
Er, right, my mistake -- I was trying to describe it as verifying a URI as input, not as looking only at the certificate field for URI-ID. It should either be left unsaid, because it is defined by that RFC, or possibly specify DNS-ID with maybe URI-ID as a backup?
I am not entirely sure that there is need to mention URI-ID (I, for one, don't know of usage of it with HTTP; I barely know of usage of it at all). My understanding is that current practice prefers DNS-ID with a grudging tolerance for CN-ID as fallback (though there are efforts underway to fully deprecate use of CN-ID). Note also that when referencing the RFC 6125 procedures, the protocol document is expected not only to specify what name and type are to be used as input to verification, but also whether wildcard certificate are allowed. It is sometimes also useful to give instruction about what procedures are to be used for revocation checking, though 6125 does leave that explicitly out of its own scope. I am also trying to promote the definition and use of "IPADDR-ID" for the iPAddress SAN, but that's somewhat unrelated.
Do we want to state a position on adoption of URI-ID?