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

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.

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.

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.

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]

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