Organization Design (proposal #2)

In this proposal I'll try to document how an organisation is created and how an address is actually linked to an organisation. On the address format the organisation doesn't need to be included and the address-hash will be created using the whole address. So the address-hash for "acalatrava!" will be sha256("acalatrava") and the address-hash for "acalatrava@acme-inc!" will also be sha256("acalatrava@acme-inc").

This is done this way for several reasons:

• It's simpler.
• Keyserver needs to be as simple as possible, it will only store the info we ask for, leveraging all the verifications to the clients.
• On proposal #1 since everything is hashed the keyserver doesn't know the actual organisation name so there is no way to verify real organisation ownership. This is solved by using DNS system.

Info stored on the keyserver:

addresses db:

	{
		address-hash 		(sha256(sha256(user)))
		routing  		(where is this account hosted)	
		public_key 		(the public key of the account)
		organisation 		(domain)
		organisation_signature 	(sha256(sign(sha256(user) + domain + routing)))
		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:

Generate a public/private keypair for the organisation. Create a TXT DNS record bitmaelum? on organisation domain and store public key there.

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(sha256(john@acme-inc!) + domain + 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@acme-inc"))
		routing  		<mailserver>	
		public_key 		<public key of john>
		organisation 		domain
		organisation_signature 	invitation token
		proof  			proof of work for the account (on data: [address-hash])
}

The key server will check the following:

• is the proof correct?
• create a signature-token with all info (org's pk, hash address, domain, routing info), and check if it matches the one send. If so, we know this organisation has allowed this user (well this is really not needed since it will be verified by the client when fetching the messages. Also if the routing is not correct the mail server will reject the messages)

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.

Mailing examples

From non-org address to another address:

user alice! sends an email to bob!.

• First, the mail client will look up the address for the hash bob!. It will return a public key & 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 bob! can decrypt it.
• Secondly, the message will be sent to the routing mail server of alice!, asking it to send the message to the hash of bob!. 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.

From org-address to another address:

user alice@acme-inc! sends an email to bob!.

• First, the mail client will look up the address for the hash bob!. It will return a public key & 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 bob! can decrypt it.
• Secondly, the message will be sent to the routing mail server of alice@acme-inc!, asking it to send the message to the hash of bob!. 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 (except for the organisation domain name in this case, since it's public info).
• Thirdly, when bob! fetch their messages, his mail client will ask the keyserver for the information about alice@acme-inc and it will return organisation and organisation_signature. It will verify that organisation_signature is correct by computing the signature using the public key of the organisation from the domain name DNS TXT record. If it's correct it will flag the message as verified coming from the organisation domain name. If it's not correct a warning should alert the user.

In summary

• This system will allow any address to be linked to an organization. We can link alice! to organisation acme-inc if acme-inc allows us to.
• Organisations are verified through current DNS system, this way I cannot register apple.com organisation if I don't own apple.com domain name.

Drawbacks

• Since organisations need to be verified there is public information revealed where you may know that an address belongs to a specific organisation domain name.
• Addresses can only be linked to one organisation... (is this a problem?) we could store organisation and organisation_signature as an array so the address can be linked to several organisations (domains).