[openpgp] Re: I-D Action: draft-ietf-openpgp-pqc-14.txt

On Tue, 2025-11-18 at 09:55 +0100, Johannes Roth wrote:
> Hi Robert,
> 
> to me that sounds like a problem that RPM has to deal with. I think it's 
> backwards to require deterministic signatures for that. There is no 
> technical reason why it should not be possible to compare the signed 
> binary parts and leave out the signature in the comparison. Maybe it's 
> hard with RPM for some reason but I don't think it's the right way to 
> require deterministic signatures. What if future signature algorithms do 
> not even have a deterministic variant? Then you would be limited to old 
> (and possibly weak) algorithms.

There is not need for deterministic signatures for RPM. And it not hard
to strip away signatures before comparing the binaries. It is all in
the RPM metadata which is easy to verify.

> Unfortunately, supporting the creation of deterministic signatures means 
> that we need to ignore one core part of the v6 signature format (the 
> salt), and at the same time, need to also specify and implement the 
> deterministic variants of signature algorithms.
> This requires a lot of effort to standardize, implement, and test.

Even if you had deterministic signatures, you would still require
access to the original key material in order to reproduce a signature,
which is generally not something you should really have (any serious
distribution of RPM should use an HSM for signing, and should not sign
arbitrary RPM files "just for testing if the signature match").
And really most of the value of reproducible builds is for checking
that a 3rd-party build actually conform to the sources, so the common
case would be lack of key material to reproduce the signature anyway.

If you are not reproducing the signature but just the build, then you
should obtain bit-by-bit identical cpio archive, and then you can
simply copy the signature metadata from the RPM you intend to test and
all should just work.

> Further, you need to take care with hashed signature subpackets like the 
> Signature Creation Time, and possibly others, as well. Even a preference 
> subpacket is not necessarily guaranteed to output the same values or the 
> same order across different versions of an OpenPGP implementation.
> 
> I think you should first motivate clearly why all of this is easier 
> compared to dealing with randomized signatures in RPM (or other 
> code-signing contexts) directly.

I do not see any rational motivation to include signature generation in
reproducible build tooling.

Signatures only attest the authenticity of a package producer, and have
no influence on the contents.

> Best,
> Johannes
> 
> On 18.11.2025 01:29, Elliott, Robert (Servers) wrote:
> > > Falko Strenzke:
> > > nevertheless it would be possible to deliberately violate the standard by using
> > > repeated salt values and the deterministic variant of ML-DSA and
> > > thus obtain deterministic signatures
> > 
> > > Aron Wussler:
> > > OpenPGP v6 signatures include a prepended random salt on the protocol level,
> > > deterministic signatures are therefore unattainable.
> > 
> > I didn’t notice that change in v6; thanks.
> > 
> > Although that could improve security for many use cases, it’s less attractive
> > for code signing purposes. Code signing is often done in an HSM, which might
> > be less susceptible to side channel attacks than the main CPU.
> > 
> > It's a lot simpler to just compare two binaries than try to divide them into
> > reproducible + non-reproducible parts, and be sure the non-reproducible parts
> > are limited to just the signature fields.
> > 
> > Software offering a mechanism to inject poor salt values increases risk in
> > accidentally allowing them when not wanted, so it'd be good to avoid.
> > 
> > Could a special Signature Type be defined to convey that intention?
> > 
> > 0x00  Binary Signature  (as is)
> > 
> > 0xNEW Reproducible Binary Signature
> >      specifies using no salt value (regardless of the hash choice) and using
> >      a deterministic signing algorithm (e.g., EdDSA, deterministic ECDSA per
> >      FIPS 186-5, deterministic ML-DSA, deterministic SLH-DSA, or a composite
> >      using all deterministic algorithms)
> > 
> > A verifier in a non-code signing use case in which the salt is important
> > could reject that new Signature Type. Code signing verifiers could
> > accept both.
> > 
> > _______________________________________________
> > openpgp mailing list -- [email protected]
> > To unsubscribe send an email to [email protected]

-- 
Simo Sorce
Distinguished Engineer
RHEL Crypto Team
Red Hat, Inc

_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]