Internet-Draft Mathematical Mesh Architecture August 2018
Hallam-Baker Expires March 4, 2019 [Page]
Stream:
Independent Submission
Series:
Internet-Draft
Status:
Informational
Published:
Expires
Authors:
Phillip Hallam-Baker (Comodo Group Inc.)

Mathematical Mesh Part I: Architecture Guide
draft-hallambaker-mesh-architecture-06

Abstract

The Mathematical Mesh ‘The Mesh’ is an end-to-end secure infrastructure that facilitates the exchange of configuration and credential data between multiple user devices. The architecture of the Mesh and examples of typical applications are described.

This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh-architecture.html.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time.It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on March 4, 2019

Table of Contents

1. Introduction

The Mathematical Mesh is a user centered Public Key Infrastructure that uses cryptography to make computers easier to use. One of the chief difficulties users face when using network applications is that they need to be configured before use. Configuration of applications that use cryptography to provide security controls it often particularly difficult as they require the user to manage cryptographic keys. The challenge of configuring devices increases exponentially as the number of devices the user is required to manage increases. Users no longer read their email on a single desktop computer, they have laptops, tablets, phones and even watches.

For over 25 years, implementations of S/MIME and OpenPGP have made demands of the user that are clearly preposterous.

S/MIME users are expected to apply to a Certification Authority for a certificate, to authenticate themselves and then install the certificate in their email client. If they have multiple devices, they are expected to export the private key from one device and install it in another. In some cases, the mechanism for installing the private key is not even documented. And the user is required to repeat this travesty on an annual basis despite the fact that 99% of the people they exchange email would never consider engaging in such a degrading experience.

OpenPGP attempts to convince users that Third Party Trust providers are unnecessary by making every user a Third Party Trust provider. A role for which the user is provided with neither instruction nor tools to support the effort.

The Mesh uses cryptography and an untrusted cloud service to make management of computer configuration data transparent to the end user. Each Mesh user has a personal profile that is unique to them. A user may link devices and applications to their Mesh profile to enable transparent sharing of data between them.

The user of the Mesh need never give a seconds thought to the management of their cryptographic keys for one singular reason: Any set of instructions that can be given to a user to perform can be turned into program code and performed by the machines.

For example, Alice has a laptop computer and a tablet. They are both linked to her Mesh profile which allows either to be used for email or to control any devices in her smart home. Alice has chosen to only make her cloud documents available on her laptop but she could change that to add her tablet should the need arise (Figure XX).

Figure 1 : Alice's Mesh profile connections.

Computer security professionals have been telling users to take security seriously for 25 years. It is now time to realize that security is our responsibility, not theirs. We have failed to deliver secure applications most users can use.

1.1. Mesh Profiles

All the configuration data that a user needs to configure and use a device, an application or a network service is stored in a Mesh Profile. All Mesh profiles are authenticated using digital signatures and all private material protected using industry standard end-to-end encryption.

Devices connected to a profile are provisioned with all the network configuration settings and credentials required for the device to be used with the user's applications and services. In most cases, public key credentials will be provisioned to enable transport layer and end-to-end encryption.

1.2. Mesh Services

Mesh service provide a means of exchanging profiles when connecting new devices to an existing profile. To connect a new device to her profile using the basic connection mechanism, Alice begins the process by giving her Mesh service account address to the new device. This causes a connection request to be sent to the Mesh service where a device connection request is posted. Some time later, Alice reviews pending connection requests on a device she has authorized for this purpose, approving or rejecting them. The results of her decisions are then posted back to the Mesh Service on which they originated so that the devices can complete (or abort) the connection process.

A Mesh user's profile may be active on multiple Mesh services at the same time. A user might have separate Mesh service accounts for work and personal use for example.

The connection of a device to a profile is represented by cryptographic keys stored on the connected devices, this ensures that the user remains in full and sole control of their personal profile. The only control a Mesh service can exert is to deny a user the use of that particular service. A user always has the option of connecting their profile to an account at a different service.

It is envisaged that Mesh services might be members of a federation exchanging profile updates, thus providing users with a guarantee of continued service should the original service they selected become unavailable. The Merkle Tree integrity mechanisms supported by the DARE Container format allow for distributed integrity proofs to be maintained for such a federation in a manner similar to BlockChain [BLOCKCHAIN].

1.3. Document Roadmap

The specifications describing the Mesh protocols are divided into three main groups. First set of documents describe the architecture, data structures and protocols that make up the Mesh core. The second set describes the use of the Mesh to secure existing and experimental documents. The third set of documents describe building blocks that were developed to meet requirements arising from the Mesh but are not specific to the Mesh and could be applied to the development of other Web Services that do not involve the Mesh.

