> OK, I guess I am not quite getting this sub key business yet. Doesn't the
> signature list the KeyId of the subkey it was created with? Or does it point
> to the main key and assumes the subkey will be found there?
As a first approximation, subkeys are an implementation detail and shouldn't be
exposed to users.
An OpenPGP certificate is a collection of components. The components include
the primary key, subkeys, and user IDs. A certificate's identity, i.e., its
fingerprint, is derived from the primary key (its the hash of the primary key).
This means that the certificate's identity doesn't change even if the
certificate is updated. This is important for authentication. Say I go to
FOSDEM and visit the Qubes developers. They usually wear T-Shirts with their
release key's fingerprint. I can take a picture, and when I go home, record
that the Qubes release key has the fingerprint
427F11FD0FAA4B080123F01CDDFA1A3E36879494 (e.g., using `sq pki link add`). When
I download a Qubes image in `n` years, the certificate may have been updated
(e.g., it has a new signing subkey, the expiration time has been extended,
etc.), but the certificate still has the same fingerprint, so I know that the
signature is authentic. (Note: Fedora uses a different OpenPGP certificate for
each release. I'd argue that this is not a good practice, as it makes
authenticating the downloads a lot more difficult: I have to manually check a
new certificate every six months. Creating a new signing subkey every six
months, however, is not a problem for the end users.)
Having mutliple keys also allows for domain separation. For instance, by
default, Sequoia has a separate signing-capable subkey; the primary key cannot
be used for signing data. This prevents attacks like [the shambles
attack](https://sha-mbles.github.io/), which reuses a data signature as a
certification.
The various components in a certificate are linked to the primary key via
signatures. This means that if I've authenticated a certificate (i.e., its
primary key), then I can chain forward (or backwards) and authenticate the
various components.
A signature packet includes a hint about the (sub)key that was used to create
it. Once we check that the (subkey) actually created the signature, we can
then chain backwards to the primary key.
> We need to get to the point where all operations about PGPG keys can go
> through the rpmkeys utility and no rpm commands are needed.
That sounds good to me.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2403#issuecomment-2358430329
You are receiving this because you are subscribed to this thread.
Message ID: <rpm-software-management/rpm/issues/2403/2358430...@github.com>
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
