4 ms·
> The goal is to be able to verify all signatures; whether we trust a signature or not is configured inside APT by specifying a list of trusted primary keys. W
by agwa 5y ago
> The goal is to be able to verify all signatures; whether we trust a signature or not is configured inside APT by specifying a list of trusted primary keys.
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 https://youtu.be/CiH6iqjWpt8?t=1028
- dlor 5y agoExactly this. The flow should be: * 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.
- julian-klode 5y agogpg precisely has valid signature and good signature to distinguish signatures that are technically valid from good signatures. e.g. a valid signature can be expired, so it's not good or shit like that. So, the argument is flawed.
- julian-klode 5y agoThe point is not about valid signatures from untrusted keys, it's about invalid signatures from untrusted keys. 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.
- julian-klode 5y agoBeing able to validate consistency of a repository without needing additional files is a worthwhile goal. We also validate MD5 sums of hashes when downloading, despite them not being trusted (so they can only reject on failure). If there is an invalid signature, it should fail verification whether we trust it or not. 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.