bug#57091: Git authentication reports subkey fingerprints

bug#57091: Git authentication reports subkey fingerprints

[Ludovic Courtès]

Hello,

As Tobias explains at
<https://mail.gnu.org/archive/html/help-guix/2022-08/msg00073.html> and
as can be seen from ‘.guix-authorizations’, the (guix openpgp) and (guix
git-authenticate) machinery reports the fingerprint of subkeys on
signatures (when subkeys are used) rather than the fingerprint of
primary keys.

This should be changed to report primary keys, at least optionally.

Ludo’.

bug#57091: Git authentication reports subkey fingerprints

[Maxime Devos]

[-- Attachment #1.1.1: Type: text/plain, Size: 823 bytes --]


On 09-08-2022 23:07, Ludovic Courtès wrote:
> Hello,
>
> As Tobias explains at
> <https://mail.gnu.org/archive/html/help-guix/2022-08/msg00073.html>  and
> as can be seen from ‘.guix-authorizations’, the (guix openpgp) and (guix
> git-authenticate) machinery reports the fingerprint of subkeys on
> signatures (when subkeys are used) rather than the fingerprint of
> primary keys.
>
> This should be changed to report primary keys, at least optionally.

Why should it be changed? IIUC .guix-authorizations and (guix ...) care 
about the key that things were signed with, not necessarily the primary 
key, so it seems to me that it needs to report the subkey fingerprint, 
not the fingerprint of the primary key it belongs to, as the primary key 
is irrelevant to them IIUC.

Greetings,
Maxime.


[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

bug#57091: Git authentication reports subkey fingerprints

[Ludovic Courtès]

Hi,

Maxime Devos <maximedevos@telenet.be> skribis:

> On 09-08-2022 23:07, Ludovic Courtès wrote:
>> Hello,
>>
>> As Tobias explains at
>> <https://mail.gnu.org/archive/html/help-guix/2022-08/msg00073.html>  and
>> as can be seen from ‘.guix-authorizations’, the (guix openpgp) and (guix
>> git-authenticate) machinery reports the fingerprint of subkeys on
>> signatures (when subkeys are used) rather than the fingerprint of
>> primary keys.
>>
>> This should be changed to report primary keys, at least optionally.
>
> Why should it be changed? IIUC .guix-authorizations and (guix ...)
> care about the key that things were signed with, not necessarily the
> primary key, so it seems to me that it needs to report the subkey
> fingerprint, not the fingerprint of the primary key it belongs to, as
> the primary key is irrelevant to them IIUC.

Yes, I kinda agree, but…  the motivation here is that OpenPGP user
interfaces don’t normally refer to subkey fingerprints; instead they
refer to primary key fingerprints, even if you use a subkey, which is
the point of subkeys AIUI.  That Guix treats subkeys differently is
confusing to seasoned OpenPGP users.

Ludo’.

bug#57091: Git authentication reports subkey fingerprints

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

This is not a mere UI issue.  Basic verification is currently broke^Wdifferent, too, or the latest incident wouldn't have happened.

Hmm.  I wonder...

Ludo', are you worried that, since we already handle revocations like GPG would, the 'proper' OpenPGPmodel could somehow break?  That we are in effect unable to safely fix this (yes, I maintain it is a) bug?

Apologies if I'm wildly off the mark here.  But then I'd like to hear some plausible threat models.  Maxime?

In their absence, nasty surprises like what happened last week are argument enough to (try to! :-) implement normal OpenPGP behaviour.



Kind regards,

T G-R

Sent on the go.  Excuse above-average rambliness.

bug#57091: Git authentication reports subkey fingerprints

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Of all the stupid typos...

>Ludo', are you worried that, since we already handle revocations like GPG would

...DON'T handle, of course, by design.

Kind regards,

T G-R

Sent on the go.  Excuse or enjoy my brevity.

bug#57091: Git authentication reports subkey fingerprints

[Maxime Devos]

[-- Attachment #1.1.1.1: Type: text/plain, Size: 1257 bytes --]


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.


[-- Attachment #1.1.1.2: Type: text/html, Size: 1842 bytes --]

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

bug#57091: Git authentication reports subkey fingerprints

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

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.

bug#57091: Git authentication reports subkey fingerprints

[Maxime Devos]

[-- Attachment #1.1.1.1: Type: text/plain, Size: 2189 bytes --]


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.

[-- Attachment #1.1.1.2: Type: text/html, Size: 3278 bytes --]

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]