river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: WOT: trust bootstrapping
Date Thu, 29 Dec 2011 11:46:38 GMT
In asymetric key cryptography, the public key is used to encrypt information that can only
be encrypted by the holder of the private key.

The trouble is you don't know who the public key belongs to.

For the web, they came up with certificate authorities, the public certificates bundled with
the browser.

For PGP, you exchange keys with the other party, a paper copy or physically hand it to them,
fax it etc, phone up and confirm the key verbally.  They can sign the electronic copy and
send it back and you can sign their key.  Keys expire and they can be revoked.  PGP public
key servers are available on the internet.

Often you have more than one key pair, where one is used to sign the other that you

By self signing your own certificates, the people at the other end still need a way to id
you're cert.

This is the hardest part of cryptography to solve.

There may not always be a user or person on the other end, so there needs to be a programmatic
alternative also.

If you own all the nodes, you can install your own public key on all of them, then sign others
keys for use in your djinn.  You become the cerificate authority in that case.

I'm not sure of the best solution, this is a hard problem to solve, but I'm open to experimenting
with new ideas.

Cheers,

Peter.

----- Original message -----
> On 29-12-11 02:16, Peter Firmstone wrote:
> > Interesting, we could explore different trust models, like pgp's web of
> > trust, perhaps even using the pgp public key servers. Or perhaps a multi
> > referral trust model: ask others we trust if they know and trust the new
> > party. In any case I'd like to avoid the CertificateAuthority model.
>
> I would like to avoid the CertificateAuthority model as well. The PGP
> introducer model has similarities to the CertificateAuthority model.
>
> So the most basic scenary would be the totally isolated bootstrap of
> ones own identity, meaning a self signed certificate. The first
> 'problem' area would be the TLS handshake, which verifies the cert in a
> X509TrustManager. This trustmanager needs to let through the self signed
> ceritificates, the default doesn't. Current the trustmanager is
> jini-system-wide maybe this is something that should be changed into
> thread / connection / ClientSubject oriented.
>
> One could have the trustmanager offer the unknown certificate for
> acceptance to the user, in order to allow authentication via external
> channels.
>
> This would be a better way of exchanging certs, than exchanging them in
> plaintext communications, because (this need verification) the certs are
> exchanged end-to-end encrypted, so no identity is exposed to third parties.
>
>
> > Cheers,
> >
> > Peter.
> >
> > Simon IJskes - QCG wrote:
> > > Some notes:
> > >
> > > * the most basic trust bootstrap is generating a local priv/pub
> > > keypair for your own identity, so without introducer.
> > > * in this case, verification occurs outside the scope of river.
> > > * in order to exchange unknown public keys with TLS, we need a key
> > > collecting X509TrustManager, inserted into river via the
> > > com.sun.jini.jeri.ssl.trustManagerFactoryAlgorithm property.
> > >
> > > Comments? Additions?
> > >
> > > Gr. Sim
> > >
> >
>
>
> --
> QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
> Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message