[openssl-users] Subject CN and SANs

[Kyle Hamilton]

In order for an Issuer to exist in PKIX, it must be the Subject of another
Certificate (or of a trust anchor).  If a certificate identifies an Issuer,
then the certificate cannot contain an empty sequence of RDNs in the
Subject and still be conformant to PKIX.  This is because the Subject of
the issuing authority certificate needs to be copied (in some way which is
compatible with RFC4518's string preparation rules) into the Issuer of the
certificate that it issues.  This is implied by the path validation
algorithm, and stated explicitly in the last paragraph of RFC5280 section
4.1.2.4 which also refers to RFC5280 section 7.1.

However, PKIX is just a profile of X.509, and alternative approaches to
identifying the Issuer of a certificate exist.  (For self-signed
certificates, Issuer can be an empty sequence of RDNs, but I like to think
of that as a degenerate case that is also explicitly not conformant to PKIX
[RFC5280 section 4.1.2.4 last paragraph].  More importantly, the
IssuerKeyIdentifier can also be set, and matched with the
SubjectKeyIdentifier of another certificate.  This use is contemplated in
RFC 5280 section 4.2.1.2.)

(Note, though, that RFC 5914, "Trust Anchor Format", defines certPath :==
CertPathControls OPTIONAL.  In this case, *only*
IssuerKeyIdentifier/SubjectKeyIdentifier matching can work, and Issuer
otherwise apparently should be blank because the Anchor has no
taName/Subject.  You have to love the inconsistency of the PKIX standards,
yes?)

I haven't ever seen anything claiming that OpenSSL is expected to be
completely and invariably conformant to the PKIX profile.  It's possible
that it could be implied (if SSL or TLS specify that the certificates in
their Certificate records either "SHALL" or "MUST" be PKIX-profiled --
which does not appear to be the case in RFC 8846, which defines TLS 1.3),
but even then I'm not sure it would be appropriate to restrict its utility
in the manner of preventing newer versions from interoperating with
certificates issued by or which worked with older versions that permitted
such degenerate cases.

Merry Christmas (or happy holidays!),

-Kyle H



On Sun, Dec 23, 2018 at 5:33 PM Viktor Dukhovni <openssl-users at dukhovni.org>
wrote:
>
>
>
> > On Dec 23, 2018, at 6:01 PM, Kyle Hamilton <aerowolf at gmail.com> wrote:
> >
> > You're right, I typoed.  SubjectDN is non-optional.  But it can, as
> > you mentioned, be an empty sequence.
> >
> > But for PKIX purposes, it can't be empty if it's an Issuer (because
> > IssuerDN can't be empty in the certificates that it issues).
>
> That's an odd use of "it", since the issuerDN while also a DN is not
> a subjectDN.  The "it" that is the subjectDN is sometimes legitimately
> empty.  The other "it" that is the issuerDN is supposed to always be
> non-empty, but some self-signed certificates violate that requirement
> with apparent impunity, e.g. nothing in OpenSSL requires a non-empty
> issuer DN in an end-entity self-signed certificate, if it breaks, the
> constraint would be at the application layer.
>
> --
>         Viktor.
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20181224/292d88e2/attachment-0001.html>