Hi Maxime,
Quick reply mainly to say thanks for replying :-)
On 2022-08-11 17:07, Maxime Devos wrote:
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:
(Well, you snipped my previous paragraph where I mention what you seem
to describe below, so yes.)
* 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.
Why does none of this apply to primary keys?
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.
Git commit dates aren't reliable. Requiring that they be accurate going
forward would be imposing yet another 'artificial'/idiosyncratic
limitation. I think we should be very hesitant to build a verification
system on assumptions stacked just so.
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.
Sure. We always need to be careful when updating the keyring branch.
Kind regards,
T G-R
Sent from a Web browser. Excuse or enjoy my brevity.
