> > ```
> > * Another example is the [Google's Linux signing
> > key](https://dl.google.com/linux/linux_signing_key.pub), which is actually
> > a collection of public keys bundled inside a single certificate. For the
> > record, its contents are:
> > ```
> > $ cat linux_signing_key.pub | gpg --show-keys --with-subkey-fingerprint
> > pub dsa1024 2007-03-08 [SC]
> > 4CCA1EAF950CEE4AB83976DCA040830F7FAC5991
> > uid Google, Inc. Linux Package Signing Key
> > <linux-packages-keymas...@google.com>
> > sub elg2048 2007-03-08 [E]
> > 9534C9C4130B4DC9927992BF4F30B6B4C07CB649
> >
> > pub rsa4096 2016-04-12 [SC]
> > EB4C1BFD4F042F6DDDCCEC917721F63BD38B4796
> > uid Google Inc. (Linux Packages Signing Authority)
> > <linux-packages-keymas...@google.com>
> > sub rsa4096 2016-04-12 [S] [expired: 2019-04-12]
> > 3B068FB4789ABE4AEFA3BB491397BC53640DB551
> > sub rsa4096 2017-01-24 [S] [expired: 2020-01-24]
> > 3E50F6D3EC278FDEB655C8CA6494C6D6997C215E
> > sub rsa4096 2019-07-22 [S] [expired: 2022-07-21]
> > 2F528D36D67B69EDF998D85778BD65473CB3BD13
> > sub rsa4096 2021-10-26 [S] [expires: 2024-10-25]
> > 8461EFA0E74ABAE010DE66994EB27DB2A3B88B8B
> > sub rsa4096 2023-02-15 [S] [expires: 2026-02-14]
> > A5F483CD733A4EBAEA378B2AE88979FB9B30ACF2
> > ```
> > ```
>
> This is not how the term certificate is commonly used in the OpenPGP
> ecosystem. This file includes two certificates:
> 4CCA1EAF950CEE4AB83976DCA040830F7FAC5991 and
> EB4C1BFD4F042F6DDDCCEC917721F63BD38B4796.
Thank you for your patience!
They are bundled together into a single file, and into a single (virtual?) RPM
package gpg-pubkey-38ab71f4-60242b08. Is there standard terminology for this
situation?
> > > Can you explain what it means for "a key master" to "publish keys with
> > > separate certificates"?
> >
> > My first example above -- the Fedora 36 signing key -- is distributed in
> > its own certificate. Fedora 37 has a separate key and a separate
> > certificate. This separation means that the user can install any
> > combination of them at their leisure. If for some reason they want to check
> > old signatures, they can do so by installing old certificates containing
> > old keys. Since Fedora publishes keys in separate certificates, there is no
> > need to merge Fedora's certificates.
>
> You've unfortunately lost me again. In OpenPGP, a key is not separate from a
> certificate. A key is a component.
What I mean is that the Fedora 36 signing key can be installed separately from
the Fedora 37 signing key. They are in separate virtual RPM packages, and they
have separate keys and certificates. This contrasts with the Google situation
where it's different versions of the same certificate.
> > On the other hand, Google publishes many keys within a single certificate
> > (the second example). If a new version of the certificate removes some old
> > keys, this would prevent the user from verifying old signatures. For
> > example, the key that was issued on 2016-04-12 (and expired in 2019) might
> > get removed from future versions of this certificate. If this happens, then
> > the user would have no obvious way of verifying packages signed by this
> > key. Your proposal of merging the new certificate with previously installed
> > ones is one way of addressing this problem. But I think it comes with a
> > serious downside that the user has no way removing revoked keys. If the
> > 2016-04-12 key gets compromised, your proposal might leave the user
> > vulnerable to attacker-signed packages. (The fact that they key has expired
> > might help, but it's not the end of the story; e.g. what if a more recent
> > key gets compromised?)
>
> I don't understand why a user would want to remove a revoked key. If it is
> revoked, the user should just import the revocation certificate and then it
> can't be used to verify packages any more.
Good point. I guess I was worried that the key master might not distribute a
revocation certificate, or that DNF / RPM might not acquire and process the
revocation certificate correctly. Has this been tested?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2577#issuecomment-1651519766
You are receiving this because you are subscribed to this thread.
Message ID: <rpm-software-management/rpm/issues/2577/1651519...@github.com>
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
