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.
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
