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
