Michael Schroeder <m...@suse.de> writes: > On 10/21/21 18:12, Justus Winter wrote: >> First, I think replacing RPM's point solution with a general purpose >> implementation will improve correctness. Robust signature verification >> requires canonicalization of the issuing certificate, which is tricky >> [0], [1], [2]. > > Wait, those links don't say why canonicalization is required. What's > the attack vector? Do you have other pointers?
Canonicalization is required before a certificate can be safely used for any operation. OpenPGP certificates are compound structures made out of packets bound together by signatures. Canonicalization requires several steps, among them re-ordering out-of-place packets, deduplicating packets, checking signatures (and embedded signatures for signing subkeys), reasoning about signature and key lifetimes, and revocations. >> Further, RPM shouldn't be burdened with maintaining >> their own point solution, which will require constant maintenance to >> keep up with evolving standards and algorithms. > > I somewhat agree except that PGP moves really really slowly. It takes > ages till some new algorithm goes in. See EdDSA as an example. That unfortunately is true. Or rather, it was. OpenPGP's development picked up speed, we recently formed a design team that is creating a proposal for the next RFC, and have produced a new draft just last week: https://datatracker.ietf.org/doc/draft-ietf-openpgp-crypto-refresh/ Relevant changes for RPM include: New key packet types, new hash algorithms, EdDSA over Ed448, new fingerprint format, maybe new signature packet types. I expect the working group to produce a new revision of OpenPGP later this year or early next year. >> Second, Rust has been criticized for being not too portable [3]. While >> there is some truth to that, at least today, there is ongoing work to >> add a GCC backend to the Rust compiler [4], and to write a Rust frontend >> for GCC [5]. > > But doesn't that mean that we need to wait till this work is done? Well, we can carefully structure the work so that RPM can keep the current implementation while adding support for a Sequoia-based one. So RPM can keep using its current implementation in environments where Rust is too much of a burden as a build dependency. At the same time, adding a proper abstraction layer will likely benefit the code base, and we can improve the current implementation by comparing what it computes with what Sequoia computes. Justus
signature.asc
Description: PGP signature
_______________________________________________ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