Mesh Core
This document provides a high level description of the Mesh architecture and mode of use. Detailed specifications including schemas and examples are specified in the accompanying Mesh Reference document [draft-hallambaker-mesh-reference].
Mesh Services
The Mesh Service protocol.
Mesh Platform
Specifications that the Mesh builds on that are not specific to the Mesh. These include JSON Web Service Binding [draft-hallambaker-json-web-service], Uniform Data Fingerprint [draft-hallambaker-udf], Strong Internet Names [draft-hallambaker-sin], JSON-BCD [draft-hallambaker-dare-message], DARE Message [draft-hallambaker-json-web-service] and DARE Container [draft-hallambaker-dare-container].

In addition, two additional documents describe the use of the reference code base [draft-hallambaker-mesh-developer] and recommendations for implementing Mesh enabled applications to take advantage of the cryptographic facilities offered by specific operating system platforms [draft-hallambaker-mesh-platform].

2. Definitions

This section presents the related specifications and standards on which the Mesh is built, the terms that are used as terms of art within the Mesh protocols and applications and the terms used as requirements language.

2.3. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

2.4. Implementation Status

The implementation status of the reference code base is described in the companion document [draft-hallambaker-mesh-developer].

3. Mesh Services

The Mesh supports multiple mechanisms for connecting devices to an account:

Each of these mechanisms provides for strong mutual authentication of the device profile to the personal profile it is being connected to and vice versa. In each case, the connection request MUST be authorized by the profile owner from a device that has already been connected to the profile and granted administration privileges.

While the first two mechanisms provide a satisfactory means of establishing an initial connection to a Mesh profile, they are only possible when the devices being connected have the necessary affordances and they are impractical as a means of maintaining profiles. Except in unusual circumstances such as offline management of private keys in an air-gapped environment, the process of establishing and managing Mesh profiles is mediated by a Mesh service.

The Mesh Service protocol is divided into three parts as follows:

Portal
The Portal services support creation of a Mesh Service account and management of the owner's Mesh profile.
Catalog
The Catalog services support communication of application data between the devices an owner has connected to their profile. These include configuration profiles for legacy applications such as SMTP mail and SSH, lists of contacts, tasks and calendar entries, and credential storage.
Messaging
The messaging services are Mesh services that accept requests that come from third parties. These include the contact request service, the confirmation service and the message service.

The Portal, Catalog and Messaging services are built on a common platform that reduces the involvement of the service to the bare minimum. All data that is not required to support the service is encrypted. One important (and useful) consequence of this approach is that from the point of view of the Mesh service, the set of Catalog and Messaging services supported are a single interface to a set of data stores distinguished only by the service name.

Since messaging requests may impose a cost on the owner ranging from wasting their time to providing a means of attack, messaging services SHOULD be either highly constrained to mitigate such attacks or require requests be subjected to access control. The authentication and authorization statements used to enforce this access control is stored in the owner's contact catalog. A owner's contact catalog is thus the mediator of messaging requests.

3.1. Portal Service

The portal service supports

The first step in creating a Mesh service account is to create a Mesh personal profile if the user doesn't own one already. A user MAY use the same profile to register multiple accounts at the same Mesh service and at multiple services.

Having established a profile on their first device, a user will typically connect more devices. Figure XX shows Alice connecting a new desktop computer to her profile, the connection request is initiated from the new device (desktop) and approved from the administration device (tablet).

Figure 2 : Alice connects a new device.

Implementing a pure peer-to-peer protocol in which the desktop and tablet communicate directly would require both machines to be turned on at the same time and able to communicate. Experience has shown that this process is considerably more reliable when mediated by some form of broker.

3.2. Catalog Services

Catalog services track data that is created by the user for their own use. Catalog services include:

Contact Catalog
Contains user's contacts. The contact catalog has a special purpose in a Mesh Service as it MAY be required as a source of authorization and authentication information for performing access control on requests to messaging services.
Credential Catalog
Contains username/password data for accessing other services.
Application Configuration Catalog
D

A Mesh Service is not required to support any particular service. However a Mesh service that supports Messaging services MUST support the catalog service so that requests from third parties can be subjected to access control.

3.2.1. Persistence Model

Each service maintains a catalog that represents the state of a set of objects according to the DARE Persistence Model [TBS]. In that model an object is defined as follows:

A catalog service will accept any request to update the catalog that is properly authenticated, that is:

A request MUST meet both criteria to be accepted. The first ensures that the update requests are current at the time they are accepted. The second ensures that the update requests can be authenticated by the devices connected to the profile.

