The possibility of same institution having different distinguished names when validating signatures

[peteris-zealid]

Out in the real world there are cases when some governments have multiple ID document issuing institutions or the same institution having different issuing certificates, however when it comes to CRLs there is usually just one distribution point. And even when there is more than one they all serve the same CRL.

This is the case for Netherlands and Italy in particular. For NL this problem is particularly visible because there are document certificates with a CRL distribution point on them, but the distinguished name of the CRL issuer (from this DP) is not the same as issuer of the document certificate.

Technically:

• on the document

SEQUENCE (4 elem)
                SET (1 elem)
                  SEQUENCE (2 elem)
                    OBJECT IDENTIFIER 2.5.4.3 commonName (X.520 DN component)
                    UTF8String CSCA NL
                SET (1 elem)
                  SEQUENCE (2 elem)
                    OBJECT IDENTIFIER 2.5.4.11 organizationalUnitName (X.520 DN component)
                    UTF8String Kingdom of the Netherlands
                SET (1 elem)
                  SEQUENCE (2 elem)
                    OBJECT IDENTIFIER 2.5.4.10 organizationName (X.520 DN component)
                    UTF8String Kingdom of the Netherlands
                SET (1 elem)
                  SEQUENCE (2 elem)
                    OBJECT IDENTIFIER 2.5.4.6 countryName (X.520 DN component)
                    PrintableString NL

• on the crl

SEQUENCE (5 elem)
                SET (1 elem)
                  SEQUENCE (2 elem)
                    OBJECT IDENTIFIER 2.5.4.5 serialNumber (X.520 DN component)
                    PrintableString 6
                SET (1 elem)
                  SEQUENCE (2 elem)
                    OBJECT IDENTIFIER 2.5.4.3 commonName (X.520 DN component)
                    UTF8String CSCA NL
                SET (1 elem)
                  SEQUENCE (2 elem)
                    OBJECT IDENTIFIER 2.5.4.11 organizationalUnitName (X.520 DN component)
                    UTF8String Kingdom of the Netherlands
                SET (1 elem)
                  SEQUENCE (2 elem)
                    OBJECT IDENTIFIER 2.5.4.10 organizationName (X.520 DN component)
                    UTF8String Kingdom of the Netherlands
                SET (1 elem)
                  SEQUENCE (2 elem)
                    OBJECT IDENTIFIER 2.5.4.6 countryName (X.520 DN component)
                    PrintableString NL

The difference is just in the extra serialNumber and it is clear that both DNs refer to the same institution, but different certificates. Still there is only one CRL and it is reasonable to assume that it covers both issuing certificates (it is listed as the DP of the subject after all).

Proposal is for the user of the api to configure sets of DNs that are considered aliases in the context of CRL validation. This of course does not strictly confirm to the spec, but given that the whole PKI is a big mess I would argue that allowing more flexibility is a good idea.

I could probably implement this myself, but wanted to discuss first.

[MatthiasValvekens]

Interesting. In "PKIX orthodoxy" this practice is actually explicitly supported through the indirect CRL mechanism (see RFC 5280, search for "indirectCRL" and "cRLIssuer"). Of course using said mechanism requires a number of extensions to be correctly set on both the CRL and the certificate, and I presume that that is not the case here...

I know for a fact that pyhanko_certvalidator supports this use case (as did its parent project certvalidator) because there are several test cases in the PKITS test suite that validate exactly this. That said, I've never tested it with PDF signatures in pyHanko itself, so if the CRL is a "proper" indirect CRL and it's causing some kind of issue nonetheless, it could simply be a bug.

Also, is the "binding" between cert issuer and CRL issuer reflected in any trust lists in this case? That could explain how they got away with it until now (the more likely explanation is that nobody bothered to complain, but that's a different issue).

I'm not necessarily opposed to adding the aliasing feature you want, but I'd like to make sure that we exhaust all standards-based avenues first and make sure we're not simply covering up for some kind of bug.

[peteris-zealid]

I am really overwhelmed by the spec -- it is not intuitive.

Regarding indirectCRL it is not the case because that flag is not set on the certificate and is false by default (and that is the end of it I suppose).

There are 2 different trust root (certs) by "Kingdom on Netherlands" that have one intermediate issuing cert each. There does not seem to be any binding. The newer institution "Ministry of the Interior and Kingdom Relations" also have multiple trust roots that each have one intermediate cert, but for those the distinguished name is the same. The crl distribution point is different in this case.

So the problem with "Kingdom on Netherlands" is that they have different distinguished names, but refer to the same distribution point. This really looks like a bug on their end, but luckily this is the older institution that is gradually phased out as I understand.

Anyway, thank you for the feedback. I do not have time to look into Italy in greater detail right now. I will get back to this in the future.