Should the trust anchor be validated

[peteris-zealid]

This is a question about pyhanko_certvalidator.

When running _validate_path It looks like the code does not do any validation on the trust anchor. This includes expiry time and CRL checking. Is this expected behaviour? The same issue exists in the original certvalidator should I raise the issue there as well?

Related code from validate.py:

    path_length = len(path) - 1
    for index in range(1, path_length + 1):
        cert = path[index]
        # lots of validation

I can see how managing trust anchors is the responsibility of the system administrator and in most cases this will be handled by the maintainers of the operating system. However I can also see how many who handle their own trust roots would not understand or care to do a good job at it.

Maybe there is something I do not understand myself well enough.

[MatthiasValvekens]

Excellent question!

I can see how managing trust anchors is the responsibility of the system administrator and in most cases this will be handled by the maintainers of the operating system. However I can also see how many who handle their own trust roots would not understand or care to do a good job at it.

Yes, that's true. RFC 5280 doesn't even define trust anchors as certificates; they're just name<>pubkey pairs for the purpose of validation, and that binding is trusted by fiat. Any further restrictions such as expiry dates, issuance policy constraints etc. are (by definition!) out of scope for the purposes of path validation according to the RFC 5280 trust model.

Of course that doesn't prevent any particular implementation from going beyond RFC 5280. When trust anchors are sourced from self-signed certificates, there are some "reasonable defaults" that can be added to the path validation parameters; see e.g. RFC 5937.

I've taken some steps towards that in my certvalidator fork, but it's still at a very early stage. In particular, enforcing expiry dates for root certs is tricky business, especially when dealing with signatures created at a time long in the past (what about the implications for timestamp trust, for example?).
I'll revisit that problem once I get around to fully implementing AdES-style point-in-time validation, because that's already tricky enough without having to deal with expired roots in addition to the "regular" restrictions.

As far as revocation is concerned: trust roots, by definition, are not subject to revocation. After all, who would issue such a revocation? The authority can't do that by itself; the signature on the CRL would be effectively unverifiable. A CRL asserting "my issuer's certificate is revoked" is kind of similar to the liar's paradox.

---

So, TL;DR: In the traditional RFC 5280 trust model, the answer to your question is "no". Of course, that trust model can be augmented, but for document signing that's not as obvious as it may seem. Especially expiry dates for root certs are weird. I'm working on adding some of that extra richness, but there's work to be done on AdES validation first.

Side note: all of this is much, much simpler in a setting like TLS, where connection lifetimes are very short compared to certificate lifetimes, so rejecting out-of-date roots is kind of the obvious thing to do. With document signatures we don't have that kind of luxury.

[peteris-zealid]

Thank you! This is an excellent answer.

Regarding revocation I think it should still be possible because computers are really good at resolving things like the lier's paradox (they do not think too hard about it). Maybe I am being naive but I see no problem checking that the trust root is a self signed cert and add it to the existing validation loop if it is.

For now I will probably trust the trust root. If my company decides to fork this lib I will revisit this question.

I have to admit that I did not do my homework of reading the spec before asking the question.

[MatthiasValvekens]

If you need a particular validation behaviour for a specific root r, there's a pretty straightforward workaround: make a new trust root for which your validator controls the key, and issue a certificate with whatever standard constraints you want for the subject<>key pair of r, signed by your new root. All previously valid paths that depended on r will remain valid, unless the new cross-signed cert you issued for r has restrictions that would prevent that (e.g. a policy constraint, name constraints, new expiration date...). In principle, you could even replace your entire root cert store by certificates issued by one single root under your own control---although I have no idea whether people actually do that.

Many subtleties in RFC 5280 exist precisely to enable that cross-signing use case, and that's probably also why RFC 5280 doesn't bother going into too much detail on what a trust root is, since they're pretty fungible in practice.

[peteris-zealid]

Yes, that makes sense. But this is not a cheap workaround because then I would need to securely manage some private keys. Unless I generate that new root on the fly.

[MatthiasValvekens]

securely manage some private keys

Yeah, the new root is only trusted by your validator, so if you generate it on the fly, it only needs to be as secure as the code that runs your validator application. That puts the bar a lot lower. Anyway, now we're venturing into thought experiment territory...