Sorry I am slow with replying On Sat, Aug 03, 2024 at 09:11:52AM GMT, Daniel Kahn Gillmor wrote: > On Tue 2024-07-30 06:16:00 -0400, Daniel Kahn Gillmor wrote: > >> What's missing from sopv are mechanisms for specifying crypto > >> policies, such as allowed hashes, allowed crypto algorithms, and > >> allowed key sizes. I'm not sure if there's stuff I'm missing. > > I think we'd be putting apt pretty deep in the crypto weeds if we try to > set those rules in apt itself. Rather, apt should depend on a sopv > implementation that makes reasonable choices about what kinds of > cryptography is acceptable for signing. I think we have a fundamental issue here that we are conflating different contexts of signing, it doesn't make sense to require all contexts to use the same signing requirements. For OS-level code signing like APT repositories we can make informed choices and we can increase the security level each release, vendors of third-party repositories can adjust to that reasonably. It's much easier to stay ahead of the crypto wars then in e-mail where you may need to wait ages to sign with an ed25519 key because others won't understand your signatures or stuff. Even within code signing there are different usage contexts that require different policy, imagine if UEFI were using OpenPGP instead of CAs, or flatpak is a good example because its store caters all distributions across all releases - it takes much longer to be able to push new requirements on flatpak repository signign schemes. So this may be a lack in OpenPGP where you'd want to define a signing context like sign/code/org.debian.apt such that you can define requirements at each level (then you just need all OpenPGP implementations to read the requirements from the same file such that you can centrally configure that as a system vendor). > >> What we found out here is that verifying the key algorithm and size > >> during signature verification is a bit annoying, they only work with > >> errors. > >> > >> Imagine you have two keys, one weak and one strong. You never get a > >> warning about the weak key until you see a signature from it. > > even then, i don't think you'd want to see a warning. A weak signature > should be treated the same as no signature; it doesn't validate, > regardless of where it came from. The issue we need to solve is that we need to have at least 3 different levels of weak keys: 1. keys that are so weak we don't trust them anymore 2. keys that will soon be considered and we need to warn about 3. keys that are not best practices and if you opt-in to receiving messages about best practices, you should get a message about them That's what apt 2.9.x implements as the "current", "next", and "future" security levels, with the --audit flag to opt-into messaging about far-away/not-best-practices key algorithms. A validation of keys at signature level means that only 1 becomes meaningful, you'll only see messages about type 2 and type 3 keys once they become used for signing. However, you want to see messages about type 2/3 keys whenever they are configured as acceptable signing keys. Example: If we get a easy rsa1024 attack, we can't just go put them in category 1 and block all third party repositories, we'd need to put it in category 2, have warnings for 6 months and give people time to migrate to newer signing keys. > > >> We also need status communicated: > >> > >> fingerprints of keys that are unknown > >> uids and fingerprints of expired keys such that we can display them > > Why do we want to display them? those sorts of warnings are footguns to > most admins: they see them as a warning that they need to fix, and they > go and hunt down the unknown key and "install" it to clear the warning. > > I agree that there are use cases for debugging tools, but i think the > core part of apt should focus on a simple signature checker that just > does the right thing and fails appropriately when not on the happy > path. Admins in the debugging case can bring different tools to bear. People shout at you if you just say the validation failed and don't explain to them *why* it failed. Once we're at a point where every source has a Signed-By field, pointing at a filename the messaging becomes easier: You just tell them you could not verify using that key file, but right now for sources without the field it's quite confusing if you just say validation failed. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Attachment:
signature.asc
Description: PGP signature