4 ms·

I don't understand your point about the public key. The goal is to be able to verify all signatures; whether we trust a signature or not is configured inside AP

I don't understand your point about the public key. 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. > # The algorithm is stored with the signature. > This is slightly less bad than above, but still bad Which algorithms are trusted is a client side decision. We do need the string to be able to parse the signature itself. signify also has it, except that it includes it inside the base64 as the first two bytes. I do not believe there is a need to be able to configure the trusted algorithms on a per primary key basis (aka storing it with the public key). Basically the problem we have with GPG is that it trusts algorithms for far too long. So we had to implement lists of trusted algorithms inside APT ourselves. We still have no way to reject 1k RSA keys, though, because GPG does not tell us the key size. We can assign algorithms trust levels and prevent downgrades to weaker keys alongside the other downgrade attack checks for Release files we already have in APT. > I didn't look at the sub-key protocol in detail. The ephemeral key for every release is an interesting choice. The root key is "offline". But if it must be brought online to sign a new ephemeral key for every release anyway, you might as well just use it to sign the release itself. Yes, well, if you go with the subkey approach you'll always have a subkey, so you can't sign directly with a primary key. I think there's some confusion here in that people believe both formats should be supported at the same time, but they are two separate proposals, and only one should make it into real code. > Using minisign/signify like OpenBSD does and keeping things very simple makes sense to me. The complexity designed into this system (sub-keys, multiple algorithms and signatures) starts to stretch the bounds to where TUF (https://theupdateframework.io/ https://theupdateframework.io/) might make sense. TUF is very complex and not worth it for most projects, but Debian is exactly what TUF is designed for. I've said it 4 years ago - we don't want TUF. TUF does not provide useful things, but adds (duplicates) a lot of complexity. It's the opposite of what we're trying to achieve here. https://blog.jak-linux.org/2017/08/17/why-tuf-does-not-shine-for-apt-repositories/ https://blog.jak-linux.org/2017/08/17/why-tuf-does-not-shine... Add to that that we'd have to rewrite the whole thing to use YAML/deb822 instead of JSON files for repository format compliance.

julian-klode 5y ago
> # The algorithm is stored with the signature. > This is slightly less bad than above, but still bad So I just also realized that for the subkey scheme, it matters even less, because the algorithm is effectively part of the subkey packet. It's not encoded in there, but how high is the chance that a different algorithm would produce the same signature for it? We really just need the algorithm field to be able to determine how to parse that, but it reinforces itself by virtue of the subkey being signed by the primary key itself.
joshuagl 5y ago
I don't expect to change your mind about TUF, though I would love to talk about how Debian could adopt pieces of the TUF design where it makes sense _and_ how TUF might provide affordances to better suit Debian. For other readers, I think it's important to point out that: 1. TUF does not require use of JSON, or any other specific format. > Implementers of TUF may use any data format for metadata files as long as all fields in this specification are included and TUF clients are able to interpret them without ambiguity. from https://theupdateframework.github.io/specification/v1.0.19/#metaformat https://theupdateframework.github.io/specification/v1.0.19/#... 2. The blog post you link to says that TUF does not handle key revocation. That's untrue. TUF does key revocation explicitly, by replacing the listed keys in the root (for top-level roles) and targets (for delegated roles) metadata, and implicitly through expiration times.
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

julian-klode 5y ago

> # The algorithm is stored with the signature. > This is slightly less bad than above, but still bad So I just also realized that for the subkey scheme, it matters even less, because the algorithm is effectively part of the subkey packet. It's not encoded in there, but how high is the chance that a different algorithm would produce the same signature for it? We really just need the algorithm field to be able to determine how to parse that, but it reinforces itself by virtue of the subkey being signed by the primary key itself.

joshuagl 5y ago

I don't expect to change your mind about TUF, though I would love to talk about how Debian could adopt pieces of the TUF design where it makes sense _and_ how TUF might provide affordances to better suit Debian. For other readers, I think it's important to point out that: 1. TUF does not require use of JSON, or any other specific format. > Implementers of TUF may use any data format for metadata files as long as all fields in this specification are included and TUF clients are able to interpret them without ambiguity. from https://theupdateframework.github.io/specification/v1.0.19/#metaformat https://theupdateframework.github.io/specification/v1.0.19/#... 2. The blog post you link to says that TUF does not handle key revocation. That's untrue. TUF does key revocation explicitly, by replacing the listed keys in the root (for top-level roles) and targets (for delegated roles) metadata, and implicitly through expiration times.

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