Re: [Uta] WGLC for draft-ietf-uta-rfc6125bis-06

[Peter Saint-Andre <[e-mail]>]

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" <[e-mail]> 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