I don’t recall if any of the signatures sign across any other signatures. I think in some cases it’s just a… Merkle List?

Merkle trees get weird if they’re done as signatures. With bitcoin everyone votes on the validity in a fairly narrow timeframe and the implausibility of spoofing a record and then spoofing the next n is what allows for the trust-in-the-blind to be practical (even if I don’t agree that the theory is sound).

For signatures, on data at rest, it gets complicated. Because at some point you’re trusting a payload that has signatures from expired certificates. You end up having/needing transitive trust, because the two signatures you care about are valid, and they signed the payload while the signatures they cared about were still valid. So now you need to look at signature timestamps, Cert validity range, Cert chain validity range, CRLs or OCSP, and you better make sure all your timestamps are in UTC…

It’s easier if the system has a maximum deliver-by date, and you just drop anything that shows up too out of band. I can use a piece of software that was created and signed over a year ago, but maybe I shouldn’t accept year-old messages.

I did a code signing system for avionics software, that supported chain of custody via countersigning (Merkle before anyone heard of bitcoin). The people who needed to understand it did but it broke some brains. I lost count of how many meetings we had where we had to explain the soundness of the transitivity. People were nervous, and frankly there weren’t enough people watching the watchers. Sometimes you only catch your own mistakes when teaching.