Issuer of 200103ffe3ff8

[Viktor Dukhovni]

On Thu, May 11, 2023 at 05:51:40AM -0400, Robert Moskowitz wrote:

> > Just use an uninterpreted unique Common name for each issuing CA, and
> > empty subject names for all EE certificates.
> 
> Kind of what I was thinking.
> 
> > Any names that have meanings would then be Subject Alternative Names
> > of the relevant certificates.  If there's a reasonable use case, you
> > could also employ Issuer Alternative Names.
> >
> >      https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.7
> 
> 4.2.1.7.  Issuer Alternative Name
> 
>     As with Section 4.2.1.6, this extension is used to associate Internet
>     style identities with the certificate issuer.  Issuer alternative
>     name MUST be encoded as in 4.2.1.6.  Issuer alternative names are not
>     processed as part of the certification path validation algorithm in
>     Section 6.  (That is, issuer alternative names are not used in name
>     chaining and name constraints are not enforced.)
> 
> Not used in the path validation is an issue.  So probably not the way to go.

They're just informational.  They're neither the way to go, nor not the
way to go.  They're not an alternative to issuer certificate subject DNs
matching subject certificate issuer DNs, they're just something you can
decorate the certificate with, if your application can then benefit in
some way from having access to properly typed issuer names (signed by
a parent issuer, or self-signed if a trust-anchor).

> As I was falling asleep last night I thought that
> authorityKeyIdentifier is part of the solution.

You can put directory names and serial numbers there, but not clear
what problem you're really trying to solve.

> issuerName is CN=20010030000000
> authorityKeyIdentifier is iPAddress=20010030000000052aeb9adc1ce8b1ec

GeneralNames in the AKID specify the issuer's issuer (along with a
mandatory associated serial number), I've never seen anything other
than directory names used there, and other name types are likely to
not be supported.

Issuer names are just opaque blobs used to create links in the chain
from trust-anchor to end-entity certificate.  Just don't ascribe them
any meaning beyond making them somewhat human readable, so operators
will be able to tell them apart.

All that matters in the end is that the EE certificate chains up to
the trust anchor via a series of zero or more intermediate (a.k.a.
subsidiary) issuer certificates.

The name of the EE certificate is meaningful and should be a SAN.
The issuer CA and TA names are opaque chain node ids.

-- 
    Viktor.