Re: X.509 and ssh



Peter Gutmann wrote:
"JKV" <jkvbe@N O S P A M y a h o o . c o m> writes:

I would like to use it the other way around. All users presenting a X.509
certificate issued by a trusted party can access the server. Then I only
need to install the root certificate of the trusted party on the server and
the user management doesn't need to be done on that server but can be done
independently.

Then all you need to do is arrange the small matter of managing a PKI
alongside SSH.

Somehow I think this isn't going in the right direction :-).

Peter.


I couldn't help but come across this cynical naysayer (habitual at that,
reading through prior posts).

"all you need to do is arrange the small matter of managing a PKI
alongside SSH"

As if to say its complicated? Surely, it is, if you don't understand or
study it -- like anything else.

As a matter of fact, creating your own CA can be as simple as a few
openssl commands, or combining them into a couple scripts (one to create
the CA, another to sign certs), and answering the identification
questions (even that can be automated). One can issue certificates, or
sign reqs in mere seconds.

With a large set of machines, this SURE beats random public keys by
themselves (which are far, far, FAR more difficult to keep track of)
when in you are inside of a large organization or computers or otherwise
have a large number of client machines to administer (image a world
where https site used only byte/hex string keys). The only time the
contemporary PKI public key byte/hex string is overall
easier to use (verify communications) -- is when one only has a few machines that need to communicate with each other -- unless some (always risky and poor-scalability) trusted-keys replication is used.

Moreover, x509 certs (and constructed CAs) instantly lend themselves to a whole host of other secure AND trust applications, https, ldaps, smtps, ftps, imaps (to name a few), mail signing / encryption, software signing. When you extend their reach out to all these other forms of communication, and used by computer laymen, old-fashioned random public key strings is simply not at all feasibile.

Anyone who claims that that x509 is disadvantaged compared to plain PKI, is simply demonstrating that they have no practical or level experience with BOTH technologies. That really shows like sore thumb to those of us who do have both exeriences.

The inability to present a balanced view of two arguments is highly detrimental only to ones own credibility, especially when combined with one-sided cynicism and hyperbole where they are trying to persuade undecided minds into adopting their beliefs.

People aren't truly persuaded by another other single persons opinion - they are are much more persuaded by practical experience.
.



Relevant Pages

  • Re: SSL certificates and keys
    ... Is the server's public key contained in the ... Or it's only the ciphersuite that client and server ... and the certificate is used only for server ...
    (sci.crypt)
  • Encrypting off-site with certificates public key
    ... I thought it would be wise to use a certificate encryption scheme to allow ... Then the data is written into a varbinarycolumn on the central server ... For some reason the public key is generating a different algorithm on .NET ...
    (microsoft.public.sqlserver.security)
  • Re: how can you verify that the site you get is not a fake?
    ... >> know what the information shoudl be from the server with the ssl cert, ... > The information sent to the client is the server's public key bearing ... In order to play ball you don't just need the certificate (or ... Web certs and so on) identity is valid and passes some validity ...
    (Fedora)
  • Re: Is this right? Question about SSL and PKI...
    ... > issuing CLIENT certificates. ... > certificate on my server. ... can be authenticated with some public key in their table of trusted ...
    (sci.crypt)
  • Re: X.509 and ssh
    ... X.509 certificate issued by a trusted party can access the ... trusted party on the server and the user management doesn't need to ... the original offline door badge systems were only a slight step up ...
    (comp.security.ssh)