[Ssh] Re: Complaint about draft-ietf-sshm-cert

[Falcon Darkstar Momot <[e-mail]>]

For what it's worth, the existence of the current PQ signature schemes 
implies that relying on keys being small may not be a tenable long-term 
position.

Agreed that hashes should be used more generally than just this, but it 
seems less urgent: even on embedded devices, a few 1-3kb keys to be 
stored on disk are unlikely to present an operational problem.

--Falcon

On 2026-07-29 17:44, Damien Miller wrote:
> On Wed, 29 Jul 2026, Scott Fluhrer (sfluhrer) wrote:
>
>> The current proposal contains a field called the 'signature key', which is
>> the CA's public key.
>>
>> Now, this CA public key must be trusted already (otherwise you don't get any
>> security); that is, the receiver must already know it.
>>
>> Now, for ECDSA or EdDSA, this key is tiny, and for RSA, it isn't that bad.
>> However, once we get to ML-DSA, these keys become much larger.
>>
>> In Madrid, I asked if we could replace this field with the hash of the
>> public key (at least based on a critical option) - I was told that was
>> reasonable.
>>
>> I just checked - it's not in the current draft.  Of course, the current
>> draft doesn't list an ML-DSA certificate type (either pure or hybrid) - I
>> suppose it would be added then, but I believe it would be cleaner now (and
>> would make RSA certificates smaller)
>>
>> Of course, this would mean that the implementation must keep around the
>> actual key value (rather than a hash to recognize the key value); I am not
>> an implementor (and so I can't say authoritatively), but it would appear to
>> be a reasonable trade-off.
>>
>> Do the people on the list agree?
> I agree that allowing a hash to act as a standin for a full CA key is
> desirable, but haven't proceeded with this for a few reasons:
>
> 1) there are still no PQ signature schemes adopted to properly justify it.
> 2) I'd prefer the certificates draft to just document current practice
>     and not extend on it. I don't think "just hash the CA key and store
>     that" is sufficient - there's a bit more design and specification
>     needed, and this takes the certificates draft further away from just
>     documenting what is already deployed.
> 3) I'd like a more general "hashes standing in for keys" to be possible
>     in SSH than just in certificates. In particular, I think it would be
>     great if we could use hashes in (please forgive the OpenSSHisms)
>     known_hosts and authorized_keys, as this could make these files
>     easier to manage.
>
> -d
>
> _______________________________________________
> Ssh mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]