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

denis bider <[email protected]>
Newsgroups gmane.ietf.secsh
Message-ID <[email protected]>
> The "ssh-" prefix specifies the encoding to use for keys and signatures.

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.

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.

But if this was relevant, the names in the current draft still meet your criteria:

- 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.

- 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.

Note that, besides a different name, the signature encoding is identical to this, defined in RFC 6187 for the key format "x509v3-rsa2048-sha256":
     string  "rsa2048-sha256"
     string  rsa_signature_blob
Notice how this does not have an "ssh-" prefix.


> And even if it were a small mistake, we should
> strive to keep naming consistent.

There has to be a reason for decisions beyond just consistency. Consistency must have a benefit, which it often does; but I do not see that benefit here.

What I see are disadvantages:

- We have to deal with a less practical, less readable name everywhere.
- The prefixed name would not disambiguate this algorithm from anything.
- The prefixed name would not even be consistent with RFC 6187.
- People frown on us for having deliberately chosen, for ourselves and for everyone, a less practical name.

The name we choose right now will be with us and our users for years to come. The non-prefixed choice is one I would very much prefer to see - and is the one that I think is more sensible.

Also:

https://en.wikipedia.org/wiki/Parkinson's_law_of_triviality


----- Original Message -----
From: Niels "Möller" 
Sent: Monday, November 9, 2015 12:42
To: denis bider 
Cc: Peter Gutmann ; [email protected] ; Jeffrey Hutzelman ; Mark D. Baushke ; [email protected] ; [email protected] ; [email protected] ; Max Horn 
Subject: Re: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation

denis bider <[email protected]> writes:

> The "ecdsa-sha2-..." algorithm names (RFC 5656) do not use the "ssh-" prefix.
>
> Neither do the new formats in RFC 6187, i.e. "x509v3-rsa2048-sha256"
> and "x509v3-ecdsa-sha2-...".
>
> In my opinion, the "ssh-" prefix is superfluous. The context of SSH is
> implied by where the names are used.

The "ssh-" prefix specifies the encoding to use for keys and signatures.
My understanding is that for ecdsa- and x509v3-, the encoding is
specified by appropiate other standards. While for ssh-rsa and ssh-dss,
the encoding is ssh-specific: It is specified in the ssh transport
protocol (RFC 4253), and include strings like "ssh-rsa" as part of the
encoding.

I belive the new rsa-sha2-256 algorithm name ought to also have an
"ssh-" prefix, because the format is equally ssh specific.

> I think the use of "ssh-" prefixes for all kinds of names was a
> (small) mistake in the original design.

I disagree. And even if it were a small mistake, we should strive to
keep naming consistent.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.