On 06/05/2008 3:55 AM, Dirk Meyer wrote: > Peter Saint-Andre wrote: >>> Using an existing CA you have to pay a lot of money; users >>> don't like that :) And setting up your own CA is not that simple, >> https://www.xmpp.net/ :) > > If I'm paranoid why should I trust the same CA that verified the > server I use? Maybe they are both controlled by the same person.
You could do some research into the policies of the CA, determine its ownership, follow up with the auditors, try to hack on its services in a white-hat kind of way, etc. Due diligence. Or you could refuse to connect to the Internet. I'm just pointing out that you don't necessarily need to pay a lot of money to obtain a certificate, because for the XMPP network we give away certificates for free (so far only server certificates, but we could issue end-user certificates if we wanted to). >>> creating self-signed certificates on the other hand is an openssl >>> one-liner. >> Right. We've also looked into short authentication strings (SAS) for use >> in XTLS. But that would be farther out. > > IMHO we have several use cases here: > > 1. User to user communication: they can talk. Maybe they exchange a > shared secret somehow and can use that to verify the > fingerprint. No CA needed. Agreed. > 2. My service based idea. In that case bots "talk" to each other > > a. Both peers belong to the same user. One other entity added them > to the network. > > b. They belong to different user. The users trust each other Why do they trust each other, and on what basis? > c. The service belongs to a company. E.g. you access flickr with > XMPP in the future. The Flickr service entity has a valid > certificate but the user has not. > > Well, I think HOW to verify a certificate belongs to an extra > document. You bet. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
