bug#57091: Git authentication reports subkey fingerprints

[Tobias Geerinckx-Rice via Bug reports for GNU Guix <bug-guix@gnu.org>]

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.