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

[Andrew Clausen]

> Is a "key master" the entity that controls the key?
>
> I think we are using the word certificate in different ways. According to RFC 4880, a certificate in OpenPGP (as a first approximation) is a Public Key packet, zero or more direct key signatures, zero or more User ID packets with any accompanying self signatures, and zero or more Subkey packets with any accompanying self signatures. Is that how you are using the word certificate?

You are right, I am not on top of OpenPGP terminology, and I suspect much of the documentation floating around (including GPG's own manual) is not entirely aligned with it.  Thank you for being patient with me!

By *key master*, I mean the person (or team of people) who manage the signing keys at Google.

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

 * 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
   ```


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

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?)

Sorry for the long letter.  But hopefully my writing (and my thinking!) is a bit clearer now.

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

Message ID: <rpm-software-management/rpm/issues/2577/1646809963 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20230723/0d6a7f03/attachment.html>