From: cvs@openprivacy.orgCVS update: openprivacy/htdocs/notes/reputations
Date: Monday December 11, 19100 @ 17:48
Author: fen
CVSWEB Options: -------------------
Main CVSWeb: http://openprivacy.org/cgi-bin/cvsweb/cvsweb.cgi
View this module: http://openprivacy.org/cgi-bin/cvsweb/cvsweb.cgi/openprivacy/htdocs/notes/reputations
-----------------------------------
Update of /usr/local/cvsroot/openprivacy/htdocs/notes/reputations
In directory openprivacy.org:/home/fen/projects/openprivacy/htdocs/notes/reputations
Modified Files:
requirements.txt
Log Message:
updated section B
*****************************************************************
File: openprivacy/htdocs/notes/reputations/requirements.txt
CVSWEB Options: -------------------
CVSWeb: Annotate this file: http://openprivacy.org/cgi-bin/cvsweb/cvsweb.cgi/openprivacy/htdocs/notes/reputations/requirements.txt?annotate=1.17
CVSWeb: View this file: http://openprivacy.org/cgi-bin/cvsweb/cvsweb.cgi/openprivacy/htdocs/notes/reputations/requirements.txt?rev=1.17&content-type=text/x-cvsweb-markup
CVSWeb: Diff to previous version: http://openprivacy.org/cgi-bin/cvsweb/cvsweb.cgi/openprivacy/htdocs/notes/reputations/requirements.txt.diff?r1=1.17&r2=1.16
-----------------------------------
Index: openprivacy/htdocs/notes/reputations/requirements.txt
diff -u openprivacy/htdocs/notes/reputations/requirements.txt:1.16 openprivacy/htdocs/notes/reputations/requirements.txt:1.17
--- openprivacy/htdocs/notes/reputations/requirements.txt:1.16 Mon Dec 11 17:46:26 2000
+++ openprivacy/htdocs/notes/reputations/requirements.txt Mon Dec 11 17:48:07 2000
@@ -1,4 +1,4 @@
-$Id: requirements.txt,v 1.16 2000/12/12 01:46:26 burton Exp $
+$Id: requirements.txt,v 1.17 2000/12/12 01:48:07 fen Exp $
Reputation Server Requirements: top level feature list
@@ -12,35 +12,47 @@
B. === Security, Authentication, Privacy, Validation ===
+Key:
+ U user
+ I pseudonymous identity
+ J pseudonymous identity (virtually created by an I)
+ J[s] J's secret key
+ J[p] J's public key
+ O an object in the OpenPrivacy or Sierra system
+
1. Pseudonym (nym) creation and maintenance
a. creation of identity I (public/private key pair)
(may have multiple identities)
- b. creation of child J (public/private key pair spawned from N)
- (kab) what do you mean (spawned from N???... it should not be based on
- anything)
- . ability to sign/encrypt data packet with J[s]
+ b. creation of child J (public/private key pair spawned from I) such that:
+ i. J's can't be connected nor traced to back to parent I
+ ii. parent I can document ownership of any single J or group of J's
+ c. ability to sign/encrypt data packet with J[s]
d. ability to verify/decrypt data packet with J[p]
- e. N has ability to create new J as owner of several J data packets
-2. Object validation
- a. does the object that was grafted to still exist
- (kab) this depends on the object actually being network addressable instead
- of just a URI. IE not possible in all situations.
- b. has the object that was grafted to changed?
- (kab) again... this depends on being network addressable... it may work if
- it is time based... IE "this is valid as of Dec 7 but may have changed since
- them. "
- c. are signatures valid
+2. Object validation (further mathematical refinement is needed here)
+ a. does O (say, an object of a reputation graft) exist?
+ i. depends if O is network addressable and reachable
+ (in other words, existence can be proven, but non-existence cannot)
+ b. has O (that was grafted to) changed?
+ i. again, positive proof may exist, but lack of proof proves nothing
+ c. are signatures valid?
+ i. signatures may have expiration dates (is this a requirment?)
+ ii. check for a hash mis-match
+ requires access to the public key, thus:
+ a signer's pubkey <KeyInfo> needs to be accessible to verify a signature
d. are signatures reputable?
+ i. given a pubkey, look up its URI and find its reputation
-Security
- Third parties can not forge opinions or spoof other users
- (since Reputation data is based on public key certificates)
- http://slashdot.org/comments.pl?sid=00/12/06/0126224&cid=157
- http://slashdot.org/search.pl?query=perens&op=users
+3. Security
+ a. third parties can not forge opinions or spoof other users
+ (since Reputation data is based on public key certificates)
+ i. http://slashdot.org/comments.pl?sid=00/12/06/0126224&cid=157
+ ii. http://slashdot.org/search.pl?query=perens&op=users
+ b. each server maintains at least one I[s] used for intra-server communications
+ i. requires trust of key management facility of server's administrators
+ c. intra-server communications can be signed and encrypted
-Note: the reputation server intranet will be secure in and of itself.
- Getting data in and out of the system securely is not part of this spec
+Note: Getting data in and out of the system securely is not part of this spec
C. === Data storage ===
This archive was generated by hypermail 2b30 : Mon Jan 22 2001 - 15:52:14 PST