Post Quantum Signatures support

[simo5]

The problem
With the standardization of the new Quantum Safe algorithms from NIST and the pressure from US and international agencies to adopt Quantum Safe asymmetric cryptography it is time to consider how this will be done in RPMs.

Context
In the past, new algorithms would take years, even decades before being adopted by standard bodies, however the timelines today are compressed because there is a somewhat reasonable threat that Quantum Computers capable of breaking classic cryptography will actually be available "soon".

This means there is no time to wait for all existing OSs to grow support for QR algorithms and then have a flag day and change signature algorithms.

Moreover some of the new algorithms are pretty young and there are still some doubts on their ability to withstand cryptanalysis, therefore either double-signature or hybrid encryption schemes are being considered as the logical next step.

For RPM this means we should have the ability to produce RPMs that carry both a classic signature with the current format for backwards compatibility, and a new signature using Quantum Safe algorithms.

The Openpgp standard is evolving in IETF to make available PQ algorithms for both encryption (KEMs) and Signatures, however they are bundling these changes in a new packet level format that will require new implementations of the libraries to be able to use it. This means that even if they come up with a hybrid scheme RPM will not be able to use it and provide backwards compatibility to older Operating Systems.

Describe the solution you'd like
The RPM format should evolve to be able to carry additional signatures (more than one) so that we can approach a transition to PQ signature schemes without disrupting the ability to install or even just verify RPMs on current OSs using the current classic signature.

Describe alternatives you've considered
The alternative is to update the signature scheme to a hybrid signature, this would meet the requirement of signing with a PQ scheme but would be extremely disruptive as legacy systems would not be able to check signatures at all.

Additional context
One of the reasons why the timelines are compressed and require (IMO) to support multiple disjoint signatures is the CNSA 2.0 document: https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF
See the timeline part for adoption of Software/firmware signatures.

Other nations agencies are developing similar plans.

Note on signatures timelines
For those wondering why CNSA 2.0 has such a timeline for software signing when IETF is focusing mostly on Online encryption (to prevent "harvest now decrypt later"), my hypothesis is that the NSA, in this case, is more grounded in reality than (software/standards) developers :)

Although harvesting is definitely a big threat the NSA knows that hardware gets actually deployed and will not be changed easily until its lifetime is spent, for some devices this lifetime is measured in decades, while most consumer stuff last 3-5 years.
If your device receives software updates that are signed with classic algorithms only, the downfall of classic algorithms means anyone would be able to attack the systems by providing updates with forged signatures. This is especially problematic for firmware and OS updates as they underpin any data being managed by this hardware.

[mlschroe]

See also #189 and #1050

[pmatilai]

The signature header is a generic container, it can carry arbitrary number of items. Adding new things is basically a matter of reserving a tag number for it, so that is a non-issue. I got the impression that there's work going on to standardize around PQ in the OpenPGP realm, so I'd expect that direction to be the path of least pain.

I wouldn't know a PQS if it walked up to me on the street. So lets start with a practical question: how do you generate such a signature?

[simo5]

