Subject: [Uta] Some draft-ietf-uta-use-san nits

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 21 Apr 2021 13:52:40 -0400

On Wed, Apr 21, 2021 at 01:06:21PM -0400, Viktor Dukhovni wrote:

> On Wed, Apr 21, 2021 at 06:50:56PM +0200, Eliot Lear wrote:
> 
> > If this is scoped to dnsNames then I’m fine with it going forward as
> > is.  Other names would be problematic.
> 
> It was my expectation/understanding all along that we're talking about
> is deprecation of CN-ID fallback when the reference identifier is a
> DNS-ID.

Therefore (also correcting reference vs. presented confusion):

    https://tools.ietf.org/html/draft-ietf-uta-use-san-00#section-3.3

    OLD:
       When constructing a list of reference identifiers, the client MUST
       NOT include any CN-ID present in the certificate. ...

    NEW:
       When constructing a list of presented DNS identifiers, the client MUST
       use only DNS-ID SANs and MUST NOT include any CN-ID present in the
       certificate. ...

In 6125 the definition of CN-ID is:

      *  CN-ID = a Relative Distinguished Name (RDN) in the certificate
         subject field that contains one and only one attribute-type-
         and-value pair of type Common Name (CN), where the value
         matches the overall form of a domain name (informally, dot-
         separated letter-digit-hyphen labels); see [PKIX] and also
         [LDAP-SCHEMA]

While the draft has a rather more expansive definition:

    https://tools.ietf.org/html/draft-ietf-uta-use-san-00#section-2

       *  CN-ID: the Common Name element of a Distingiushed Name.

I think the original definition is better, and should just be retained
by reference, or repeated verbatim.

-- 
    Viktor.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 21 Apr 2021 18:23:51 +0000

Victor suggests replacing section 3.3 as follows:
        OLD:

This seems okay to me, but I have a question about the ellipsis.  Are you suggesting that the "This means section 6.4.4..." sentence should be kept?

There draft says:
   The terminology from [RFC6125] is used here.  Specifically, the
   following terms and brief definition (as a reminder):
 
So I think there's a reference. I do not want to repeat the formal definition from 6125, it's a mouthful.