Subject: [Uta] Some quick comments on some changes in draft-ietf-uta-rfc6125bis-04

From: Alexey Melnikov <[email-masked]>
Date: Thu, 25 Nov 2021 18:01:03 +0000

Hi Rich,

I've noticed some recent changes to the document that don't look right 
to me:

> 3.  Designing Application Protocols
>
>    This section defines how protocol designers should reference this
>    document, which MUST be a normative reference in their specification.
This is kind of a funny "MUST" and I don't think it is needed. But if 
the point is to make it clear that Informative reference is not Ok, then 
it is probably acceptable. I mean people should really need to know the 
difference between Normative and Informative references and I don't 
think this document is the right place to teach people.
>    The technology MUST only use the identifiers defined in this
>    document.
Are we Internet police? If people want to define other identifiers not 
defined in this document, then who are we to stop them? Also, I don't 
understand why is this effectively prohibiting use of subjectAltNames 
not defined in this document. So please delete this sentence.
> Its specification MAY choose to allow only one of them.
This point is important. If a specification is referencing rfc6125bis, 
only using some identifiers is fine.
>
> 4.1.  Rules
>
>    When a CA issues a certificate based on the FQDN at which the
>    application service provider will provide the relevant application,
>    the following rules apply to the representation of application
>    service identities.  Note that some of these rules are cumulative and
>    can interact in important ways that are illustrated later in this
>    document.
>
>    1.  The certificate MUST include a "DNS-ID" as a baseline for
>        interoperability.
You've change a SHOULD to a MUST. I think this is incorrect, because 
presence of DNS-ID will overshadow presence of URI-ID and SRV-ID, making 
them pointless. I think this either needs to be removed, SHOULD should 
be restored or the whole sentence should be rephrased to say something 
along the lines "if you don't know much about what you are doing in your 
protocol, picking DNS-ID as the default is fine".

Best Regards,

Alexey

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 29 Nov 2021 15:43:31 +0000

Alexey,

Thanks very much for your comments. I was a little over-zealous :).  Does this diff address your concerns?
It's also at https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/37

; g diff
diff --git a/draft-ietf-uta-rfc6125bis.md b/draft-ietf-uta-rfc6125bis.md
index bf8eb3d..8f1080e 100644
--- a/draft-ietf-uta-rfc6125bis.md
+++ b/draft-ietf-uta-rfc6125bis.md
@@ -486,9 +486,9 @@ identify a service.
 # Designing Application Protocols {#design}
 
 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.
+which would typically be a normative reference in their specification.
+Its specification
+MAY choose to allow only one of the identifier types defined here.
 
 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
@@ -522,7 +522,7 @@ Note that some of these rules are cumulative
 and can interact in important ways that are illustrated later in this
 document.
 
-1. The certificate MUST include a "DNS-ID" as a baseline
+1. The certificate SHOULD include a "DNS-ID" as a baseline
    for interoperability.
 
 2. If the service using the certificate deploys a technology for which

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 29 Nov 2021 15:49:07 +0000

Hi Rich,

> Thanks very much for your comments. I was a little over-zealous :).  Does this diff address your concerns?

Works for me.

Best Regards,

Alexey

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 29 Nov 2021 15:57:43 +0000

>    Works for me.

Merged into the editor's copy.  Thanks.