3.2.2. Retrieval Model

The value associated with an object consists of a body and a set of associated attributes some of which may be identified as serving as retrieval keys.

Examples of retrieval keys include

3.3. Messaging Services

Messaging services are functionally identical to catalog services except while a request to create or update an object to a catalog entry can only come from the profile owner, requests received by an messaging service MAY come from an external party and MUST therefore be subjected to access control to prevent various forms of abuse.

Examples of messaging services include:

4. Requirements

Before the Web, most trade was performed in person. Mail order existed but was limited in scope. Most banking transactions other than withdrawing cash from an ATM had to be performed in-line at a branch rather than online through the Web. Trade in stocks and shares barely existed in its modern form. The TLS protocol and the WebPKI that supported it enabled the e-commerce economy that we live in today.

The WebPKI is a powerful infrastructure but it does have one major drawback: It Authenticates the bank to the customer but it does not authenticate the customer to the bank. The use of passwords instead of strong cryptographic credentials makes users vulnerable to phishing.

Design of a public key authentication protocol is straightforward. Making the use of such a protocol practical is a much greater challenge because it requires the user to manage a private key. Users cannot perform even the simplest public key cryptography algorithm in their head and so some sort of device must perform the calculations and this in turn must be provisioned with the private key.

Management of the server private keys for the WebPKI is challenging enough and they tend to stay in one place (at least until recently). Managing private keys for users is much more challenging than managing server keys because:

What has made matters worse is the notion that because users are less sophisticated than system administrators, they cannot use sophisticated technology. In practice, the exact opposite is the case. To make the user experience completely frictionless, we must embrace technologies that are more sophisticated, not avoid them. Systems administrators are usually willing to accept technology that is less than perfect and shows many 'rough edges' because they are experts and using those tools is their job. Users are much less tolerant of technology that meets their needs.

Modern cryptography provides us with the tools to secure practically any form of Internet interaction. In almost every case, the main constraint that holds us back is the impracticality of using client-side private keys:

The SSH protocol supports the use of public key cryptography for authentication, of course. But this is the exception that proves the rule. The use of client side keys in SSH is highly effective for the developer or the systems administrator who only makes use of one machine as their client. Attempting to manage SSH credentials across multiple client and server machines under strict operational controls is not for the fait hearted. Not only is it not uncommon for users to use a single private key for SSH on all the machines they use, there are Web sites that 'explain' how to do this by emailing their private key to themselves over SMTP.

From the user's perspective, a security protocol 'works' when it lets them do their job in peace. The VPN access token works when they gain access to the corporate network, SSH works when they gain access to the server, passwords work when they can log into their bank Web site and pay their bills. But when evaluating a security protocol, it is equally important that the attacker is defeated and that no new failure modes are introduced. The acronym C.I.A. provides a useful mnemonic:

Confidentiality
Protect data from disclosure to unauthorized parties. Prevent unauthorized parties inferring confidential information from traffic analysis.
Integrity
Protect data from unauthorized modification. Establish and verify data authenticity.
Availability
Ensure that data and data services are available when needed. Restrict access to authorized parties. Establish accountability.

While Confidentiality is usually the paramount concern of users, Integrity attacks almost invariably inflict more serious damage and Availability attacks include some that inflict the greatest damage of all. The typical consumer gets irritated if their bank carelessly reveals details of their account but is considerably angrier if it has been depleted by fraud. But as the recent spate of ransomware attacks prove, while the consumer becomes angry when they are a victim of fraud, many will actually pay money to the criminals if the alternative is to lose the pictures of their grandchildren when they were five.

Best practices for managing cryptographic keys present multiple operational challenges:

Separation of Cryptographic Purpose
Each private key SHOULD be used for exactly one cryptographic function. Keys used for encryption SHOULD NOT be used for authentication. Keys used to secure one application SHOULD NOT be used to secure another.
Key Compromise
Revocation of compromised keys MUST be supported.
Key Rotation
It SHOULD be possible to periodically refresh keys used to secure applications, thus ensuring that any compromise of the keying material is time bounded.
Device Isolation
Each device SHOULD have separate keys to protect applications on that device. This limits the consequences should the device be compromised, lost or stolen and permits revocation to be limited to the keys used in that device.
Key Escrow
Whenever a key is used to encrypt static data (i.e. data stored on a disk or other storage device), provision MUST be made to permit (but not require) the decryption key to be escrowed to permit recovery should the need arise.

Provision of Key Escrow is controversial since any mechanism that enables the user to recover a cryptographic key voluntarily enables the user to disclose the key in case of coercion. But this state of affairs, while unsatisfactory, is a lot more satisfactory than the current state of affairs which is to rarely encrypt static data at all.

