Organization Design (proposal #3)

This proposal is a proposal that will try and merge both proposal proposal #1 and proposal #2:

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:	Default IP/Host, for when no routing info on an account is present
public_key:	RSA 4096 public key
    validation:     comma separated list of validation methods

Validation could be one (or more) of the following: DNS:domain-name KEYBASE:.... PGP:...

DNS validation: If validation is not empty, it will point to a domain-name, which holds a TXT record bitmaelum with the organisation hash as value. This will allow users to verify the organisation.

Other validation: Other methods of validation could be added at a later stage.

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"))
  pub-key: <public key of john>
      routing: route to mailserver, or 0.0.0.0 when using the organisation default
  pow: proof of work for the account (on data: [address-hash])
  signature-token: invitation token (NOT STORED)
  org-id: hash of the organisation
  user-id: hash of the user  (NOT STORED)
  

  When updating or deleting the key, we need additional info:

  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.

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@acme-inc!. 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). This includes information about the organisation.

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. Not only the signature of the actual account is valid, also the signature of the organisation account as well.

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).

Who needs to know organisational information:

• the sender of a message The sender of the message knows the organisation. Nothing is really needed from this, as we use the plaintext address.
• sending mailserver The sending server only receives a header file with routing info to the recipient hash. If we allow "0.0.0.0", as fallback route, we will fetch the organisation hash from the keyserver, to fetch the default route from the organisation. Inside the message, there is no information about organisations needed.
• proxying mailservers Proxying mailservers are not implemented yet.
• receiving mailserver The receiving mailserver does not need to know about organisations. Only the account address hash is important.
• recipient of a message The receiver is already aware of its organisation
• key-server The key server needs to know the organisation, as it needs to check:
  • does the organisation exist (we need to have an organisation before we can add users to it (would make things easier in the future))
  • does the organisation allow this user account on this specific mail server? This is checked through the signature/invitation token system. For this to work we need to upload both the organisation hash and the user hash for validation, but we only need to store the organisation hash for fallback routes.