[Rpm-maint] [rpm-software-management/rpm] rpm --import does not replace old keys with new keys (Issue #2577)

Tue Jul 25 17:01:47 UTC 2023

> > Is a "key master" the entity that controls the key?
> I think I was using the word _certificate_ inconsistently, but mostly in the same way you are. I think it's helpful to use examples to make 100% sure we are talking about the same thing. Examples of certificates include:
> 
>     * Each item listed in the output of `rpm -qa gpg-pubkey*` contains a single PGP public key block.  As far as I know, each of these contains a single certificate.  For example, one of these on my system is `gpg-pubkey-38ab71f4-60242b08`.  The contents -- including subkeys -- can be viewed by typing:
>       ```
>       $ rpm -qi gpg-pubkey-38ab71f4-60242b08 | gpg --show-keys --with-subkey-fingerprint
>       pub   rsa4096 2021-02-10 [SCE]
>             53DED2CB922D8B8D9E63FD18999F7CBF38AB71F4
>       uid                      Fedora (36) <fedora-36-primary at fedoraproject.org>
>       ```

Yes.

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

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

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

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2577#issuecomment-1650208072
You are receiving this because you are subscribed to this thread.

Message ID: <rpm-software-management/rpm/issues/2577/1650208072 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20230725/30297d7c/attachment.html>