|
From: | Maxime Devos |
Subject: | bug#57091: Git authentication reports subkey fingerprints |
Date: | Thu, 11 Aug 2022 20:10:48 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 |
* 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?
For primary keys as they are currently used in Guix, to revoke a
key (from Guix' point of view), you remove it from
.guix-authorizations, done.
For revoking subkeys, you trust GPG or whatever to take care of
things, but Guix-modified-to-allow-subkeys-too doesn't have a clue
that the subkey should be considered revoked, se bullet list
above.
That could be solved by also adding a list of revoked subkeys to
.guix-authorization, but that seems opposite to the proposed
change.
Yes, forbidding setting the datetime to something way off (e.g. 1970-01-01) for privacy or such is quite a limitation.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.
They do not have to be accurate however, as long as the discrepancies in commit dates / actual time (*) are small compared to the expiration times.
(*) of non-attackers -- assuming frequent commits, an attacker
cannot trick the expiration mechanism into large time difference.
That might not be good enough for branches like 'wip-foo' or
channels with infrequent commits though.
OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
[Prev in Thread] | Current Thread | [Next in Thread] |