[Ssh] Re: PQ signatures - where do we want to end up?

[Roumen Petrov <[e-mail]>]

Hello Matt and Ryan,

На 29.04.26 г. в 4:31, Matt Johnston написа:
> On 2026-04-29 1:46 am, Appel, Ryan wrote:
>> Hey Roumen,
>>
>> I don't believe it needs to be specified either.
>>
>> OpenSSH and Putty for example have completely different ways of
>> representing key files (which is obviously different than pkixssh
>> which uses certificates), and specifying a specific way to store the
>> key (either in expanded / seed form) is likely unnecessary. This is my
>> perspective, I just wanted to gather consensus.

FYI: PKIX-SSH could convert between PKCS#8(standard)(*) format and OpenSSH proprietary format i.e. to use both.


> 
> In the case of OpenSSH and Putty key files, it's possible to convert between formats, the underlying key components are the same.
> For server keys in particular it's desirable to keep stable host keys, even if switching software implementations.
> 
> If only the expanded ML-DSA key is stored by an implementation, that can't be converted to other implementations that expect a seed.
> That would be a change to behaviour SSH users expect with key files.


This is my point for ML_DSA and etc keys: (1)private+public vs (2)seed+private(secret) vs etc.(3) in PKCS#8(*) format.
Some cryptographic implementation use (1), other use (2), (3) or both (1)+(2).

I think that specification must specify how is stored private part.
Is there a reason for a hardware token to follow non-related specification?

The same for file-based store. For instance, I don't care how a wallet stores and protect keys.

Only specification for a cryptographic module may specify how is stored private part. Note that it could be non-exportable.
All other specifications must be considered flawed.


[SNIP]

Regards,
Roumen Petrov