Organization Design (proposal #1)

Current info stored on the keyserver:

{
	address-hash 		(sha256(sha256(user) + sha256(org))
	routing  		(where is this account hosted)	
	public_key 		(the public key of the account)
	proof  			(a proof-of-work that proofs that an account has done some work before creation)
	serial number		(a number that changes on each update)
}

Steps to setup an organisation / account:

Step 1:

create and register organisation:

address-hash:	sha256(sha256("") + sha256(org))
routing:		IP/Host
public_key:		RSA 4096 public key

Step 2:

• john asks acme-inc! to create an account (john@acme-inc!) on server X.
• acme-inc creates an invitation token: base64(sha256(sign(hash(john@acme-inc!) + route[server X]))

Step 3:

• John uses the invitation token to register onto server X.

• Server X checks if the invitation token is "correct" by creating the signature from

  • the organisation's PK
  • john's hash address
  • route[self]

  if the invitation token matches, we know the "organisation" has granted the account to john.

• The mailserver will create the account on the server

• Once successfully created, the mail CLIENT will send the account info to the key server:

  address-hash: sha256(sha256("john") + sha256("acme-inc"))
  signature-token: invitation token
  pub-key: <public key of john>
  org-id: hash of the organisation
  user-id: hash of the user
  pow: proof of work for the account (on data: [address-hash])
  
  signature(address-hash) with private key
  

The key server will check the following:

• is the signature of the address-hash correct for this public key (this will be a dummy check on an account creation, as there is no public key yet, and we do not use the public key the user has sent with)
• does the hash of org-id, plus hash of user-id combined make up the address-hash. If so, we can safely say that this is the actual organisation for this user.
• if the pow correct?
• create a signature-token with all info (org's pk, hash address, routing info), and check if it matches the one send. If so, we know this organisation has allowed this user (question: is there any way to spoof this? What if we send somehow a fake organisation id? I don't think this is possible, as that would change the hash of the address as well)

if we update or delete the key, we can only do so if the signature of the address-hash matches the public key currently on record. Only if this is true, we can update key data. This is to ensure that nobody else than the owner of the private key can change data.

Step 4:

user hello! sends an email to john@acme-inc!.

• First, the mail client will look up the address for the hash (john@acme-inc!). It will return a public key and routing info. The public key is used to encrypt the message (actually, it encrypts a key that encrypts the message), so only the private key of john@acme-inc! can decrypt it.
• Secondly, the message will be sent to the mail server of hello!, asking it to send the message to the hash of john. The mail-server, and any other mail-servers in between, including the target mail server, will NOT know anything about the sender and the recipient. (currently, we do not allow proxying of messages, but we might in the future).

Questions to be asked:

Q: can we force the organisation to remove a key if the organisation says so?

A: if we store the org-id, we can send a command on behalf of the organisation (the command is signed by the private key of the org). This command could be: "remove address", or "change routing". THis implies we need a organisation id stored on the keyserver.

Q: could we have a default route for organisations, so we don't have to change all addresses when an organisation moves?

A: In theory: when we send a message, we know the organisation. WE could add this to the message routing (but rather not), but this would allow the mailserver to check the keyserver account. If the routing is empty (or 0.0.0.0 for instance), it can fall back to the organisation ID's route. This means a double lookup (which is ok I think).