On 11-08-2022 13:17, Tobias Geerinckx-Rice wrote:
Apologies if I'm wildly off the mark here. But then I'd like to hear some plausible threat models. Maxime?
Here's a problem with allowing subkeys, if that's what you mean: * Expiration times and GPG-level revocation must be ignored (for time-travel, and pulling from an old Guix), similarly to why it must be ignored for when no subkeys are used * Someone used to GPG-style subkeys generates a new subkey to replace old expired subkey or revokes old subkey, without keeping in mind that Guix doesn't take that in account. * An attacker uses a compromised-but-revoked-or-expired subkey to compromise the channel.Expiration times might be solvable by taking the commit time of the previous commit as 'current time' (not the commit that was signed, otherwise an attacker could just lie). I don't know a solution for GPG-level revocation of old subkeys but I haven't looked either.
Another problem: * When replacing the key in the 'keyring' branch with an 'updated' key that contains the new subkey, we have to be careful to never remove old subkeys, to avoid breaking time travel or pulling from old versions. Greetings, Maxime.
OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