4.1. Use Case

Alice works with Bob, Carol, and Doug. As part of her work she exchanges email messages with them which may contain confidential information. She also connects to the machines Server1, Server2 and Server3 to perform system administration tasks. She has a personal desktop, a laptop, and a tablet computer. She requires:

This use case is deliberately limited to configuring Alice's devices to enable her to use current security protocols. A large number of use cases and applications were considered during the design including configuring IoT devices in Alice's home and configuring a borrowed or rented device. It was discovered that considering the end-to-end email case was sufficient because the requirements it exposes are a superset of the requirements of the others.

The only use case that introduced requirements beyond Alice configuring end-to-end email and SSH for herself was configuring end-to-end email and other secure applications for a remote co-worker. Meeting these requirements is deferred as a future work item.

4.2. What Makes PKI Hard

Every day, billions of people access Web sites using PKI encryption without even being aware that they are doing so. A smaller but still large number of people use PKI for secure payments, the only difference they are aware of being that they insert their card rather than swiping it through the reader.

Many of the issues that have made PKI hard in the past are due to design choices taken by technologists rather than an intrinsic restriction of PKI. In particular:

S/MIME and other client centered security technologies were added to many Internet applications in the 1990s in response to enterprise requirements. The people who make the purchasing decisions for enterprise software and those who use it on a daily basis are often if not invariably different, the enterprise software market has prioritized functionality over usability. An email client that requires the user to remember to click on the right button to encrypt an email is considered acceptable in the enterprise space, it is not acceptable in the consumer space.

While working on this project, the author attempted to configure a very popular email client to make use of the built in S/MIME capabilities. Even with 25 years of experience, this took over half an hour and required the user to follow a procedure with 17 different steps involving three different applications. Even though the certificate was being issued for use with email, the user had to use a Web browser to enroll for the certificate, validate the request using the email client, download the certificate using the Web browser and then install it using a key management tool.

The bar for security usability is much higher than most security specialists, even those who focus on security admit. Experience should teach us that the iron law of security usability is that a security application that requires the user to think about security will fail.

It is noted in passing that security usability is not achieved by preventing the user seeing the information they need to make their own security decisions.

4.3. The Devil is in the Deployment

One of the most important reasons for the failure of PKI applications has been the failure of PKI applications. As with any communication tool, the value of end-to-end secure email is a function of the size of the network that can be reached. The community of S/MIME users and the community of OpenPGP users have both stalled in the low millions, a significant number but falling far short of ubiquity. End to end secure email can only realize its full potential when its use is the norm and not the vanishingly rare exception.

After a time, failure becomes a self-reinforcing vicious circle. Very few people use end-to-end secure email applications because they are difficult to use. Application providers refuse to invest in developing end-to-end secure email applications because 'there is no demand'.

The Mesh is designed for deployment by providing a stand-alone value proposition to early adopters. The ability to automate the use of end-to-end secure email is not a highly attractive proposition for most when less than 0.1% of the Internet user population have ever registered an S/MIME or OpenPGP key. But an end-to-end secure password manager for Web browsers, or an SSH credential management tool do provide a stand-alone value proposition.

4.4. Why change is possible

All four of the open standards based PKIs that have been developed in the IETF are based on designs that emerged in the mid-1990s. Performing the computations necessary for public key cryptography without noticeable impact on the speed of user interaction was a constraint for even the fastest machines of the day. Consequently, PKI designs attempted to limit the number of cryptographic operations required to the bare minimum necessary. There were long debates over the question of whether certificate chains of more than 3 certificates were acceptable.

Today a 32-bit computer with two processing cores running at 1.2GHz can be bought for $5 and public key algorithms are available that provide a higher level of security than was achievable in the 1990s for less computation time. In 1995, the idea that a single user might need a hundred public key pairs and a personal PKI to manage them as an extreme scenario. Today when the typical user has a phone, a tablet and a laptop and their home is about to fill up dozens if not hundreds of network connected devices, the need to manage large numbers of keys for individual users is clear.

Use of public key cryptography on the scale used in the Mesh would have been impractical even for financial applications as recently as 15 years ago. Today, the performance and memory overhead is negligible.

5. Architectural Principles

Over the course of the first quarter century of commercial use of PKI, a consensus has emerged as to the principles of robust protocol design; All aspects of the design should be public, all cryptographic algorithms should be open standards that have been widely reviewed by domain experts, etc.

The Mathematical Mesh is appropriately aligned with this established consensus but departs from existing practice in certain areas as set out in the following.

