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