Re:Ditching OpenPGP, a new approach to signing APT repositories
by xloem on Tuesday June 22, 2021 @08:40PM
(#27599294)
> APT would maintain a list of allowed public primary keys.
You've blatantly forgotten the implication of TOFU regarding new debian keys. Without a way to certify debian's keys, there's no way to verify that installation media is correct any more. With PGP, there was the web of trust. Now there is TLS at best, no?
It seems the proposed specification lacks a crucial addition of keysigning.
Re:Ditching OpenPGP, a new approach to signing APT repositories
by nullc on Wednesday June 23, 2021 @04:57PM
(#27610250)
> Well. There are two proposals. If we go with the subkey proposal, we'd not implement the simple protocol, solving that issue.
Avoiding that concrete exploit.
The lack of domain separation design flaw remains. :)
As typical for design flaws it may not be meaningfully exploitable at any given time. Doesn't mean it isn't a design flaw.
Well. There are two proposals. If we go with the subkey proposal, we'd not implement the simple protocol, solving that issue.
> Signer is setup to have the whole input in memory at once
It's fine.
> This text says very little about validating trusted keys. A signature where you just take the pubkey from the input
That would be silly. APT would maintain a list of allowed public primary keys. The spec hints at that with "Clients shall verify all signatures from supported algorithms in the Release file, whether a given key is considered trusted or not."
> No obvious affordance for additional signed metadata, which is useful for forensics. So, for example, if a project has multiple parties with access to the keys they may want to tag which user(s) authorized the signature or included a timestamp. If their signing is performed by a HSM (e.g. something like USB armory that allows no user access) the consistency of their metadata could be preserved. This could probably be kludged on by requiring the metadata just be inside the payload somewhere.
We don't have a use for that. The feature set of GPG is already over the top.
> It's not entirely clear to me that it's supported to hand out multiple subkeys to different parties all with the same serial, and they stay all equally valid until a key is observed with a newer serial (at which point all subkeys need to be updated)
Yeah, the serial exists to revoke all priorily issued subkeys, effectively.