[ssh_x509] other key formats from RFC 6187
ssh_x509 at roumenpetrov.info
ssh_x509 at roumenpetrov.info
Tue May 17 03:16:21 EEST 2016
On 5/9/16 5:09 PM, ssh_x509 at roumenpetrov.info wrote:
> Hi Kent,
> Post from non-list members are moderated and for some reasons I did
> not check regularly.
Strange, I thought I was subscribed, I even just received April's
"mailing list memberships reminder" message. I just logged into mailman
and set my account to receive acknowledgement mail when I send mail to
the list - we'll see what happens this time...
> ssh_x509 at roumenpetrov.info wrote:
>> Hi Roumen,
>> Is it correct that PKIX-SSH only implements the x509v3-ecdsa-sha2-*
>> algorithms from RFC 6187?
>> That is, it does not support x509v3-ssh-dss, x509v3-ssh-rsa, or
>> x509v3-rsa2048-sha256 - is that right?
> For historical reasons supported algorithms are those from draft v12
> of "SSH Transport Layer Protocol" (draft-ietf-secsh-transport-12.txt)
> x509v3-sign-rsa and x509v3-sign-dss ensure compatibility between SSH
Okay, I'll take that as another "yes" then ;)
> I'm not aware of SSH application s that support RSA algorithms from
> RFC 6187.
> Please let me know servers or clients that support them.
Sure, check out the Maverick legacy client here:
https://www.sshtools.com/en/products/j2ssh#. It's Java docs claims to
I've been trying to get Maverick legacy client to work with PKIX-SSH
using its "SshX509EcdsaSha2Nist256Rfc6187" key, but so far no luck (I
think the issue is in how I'm creating the certificate for the
FWIW, I was previously able to get Maverick legacy client to work with
PKIX-SSH using its " SshX509RsaPublicKey" key, which maps to
x509v3-sign-rsa, which makes the issue I'm having now all the more
I was really hoping that PKIX-SSH supported any of x509v3-ssh-dss,
x509v3-ssh-rsa, or x509v3-rsa2048-sha256 - as that would be closer to
what I had working before...
> Support for DSS(dsa) at some point will be removed completely from
I'm personally okay with this, as I don't perceive DSS/DSA being in use
anymore, but I'd suggest waiting until they've been officially
deprecated from RFC 4253...
> Main issue is how to support legacy x509v3-sign-rsa and new algorithm
> names is a user friendly manner.
So my thoughts are that since x509v3-sign-rsa and x509v3-sign-dss didn't
make the final for RFC 4253, there is no standards-based reason to
maintain support for them. I would like to suggest not enabling them
by default, and then require a compile/runtime flag to re-enable
them...or drop them from PKIX-SSH altogether...
> Lets client is with 2048 bit RSA with X.509 certificate (stored on
> 1) What to store in "public key" file?
> Note that "public" file contain a line in format
> Private key file may not exist (in case of smart-card) or could
> contain private key and X.509 certificates. This file does not
> describe algorithm.
> So only public file describes algorithm, but in this case we could use
> x509v3-sign-rsa, or x509v3-ssh-rsa or x509v3-rsa2048-sha256.
> 2) If the public part is with legacy name "x509v3-sign-rsa ...." but
> server support x509v3-ssh-rsa how to configure client?
> 3) Lets server support all three rsa algorithms but server options
> PubkeyAlgorithms list only x509v3-rsa2048-sha256 .
> Perhaps server should reject x509v3-sign-rsa and x509v3-ssh-rsa.
> 4) How server or client to know supported algorithms (
> see SSH_MSG_EXT_INFO from draft-ietf-curdle-ssh-ext-info-00 )
> In brief how to configure "key aliasing" in client, server or agent?
I think that most of the above would be resolved by deprecating the
legacy algorithms, but your #1 seems like it would still be an issue.
That is, even with just RFC6187 algs, there would still be ambiguity
between if a 2048bit RSA key should use x509v3-ssh-rsa or
x509v3-rsa2048-sha256. Maybe the logic could default to using
x509v3-rsa2048-sha256 if the X.509 certificate also uses sha256? Or the
logic could require the application to specify an ordering? - but then
again, isn't this what HostKey is for?
More information about the ssh_x509