On 6/24/22 4:40 PM, Peter Saint-Andre wrote:
The list admins might want to be aware that this message was truncated
as follows (at least for me and Rich)...
On 6/24/22 10:04 AM, Yaron Sheffer wrote:
So here's a few comments. Thanks Valery for the reminder!
* The DTLS reference should change to DTLS 1.3.
Easily fixed.
* See Appendix A of [VERIFY]
Yes, that's a typo.
* The rules are brief - it's not clear from the text if this is a
summary of the totality of the new RFC, or just the changes from the
previosu version
Section 1.3 is entitled "Overview of Recommendations" but we could make
the text clearer (e.g., "The following is a brief summary of the rules,
which are described at greater length in the remainder of this document").
In the archive [1], Yaron's message continued as follows...
###
* No definition is given for "FQDN" even though the name being an FQDN
is a major component of the document's scope. Specifically, are
enterprise hostnames (that are not on the public DNS) in scope? Are
.local names?
Section 2.2 of RFC 6125 referenced RFC 1034 in this regard. IIRC from
when Jeff and I worked on RFC 6125, it is surprisingly difficult to find
a canonical definition for FQDN and similar terms.
* Similarly, it is not clear to me whether certs obtained through DANE
are in or out of scope.
Well, DANE (RFC 6698) post-dates RFC 6125 so we might need to update our
recommendations to take account of DANE. I'll need to think about the
exact text we need.
* And the same question for delegated credentials
(draft-ietf-tls-subcerts).
That's an emerging technology, but at least an informational reference
might be appropriate.
* The Common Name RDN... can appear more than once in the subjectName.
I'm probably missing something, but how is this different from multiple
server names appearing in SAN when the certificate protects multiple
services?
We do say (in Section 2):
The Common Name RDN MUST NOT be used to identify a service.
I'm probably missing something in what you suggest here.
* XMPP backward compatibility: does the XmppAddr still need to be
mentioned in -bis?
For server certificates, that would be appropriate (see Section
13.7.1.2.1 of RFC 6120).
* the service provider SHOULD request [...] an SRV-ID or URI-ID that
limits the deployment scope of the certificate to only the defined
application service type. This is only somewhat accurate, because an
HTTP client would happily accept the DNS-ID, no matter what other
SRV-IDs are found there.
As far as I know, there is no SRV-ID or URI-ID defined for HTTP
(although there was an Internet-Draft on the topic years ago). Do you
think that changes are needed to the text?
* Which identifier types a client includes in its list of reference
identifiers, and their priority, is a matter of local policy - given the
situation today, can we have a normative recommendation for clients to
be strict in constructing their reference list? If we don't include such
normative text, we're basically telling people to make the easier choice
and build lenient clients.
It seems to me that the local policy will depend a great deal on the
protocol(s) that an application supports, the state of SRV-ID and URI-ID
support in that protocol and its implementations/deployments, etc.
However, I do think that we can formulate some more strict rules that
ought to be followed by implementations. Text to follow.
Peter
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
