Subject: Re: X.509

From: [email-masked] (Peter Gutmann)
Date: Tue, 13 Mar 2007 18:37:10 +1300

Oskari Saarenmaa <[email-masked]> writes:

>I recently submitted a new individual draft for ssh x509 which backs down
>from what we specified in the latest WG draft, and just specifies how we use
>certificates in our implementations.  It's available at
>http://tools.ietf.org/wg/secsh/draft-saarenmaa-ssh-x509-00.txt
>
>Any thoughts?

Further to my previous comments, the text in the Implementation Considerations
section seems a bit misplaced.  Firstly, it's already subsumed by the "refer
to PKI standards" requirement in the Security Considerations, so it's
redundant.  Secondly, I would both hope that any implementation that doesn't
implement a verification algorithm would fail to verify the certificate that
uses it, and can't really see why this would be singled out for special
attention when there are lots of other things that also need to be checked.
Finally, to be nit-picky, you need to verify up to a trust anchor, which isn't
necessarily "all the certificates in the chain".

For all of the above, the appropriate solution seems to be to remove this
section, since it's already more than covered by the requirement in section 7.

Is anyone running a test SSH server that implements this authentication
mechanism?  I'd like to have something to test against...

Peter.

---

From: Roumen Petrov <[email-masked]>
Date: Wed, 28 Mar 2007 00:51:25 +0300

> attention when there are lots of other things that also need to be checked.

It is possible simple implementation to compare public key extracted from
certificate sent with keys from its configuration and if they match to 
accept
connection. As example without this self-issued(self-signed) X.509 
certificates
cannot be used in authentication.

> necessarily "all the certificates in the chain".
Yes verification should be described in RFC3280. Only the direction is 
opposite -
valid path (chain) start from trust anchor .

> mechanism?  I'd like to have something to test against...

You can test my implementation based on openssh and diff files
on http://roumenpetrov.info/openssh/download.html .

Check the options X509KeyAlgorithm and may be KeyAllowSelfIssued.

The configuration like this:
  X509KeyAlgorithm x509v3-sign-rsa,rsa-sha1,ssh-rsa
  X509KeyAlgorithm x509v3-sign-dss,dss-raw,ssh-dss
, should be in conformance with draft.

The configuration:
  X509KeyAlgorithm x509v3-sign-rsa,rsa-sha1
  X509KeyAlgorithm x509v3-sign-dss,dss-raw
, should be used with ssh.com, f-secure.com (etc. ?) .
I think that ssh.com and f-secure.com will accept md5 hash (rsa based 
cert.),
but not in default configuration.

The default is compatible with openssh, vandyke.com (etc. ?) .

Roumen

---

From: [email-masked] (Peter Gutmann)
Date: Sun, 01 Apr 2007 03:56:31 +1200

Roumen Petrov <[email-masked]> writes:
>certificate sent with keys from its configuration and if they match to accept
>connection.

Sure, but that's a specific local policy issue, there are (literally) a
million other ways to do this and I'm not sure why the RFC draft is choosing
to focus on this one particular issue.

>>Finally, to be nit-picky, you need to verify up to a trust anchor, which
>>isn't necessarily "all the certificates in the chain".
>
>opposite - valid path (chain) start from trust anchor .

Only if you've swallowed the spaghetti-PKI red-pill lunacy that path
construction is top-down, which means you have to solve an NP-hard graph
theory problem to verify your cert(s) (at one PKI talk, a top-down path-
construction advocate described, with a totally straight face, how his path-
construction software had run for three days without terminating, until he
killed the process).

>You can test my implementation based on openssh and diff files on
>http://roumenpetrov.info/openssh/download.html .

Thanks.

Peter.