Thank you Rich and Peter, some follow-ups below.
Yaron
On 6/25/22, 02:07, "Peter Saint-Andre" <stpe...@stpeter.im> wrote:
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").
That would be clearer.
> 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.
Yep, we can punt the definition but then we need to address all the special
cases. For example, you didn't answer my questions re: non-public DNS names and
".local"...
> * 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.
Sorry, should have been clearer. I am referring to this text, that lists two
reasons why the Common Name RDN doesn't identify a service. I agree with the
first reason but I think the second one is incorrect, because SubjectAltNames
have the same property and we still use them.
> * 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).
My question was: is it possible that we needed for *backward compatibility* 11
years ago may be outdated and ready to be obsoleted today.
> * 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?
This particular sentence is not great but I don't have a better alternative.
> * 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
