> > 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-prim...@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-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.
> > 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/1650208...@github.com>
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
