On 6/25/22 8:30 AM, Yaron Sheffer wrote:
Thank you Rich and Peter, some follow-ups below.
Yaron
On 6/25/22, 02:07, "Peter Saint-Andre" <stpe...@stpeter.im> wrote:
<snip/>
> 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.
I would prefer to bring back the reference to RFC 1034.
For example, you didn't answer my questions re: non-public DNS names and
".local"...
I'm not sure what you mean by "non-public DNS names". As for .local
addresses, I'm not sure who would issue certificates for those. However,
if you can obtain certificates for either of these name-types, then I
don't see why the same rules wouldn't apply.
<snip/>
> * 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.
Ah, I see. The first reason ("It is not strongly typed and therefore
suffers from ambiguities in interpretation") is probably sufficient.
> * 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.
Yes, that's what I'm saying. At this point XmppAddr would be included
only in client certificates, not in server certificates.
> * 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.
OK. I will see if I can improve the wording.
Peter
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
