[ssh_x509] empty x509v3-ecdsa-sha2-nistp256 key?

ssh_x509 at roumenpetrov.info ssh_x509 at roumenpetrov.info
Sun Feb 12 21:39:18 EET 2017


Hi Kent,

ssh_x509 at roumenpetrov.info wrote:
> Hi Roumen,
>
> Your finding about the missing algorithm name is consistent with what 
> I found as well, with the blank "[]" in the Java exception trace...
>
> I also had an issue with SshX509RsaPublicKeyRfc6187 before, though I 
> had assumed it was due to the historical reasons in PKIX-SSH you 
> mentioned before 
> (http://roumenpetrov.info/pipermail/ssh_x509_roumenpetrov.info/2016q2/000148.html)...or 
> is this what you meant by putting a "work-around in PKIX-SSH to accept 
> x509v3-ssh-rsa"?

I mean option X509KeyAlgorithm (please see manual pages for details) . 
The other rfc 6187 keys will be described as 
"x509v3-ssh-rsa,rsa-sha1,ssh-rsa" or "x509v3-ssh-dss,dss-raw,ssh-dss" 
(see attached patch) but this is just 1% percent of expected work.

The main goal is to move processing from "key-centric" to 
"algorithm-centric". In "key-centric" function argument is "key 
type"(enumeration) or key. This is not acceptable as key material is key 
and associated certificate and depending from context (algorithm) key 
material has to be encoded differently. And this is 99% percent of work.

My repository has to more patches before attached to this email. All are 
related to refactoring existing code base (main part is same as OpenSSH) 
to propagate algorithm to key encoding and decoding functional (another 
10% of work).

> Any chance you could put in a switch to make turn this behavior on or, 
> better, let this be the default behavior and have a switch to turn on 
> legacy draft-ietf-secsh-transport-12 support?
For upcoming version I plan default for certificates with RSA key to be:
X509KeyAlgorithm x509v3-sign-rsa,rsa-sha1
X509KeyAlgorithm x509v3-sign-rsa,rsa-md5
X509KeyAlgorithm x509v3-ssh-rsa,rsa-sha1,ssh-rsa

Quote from manual page "... use the first listed for "rsa" or "dsa" key 
in signing and accept all listed".
Remark: "first" is due to "key-centric" processing. Also first mean the 
default.

So for Maverick 1.7.3 work around will be following definition 
"X509KeyAlgorithm x509v3-ssh-rsa,rsa-sha1,x509v3-ssh-rsa" and only one 
certificate.
For SecureCRT 8.1.0 - "X509KeyAlgorithm 
x509v3-ssh-rsa,rsa-sha1,x509v3-sign-rsa". No encoding issue with 
multiple certificates.

> What is the pkcs#12 file having only one certificate issue?
This is because sample maverick code (see X509Connect) use pkcs#12 key 
store. My tests are based on this sample.
For rfc6187 keys (class) argument is Certificate[]. To get the chain I 
use keystore.getCertificateChain(alias).
If store has more then one certificate due to "encoding error" 
connection fail. This will be discussed separately.

So let me rephrase - for maverick 1.7.3 rfc 6187 keys pass to 
constructor argument only certificate that match private key.
My implementation is nor restrictive and accept such keys material.
On remote side chain is build internally. This require other 
certificates (intermediate) to be part of key-store on remote side. Root 
is required in all cases.

I found another incompatibility in encoding of signature for ec keys. I 
will provide more details in separate email.

> [SNIP]
>
> Kent 

Roumen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-RFC6187-RSA-DSA-algorithms-test-implementation.patch
Type: text/x-diff
Size: 2315 bytes
Desc: not available
URL: <http://roumenpetrov.info/pipermail/ssh_x509_roumenpetrov.info/attachments/20170212/5c4880e0/attachment-0001.bin>


More information about the ssh_x509 mailing list