Well it depends at what level you are asking.
I can give you openssl commands that use oqs-provider and will let you generate keys and apply raw signatures.
But I assume you want to see a PGP command line app that will generate a PQ signature instead?
In that case we should probably ask someone like @nwalfield if sequoia already has a way (I think I've seen Justus mentioned on IETF mailing lists they did make test with PQ algorithms already).

[teythoon]

The OpenPGP working group is working on draft-openpgp-pqc. Currently, the focus is on FIPS compliance, and harmonizing KEM combiners and algorithm selection across different protocols to amortize the implementation and validation efforts across different software components.

It is true that PQC in OpenPGP will depend on a new wire format, RFC 9580 aka "v6", but Sequoia is very robust in that regard. If you go with having two OpenPGP signatures, one classical and one PQ (ML-DSA as composite, or SLH-DSA), current versions of Sequoia can gracefully ignore the PQ signature. We'd be happy to assist you with creating plausible mockups of v6 PQ signatures for RPMs test suite.

Thinking about the timeline, our v6 implementation is almost complete, and we plan to merge it later this year. I don't expect the work on draft-openpgp-pqc to conclude before that.

Adding PQC support on top is relatively straight forward, as from an OpenPGP perspective it only adds algorithms. The challenge here will be to find suitable cryptographic libraries to supplement our current cryptographic backends with, as I expect that support in the mainstream cryptographic libraries will be a little behind.

[simo5]

Cryptographic support will not be an issue, we already have support in OpenSSL via liboqs+oqs-provider and OpenSSL will natively integrate ML-KEM / ML-DSA / SLH-DSA in due time.
Nettle has a ML-KEM implementation and is receiving a ML-DSA one.

We will need two distinct signature packets to make the packages usable on older systems that do not have support for the newest v6 formats, while allowing to add PQ signatures for those that can use them.
The classic signature will need to continue using the current v4 format to attain this goal. Binding the signatures is not a goal.

SLH-DSA is attractive because the math is solid and it is less "risky", but we'll need to be flexible, and may even need to add multiple PQ signatures for wider compatibility and risk management.

[pmatilai]

Well it depends at what level you are asking.
I can give you openssl commands that use oqs-provider and will let you generate keys and apply raw signatures.
But I assume you want to see a PGP command line app that will generate a PQ signature instead?

OpenPGP command line yes, but while waiting for that to materialize I play the cat that curiosity killed and poke at openssl created raw signatures instead. Not for applying in rpm, but just to make this whole PQ affair somehow more tangible. Seeing is believing etc.

As for the rpm part: the verification machinery in rpm does support multiple signatures per package as-is, I added it as a pre-requisite for #1050 back in 2018 or so, but the part that actually creates multiple signatures in rpm was never merged, so it's been unused and could've bitrotted. The foundation is there though.

The existing RSAHEADER/DSAHEADER signatures are treated as if only one can exist, but that's just convention rather than a technical limitation. So assuming Sequoia can do OpenPGP PQS, we can add a new tag for that and add it alongside an existing RSA/DSA signature instead of replacing it. And then on package read, stash it up for verification, and voi'la, the rest is up to rpm-sequoia. Rpm only knows "verify everything" policy currently, but what makes up "everything" can be configured with the various verification macros, so you could manually disable either the "classic" or the PQ signature. And with that, I think we have a rudimentary PCS support in rpm.

[simo5]

Is there any chance we can start testing something by applying both an RSA and an ECDSA based signature? And later we replace one of them with a PQ algorithm ?

[simo5]

Or even two RSA signatures with different keys ..

[pmatilai]

It could be demoed with RSA+ECDSA signatures, yes. Perhaps counter-intuitively, two RSA signatures would be more complicated 😅

[simo5]

It would be a nice feature though, it would allow to have backup keys or slowly rotate keys.
Of course it would need to allow verification to be marked ok with a single signature verifying providing the other has a missing verification key ... fun times.

[pmatilai]

The problem with multiple signatures of the same type is that they are stored as a binary type in the header, and the header doesn't support array of these. The non-merged PR #1050 basically adds support for arbitrary number of signatures by moving them to encoded data in string arrays. But that's a much bigger task, and there wasn't much interest back then.

[simo5]

So currently RPM only allows one signature per type?
I think we can still work with that, but it also means signatures can't be completely opaque to RPM and will need to allocate an ID for each signature type ?

[pmatilai]

Exactly.

And the more I think about this, the more stupid it all seems now. Rpm is not in the slightest interested in what algorithm is used in an OpenPGP signature. The problem with #1050 was basically lack of direction and motivation, but it's time to take another look at that because we have a clear direction now: get the heck out of OpenPGP business. If the named multisignature support was there, we wouldn't necessarily be even discussing this now, PQC-OpenPGP would be just another OpenPGP signature that somebody chose to slap on their packages, rpm would not really need to know.

To summarize the named multisignature stuff from 1050:

• add a new string array tag called RPMTAG_OPENPGP
• the signatures are stored in something like <label>:<base64sig> format, with the label being a part of the signed data
• label is an arbitrary string describing the signature in whatever means makes sense to you: you can put the algorithm in there (RSA/EcDSA...), you can put a role in there (devel/qe/distro), email, organization (AcmeCorp IT) etc - whatever

What was missing was:

• selectively deleting signatures
• interoperability with the traditional signatures
• applying a signature policy based on the labels

With the exception of the policy stuff, it should be pretty easy to revive that effort.

[simo5]

Do we even need a label ?
Pretty sure openpgp packets have a signature ID somewhere embedded in the packet.
As for legacy support perhaps we just copy in the traditional header only one v4 signature of the supported type. That is, we put all signatures in the new header in whatever format openpgp supports in the future, and we copy (or generate) one v4 signature for legacy purposes to be placed in the old header until compatibility is needed.

New rpm version will be able to handle RPMs that lack the traditional field if it is the only available otherwise ignore it and use only the new one?

[pmatilai]

I don't know if those labels are needed, it just seemed like a potentially useful thing to have without reaching into OpenPGP details - ie something that's a fully an rpm level thing. Based on the feedback, it seems like a solution looking for a problem 😅 If we toss the label out it only makes things simpler of course.

For the simplest possible semantics, I suppose --addsign would just keep piling on signatures in the new tag, and --delete just deletes all of them. Compatibility could indeed be handled by copying one to a legacy tag. For that there are basically two choices: either only do the copy on the first, or replace it on each newly added signature and of those, I think only the former makes sense as it allows you to place some "classic" signature there first for interoperability and then you can pile whatever fancy you need on top.

Technically it wouldn't be hard for rpm to just pull in all the signatures it finds for verification regardless of the source tag, but if the new openpgp-tag is defined to have them all, then that just simplifies things.

I think that's actually along the lines of what I envisioned back then, but at that time there was the additional complication of rpm v3 signatures which made the legacy compat semantics weirder (and I never fully thought it through before the steam ran out). The rpm v3 signatures are gone now so it seems actually pretty simple now.

[pmatilai]

With that sort of specification, backporting the new openpgp tag verification support to 4.x shouldn't be much of a problem either because the foundations are there since 4.14.2 (think RHEL-8)

[mlschroe]

(Why are v3 sigs gone? I don't think this is true. And why would the signature version matter to rpm now that the pgp parsing is no longer in the code?)

[simo5]

(Why are v3 sigs gone? I don't think this is true.

Are you aware of maintained OSs that can't deal withv4 signatures?

And why would the signature version matter to rpm now that the pgp parsing is no longer in the code?)

Backwards compatibility with currently supported OSs (on the market) that won't quickly move to newer rpm versions.

[pmatilai]

(Why are v3 sigs gone? I don't think this is true. And why would the signature version matter to rpm now that the pgp parsing is no longer in the code?)

Note that I'm talking about rpm v3 signatures: the ones on header+payload, aka RPMSIGTAG_GPG and RPMSIGTAG_PGP.

[pmatilai]

Having slept over it... If the multiple signature support in 2018 lacked direction and motivation, the simplified form as drafted out in the above by me & Simo makes so much sense today that it would be downright stupid not to do it. There's a Finnish saying about killing two flies with one swat, and here we're talking about more like four or five:

• support for multiple signatures has generic benefits and use-cases
• puts a further layer of insulation between rpm and crypto, something we have been actively driving for a couple of years now
• adds provisions for PQC without us getting directly involved in it
• lines up nicely with the rpm v6 theme and timing
• most of it is already implemented

I'll spin off a separate ticket detailing that part. Dusting off the multisignature patch from #1050 and trimming off excess (ie the label part) shouldn't be more than a one day job.

[pmatilai]

Created #3385 for the multiple signature support now for a fresh start, it's quite clearly defined now and is not about PQC as such. We can continue discussion around that topic here.

[pmatilai]

Support for multiple signatures (#3385) landed yesterday (#3439), so the groundwork for arbitrary algorithms in OpenPGP signatures is there now. Adjusted the ticket title a bit because there'll be more work to do in terms of verification policies etc but what's there now should be sufficient from file format POV.

[nwalfield]

Nice work! Thanks.