[ssh_x509] RFC 6187 Support ?

ssh_x509 at roumenpetrov.info ssh_x509 at roumenpetrov.info
Tue Feb 5 22:57:58 EET 2019


Hello Roy,

ssh_x509 at roumenpetrov.info wrote:
> Fellow PKIXSSH'ers,
>
>     I was recently writing an SSH Agent that was backed by X.509v3
> certificates with RSA keys (on smartcards) and after implementing 
> "ssh-rsa" (draft RFC, and RFC 4253) I added support for 
> "x509v3-ssh-rsa" keys from RFC 6187.
>
> Specifically RFC 6187 Section 2.1:
>
>     string  "x509v3-ssh-dss" / "x509v3-ssh-rsa" /
>             "x509v3-rsa2048-sha256" / "x509v3-ecdsa-sha2-[identifier]"
>     uint32  certificate-count
>     string  certificate[1..certificate-count]
>     uint32  ocsp-response-count
>     string  ocsp-response[0..ocsp-response-count]
>
> So the final result looked something like
>
>     [0, 0, 0, 14, "x509v3-ssh-rsa",
>      0, 0, 0,  1, <certifificateLengthAsUint32>, <certificateBytes>,
>      0, 0, 0, 0]
>
> However the "ssh-add" command that came with PKIXSSH 11.6 could not 
> understand this, and instead appeared to only support keys in the 
> older "x509v3-sign-rsa" format.  Many of my tools do not work well 
> with "x509v3-sign-rsa" format keys since they are unprefixed blobs, 
> unlike "x509v3-ssh-rsa" which is tagged with its format.

So protocol to load X.509 key  to agent is not specified.
I wrote this long time ago and today without to look into code I cannot 
remember implementation details. Actually format is quite specific  - 
methods start with 'A' prefix.

I will try to explain functionality.
Main goal was to transfer X.509 certificate and to use it as "key 
identifier" or "secondary key" used to find private key material.
For compatibility with OpenBSD implementation is used existing 
functionality.

On load after information for private and public key is serialized X.509 
certificate. This should differ from from any format.
For some request is pushed just X.509 certificate.
For signing request is pushed key according RFC or RFC drafts  - parser 
should be able to "decode" algorithm and based on this to encode signature.
Remark:  legacy format  for X.509 certificate was present in RFC draft 
up to version 12 (document is listed in manual page).


>
> I read through some of the documentation and there was mention of RFC 
> 6187 support, but only for EC keys.
>
> Is there any hope of adding RFC 6187 support for RSA keys to PKIXSSH ?
Is is supported - 10.0 version is first with support for RSA, DSA and 
correct EC in RFC 6187 format.
Version before 10.0 support EC but format is not correct.


>
> Thanks,
>     Roy Keene
>

To simplify details let exclude PKCS#11 support in agent.


There is RFC draft with description of OpenBSD implementation. More or 
less in draft "key blob" is equal 'public key material'. Unfortunately 
using RFC 6187 format is huge overload.


What about request to delete key from agent?
Theoretically request with fingerprint (SHA1 or SHA256) should be enough 
to find corresponding key and to delete them.
Draft (based on existing code) uses keyblob. This is overload. What for 
RFC 6187 format: to send 10K+ bytes instead - this is huge overload?
Also for X.509 we could send distinguished name in DER format and this 
should be enough to find key. Not universal.
Dunno why I chose to send X.509 certificate instead just public public 
part of certificate.


Next list keys from agent.
Note that agent could use key material to sign requests for legacy, 
rfc6187 or just "plain" public key algorithms.
What to return from agent for a key with X.509 certificate:
- Whole certificate chain (aka RFC 6187): we could return but why as on 
screen is displayed "certificate distinguished name",
- Plain key: not so useful, due to missing  information that key has a 
X.509 certificate.
- X.509 certificate - this is current solution.
Remark: output of ssh-add -L could be used to fill authorized keys file.


Load of keys:
Theoretically to agent could be send only private key and agent recreate 
public key. Also it could calculate fingerprint and to use it other 
message to find keys. Approach is not suitable for X.59 - see list of 
key request above.


Signing request:
Theoretically as "delete" operation fingerprint should be enough for 
identify key, name of public key algorithm for how to encode signature. 
Flags , no comment on this field.
Unfortunately agent message format is with "keyblob" and so requester 
has to send key in respective format: legacy, rfc6187 or formats for 
"plain" keys according corresponding RFC. From "keyblob" agent must 
parse public key algorithm. Tricky part is legacy format - algorithm is 
not encoded in "keyblob". Other formats include algorithm name, with 
exception for broken "EC X.509" format  in versions before 10.0


Current situation is balance between existing implementation, 
compatibility and usability.


I cannot see a way to improve situation except to implement different 
agent protocol.


Regards,
Roumen Petrov.




More information about the ssh_x509 mailing list