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 126.96.36.199 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 188.8.131.52 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 184.108.40.206.)
(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!),
On Sun, Dec 23, 2018 at 5:33 PM Viktor Dukhovni <[hidden email]> wrote:
> > On Dec 23, 2018, at 6:01 PM, Kyle Hamilton <[hidden email]> 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.
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> 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.
Yes, CA certificates need to have a non-empty subject name if they're
to be used for signing subordinate certificates.
End-entity certificates do not need to have a non-empty subject name,
and some do not. The usual public CAs have on the whole not yet
stopped populating CN values into the subject DN of subordinate EE
certificates, but when the DNS name in question is longer than ~64 bytes,
they have no choice but to omit the CN.
Undoubtedly a search through the CT logs would find some examples.