[ssh_x509] other key formats from RFC 6187

[ssh_x509 at roumenpetrov.info]

[resending]


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?
> yes
>
>> 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 
> clients.
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 
support:

     SshX509DsaPublicKeyRfc6187
     SshX509EcdsaSha2Nist256Rfc6187
     SshX509EcdsaSha2Nist384Rfc6187
     SshX509EcdsaSha2Nist521Rfc6187
     SshX509EcdsaSha2NistPublicKeyRfc6187
     SshX509Rsa2048Sha256Rfc6187
     SshX509RsaPublicKeyRfc6187

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 
elliptical key).

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 
frustrating  ;)

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 
> defaults.
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 
> smart-card).
>
> 1) What to store in "public key" file?
> Note that "public" file contain a line in format 
> <algorithms><space><blob><space><comment>.
> 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?


Thanks,
Kent