5.1. User Centered Design

Traditional enterprise centered PKI keeps the enterprise (and to an extent the users) secure but only as long as the users follow a long list of often complex instructions. Even the US National Security Agency, an institution whose core competence is cryptography and whose principle purpose is to protect US government information failed to protect some of its greatest secrets because it was just too hard to use the right cryptography.

A key principle that guides the design of the Mesh is that any set of instructions that can be written down and given to a user can be written down as code and executed by the computer. Public key cryptography is used to automate the process of managing public keys. Instead of telling the user how to register for a certificate and install it in their mail client, we tell the computer how to do the task for them.

5.2. User Centered Trust.

One of the principal ideological battles that has been fought in the development of end-to-end email security has been the manner in which trust is provided. In the S/MIME protocol, trust is established through a hierarchy of trust providers. In the OpenPGP protocol, trust is in theory established through a 'Web of Trust' but is in practice almost invariably established through either a direct trust model (exchange of key fingerprints) or on a trust after first use basis.

Perhaps, what we should be willing to learn from the experience of attempting to apply these models to real world applications is that none is sufficient by itself. Rather than attempting to impose a single model of trust on every circumstance, multiple trust models should be supported.

The trust model appropriate for validating a key depends on the context in which it is to be used. If Alice is sending Bob a personal email, it is likely that the best key to use will be the one that matches the key fingerprint from the business card he gave her when they met in person. But when Alice is sending Bob an email as her stockbroker, the best key is going to be the one that is issued to Bob as an employee of the brokerage company.

Any trust model must be built around the needs of the user. The Mesh does not impose a model for mapping human to machine interaction identifiers but it does allow the user to put that mapping under their personal control. Devices connected to a Mesh Personal Profile share the same view of the world; the same set of bookmarks and contacts for defining personal names and the same set of trust roots for Certification Authorities trusted to provide brokered trust.

In the traditional model, PKI is used to validate network hosts after discovery. The credential issued by the CA is verified each time the user visits the site.

Figure 3 : Traditional PKI role.

In the Mesh trust model, the primary role of the CA is to provide introductions. When the user first visits the site, to buy goods, the site (and often the vendor it belongs to) is unknown. At this point, the user is looking to the Authority to help decide if they wish to purchase from.

Figure 4 : Trusted Authority as Introducer

Once users can easily maintain a personal directory of trusted vendors and share it across all the devices they use, their personal trust directory becomes their primary trust provider. Thus, the role of the authority changes once a trust relationship has been established from trust provider to trust revoker. The user does not need the authority to tell them to trust a vendor they are already doing business with but they may need the authority to warn them if the vendor has defaulted on purchases made by other customers or has suffered a major breach, etc.

5.3. A Credential Designed for Persistence

One of the main difficulties in using S/MIME for email security is that many users stop using the system when their certificate expires. It is likely that one of the main reasons that OpenPGP is more popular amongst system administrators is that a maintenance-free user experience is available to anyone who decides to neglect key rollover.

A Mesh Master Profile fingerprint is designed to provide a user with a credential that can be used for a lifetime. Using the same offline/online key management approaches that have been applied to root key management in the WebPKI since it began provides users with a credential with a cryptographic lifetime of 20-30 years. The addition of linked notary log technology in the Mesh Portals allows such credentials to be securely renewed should the need arise and thus enabling indefinite use.

5.4. Eliminate unnecessary options

Traditionally cryptographic applications give the user a bewildering choice of algorithms and options. They can choose to have one RSA keypair used for encryption and signature or they can have separate keys for both, they can encrypt their messages using 3DES or AES at 128, 192 or 256 bit security. And so on.

The Mesh eliminates such choices as unnecessary. Except where required by an application, the Mesh always uses separate keys for encryption and signature operations and only uses the highest strength on offer. Currently, Mesh profiles are always encrypted using RSAES-PKCS1-v1_5 with a 2048 bit key [RFC8017], AES with a 256 bit key [FIPS197] and SHA-2-512 [SHA-2]. The use of RSA 2048 will be replaced with Ed448 [RFC8032] when sufficiently mature implementations become available.

For similar reasons, every Mesh master profile has an escrow key. The use of key escrow by applications is optional, but every profile has the capability of using it should circumstances require.

5.5. Strong Public Key Identifiers

A key departure from traditional PKI approaches is that all cryptographic keys are identified in every circumstance by either the UDF fingerprint of the public key in the case of a public key pair or the UDF fingerprint of the symmetric key in the case of a symmetric key pair. No other form of key identifier is used.

This approach greatly simplifies the processes of key discovery, management and signature verification.

