Our Services Our Choice

Open Infrastructure

The Mathematical Mesh is an Open Infrastructure for managing cryptographic applications:

  • Use of the Mesh does not depend on the choice of service provider.

  • Any Mesh user can interact with any other regardless of which service provider they choose.

  • Users can change their service providers at any time with minimal switching costs.

But even more important than the control this gives to users over their use of the Mesh is that the Mesh allows us to take back control of our legacy applications designed to shut us into a walled garden. The Mesh functionality that makes this possible is the Mesh Contacts catalog.

Signed Contact Assertions

From the user’s point of view, a Mesh Contacts Catalog looks just the same as any other Address Book application: A list of names and addresses that is automatically synchronized between the user’s devices. For the sake of backwards compatibility, the catalog supports legacy contact formats such as VCard so that users can interact with people who are not yet Mesh users. A Mesh Contact Assertion contains essentially the same information but with one important difference: Every contact assertion is authenticated and contains the means to obtain and authenticate updates.

Every Mesh account has a unique root of trust that authenticates the digital signature keys used by devices connected to the account. This allows a Contact Assertion to be used to provide cryptographic credentials for authenticating the user in other protocols such as:

  • S/MIME

  • OpenPGP

  • SSH

Support for any protocol can be added in the same way. All that is required to establish a secure session on any existing communication platform is:

  • A unique scheme identifier

  • The address used to identify the subject within that scheme

  • The credential(s) used to authenticate the subject within that scheme

Expressing this information in URI syntax allows automatic handling of outbound communication requests by the application of the user’s choice on the principal mobile and desktop platforms.

Establishing Contact

The Mesh allows contact assertions to be exchanged through a wide variety of means depending on the available circumstances and the nature of the relationship between the parties. We begin by considering the case of a personal relationships.

If Alice and Bob meet face to face at a conference, they can swap their contact information through a simple QR code exchange or if near field communication is available on the platform by ‘bumping’ phones. While a very determined adversary could attempt to impersonate one of the parties, this is a high cost/high risk attack.

If Alice and Bob are attempting to exchange contacts remotely, the quality of authentication provided is necessarily limited to ‘Trust After First Use’ unless there is some form of out of band channel allowing the credential exchange to be authenticated or recourse to a Trusted Third Party of some form.

Relationships between a person and a business require a different approach because even though a contact assertion issued by a business might specify the name of an individual, it contains addresses that correspond to the employee’s position and not the employee themselves.

Updating Contacts

Contact assertions may be updated in one of two ways:

Push: Sending a contact update message containing the new contact information to each entry in the Contacts Catalog.

Pull: Polling a contact update service specified in a contact assertion before use.

Thus, if Alice decides to add Signal to her list of messaging service providers or switch from Signal to WhatsApp, all she needs to do is to update her personal contact entry and all the administrative chores associated with the change will be handled for her automatically.

Encrypted Contacts

Encrypted contact assertions allow different contact information to be provided to different groups of users separating business from personal and family from friends. Such separation is clearly of particular importance when a physical location such as a home address is being shared.

Eliminating Switching Costs

As currently implemented, the Mesh greatly reduces but does not entirely eliminate switching costs. Mesh accounts have two forms of address:

  • The fingerprint of the root of trust for the account

  • One or more account addresses (alice@example.com, alice@example.net, …) allowing the current service provider to be located.

The Mesh is designed to limit the use of these addresses to the singular purpose of contact exchange. Alice can change her Mesh service provider from example.com to example.net and all her existing contacts who are Mesh users will be automatically notified of the change. This is an important and useful move towards ‘email address portability’ but leaves one very important requirement unaddressed: How does Alice provide her contact information in a printed document such as an academic paper or a business card?

The only solution to this problem today is for Alice to register a DNS name and either set up her own Mesh service or have the DNS address point to her service provider.

The DNS works very well for the specific problem it was designed to address: assigning human readable address identifiers to organizations. It is far from being satisfactory an infrastructure for identifying people. Names are rented, not sold and the cost and technical complexity of registering names is non-trivial.

If we are going to fully eliminate switching costs a new infrastructure that is designed to meet the needs of assigning identifiers to be used by people.

  • Human readability

  • Low cost ($0.10 or less)

  • No renewal fees or requirements

The Callsign Registry presents a proof of concept demonstrating the technical feasibility of meeting these requirements in a new infrastructure. In contrast to the Mesh, which is an open infrastructure, the Callsign Registry architecture accepts the natural tendency for naming infrastructures to converge on a single source of authority. Accordingly, the Callsign Registry architecture anticipates the use of separation of roles and accountability controls to protect the interest of the community relying on it rather than attempting to enforce this through cryptographic mechanisms.