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
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