Since a UDF fingerprint of sufficient length, uniquely identifies a public key pair, it follows that if the attempt to verify the signature under a public key whose fingerprint matches that specified returns the result false, that the signature is invalid. Contrawise, if the result returned is true, the data is validly signed for a given purpose if and only if the key identifier is authorized for that purpose.

6. Mesh Profiles

All information exchanged through the Mesh is described in a profile. Profiles have the following properties.

At present, four types of Mesh Profile are defined:

Master Profile
Describes the criteria for validating a user's personal profile.
Personal Profile
Describes the user's personal Trust Mesh, the set of device and application profiles connected to it.
Application Profile
Describes the use of a particular application.
Device Profile
Describes a device and cryptographic keys specific to that device.

A profile is Valid if and only if it is Verified, Current and Correct:

Verified
A signature is verified if the key identifier specified maps to a
Current
A profile is current if and only if it has not been superseded by a new profile published to the Mesh Portal.
Correct
A profile is correct if the signing key identifier specified in the signature data is a legitimate signing key for that type of profile as specified in Section YY below.

A profile is connected to a personal profile if and only if:

This trust model allows Application Profiles and Device Profiles to be connected to a Personal Profile by enumerating the identifiers of the connected profile in the personal profile.

Figure 7 : A Master/Personal Profile connected to Application and Device profiles.

6.1. Master and Personal Profiles

Each Mesh user has a Master Profile and a Personal Profile.

Personal Profile
Contains a list of all the device profiles and application profiles that are currently connected to the user's personal Mesh. The personal profile is signed by an administrative key.
Master Profile
Contains a list of administrative keys used to sign personal profiles and the master signature key used to sign the Master Profile.

The use of master signature keys and administration keys to authenticate the Master and Personal profiles needs further explanation.

Figure 5 : Master and Personal Profile Signature

This separation allows the user to add devices and/or change application settings frequently without the need for changes to their master profile or to access their master signature key. This allows the master signature key to be stored in a safe place, preferably using a Hardware Security Module or other precautions without the inconvenience this would entail if regular use of the key was required.

A typical user might modify their personal profile hundreds of times over their lifetime, conceivably even more in a world where homes are filled with hundreds of IoT devices. Adding or removing administrative devices is likely to occur much less frequently. The master signature key used to authenticate the Master Profile never changes. If it becomes necessary to replace the master signature key, it will be necessary to create a new Master profile and perform a secure transition to the new key.

Since the master signature key does not change by definition, the fingerprint of the master signature key is a persistent identifier that will remain constant and only ever refer to exactly one Master Profile. Furthermore, since at any given time a Master Profile has exactly one Personal Profile attached to it (and vice versa), the fingerprint of the master signature key is a persistent identifier for the Personal Profile as well.

6.2. Device Profiles

A device profile contains a description of the device and the public keys to be used as the basis for encryption, authentication and signature on that device (Figure XXX). Ideally, the private keys associated with the device are generated using a secure procedure on the device itself and are bound to the device so that they cannot be exported from it.

Figure 6 : Device Profile

Application profiles MAY specify additional profiles to be used with a particular device for an application specific purpose.

While it is usually desirable for such keys to be generated on the device itself, this is not always possible. If, for example, the application profile is connected to a personal profile with multiple existing devices. In this circumstance, the use of a co-operative key generation approach [PHB-CoKey] is preferred but not always possible. If no other options are available, additional application private keys may be provisioned to the device by encrypting them under the device private key.

Device profiles are connected to a personal profile by enumerating them in the Personal Profile.

6.3. Application Profiles

An application profile describes the configuration of an application. An Application Profile MAY contain:

Public data
Information that is intended for public use that applies to all devices. For example, the user's public encryption key for end to end secure email.
Private Data
Information that applies to all devices that is only intended for use by connected devices. For example, the network configuration information describing how to access the messaging and outbound mail servers.
Public Per Device Data
Information that is intended for public use that applies to a specific device. For example, the user's public signature key might be different for each device.
Private Per Device Data
Information that applies to a specific device and is only for the use of that device. For example, a per-device signature key.

Application Profiles are connected to a Personal Profile by an Application Device Entry. The Application Device Entry specifies the identifier of the device and the set of privileges delegated to it with respect to that application. These privileges MAY include the privilege of signing Application Profile updates. This allows a device that is not an administration device for the personal profile to be permitted to update the application profile. Thus, Alice might not want her laptop to be an administration device but would likely want to be able to add or update Web Site usernames and passwords.

6.4. Verifying Profiles

