Subject: [Uta] 6125bis changes

From: "Salz, Rich" <[email-masked]>
Date: Wed, 22 Sep 2021 18:58:20 +0000

I have a PR that does a lot of editing of the “naming” section.  It is mostly editorial work, also an update for cross-protocol
Attacks.  It is at https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/24 and is based on the existing PR to edit the “introduction” section.  As with that, the diff is big and mostly boring so I encourage people to look at the PR.  If you have problems or issues with looking at the GitHub content, get in touch and I will email you the diff.

I also have a PR that edits the “designing protocols” section at https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/25. This is a mix of editorial, and also using more MUST MAY SHOULD language. It’s short, so here is the complete new text.

I would greatly appreciate comments on these, as well as https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/23, which I mentioned last week.

+This section defines how protocol designers should reference this document,
+which MUST be a normative reference in their specification.  The technology
+MUST only use the identifiers defined in this document.  Its specification
+MAY choose to allow only one of them.
+
+If the technology does not use DNS SRV records to resolve the DNS domain
+names of application services then its specification MUST state that SRV-ID
+as defined in this document is not supported.  Note that many existing
+application technologies use DNS SRV records to resolve the DNS domain names
+of application services, but do not rely on representations of those records
+in PKIX certificates by means of SRV-IDs as defined in {{SRVNAME}}.
+
+If the technology does not use URI's to identify application services, then
+its specification MUST state that URI-ID as defined in this document is not
+supported.  Note that many existing application technologies use URIs to
+identify application services, but do not rely on representation of those
+URIs in PKIX certificates by means of URI-IDs.
+
+A technology MAY disallow the use of the wildcard character in DNS names. If
+it does so, then the specification MUST state that wildcard certificates as
+defined in this document are not supported.
 # Representing Server Identi

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 27 Sep 2021 16:09:11 +0000

I have merged the first two big, boring, editorial PR’s and would like WG feedback on the quoted text below.  Thanks.

From: "Salz, Rich" <rsalz=[email-masked]>
Date: Wednesday, September 22, 2021 at 2:58 PM
To: "[email-masked]" <[email-masked]>
Subject: [Uta] 6125bis changes

I have a PR that does a lot of editing of the “naming” section.  It is mostly editorial work, also an update for cross-protocol
Attacks.  It is at https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/24<https://urldefense.com/v3/__https:/github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/24__;!!GjvTz_vk!Ebp3Qq-dElPSiy9T3jzr5vSIL8YWjrRUvcuoziiEZFNJ4K4baDcvocw8qxKz$> and is based on the existing PR to edit the “introduction” section.  As with that, the diff is big and mostly boring so I encourage people to look at the PR.  If you have problems or issues with looking at the GitHub content, get in touch and I will email you the diff.

I also have a PR that edits the “designing protocols” section at https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/25<https://urldefense.com/v3/__https:/github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/25__;!!GjvTz_vk!Ebp3Qq-dElPSiy9T3jzr5vSIL8YWjrRUvcuoziiEZFNJ4K4baDcvoTi0isVB$>. This is a mix of editorial, and also using more MUST MAY SHOULD language. It’s short, so here is the complete new text.

I would greatly appreciate comments on these, as well as https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/23<https://urldefense.com/v3/__https:/github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/23__;!!GjvTz_vk!Ebp3Qq-dElPSiy9T3jzr5vSIL8YWjrRUvcuoziiEZFNJ4K4baDcvoRkj7me0$>, which I mentioned last week.