The other goal of the design - with the subkeys - is to be able to start signing repositories with a new subkey, without having to distribute the new subkey to users out-of-band.
The talk is unfortunately not understandable due to inadequate audio quality. It's also not the right medium to bring this across, you'd want to have a paper of up to 3 pages.
gpg has the same distinction between valid signatures and good signatures, though you need to distribute the key out of band there.
I don't see how this can confuse people. Nobody else should be implementing this specification.
* Look up keys that I trust
* Check if the signature verifies against any of those keys
Key hints can aid in selection here if you have many trusted keys, but you can also just loop through.
Not:
* verify the signature
* check if the key matches one I trust
The second is much more dangerous, a "valid" signature from an untrusted key is just as bad as an "invalid" signature from a trusted key. There's no reason to treat these states as different.
Some repositories are signed with multiple keys. People building the repositories might only have one key T as trusted, and then mess up signing with the other key U (imagine that one is an offline key - this is how debian stable releases are signed).
By verifying all signatures and rejecting any invalid one, it will be immediately obvious if the signature by U is wrong.
Also, as mentioned before, the scheme allows for rapid subkey replacement in case of potentially compromised subkey.
e.g. a valid signature can be expired, so it's not good or shit like that.
So, the argument is flawed.
Why is it a goal to be able to verify signatures from untrusted primary keys? At best, this conveys zero information. At worst, it may confuse people into thinking that the signature is safe when it really isn't. It also opens your format up to JWT-style vulnerabilities.
Generally, to avoid JWT-style vulnerabilities, you should be using some sort of key ID attached to the signature to look up the key in the list of trusted keys. If the key is not known, you just ignore the signature. If it is known, you know from the key itself what kind of key it is, and thus how to parse the signature. Enforce algorithm deprecation when deciding whether to trust a key, rather than when parsing a signature.
This talk by Sophie Schmieg at Real World Crypto 2021 is extremely informative about this: https://youtu.be/CiH6iqjWpt8?t=1028