As described in section XXX, the key identifier in a Mesh Profile signature is the UDF fingerprint of the public key to be used for verification. Therefore, a Profile is invalid if either:

Attempting to validate the profile under a public key whose UDF fingerprint matches that specified in the key identifier returns the result false.

The Key Identifier specified in the signature is not explicitly authorized for the purpose as described below.

The Key Identifiers authorized to sign a profile depend on the type of profile as follows:

Master Profile
The Key Identifier of the key that signs the profile MUST be the UDF fingerprint of the Master Signature Key specified in that Master Profile.
Personal Profile
The Key Identifier of the key that signs the profile MUST be listed as the identifier of an Administrator Key specified in the corresponding Master Profile.
Device Profile
The Key Identifier of the key that signs the profile MUST be the UDF fingerprint of the Device Signature Key specified in that Device Profile.
Application Profile
The Key Identifier of the key that signs the profile MUST be listed as the identifier of an Administrator key for that Application Profile in the corresponding Personal Profile.

6.5. Key Escrow and Recovery

Key Escrow and Recovery capabilities are built into the core of the Mesh. Use of these capabilities is RECOMMENDED but not required.

Encryption of stored data such as email messages and personal photographs protects confidentiality but introduces a major availability risk: The data will be lost if the user loses access to the decryption key. While the risk of being coerced into disclosure of material is a risk for some users, availability is a concern for all users.

The Mesh supports two types of key escrow, Offline and Online.

Offline Key Escrow
Is used to escrow Master Signature Keys, Master Escrow Keys and other private keys that are particularly important to a user and are to be preserved.
Online Key Escrow
Is used to protect all other keys by escrowing the key under a Master Escrow Key.
6.5.1. Offline Escrow

The use of Shamir Secret Sharing [ShamirXX] to escrow private keys is supported as follows:

Since the purpose of the Mesh Portal is in part to provide a high availability data storage facility, the use of the Mesh to store the key recovery blob is preferred.

Data recovery is the reverse of the escrow process:

It will be noted that this process is anonymous. The key recovery blob does not identify the profile or user to which it refers in any way.

6.5.2. Online Escrow

Support for Online escrow requires only that decryption keys for application use be encrypted under the master escrow key as if it was another device connected to a Personal Profile.

7. The CryptoMesh

As described earlier, a Mesh Portal Service is an untrusted cloud services that facilitates the management of Mesh profiles by providing persistent storage. A personal profile MAY be registered to one, many or no Mesh Portal Services at a time.

For the sake of convenience and familiarity, the Mesh Portal Protocol makes use of account identifiers in the traditional [RFC5322] format <user>@<domain>. Transactions supported by the Portal Protocol include:

Transactions marked with an asterisk* require administration privileges for the personal profile.

Although the Mesh Architecture regards the Mesh Portal to be an untrusted cloud service with respect to Confidentiality and Integrity, the information transferred between devices and the portal could be susceptible to traffic analysis. For this reason, all exchanges between devices and the portal MUST be protected using a transport layer security enhancement such as TLS [RFC5246].

7.1. Federated Portals

A Mesh Portal MAY belong to a Federation. Portals belonging to a Federation periodically synchronize their transaction logs so that all the members of the federation have access to the complete set of transaction logs for all the portals belonging to the federation. This allows the federation to collectively guarantee the availability of the user's profile data should one or more portals become unavailable either temporarily or permanently.

The InterMesh protocol is supports Portal Federation.

The CryptoMesh is proposed open federation of Mesh Portals that permits any portal willing to accept its terms of service to join. Due to the nature of the network effect it is expected that there would be only one such open federation baring major disagreements as to terms of service. Figure XXX

Figure 8 : The Cryptomesh.

Mesh Portals that are a member of a Federation have a mutual responsibility to protect availability by acting to mitigate abuse by users attempting to create excessive numbers of profiles or perform excessive numbers of updates.

8. Security Considerations

NYI

9. IANA Considerations

This document does not contain actions for IANA

10. Acknowledgements

Comodo Group: Egemen Tas, Melhi Abdulhayoğlu, Rob Stradling, Robin Alden.

References

Normative References

