[openpgp] Re: ML-KEM and ML-DSA secret key format

Hi Aron,

I've been watching the LAMPS discussion on this, but not reading
it in detail (too many mails/options;-). Shouldn't we wait until
LAMPS has reached a rough consensus on the topic before we make
a change? We might or might not want to land in the same place,
but it'd seem odd if we don't factor their conclusions into our
discussion, and they don't yet seem to have reached a conclusion.
(Or did I miss that?)

Thanks,
S.

On 26/02/2025 11:51, Aron Wussler wrote:
> Hi everyone,
> 
> At the interim meeting on February 10 we discussed the ML-KEM and ML-DSA secret key format, stating we'd prefer to keep the seed format even though LAMPS is reconsidering this choice because of HSM manufacturers.
> We gave it another thought, and we'd like to collect more explicit consensus on this point, also considered Simo's thread on the list [1] that opened right after the interim.
> 
> We would like to consider the following two options:
> 
> ## Keeping the seed format only
> This is the status quo in the specification.
> - It makes it very hard to introduce a different SK format in the future, because we only use fixed length. It could be somehow inferred from the packet length, but it would be astonishingly hacky.
> - Importing keys into HSMs will always be possible (no matter if expanded or seed, if tooling is available)
> - Exporting keys from HSMs that support only expanded format will not produce a valid OpenPGP key (the key can't be rendered as the standard seed wire format, but they could be copied to a similar HSM)
> 
> ## Allowing both seed and expanded format explicitly
> Proposed text: https://github.com/openpgp-pqc/draft-openpgp-pqc/pull/171
> - It makes both formats possible, preferring seed format
> - Adds complexity and failure cases
> - Importing keys into HSMs will sometimes fail (HSM supports only seed, but key is expanded)
> - Exporting keys from HSMs will always result in a valid wire format
> - Not all current crypto libraries accept the expanded format (one of the reasons why it's optional in the proposed spec)
> 
> We have considered the option of adding a "version" or "type" byte that leaves the door open for a future standardization of another secret key format without doing it directly now, but I see only disadvantages in this:
> - If we never use it, it's a useless byte and additional failure case (unknown value)
> - If anyone ends up using it, it will bring all the complexity as defining two formats now, plus the chance of having little to no specification or guidance
> 
> For reference, this is tracked in this issue: https://github.com/openpgp-pqc/draft-openpgp-pqc/issues/169
> 
> Please provide feedback in the next two weeks (until the start of IETF 122 on Sat 15.03).
> 
> Cheers,
> Aron
> 
> [1] https://mailarchive.ietf.org/arch/msg/openpgp/wborm6DvCotyZPzs-kPdyXPtoS0/
> 
> --
> Aron Wussler
> Sent with ProtonMail, OpenPGP key 0x7E6761563EFE3930
> 
> 
> _______________________________________________
> 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]

-----BEGIN PGP SIGNATURE-----

wnsEABYIACMWIQQwbnhHy1kPJkWsM6fk2On5l6gz3QUCZ78XpAUDAAAAAAAKCRDk2On5l6gz3ZaX
AQD2ZpuJpuMKf+2tF216HhR1pQKCucxRgK7fngMob0AwWQEAgk4QwcTlg52KFuqV0iMU5eDYrTAR
tZRGa4gwddgGsQQ=
=lru1
-----END PGP SIGNATURE-----