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

Attachment: signature.asc
Description: PGP signature

_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Reply via email to