[openpgp] Re: Encryption subkey selection

Hi all,

I agree with Falko that the ordering by algorithm ID is not ideal. 
Currently, with ML-KEM only, this is not a problem. As soon as we add a 
new algorithm that also has two IDs with different security levels, the 
logic doesn't guarantee the preference of the stronger keys. However, as 
a sane default logic it might be ok and the "weaker" keys are still 
considered sufficiently strong, just with less security margin. Also, 
nothing prevents implementations to implement their own logic. However, 
this also means that we cannot assume that all implementations follow 
the proposed default logic, making it impossible for certificate holders 
to express their own ordering reliably with this approach.

Note that there might be further edge cases if two equally strong 
parameter sets are introduced for an algorithm. Then, the one assigned a 
higher ID would always be preferred which might not always be ideal. We 
have this for signatures, currently: SLH-DSA 128f and 128s offer the 
same security but different tradeoffs with respect to size and speed.

Personally I am a bit skeptical about specifying the subkey creation 
time as a primary selection criterion. It somewhat overloads the simple 
statement about the creation time. If you have a PQC-only certificate 
and realize you need an ECDH key for backwards compatibility, you would 
need to set the creation time to an earlier date than your PQC keys 
which is counter-intuitive, and also requires you to add this delta to 
your expiry time, otherwise it will expire earlier than intended. At 
this point, I would consider it more sensible to let the certificate 
holder express his order preferred order explicitly.

Bottom line: I think having such a default logic makes sense, but I also 
think it won't reliably solve the problems it addresses. In case we only 
specify PQC algorithms from now on, it would at least ensure the 
prefernce of PQC keys.

Best,
Johannes

On 06.05.2025 10:06, Daniel Huigens wrote:
> Hi Falko,
> 
> On Tuesday, May 6th, 2025 at 08:22, Falko Strenzke wrote:
>>
>> Preferring the higher algorithm ID doesn't work for a simple reason: 
>> there are different security levels for each algorithm stacked one 
>> after another as code points (2 for ML-KEM currently). This means that 
>> the suggested selection mechanism might result in the preference of 
>> strictly weaker keys.
>>
> Saying that the proposal "doesn't work" is a very strong statement but 
> what I think you mean is: it might lead to suboptimal outcomes in 
> certain cases, namely if someone has a certificate with two encryption 
> subkeys, one of which is 1. weaker and 2a. has a later creation 
> timestamp or 2b. an equal creation timestamp and a higher algorithm ID.
> 
> My question would be: why would the certificate holder want to create 
> such a certificate? Do such certificates already exist in the wild?
> If we all agree on this encryption subkey selection algorithm, we can 
> just agree to not do that, and give the stronger subkey a higher 
> creation timestamp.
> Or, for future algorithms we can tweak the algorithm, if needed.
> 
> I would also like to note that we don't achieve optimal outcomes in all 
> cases in the current implementations. For example, two out of three 
> implementations don't achieve post-quantum security for the PQC test 
> vectors with multiple subkeys, as noted in the parallel thread. With 
> this proposal, that would be fixed. So, I think it's strictly an 
> improvement over the status quo :)
> 
> Best,
> Daniel
> 
> 
> 
> _______________________________________________
> 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]