bug#57091: Git authentication reports subkey fingerprints

[Maxime Devos]

On 11-08-2022 18:31, Tobias Geerinckx-Rice wrote:

> >     * 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.

> > 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.
>       
      Yes, forbidding setting the datetime to something way off (e.g.
      1970-01-01) for privacy or such is quite a limitation.

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.

    Greetings,
    Maxime.

OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key

OpenPGP_signature
Description: OpenPGP digital signature