| Network Working Group | P. Hallam-Baker |
| Internet-Draft | April 4, 2019 |
| Intended status: Informational | |
| Expires: October 6, 2019 |
Mathematical Mesh Part I: Architecture Guide
draft-hallambaker-mesh-architecture-07
The Mathematical Mesh 'The Mesh' is an end-to-end secure infrastructure that makes computers easier to use by making them more secure. The Mesh provides a set of protocol and cryptographic building blocks that enable encrypted data stored in the cloud to be accessed, managed and exchanged between users with the same or better ease of use than traditional approaches which leave the data vulnerable to attack.
This document provides an overview of the Mesh data structures, protocols and examples of its use.
This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh-architecture.html .
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 https://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 October 6, 2019.
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
The Mathematical Mesh (Mesh) is a user centered Public Key Infrastructure that uses cryptography to make computers easier to use.
This document is not normative. It provides an overview of the Mesh comprising a description of the architecture, and a discussion of typical use cases and requirements. The remainder of the document series provides a summary of the principal components of the Mesh architecture and their relationship to each other.
Normative descriptions of the individual Mesh encodings, data structures and protocols are provided in separate documents addressing each component in turn.
The currently available Mesh document series comprises:
The following documents describe technologies that are used in the Mesh but do not form part of the Mesh standards suite:
The following documents describe aspects of the Mesh Reference implementation:
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.
Besides the documents that form the Mesh core, the Mesh makes use of many existing Internet standards, including:
TBS
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] .
The implementation status of the reference code base is described in the companion document [draft-hallambaker-mesh-developer] .
The Mathematical Mesh (Mesh) is a user centered Public Key Infrastructure that uses cryptography to make computers easier to use.
For several decades, it has been widely observed that most users are either unwilling or unable to make even the slightest efforts to protect their security, still less those of other parties. Yet despite this observation being widespread, the efforts of the IT security community have largely focused on changing this user behavior rather that designing applications that respect it.
The Mesh is based on the principle that if the Internet is to be secure, if must become effortless to use applications securely. Rather than beginning the design process by imagining all the possible modes of attack and working out how to address these with the least possible inconvenience, we must reverse the question and ask how much security can be provided without requiring any effort on the user's part to address it.
The Mesh provides a personal PKI to which a user can connect all their devices so they work seamlessly together. Each connected device has a unique set of keys used for encryption, signature and authentication that are bound to that device.
Processing of Mesh assertions is similar to processing of PKIX certificates and SAML assertions but with important semantic differences. Mesh assertions do not have predetermined expiry time and the processing model is based on keys rather than identity.
As in SAML, the basic unit in the Mesh PKI is a signed assertion. A Mesh Profile is a self-signed Mesh Assertion. Currently, three types of Mesh Profile are defined:
Devices are connected to the user's personal profile by means of a connection entry consisting of one or more connection assertions and one or more device private data entries describing device specific application configuration data.
For example, Alice has a laptop, a desktop and a mobile connected to her personal profile each of which is authorized to control the garage door by means of an authenticated interaction with the door control computer:
[[This figure is not viewable in this format. The figure is available at http://mathmesh.com/Documents/draft-hallambaker-mesh-architecture.html.]]
Alice's Personal PKI
If its purpose requires, a connection assertion MAY be public. This allows a device to authenticate to Web Services and authenticate messages using its embedded public key credentials by presenting a suitable connection assertion.
For example, Alice submits an update to a source code repository. The device keys are used to authenticate access to the service and then sign them. The source code repository only has knowledge of Alice's Master Profile fingerprint but can verify the access request and code signature by validating these keys under the device profile and the connection assertion provided.
[[This figure is not viewable in this format. The figure is available at http://mathmesh.com/Documents/draft-hallambaker-mesh-architecture.html.]]
The Mesh provides an infrastructure for supporting existing Internet security applications and a set security features that may be used to build new ones.
For example, Alice uses the Mesh to provision and maintain the keys she uses for OpenPGP, S/MIME, SSH and IPSEC. She also uses the credential catalog for end-to-end secure management of the usernames and passwords for her Web browsing and other purposes:
[[This figure is not viewable in this format. The figure is available at http://mathmesh.com/Documents/draft-hallambaker-mesh-architecture.html.]]
The Mesh design is highly modular allowing components that were originally designed to support a specific requirement within the Mesh to be applied generally.
The basic device connection protocol requires the ability for one device to send a connection request to the Mesh service hosting the user's profile. To accept the device connection, the user connects to the service using an administration device, reviews the pending requests and creates the necessary device connection assertion if it is accepted.
The confirmation protocol generalizes this communication pattern allowing any authorized party to post a short accept/reject question to the user who may (or may not) return a signed response. This feature can be used as improvement on traditional second factor authentication providing resistance to man-in-the-middle attacks and providing a permanent non-repudiable indication of the user's specific intent.
Various schemes have been used to employ QR Codes as a means of device and/or user authentication. In many of these schemes a QR code contains a challenge nonce that is used to authenticate the connection request.
The Mesh supports a QR code connection mode employing the Encrypted Authenticated Resource Locator (EARL) format. An EARL is a type of UDF URI that contains a domain name and a master key:
```` Example ArchitectureConnectEARL ````
The EARL may be expressed as a QR code:
[[This figure is not viewable in this format. The figure is available at http://mathmesh.com/Documents/draft-hallambaker-mesh-architecture.html.]]
QR Code representation of the EARL
An EARL is resolved by presenting the content digest fingerprint of the encryption key to a Web service hosted at the specified domain. The service returns a DARE Message whose payload is encrypted and authenticated under the specified master key. Since the content is stored on the service under the fingerprint of the key and not the key itself, the service cannot decrypt the plaintext. Only a party that has access to the QR code can decrypt the message.
Internet addressing schemes are designed to provide a globally unique (or at minimum unambiguous) name for a host, service or account. In the early days of the Internet, this resulted in addresses such as 10.2.3.4 and alice@example.com which from a usability point of view might be considered serviceable if not ideal. Today the Internet is a global infrastructure servicing billions of users and tens of billions of devices and accounts are more likely to be alice.lastname.1934@example.com than something memorable.
Friendly names provide a user or community specific means of identifying resources that may take advantage of geographic location or other cues to resolve possible ambiguity. If Alice says to her voice activated device "close the garage door" it is implicit that it is her garage door that she wishes to close. And should Alice be fortunate enough to own two houses with a garage, it is implicit that it is the garage door of the house she is presently using that she wishes to close.
The Mesh Contacts Catalog provides a directory mapping friendly names to devices that is available to all Alice's connected devices so that she may give and instruction to any of her devices using the same friendly name and expect consistent results.
The Uniform Data Fingerprint (UDF) format provides a compact means of presenting cryptographic nonces, keys and digest values using Base32 encoding that resists semantic substitution attacks. UDF provides a convenient format for data entry. Since the encoding used is case-insensitive, UDFs may if necessary be read out over a voice link without excessive inconvenience.
The following are examples of UDF values:
```` NAAM-RIUA-RI5L-ASA7-OWSU-2ZOJ-YV4A EDJH-MWNL-ZDNG-YRLW-H2UU-4IOB-5NCQ SAQH-PKX2-BAIJ-I7EC-XGAL-7GWT-DDFP-C MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4 KCM5-7VB6-IJXJ-WKHX-NZQF-OKGZ-EWVN AA3O-LLJI-32OP-4CJB-WTYI-B34V-PV4H ````
UDF content digests are used to support a direct trust model similar to that of OpenPGP. Every Mesh Profile is authenticated by the UDF fingerprint of its signature key. Mesh Friendly Names and UDF Fingerprints thus serve analogous functions to DNS names and IP Addresses. Like DNS names, Friendly Names provide the basis for application-layer interactions while the UDF Fingerprints are used as to provide the foundation for security.
Secure Internet Names bind an Internet address such as a URL or an email address to a Security Policy by means of a UDF content digest of a document describing the security policy. This binding enables an Internet client to ensure that the security policy is applied when connecting to the address. For example, ensuring that an email sent to an address must be end-to-end encrypted under a particular public key or that access to a Web Service requires a particular set of security enhancements.
```` Example ArchSIN ````
All the cryptographic algorithms used in the Mesh are either industry standards or present a work factor that is provably equivalent to an industry standard approach.
Existing Internet security protocols are based on approaches developed in the 1990s when performance tradeoffs were a prime consideration in the design of cryptographic protocols. Security was focused on the transport layer as it provided the best security possible given the available resources.
With rare exceptions, most computing devices manufactured in the past ten years offer either considerably more computing power than was typical of 1990s era Internet connected machines or considerably less. The Mesh architecture is designed to provide security infrastructure both classes of machine but with the important constraint that the less capable 'constrained' devices are considered to be 'network capable' rather than 'Internet capable' and that the majority of Mesh related processing will be offloaded to another device.
[[This figure is not viewable in this format. The figure is available at http://mathmesh.com/Documents/draft-hallambaker-mesh-architecture.html.]]
Constrained Devices connected through a Mesh Hub.
Except where external applications demand otherwise, the Mesh requires that the following 'best practices' be followed:
All Mesh protocol transactions are protected at the Transport, Message and Data level. This provides security in depth that cannot be achieved by applying security at the separate levels independently. Data level encryption provides end-to-end confidentiality and non-repudiation, Message level authentication provides the basis for access control and Transport level encryption provides a degree of protection against traffic analysis.
Existing Internet security protocols only make use of cryptographic operations that involve two parties, one of which has knowledge of the private key and the other which knows only the public key. The Mesh makes use of multi-party cryptographic techniques in which the public operation is performed in the usual manner but the private key operations are performed by multiple parties.
For example, Alice uses secure Mesh messaging on her mobile device. Since the device might be lost, she does not want to store her Mesh messaging decryption device on the device itself. Nor does she want to store that key in the cloud. Instead, the key is split into two parts, one of which is (securely) provisioned to the device and the other to a cloud service.
[[This figure is not viewable in this format. The figure is available at http://mathmesh.com/Documents/draft-hallambaker-mesh-architecture.html.]]
Split Key Decryption.
This configuration allows the device to be used to decrypt messages if and only if the cloud service allows. If the device is lost, the cloud service is notified and all subsequent decryption requests are refused. The cloud service cannot decrypt messages under any circumstances, a fact which can be demonstrated by using a random number generated without access to the decryption key as the private key of the service and only using the decryption key to generate the corresponding device decryption key.
Multi-party techniques are also used in key generation. This allows an administration application to ensure that devices use key pairs that are sufficiently random without having access to the private key information itself.
[[This figure is not viewable in this format. The figure is available at http://mathmesh.com/Documents/draft-hallambaker-mesh-architecture.html.]]
Key Pair Co-Generation.
The Data At Rest Encryption (DARE) format is used for all confidentiality and integrity enhancements. The DARE format is based on the JOSE Signature and Encryption formats and the use of an extended version of the JSON encoding allowing direct encoding of binary objects.
The DARE Message format offers similar capabilities to existing formats such as OpenPGP and CMS without the need for onerous encoding schemes. DARE Assertions are presented as DARE Messages.
A feature of the DARE Message format not supported in existing schemes is the ability to encrypt and authenticate sets of data attributes separately from the payload. This allows features such as the ability to encrypt a subject line or content type for a message separately from the payload.
A DARE Container is an append-only sequence of Entries. A key feature of the DARE Container format is that entries MAY be encrypted and/or authenticated incrementally. Individual entries MAY be extracted from a DARE Container to create a stand-alone DARE Message.
Containers may be authenticated by means of a Merkle tree of digest values on the individual frames. This allows similar demonstrations of integrity to those afforded by Blockchain to be provided but with much greater efficiency.
Unlike traditional encryption formats which require a new public key exchange for each encrypted payload, the DARE Container format allows multiple entries to be encrypted under a single key exchange operation. This is particularly useful in applications such as encrypting server transaction logs. The server need only perform a single key exchange operation is performed each time it starts to establish a master key. The master key is then used to create fresh symmetric keying material for each entry in the log using a unique nonce per entry. Integrity is provided by a Merkle tree calculated over the sequence of log entries. The tree apex is signed at regular intervals to provide non-repudiation.
[[This figure is not viewable in this format. The figure is available at http://mathmesh.com/Documents/draft-hallambaker-mesh-architecture.html.]]
DARE Container containing a transaction log.
One of the core objectives of the Mesh is to make data level encryption ubiquitous. While data level encryption provides robust protection of data confidentiality, loss of the ability to decrypt means data loss.
For many Internet users, data availability is a considerably greater concern than confidentiality. Ten years later, there is no way to replace pictures of the children at five years old. Recognizing the need to guarantee data recovery, the Mesh provides a robust personal key escrow and recovery mechanism. Lawful access is not supported as a requirement.
[[This figure is not viewable in this format. The figure is available at http://mathmesh.com/Documents/draft-hallambaker-mesh-architecture.html.]]
Key escrow and recovery
Besides supporting key recovery in the case of loss, the Mesh protocols potentially support key recovery in the case of the key holder's death. The chief difficulty faced in implementing such a scheme being developing an acceptable user interface which allows the user to specify which of their data should survive them and which should not. As the apothegm goes: Mallet wants his beneficiaries to know where he buried Aunt Agatha's jewels but not where he buried Aunt Agatha.
Mesh Services provide an 'always available' network presence for one or more Mesh profiles. This allows a device that is connected to a Mesh profile but not always available on the network to receive Mesh messages from other Mesh users and to share information with other devices connected to the same profile.
The Mesh currently supports eight separate application profiles through operations on two basic data collection types: Catalogs and Spools. Both of which are implemented as DARE containers. This allows for a remarkably compact application protocol since the only operation needed to perform the functionality of all the Mesh applications is the ability to synchronize a DARE container from a master copy held on the service to full or partial copies on the connected devices.
While such economy of mechanism supporting a wide variety of functions is of course desirable in its own right, it is in part a consequence of the fact that a host supporting a true end-to-end service with data level encryption cannot be expected to support a rich set of operations on data it is unable to read.
Mesh Catalogs are a DARE Container whose entries represent a set of objects with no inherent ordering. Examples of Mesh catalogs include:
The first two of these catalogs have special functions within the Mesh. The Devices Catalog tracks the devices connected to a Mesh Profile and the Contacts Catalog is used to support the use of Friendly Names in place of Internet addresses and to perform access control on inbound messages.
Mesh Spools are DARE Container whose entries comprise a sequence of Mesh Messages.
The inbound spool contains Messages received from other parties and the outbound spool contains Messages queued to be sent to other Mesh users.
The Mesh Messaging model enforces a four-corner approach in which all messages exchanged between devices pass through an inbound and outbound Mesh Service. This approach permits ingress and egress controls to be enforced on the messages and that every message is properly recorded in the appropriate spools.
[[This figure is not viewable in this format. The figure is available at http://mathmesh.com/Documents/draft-hallambaker-mesh-architecture.html.]]
For efficiency and to limit the scope for abuse, all inbound Mesh Messages are subject to access control and limited in size to 64KB or less. This limit has proved adequate to support transfer of complex control messages and short content messages. Transfer of data objects of arbitrary size may be achieved by sending a control message containing a URI for the main content which may then be fetched using a protocol such as HTTP.
This approach makes transfers of very large data sets (i.e. multiple Terabytes) practical as the 'push' phase of the protocol is limited to the transfer of the initial control message. The bulk transfer is implemented as a 'pull' protocol allowing support for features such as continuous integrity checking and resumption of an interrupted transfer.
Since a wide range of network applications may be reduced to synchronization of sets and lists, the basic primitives of Catalogs and Spools may be applied to apply end-to-end security to an even wider variety of applications.
For example, a Spool may be used to maintain a mailing list, track comments on a Web forum or record annotations on a document. Encrypting the container entries under a multi-party encryption group allows such communications to be shared with a group of users while maintaining full end-to-end security and without requiring every party writing to the spool to know the public encryption key of every recipient.
Another interesting possibility is the use of DARE Containers as a file archive mechanism. A single signature on the final Merkle Tree digest value would be sufficient to authenticate every file in the archive. Updates to the archive might be performed using the same container synchronization primitives provided by a Mesh Service. This approach could afford a robust, secure and efficient mechanism for software distribution and update.
This section describes the Mesh in use. These use cases described here are re-visited in the companion Mesh Schema Reference [draft-hallambaker-mesh-schema] and Mesh Protocol Reference [draft-hallambaker-mesh-protocol] with additional examples and details.
For clarity and for compactness, these use cases are illustrated using the command line tool meshman.
The original design brief for the Mesh was to make it easier to use the Internet securely. Over time, it was realized that users are almost never prepared to sacrifice usability or convenience for security. It is therefore insufficient to minimize the cost of security, if secure applications are to be used securely they must be at least as easy to use as those they replace. If security features are to be used, they must not require the user to make any additional effort whatsoever.
The key to meeting this constraint is that any set of instructions that can be written down to be followed by a user can be turned into code and executed by machine. Provided that the necessary authentication, integrity and confidentiality controls are provided. Thus, the Mesh is not just a cryptographic infrastructure that makes use of computer systems more secure, it is a usability infrastructure that makes computers easier to use by providing security.
The user experience is thus at the heart of the design of the Mesh and a description of the Mesh Architecture properly begins with consideration of the view of the system that matters most: that of the user.
The principle security protocols in use today were designed at a time when most Internet users made use of either a single machine or one of a number of shared machines connected to a shared file store. The problem of transferring cryptographic keys and configuration data between machines was rarely considered and when it was considered was usually implemented badly. Today the typical user owns or makes use of multiple devices they recognize as a computer (laptop, tablet) and an even greater number of devices that they do not recognize as computers but are (almost any device with a display).
[[This figure is not viewable in this format. The figure is available at http://mathmesh.com/Documents/draft-hallambaker-mesh-architecture.html.]]
The first step in using the Mesh is to create a personal profile. From the user's point of view a profile is a collection of all the configuration data for all the Mesh enabled devices and services that they interact with.
```` Example ArchitectureCreate ````
Note that the user does not specify the cryptographic algorithms to use. Choice of cryptographic algorithm is primarily the concern of the protocol designer, not the user. The only circumstance in which users would normally be involved in algorithm selection is when there is a transition in progress from one algorithm suite to another.
A Mesh Service provides an 'always available' point of presence that is used to exchange data between devices connected to the connected profile and send and receive Mesh Messages to and from other Mesh users.
To use a Mesh Service, a user creates a Mesh Service account. This is analogous to an SMTP email service but with the important distinction that the protocol is designed to allow users to change their Mesh Service provider at any time they choose with minimal impact.
The account is created by sending an account registration request to the chosen Mesh Service. If accepted, the Mesh Service creates a new account and creates containers to hold the associated catalogs and spools:
```` Example ArchitectureRegister ````
As with any other Internet service provision, Mesh Service providers may impose constraints on the use of their service such as the amount of data they send, store and receive and charge a fee for their service.
A Mesh Catalog contains a set of entries, each of which has a unique object identifier. Catalog entries may be added, updated or deleted.
By default, all catalog entries are encrypted. Applying the Default Deny principle, in normal circumstances, the Mesh Service is not capable of decrypting any catalog excepting the Contacts catalog which is used as a source of authorization data in the Access Control applied to inbound messaging requests.
For example, the entries in the credentials catalog specify username and password credentials used to access Internet services. Adding credentials to her catalog allows Alice to write scripts that access password protected resources without including the passwords in the scripts themselves:
```` Example ArchitectureCredential ````
Having established a Mesh profile, a user may connect any number of devices to it. Connecting a device to a Mesh profile allows it to share data with, control and be controlled by other devices connected to the profile.
Although any type of network capable device may be connected to a Mesh profile, some devices are better suited for use with certain applications than others. Connecting an oven to a Mesh profile could allow it to be controlled through entries to the user's recipe and calendar catalogs and alert the user when the meal is ready but attempting to use it to read emails or manage Mesh profiles.
Three connection mechanisms are currently specified, each of which provides strong mutual authentication: Direct, PIN and QR.
Since approval of a connection request requires the creation of a signed Connection Assertion, requests must be approved by a device that has access to an administration key authorized by the user's Master Profile. Such devices are referred to as Administration devices. Administration devices must have data entry (e.g. keyboard) and output (e.g. display) affordances to support any of the currently defined connection mechanisms. The QR code connection mechanism also requires a suitable camera.
It will be noted that the process of connecting a device that contains a preconfigured set of device keys might in principle expose the user to the risk that the manufacturer has retained knowledge of these keys and that this might be used to create a 'backdoor'.
This risk is controlled using the key co-generation technique described earlier. The original device profile is combined with a device profile provided by the user to create a composite device profile. This ensures that every device uses a unique profile even if they are initialized from a shared firmware image containing a fixed set of device key pairs.
The direct connection mechanism requires that both the administration device and the device originating the connection request have data entry and output affordances and that it is possible for the user to compare the authentication codes presented by the two devices to check that they are identical.
```` Example ArchitectureConnectDirect ````
The PIN Connection mechanism is similar to the Direct connection mechanism except that the process is initiated on an administration device by requesting assignment of a new authentication PIN. The PIN is then input to the connecting device to authenticate the request.
```` Example ArchitectureConnectPIN ````
If the Device Profile fingerprint is known at the time the PIN is generated, this can be bound to the PIN authorization assertion to permit connection of a specific device.
The EARL/QR code connection mechanisms are used to connect a constrained device to a Mesh profile by means of an Encrypted Authenticated Resource Locator, typically presented as a QR code on the device itself or its packaging.
[[This figure is not viewable in this format. The figure is available at http://mathmesh.com/Documents/draft-hallambaker-mesh-architecture.html.]]
Since the meshman tool does not support QR input, it is decoded using a separate tool to recover the UDF EARL which is presented as a command line parameter:
```` Example ArchitectureConnectQR ````
As previously stated, every inbound Mesh message is subject to access control. The user's contact catalog is used as part of the access control authentication and authorization mechanism.
By default, the only form of inbound message that is accepted without authorization in the contact catalog is a contact request. Though for certain Mesh users (e.g. politicians, celebrities) even contact requests might require some form of prior approval (e.g. endorsement by a mutual friend).
A Mesh Contact Assertion may be limited to stating the user's profile fingerprint and Mesh Service Account(s). For most purposes however, it is more convenient to present a Contact Assertion that contains at least as much information as is typically provided on a business or calling card:
```` Example ArchitectureContactDefinition ````
User's may create multiple Contact Assertions for use in different circumstances. A user might not want to give their home address to a business contact or their business address to a personal friend.
In the most general case, the participants are remote from each other and one user must make a contact request of the other:
```` Example ArchitectureContactRequest ````
A DARE contact entry may be exchanged by means of an EARL UDF. This is typically presented by means of a QR code which may be created using the meshman tool and a QR code generator:
```` Example ArchitectureContactQR ````
The resulting QR code may be printed on a business card, laser engraved on a luggage tag, etc.
[[This figure is not viewable in this format. The figure is available at http://mathmesh.com/Documents/draft-hallambaker-mesh-architecture.html.]]
QR Code representation of the EARL
To accept the contact request, the recipient merely scans the code with a Mesh capable QR code reader. They are asked if they wish to accept the contact request and what privileges they wish to authorize for the new contact.
If it is possible for the device to generate a new QR code for the contact request, it is possible to support bi-directional exchange of credentials with strong mutual authentication.
For example, Alice selects the contact credential she wishes to pass to Bob on her mobile device which presents an EARL as a QR code. Bob scans the QR code with his mobile device which retrieves Alice's credential and asks if Bob wishes to accept it and if he wishes to share his credential with Alice. If Bob agrees, his device makes a Remote Contact request authenticated under a key passed to his device with Alice's Contact Assertion.
The Dynamic QR Code protocol may be applied to support exchange of credentials between larger groups. Enrolling the contact assertions collected in such circumstances in a notarized append only log (e.g. a DARE Container) provides a powerful basis for building a Web of Trust that is equivalent to but considerably more convenient than participation in PGP Key Signing parties.
The DARE Message format supports the use of two novel data encryption capabilities that are particularly suited to 'cloud computing' environments in which the owner of a data collection outsources the task of managing it.
An EARL is a form of URI that specifies a means of locating and decrypting a DARE Message stored on a Web Service.
[[This figure is not viewable in this format. The figure is available at http://mathmesh.com/Documents/draft-hallambaker-mesh-architecture.html.]]
Preparing data for delivery using an EARL is a task more typically performed by a document management system than an individual user.
The meshman encryption command can be used to encrypt a file as a DARE Message with the appropriate file name and return the corresponding master key required to create the corresponding EARL:
```` Example ArchitectureEARL ````
As previously discussed, the Mesh makes use of multi-party encryption techniques to mitigate the risk of a device compromise leading to disclosure of confidential data. The Mesh also allows these techniques to be applied to provide Confidential Document Control.
A Mesh Encryption Group is a special type of Mesh Service Account that is controlled by one of more group administrators. The Encryption Group Key is a normal ECDH public key used in the normal manner. The decryption key is held by the group administrator. To add a user to the group, the administrator splits the group private key into two parts, a service key and a user key. These parts are encrypted under the public encryption keys of their assigned parties. The encrypted key parts form a decryption entry for the user is added to the Members Catalog of the Encryption Group at the Mesh Service.
[[This figure is not viewable in this format. The figure is available at http://mathmesh.com/Documents/draft-hallambaker-mesh-architecture.html.]]
When a user needs to decrypt a document encrypted under the group key, they make a request to the Mesh Service which checks to see that they are authorized to read that particular document, have not exceeded their decryption quota, etc. If the request is approved, the service returns the partial decryption result obtained from the service's key part together with the encrypted user key part. To complete the decryption process, the user decrypts their key part and uses it to create a second partial decryption result which is combined with the first to obtain the key agreement value needed to complete the decryption process.
```` Example ArchitectureRecrypt ````
Should requirements demand, the same principle may be applied to achieve separation of duties in the administration roles. Instead of provisioning the group private key to a single administrator, it may be split into two or more parts. Adding a user to the group requires each of the administrators to create a decryption entry for the user and for the service and user to apply the appropriate operations to combine the key parts available to them before use.
These techniques could even be extended to support complex authorization requirements such as the need for 2 out of 3 administrators to approve membership of the group. A set of decryption entries is complete if the sum of the key parts is equal to the private key (modulo the order of the curve).
Thus, if the set of administrators is A, B and C and the private key is k, we can ensure that it requires exactly two administrators to create a complete set of decryption entries by issuing key set { a } to A, the key set {k-a , b } to B and the key set {k-a , k-b } to C (where a and b are randomly generated keys).
One of the chief objections made against deployment of Data Level encryption is that although it provides the strongest possible protection of the confidentiality of the data, loss of the decryption keys means loss of the encrypted data. Thus, a robust and effective key escrow mechanism is essential if use of encryption is to ever become commonplace for stored data.
The use of a 'life-long' Mesh profiles raises a similar concern. Loss of a Master Signature Key potentially means the loss of the ability to control devices connected to the profile and the accumulated trust endorsements of other users.
Because of these requirements, Mesh users are strongly advised but not required to create a backup copy of the private keys corresponding to their Master Profile Signature and Escrow keys.
Users may use the key escrow mechanism of their choice including the escrow mechanism supported by the Mesh itself which uses Shamir Secret Sharing to escrow the encryption key for a DARE Message containing the private key information.
To escrow a key set, the user specifies the number of key shares to be created and the number required for recovery.
```` Example ArchitectureEscrow ````
Recovery of the key data requires the key recovery record and a quorum of the key shares:
```` Example ArchitectureRecovery ````
Having recovered the Master Signature Key, the user can now create a new master profile authorizing a new administration device which can be used to authenticate access to the Mesh Service Account(s) connected to the master profile.
The security considerations for use and implementation of Mesh services and applications are described in the Mesh Security Considerations guide [draft-hallambaker-mesh-security] .
This document does not contain actions for IANA
Comodo Group: Egemen Tas, Melhi Abdulhayo?lu, Rob Stradling, Robin Alden.
| [draft-hallambaker-jsonbcd] | Hallam-Baker, P., "Binary Encodings for JavaScript Object Notation: JSON-B, JSON-C, JSON-D", Internet-Draft draft-hallambaker-jsonbcd-13, July 2018. |
| [draft-hallambaker-mesh-algorithms] | , "[Reference Not Found!]" |
| [draft-hallambaker-mesh-dare] | Hallam-Baker, P., "Mathematical Mesh Part III : Data At Rest Encryption (DARE)", Internet-Draft draft-hallambaker-mesh-dare-00, February 2019. |
| [draft-hallambaker-mesh-developer] | Hallam-Baker, P., "Mathematical Mesh: Reference Implementation", Internet-Draft draft-hallambaker-mesh-developer-07, April 2018. |
| [draft-hallambaker-mesh-platform] | Hallam-Baker, P., "Mathematical Mesh: Platform Configuration", Internet-Draft draft-hallambaker-mesh-platform-03, April 2018. |
| [draft-hallambaker-mesh-protocol] | , "[Reference Not Found!]" |
| [draft-hallambaker-mesh-schema] | , "[Reference Not Found!]" |
| [draft-hallambaker-mesh-security] | , "[Reference Not Found!]" |
| [draft-hallambaker-mesh-trust] | Hallam-Baker, P., "Mathematical Mesh Part IV: The Trust Mesh", Internet-Draft draft-hallambaker-mesh-trust-00, January 2019. |
| [draft-hallambaker-mesh-udf] | Hallam-Baker, P., "Mathematical Mesh Part II: Uniform Data Fingerprint.", Internet-Draft draft-hallambaker-mesh-udf-01, February 2019. |
| [draft-hallambaker-web-service-discovery] | Hallam-Baker, P., "DNS Web Service Discovery", Internet-Draft draft-hallambaker-web-service-discovery-01, February 2019. |
| [FIPS197] | , "[Reference Not Found!]" |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC5246] | Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008. |
| [RFC7159] | Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014. |
| [RFC7231] | Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014. |
| [RFC7515] | Jones, M., Bradley, J. and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015. |
| [RFC7516] | Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015. |
| [RFC8032] | Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017. |
| [SHA-2] | NIST, "Secure Hash Standard", August 2015. |
| [SHA-3] | Dworkin, M., "SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions", August 2015. |