[SHA-2]
"Secure Hash Standard " <https://dx.doi.org/10.6028/NIST.FIPS.180-4>
[draft-hallambaker-mesh-platform]
Phillip Hallam-Baker "Mathematical Mesh: Platform Configuration" Internet-Draft draft-hallambaker-mesh-platform-03 <http://www.ietf.org/internet-drafts/draft-hallambaker-mesh-platform-03.txt>
[draft-hallambaker-mesh-developer]
Phillip Hallam-Baker "Mathematical Mesh: Reference Implementation" Internet-Draft draft-hallambaker-mesh-developer-07 <http://www.ietf.org/internet-drafts/draft-hallambaker-mesh-developer-07.txt>
[draft-hallambaker-dare-container]
Phillip Hallam-Baker "Data At Rest Encryption Part 2: DARE Container" Internet-Draft draft-hallambaker-dare-container-02 <http://www.ietf.org/internet-drafts/draft-hallambaker-dare-container-02.txt>
[draft-hallambaker-dare-message]
Phillip Hallam-Baker "Data At Rest Encryption Part 1: DARE Message Syntax" Internet-Draft draft-hallambaker-dare-message-02 <http://www.ietf.org/internet-drafts/draft-hallambaker-dare-message-02.txt>
[draft-hallambaker-sin]
Phillip Hallam-Baker "Strong Internet Names (SIN)" Internet-Draft draft-hallambaker-sin-03 <http://www.ietf.org/internet-drafts/draft-hallambaker-sin-03.txt>
[draft-hallambaker-udf]
Phillip Hallam-Baker "Uniform Data Fingerprint (UDF)" Internet-Draft draft-hallambaker-udf-10 <http://www.ietf.org/internet-drafts/draft-hallambaker-udf-10.txt>
[draft-hallambaker-json-web-service]
Phillip Hallam-Baker "JSON Web Service Binding Version 1.0" Internet-Draft draft-hallambaker-json-web-service-10 <http://www.ietf.org/internet-drafts/draft-hallambaker-json-web-service-10.txt>
[draft-hallambaker-mesh-reference]
Phillip Hallam-Baker "Mathematical Mesh: Reference" Internet-Draft draft-hallambaker-mesh-reference-09 <http://www.ietf.org/internet-drafts/draft-hallambaker-mesh-reference-09.txt>
[RFC7231]
R. Fielding and J. Reschke "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content" RFC 7231 DOI 10.17487/RFC7231
[RFC5246]
T. Dierks and E. Rescorla "The Transport Layer Security (TLS) Protocol Version 1.2" RFC 5246 DOI 10.17487/RFC5246
[RFC8032]
S. Josefsson and I. Liusvaara "Edwards-Curve Digital Signature Algorithm (EdDSA)" RFC 8032 DOI 10.17487/RFC8032
[RFC8017]
K. Moriarty and B. Kaliski and J. Jonsson and A. Rusch "PKCS #1: RSA Cryptography Specifications Version 2.2" RFC 8017 DOI 10.17487/RFC8017
[RFC2119]
S. Bradner "Key words for use in RFCs to Indicate Requirement Levels" BCP 14 RFC 2119 DOI 10.17487/RFC2119
[RFC7516]
M. Jones and J. Hildebrand "JSON Web Encryption (JWE)" RFC 7516 DOI 10.17487/RFC7516
[RFC7515]
M. Jones and J. Bradley and N. Sakimura "JSON Web Signature (JWS)" RFC 7515 DOI 10.17487/RFC7515
[RFC7159]
T. Bray "The JavaScript Object Notation (JSON) Data Interchange Format" RFC 7159 DOI 10.17487/RFC7159
[SHA-3]
Morris J. Dworkin "SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions " <https://dx.doi.org/10.6028/NIST.FIPS.202>
[FIPS197]
"[Reference Not Found!]"
[ShamirXX]
"[Reference Not Found!]"

Informative References

[BLOCKCHAIN]
"Blockchain Specification " <https://chain.com/docs/1.2/protocol/specifications/blockchain>
[RFC4880]
J. Callas and L. Donnerhacke and H. Finney and D. Shaw and R. Thayer "OpenPGP Message Format" RFC 4880 DOI 10.17487/RFC4880
[RFC5322]
P. Resnick "Internet Message Format" RFC 5322 DOI 10.17487/RFC5322
[RFC5751]
B. Ramsdell and S. Turner "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification" RFC 5751 DOI 10.17487/RFC5751
[RFC6120]
P. Saint-Andre "Extensible Messaging and Presence Protocol (XMPP): Core" RFC 6120 DOI 10.17487/RFC6120
[RFC4301]
S. Kent and K. Seo "Security Architecture for the Internet Protocol" RFC 4301 DOI 10.17487/RFC4301
[RFC4251]
T. Ylonen and C. Lonvick "The Secure Shell (SSH) Protocol Architecture" RFC 4251 DOI 10.17487/RFC4251
[PHB-CoKey]
"[Reference Not Found!]"

Author's Address


Phillip Hallam-Baker
Comodo Group Inc.
Email:
Prepared: Rendered: