[Rpm-maint] [rpm-software-management/rpm] Add suport for multiple signature verification (Issue #4089)

[Petr Pisar]

ppisar left a comment (rpm-software-management/rpm#4089)

I will add that whether you want all signatures to be valid, or at least one is a matter of a policy (read a use case). Let's do this mental exercise:

You a have package with a single, valid, and trusted signature. A package like that is considered secure from point of view of current RPM and you will install it. Then somebody adds a valid signature made with untrusted key to the same package. Does the new untrusted signature make the package less secure? I think it doesn't. Yet current RPM rejects the package.

Don't you buy this argument? Try another. Let's say the new signature is done with an untrusted algorithm. That also makes that new signature untrusted, yet current RPM accepts that package. I dare to show that this is, from practical point view, the very same case.

Let's go further: Somebody adds an invalid signature made with a trusted key. Does the new, broken signature make the previously secure package less secure? I again dare to say that it doesn't.

This way we could come to a conclusion that the current RPM policy is wrong and RPM should be changed to require at least one, valid and trusted signature. But at the beginning I stated that it's a matter of policy. In which use case we might want to have multiple valid and trusted signatures?

In the physical world that's the case of a written agreement. E.g. when you buy a house, there are two parties to the contract and thus the agreement requires two signatures, one for each of the party. And that's not enough, it needs to be signatures of those involved parties. Not someone's else signature. This case can be generalize to N-party contracts requiring N signatures. Does RPM need to support this kind of contracts? Well maybe, but so far it has no support for it. Especially when it handles all keys imported in a key store equally and cannot bind a specific key (or user ID of the key) to a specific package. In RPM world the use case would be like "the package must be signed by Red Hat and U.S. Department of Defense".

The less strict, non-binding use case of multiple signatures is basically an OpenPGP web of trust where you require at least N trusted cross signatures to trust a new key. I dare to say that in X.509 PKI-like reality (each package distribution has only one root of trust) this use case nobody needs.

Another use case is a requirement for multiple types of algorithms when we do not want to trust a single algorithm. This looks close to the current postquantum madness, yet neither RPM, nor OpePGP enforce it. E.g. OpenPGP resorted to a hybrid signature where a single key and signature object encapsulates two keys and two signatures of different type, being identified as a distinct aggregate type. If the world is going to bundle different-algorithm keys together, then this use case is also not needed.


For the simplicity I recommend RPM to change the policy from all-signatures to at-least-one signature. (There is already a policy for no-signature-needed.) If RPM wants to preserve the policy for all-signatures, then it can retain it, but a practical use case is not clear to me.

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

Message ID: <rpm-software-management/rpm/issues/4089/3753486480 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20260115/b6599472/attachment-0001.htm>