[ssh_x509] Some additional questions on pkixssh

ssh_x509 at roumenpetrov.info ssh_x509 at roumenpetrov.info
Sat May 20 18:55:14 EEST 2017

Hello Ron,

ssh_x509 at roumenpetrov.info wrote:
> Hello Roumen,
> Tonight I got user authentication working with X.509 certificates in pkixssh 10.1.1. Thanks for all your work on this!
> As I dig into the details of pkixssh, I’ve got some questions about the configuration options.
> First, I noticed that “ssh-keygen -y” output the certificate as type “x509v3-sign-rsa” when I updated my id_rsa.pub file. I had set things up to only accept “x509v3-ssh-rsa” in my test, but the key worked despite the mismatch. Given that x509v3-sign-rsa is historical at this point, will ssh-keygen be switching over to the new name at some point?
This is main issues - to keep compatibility with existing installations. 
Goal - upgrade of programs must not require update of configurations.
Modification like in attached 
file"0008-force-public-key-algorithms-for-rfc6187-keys.patch" will not 
go soon in official releases.

>   After seeing that an “x509v3-sign-rsa” public key was accepted, I manually edited the name to “x509v3-ssh-rsa” in my id_rsa.pub and it still worked, so it looks like the two are interchangeable at the moment in the local config, with the choice of format just changing how the keys are transmitted on the wire.
Yes algorithms in local configurations (authorized keys or know host) 
has to be interchangeable as identity (key material) is one and the same 
: private key and corresponding X.509 certificate.

Depending from configuration per host (list with algorithms) and some 
server extensions (10.1+) a key could be chosen for connection.
Note key will not be used if there is no matching algorithm.
Algorithm determine format of key (algorithm , encoding signature) send 
to remote pear.

> Another thing I ran into is that pkixssh doesn’t seem to support the new ExtendedKeyUsage values of “secureShellClient” and “secureShellServer” defined in RFC 6187. Since I created my keys with this ExtendedKeyUsage set, I had to set “AllowedCertPurpose” to “Any” for now for pkixssh to accept them. Will pkixssh support these values at some point in the future?
Yep but with low priority . Patches are welcome.
Those extensions are defined in more recent openssl versions but I think 
that is easy to be implemented compatibility for earlier versions.

> Also, I was able to get both subject-based and blob-based matching to work on certificates, but I didn’t see any way to accept all certificates signed by a particular root CA the way you can with OpenSSH-format certificates and the “cert-authority” marker in authorized_keys/known_hosts.
Hmm, just put in "X.509 store" only acceptable root CAs. "X.509 store" 
holds certificates of issuers

> Is there any support in pkixssh for something like this, or for doing wildcard or partial matches on the X.509 subject names in the certificate being validated?
I didn't understand question.

> OpenSSH supports the notion of a “principals” attribute in authorized_keys, with the ability to do both positive and negative wildcard matches. Does pkixssh support anything like that for matching on X.509 principals?
In X.509 principal is common name or subject alternative name or there 
is one vendor extension, right? Unfortunately common name is not unique. 
Distinguished name(dn) is unique.

> I’ve been looking at adding support for RFC 6187 in my python “AsyncSSH” implementation. However, I was thinking it might be nice to just extend the existing OpenSSH “cert-authority” syntax in authorized_keys and known_hosts to accept both OpenSSH and X509 format certificates when I did this, leveraging things like the wildcard principal matching support I already have for OpenSSH certificates. It would be great if pkixssh also supported this existing OpenSSH syntax for which certificate authorities and principals to trust.

PKIXSSH syntax is "A priori" and quite simple.
Pattern matching is not implemented yet (lack of time).
If is implemented is will be more closed to items in a X.509 
distinguished name or X.509 certificate.

> This could even potentially eliminate the need to have separate configuration options for the X.509 store and the “subject” style syntax. Now that RFC 6187 requires that the full certificate chain (other than the root CA) always be provided by the peer, there’s no need for an X.509 store to hold intermediate CAs.
Legacy format is widely used.
Leading commercial implementation does not support 6187 algorithms yet.

> The only thing you really need to configure is which root CAs to trust. That could be done by configuring either truste
> d root CA public keys or trusted root CA self-signed certs as “cert-authority” values directly in authorized_keys and known_hosts.
OpenSSL, Apache , PKIXSSH , curl, wget and others support one and the 
same format for certificate store. In addition store could be 
directory(LDAP) based.
So I cannot see any reason to implement one more parallel configuration.

> Finally, I was hoping to test x509v3-rsa2048-sha256, but it seems like pkixssh doesn’t support that yet. Are there any plans to add it?
Not yet

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0008-force-public-key-algorithms-for-rfc6187-keys.patch
Type: text/x-diff
Size: 2307 bytes
Desc: not available
URL: <http://roumenpetrov.info/pipermail/ssh_x509_roumenpetrov.info/attachments/20170520/bf8378d8/attachment.bin>

More information about the ssh_x509 mailing list