On 04/02/14 19:49, kpn...@pobox.com wrote: > On Tue, Feb 04, 2014 at 01:31:14PM +0100, Javier R. Sobrino wrote: >> 6. Automatic Certificate Authorities (CA) management, for secure >> reliable connections. >> 7. Each node and user is associated with a CA managed by a gateway or >> publisher. >> 8. Difficult generation and global acceptance of CAs encouraged by a >> reputation system. > Would DANE be good enough? > > http://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities > > It builds on top of DNSSEC. We are going to let the name resolution for the applications. Bitcloud will be DNS-free by all means.
Let me paste something about CAs you can find in the paper <https://github.com/wetube/bitcloud/blob/master/bitcloud.org>: Certificate Authorities Certificate authorities (CAs) certifies the ownership of public keys to relay upon assertions to define trust/untrust relationships between components of the system. The main uses are: * To certify that a storage node is assigned to a gateway. * To ensure that a storage node doesn’t gain access to data it is not allowed to store. * To certify the registration precedents of users, and therefore grant or deny access to specific content. * To establish relationships between CAs that trust between them. * To revoke access to malicious contenders. CA creation Bitcloud do not use a classical centralized scheme in which only a few of CAs are widely trusted. In contrast, every gateway and publisher is in charge of generating its own CA and maintain a reputation in order to be accepted by the community. The Sybil attack is an attack wherein a reputation system is subverted by forging identities in peer-to-peer networks at a high rate. Classical centralized CA schemes avoid Sybil attacks by hosting trusted/revoked certifications in already well-reputable certificate vendors, at the expense of human resources to verify identity. Bitcloud is an automatic decentralized storage system that intents to avoid centralization, and relay in other means to verify correctness: * By making expensive to generate new acceptable CAs, a new gateway or publisher must “mine” their CA by soliciting a CPU/memory hard problem to resolve and provide the solution associated with the CA generated. * By maintaining a reputation of good QoS as promised. * By staying online with good reputation, meaning that after a period of time offline the certificate is automatically revoked by the community. * By providing a method of public/private individual revocation based on decisions from the publishers and gateways. CA trust/revocation To encourage the accomplish of the obligations, Bitcloud maintains a general synced file called the Node Pool, with statistics associated with each precise CA. Every node is in charge to publicly/privately trust or revoke other CAs based on such statistics. Revocations based on poor QoS are publicly published in the node pool. Private decisions based on private concerns not associated with QoS are kept private to the gateway or publisher. When a gateway is offered to work for the public grid, private revocations are not to be considered. _______________________________________________ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
