Git authentication reports subkey fingerprints

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

On 09-08-2022 23:07, Ludovic Courtès wrote:

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.

Hi,

Maxime Devos <maximedevos@telenet.be> skribis:

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

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.

Of all the stupid typos...

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

Kind regards,

T G-R

Sent on the go. Excuse or enjoy my brevity.

On 11-08-2022 13:17, Tobias Geerinckx-Rice wrote:

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.

Hi Maxime,

Quick reply mainly to say thanks for replying :-)

On 2022-08-11 17:07, Maxime Devos wrote:

(Well, you snipped my previous paragraph where I mention what you seem

to describe below, so yes.)

Why does none of this apply to primary keys?

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.

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.

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

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.

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.