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.
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@xxxxxxxxxxxx> wrote:
>
>
>
> > On Dec 23, 2018, at 6:01 PM, Kyle Hamilton <aerowolf@xxxxxxxxx> 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
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
