Improve visibility when we can't authenticate a binding
sq-wot
does a pretty good job of showing why a binding can be authenticated. Consider:
$ sq-wot --trust-root BFC5CA10FB55A4B790E2A1DBA5CFAB9A9E34E183 --keyring tests/data/cycle.pgp lookup '<ed@example.org>'
[ ] 78C3814EFD16E68F4F1AB4B874E30AE11FFCFB1B <ed@example.org>: marginally authenticated (25%)
◯ BFC5CA10FB55A4B790E2A1DBA5CFAB9A9E34E183 ("<alice@example.org>")
├ A637747DCF876A7F6C9149F74D47846E24A20C0B ("<bob@example.org>")
├ 394B04774FDAB0CDBF4D6FFD7930EA0FB549E303 ("<carol@example.org>")
├ 4458062DC7388909CF760E6823150D8E4408638A ("<dave@example.org>")
└ 78C3814EFD16E68F4F1AB4B874E30AE11FFCFB1B "<ed@example.org>"
But when we can't authenticate a binding, it can be frustrating to figure out why, especially when it was possible yesterday.
One approach would be to try loosening different constraints one at a time. For instance, we could rerun the trust calculations and ignore expired certifications, revocations, expired certificates, or revoked certificates, etc. By relaxing one of these constraints at a time we can probably add a helpful diagnostic along the lines of: "we can't authenticate this binding, because some certifications have expired." Identifying exactly which certification caused the problem is more difficult. But, this is a start.
An alternative approach would be to try different times in the past, for instance, a week earlier, a month earlier, and 6 months earlier, and see if we can then authenticate the binding.