Message-ID: <545a67be-231a-43f9-bcd5-2643ab9b2fb9@roumenpetrov.info>
Date: Wed, 29 Apr 2026 21:23:51 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Roumen Petrov <pkixssh@roumenpetrov.info>
To: Matt Johnston <matt@ucc.asn.au>,
 "Appel, Ryan" <ryan.appel=40bofa.com@dmarc.ietf.org>
References: <f1964c88-5199-48f7-a23d-36c0328734c8@cs.tcd.ie>
 <CAFR824zaY1QzWSnT2z=SeFu5-QVzzOqMbuHXcnPU5wMsF+-pug@mail.gmail.com>
 <c5ca13e1845d433d817442d722098e7d@bofa.com>
 <aadd19c7-d4bf-424c-bf8e-e809f8997a6c@roumenpetrov.info>
 <0b1d30dc175441e1a7bd70bdd0aea7ae@bofa.com>
 <0754a308ce6f39193b9570b6ba4f62a8@ucc.asn.au>
Content-Language: en-GB
In-Reply-To: <0754a308ce6f39193b9570b6ba4f62a8@ucc.asn.au>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID-Hash: 7EFORV656VRBVD5GVGXLKT63ZTPLKUZQ
CC: ssh@ietf.org
Precedence: list
Subject: =?utf-8?q?=5BSsh=5D_Re=3A_PQ_signatures_-_where_do_we_want_to_end_up=3F?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/ssh/NB2b4qbQschrLUpfNMo1EkWVrmQ>

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