[Rpm-maint] [rpm-software-management/rpm] Ignore most unhashed subpackets in OpenPGP signatures (Issue #1886)

[Demi Marie Obenour]

> > Agreed. I would go further and reject a signature that has a subpacket which cannot validly be in the unhashed section.
> 
> I think that is too far. At the very least, allow unknown and private subpackets there, as they may be self-authenticating.

I am only referring to stuff that is known to *not* be self-authenticating.  Key usage flags and timestamps are examples.

> > Is there ever a reason to have an embedded signature in a type 0 or type 1 signature? The only use-case I can think of is timestamping.
> 
> The predominant use case are primary key binding signatures, but RPM doesn't want to even attempt to canonicalize certificates. Timestamping is a great use case though :) But, for timestamping purposes, we'd want the signature to end up in the hashed subpacket area.

I thought that timestamping signatures were usually of the signature being timestamped, and optionally the public key.  At least that is how I believe they work on Windows and macOS.

> > At the very least, an embedded signature must not also have an embedded signature to avoid recursion.
> 
> That is only interesting if you actually attempt to verify the embedded signature. I don't see RPM doing that anytime soon. First, they don't want to canonicalize certs. Second, for timestamping purposes you'd need the certificate of the timestamping entity. That requires non-local reasoning, and I don't see that on the horizon either, given the state of RPM's OpenPGP implementation.

Indeed.  I do not want RPM to wind up reimplementing (or using!) Cryptographic Message Syntax.  The signature format should become simpler, not more complex.  A raw ed25519 signature (using a distinct tag) would be ideal.

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

Message ID: <rpm-software-management/rpm/issues/1886/1014613485 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20220117/a9d67806/attachment.html>