[Rpm-maint] [rpm-software-management/rpm] Ignore subkeys that are expired or cannot be used for signing (Issue #1911)

[Demi Marie Obenour]

> A consequence of ignoring expiration times is that expired certificates can still issue new signatures. Imagine an old distribution signing key being exfiltrated after it is expired. Now, all installations that still have that old certificate in their set of trusted certificates will consider newly created signatures valid, even though their copy of the certificate says it is expired.
> 
> A better way is to look at the creation time of the signature you want to verify, then ask the question whether the certificate and its signing subkeys are valid at that point in time.

This alone isn’t sufficient for primary keys.  The person with a copy of the secret key can just make a signature that claims to be from when the key was still valid.  They could also create a new self-signature that makes the key no longer expired. 
 A better solution is for distributions to generate their signing keys on smart cards, so that they can securely erase them once they are no longer in use.  Cryptographic Message Syntax, which is used by Windows for its code signing, solves the problem by means of a third-party time-stamping countersignature, which proves that the signature was actually made before a certain point in time.

That said, RPM needs to be able to handle expired signatures in the rpmdb.  Could `RPMRC_NOTTRUSTED` be used for that?

> We don't look at expiry dates on main keys, on purpose. How are subkeys different?
> Ignoring keys that can't be used for signing seems reasonable though, I guess.

Subkeys are different because they provide a mechanism for key rotation.  Someone in possession of a subkey cannot simply increase the subkey’s validity arbitrarily, as only the primary key can create a new subkey binding signature.  One should also be able to revoke a subkey and mark signatures made by the subkey after a certain point as no longer valid.  This requires that RPM support subkey revocation.  I might be able to implement this, but I would need to know where to store the data.  @pmatilai any suggestions?

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

Message ID: <rpm-software-management/rpm/issues/1911/1049003056 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20220223/eddb8edd/attachment.html>