Michael Schroeder <m...@suse.de> writes: > On Mon, Oct 25, 2021 at 05:32:38PM +0200, Justus Winter wrote: >> 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. > > Yes, except that rpm needs just a very limited subset of this. No > chain of trust, no revokations, and so on. It basically needs what > 'gpgv' is providing: it must check a signature against a set of > trusted public keys.
gpgv absolutely does certificate canonicalization. And it does a lot of the things that I have mentioned. I think what you are saying is that RPM expects certificates to be canonicalized before they are fed to RPM. But, that is exactly what led to CVE-2021-3521. https://access.redhat.com/security/cve/cve-2021-3521 >> 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. > > Yeah, that's the old rfc Werner has been working on the last 6 years. > I hopt it finally gets out of the "draft" status. (Actually, it's more > imporatant to us what features gpg already provides. So we already > implemented ed25519 even if it is still only in a ietf draft.) No, that is not the old RFC that Werner has been working on. The document that Werner worked on is https://datatracker.ietf.org/doc/draft-ietf-openpgp-rfc4880bis/ It is true that a lot of changes that were in RFC4880bis were cleaned up, improved, and merged into the openpgp-crypto-refresh. But, in contrast to RFC4880bis, the openpgp-crypto-refresh has been written by the working group's design team and represents a broad consensus among active OpenPGP implementations. (Disclaimer: I'm part of the design team.) Justus
signature.asc
Description: PGP signature
_______________________________________________ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
