Re: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation

[nisse%lysator.liu.se@localhost (Niels Möller)]

denis bider <ietf-ssh3%denisbider.com@localhost> writes:

> The current RSA SHA-2 draft defines signature algorithm names separate
> from public key format. I believe this is important: it allows for
> seamless upgrade of existing RSA host and user keys to use the new
> signature methods. If we do not allow for this seamless upgrade,
> adoption of SHA-2 for host and user authentication will be delayed.

I fully agree this makes sense.

> You assert that the "ssh-" prefix is necessary to convey a hint about
> the encoding. To me, this appears to be an arbitrary interpretation. I
> personally do not see this as relevant.

My understanding of this design is that the prefix simply means
"encoding is ssh-specific", and that is applicable also to the new
signature algorithm. I'm sorry if I sounded too harsh; I think
consistent naming is important, but it is still a minor detail.

> - The name of the public key format, which is the SSH-specific key
> format, continues to be "ssh-rsa". This indulges the idea that an
> "ssh-" prefix should be used if the format is SSH-specific.

I view it sligtly differently. The "ssh-rsa" string inside the key
encoding is not a name intended to be parsed (at least not when received
over the wire), it's just required to be there. Which *is* a bit of a
peculiar design. The name *identifying* the algorithm and format is the
name used in negotiating the algorithm, in keyexchange and user
authentication, and it must be known prior to parsing an encoded key or
signature.

And then it happens that the different algorithms named "ssh-rsa" and
"rsa-sha2-256" are specified to use the same encoding of public keys
(for good reasons as you explain above).

> - The signature algorithm names are "rsa-sha2-256" and "rsa-sha2-512".
> The signature encodings just contain the RSA signature blob, which is
> defined in RFC 3447. This is not SSH-specific.

That is a relevant detail I had missed at first reading. So you use a
standard format for the signature (and just prepend a fixed string, for
consistency with other signature algorithms in ssh), but keep using the
ssh-specific encoding for the keys.

To sum up the naming issue: We seem to disagree, but I can live with
either name. I'll do my best to refrain from writing more on that issue,
but I'd be happy to hear other's opinions.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.