< draft-hallambaker-mesh-architecture-06.txt   draft-hallambaker-mesh-architecture-07.txt >
Network Working Group P. Hallam-Baker Network Working Group P. Hallam-Baker
Internet-Draft Comodo Group Inc. Internet-Draft April 4, 2019
Intended status: Informational August 31, 2018 Intended status: Informational
Expires: March 4, 2019 Expires: October 6, 2019
Mathematical Mesh Part I: Architecture Guide Mathematical Mesh Part I: Architecture Guide
draft-hallambaker-mesh-architecture-06 draft-hallambaker-mesh-architecture-07
Abstract Abstract
The Mathematical Mesh ?The Mesh? is an end-to-end secure The Mathematical Mesh 'The Mesh' is an end-to-end secure
infrastructure that facilitates the exchange of configuration and infrastructure that makes computers easier to use by making them more
credential data between multiple user devices. The architecture of secure. The Mesh provides a set of protocol and cryptographic
the Mesh and examples of typical applications are described. 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 This document is also available online at
http://mathmesh.com/Documents/draft-hallambaker-mesh- http://mathmesh.com/Documents/draft-hallambaker-mesh-
architecture.html [1] . architecture.html [1] .
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 4, 2019. This Internet-Draft will expire on October 6, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Mesh Profiles . . . . . . . . . . . . . . . . . . . . . . 4 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Mesh Services . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Related Specifications . . . . . . . . . . . . . . . . . 5
1.3. Document Roadmap . . . . . . . . . . . . . . . . . . . . 5 2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 5
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 5
2.1. Related Specifications . . . . . . . . . . . . . . . . . 6 2.4. Implementation Status . . . . . . . . . . . . . . . . . . 5
2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 6 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Requirements Language . . . . . . . . . . . . . . . . . . 6 3.1. A Personal PKI . . . . . . . . . . . . . . . . . . . . . 6
2.4. Implementation Status . . . . . . . . . . . . . . . . . . 7 3.2. Support for Legacy and Future Applications . . . . . . . 8
3. Mesh Services . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.1. Confirmation Protocol . . . . . . . . . . . . . . . . 8
3.1. Portal Service . . . . . . . . . . . . . . . . . . . . . 8 3.2.2. Encrypted Authenticated Resource Locators . . . . . . 8
3.2. Catalog Services . . . . . . . . . . . . . . . . . . . . 9 3.2.3. Friendly Names . . . . . . . . . . . . . . . . . . . 9
3.2.1. Persistence Model . . . . . . . . . . . . . . . . . . 9 3.2.4. Uniform Data Fingerprints. . . . . . . . . . . . . . 10
3.2.2. Retrieval Model . . . . . . . . . . . . . . . . . . . 10 3.2.5. Secure Internet Names . . . . . . . . . . . . . . . . 10
3.3. Messaging Services . . . . . . . . . . . . . . . . . . . 10 3.3. Cryptography . . . . . . . . . . . . . . . . . . . . . . 10
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 11 3.3.1. Best Practice by Default . . . . . . . . . . . . . . 11
4.1. Use Case . . . . . . . . . . . . . . . . . . . . . . . . 14 3.3.2. Multi-Level Security . . . . . . . . . . . . . . . . 12
4.2. What Makes PKI Hard . . . . . . . . . . . . . . . . . . . 14 3.3.3. Multi-Party Cryptography . . . . . . . . . . . . . . 12
4.3. The Devil is in the Deployment . . . . . . . . . . . . . 15 3.3.4. Data At Rest Encryption . . . . . . . . . . . . . . . 13
4.4. Why change is possible . . . . . . . . . . . . . . . . . 16 3.3.5. Personal Key Escrow . . . . . . . . . . . . . . . . . 14
5. Architectural Principles . . . . . . . . . . . . . . . . . . 17 3.4. Mesh Services . . . . . . . . . . . . . . . . . . . . . . 14
5.1. User Centered Design . . . . . . . . . . . . . . . . . . 17 3.4.1. Catalogs . . . . . . . . . . . . . . . . . . . . . . 15
5.2. User Centered Trust. . . . . . . . . . . . . . . . . . . 17 3.4.2. Spools . . . . . . . . . . . . . . . . . . . . . . . 16
5.3. A Credential Designed for Persistence . . . . . . . . . . 19 3.4.3. Future Applications . . . . . . . . . . . . . . . . . 16
5.4. Eliminate unnecessary options . . . . . . . . . . . . . . 19 4. User Experience . . . . . . . . . . . . . . . . . . . . . . . 17
5.5. Strong Public Key Identifiers . . . . . . . . . . . . . . 19 4.1. Creating and Registering a Mesh Profile . . . . . . . . . 18
6. Mesh Profiles . . . . . . . . . . . . . . . . . . . . . . . . 20 4.2. Mesh Service . . . . . . . . . . . . . . . . . . . . . . 18
6.1. Master and Personal Profiles . . . . . . . . . . . . . . 21 4.3. Mesh Catalogs . . . . . . . . . . . . . . . . . . . . . . 19
6.2. Device Profiles . . . . . . . . . . . . . . . . . . . . . 22 4.4. Connecting and Authorizing Additional Devices . . . . . . 19
6.3. Application Profiles . . . . . . . . . . . . . . . . . . 23 4.4.1. Direct Connection . . . . . . . . . . . . . . . . . . 20
6.4. Verifying Profiles . . . . . . . . . . . . . . . . . . . 23 4.4.2. Pin Connection . . . . . . . . . . . . . . . . . . . 20
6.5. Key Escrow and Recovery . . . . . . . . . . . . . . . . . 24 4.4.3. EARL/QR Code Connection . . . . . . . . . . . . . . . 20
6.5.1. Offline Escrow . . . . . . . . . . . . . . . . . . . 25 4.5. Contact Requests . . . . . . . . . . . . . . . . . . . . 21
6.5.2. Online Escrow . . . . . . . . . . . . . . . . . . . . 25 4.5.1. Remote . . . . . . . . . . . . . . . . . . . . . . . 21
7. The CryptoMesh . . . . . . . . . . . . . . . . . . . . . . . 26 4.5.2. Static QR Code . . . . . . . . . . . . . . . . . . . 21
7.1. Federated Portals . . . . . . . . . . . . . . . . . . . . 26 4.5.3. Dynamic QR Code . . . . . . . . . . . . . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 27
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
11.1. Normative References . . . . . . . . . . . . . . . . . . 27
11.2. Informative References . . . . . . . . . . . . . . . . . 29
11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30
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 4.6. Storing and Sharing Data in the Cloud . . . . . . . . . . 22
management of computer configuration data transparent to the end 4.6.1. EARL Exchange . . . . . . . . . . . . . . . . . . . . 22
user. Each Mesh user has a personal profile that is unique to them. 4.6.2. Encryption Groups . . . . . . . . . . . . . . . . . . 23
A user may link devices and applications to their Mesh profile to 4.7. Escrow and Recovery of Keys . . . . . . . . . . . . . . . 24
enable transparent sharing of data between them. 5. Security Considerations . . . . . . . . . . . . . . . . . . . 25
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
8.1. Normative References . . . . . . . . . . . . . . . . . . 25
8.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 28
The user of the Mesh need never give a seconds thought to the 1. Introduction
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 The Mathematical Mesh (Mesh) is a user centered Public Key
linked to her Mesh profile which allows either to be used for email Infrastructure that uses cryptography to make computers easier to
or to control any devices in her smart home. Alice has chosen to use.
only make her cloud documents available on her laptop but she could
change that to add her tablet should the need arise (Figure XX).
[[This figure is not viewable in this format. The figure is This document is not normative. It provides an overview of the Mesh
available at http://mathmesh.com/Documents/draft-hallambaker-mesh- comprising a description of the architecture, and a discussion of
architecture.html [2].]] 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.
Alice's Mesh profile connections. Normative descriptions of the individual Mesh encodings, data
structures and protocols are provided in separate documents
addressing each component in turn.
Computer security professionals have been telling users to take The currently available Mesh document series comprises:
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 I. Architecture (This document.) Provides an overview of the Mesh
as a system and the relationship between its constituent parts.
All the configuration data that a user needs to configure and use a II. Uniform Data Fingerprint . Describes the UDF format used to
device, an application or a network service is stored in a Mesh represent cryptographic nonces, keys and content digests in the
Profile. All Mesh profiles are authenticated using digital Mesh and the use of Encrypted Authenticated Resource Locators
signatures and all private material protected using industry standard (EARLs) and Strong Internet Names (SINs) that build on the UDF
end-to-end encryption. platform.
Devices connected to a profile are provisioned with all the network III. Data at Rest Encryption . Describes the cryptographic message
configuration settings and credentials required for the device to be and append-only sequence formats used in Mesh applications and the
used with the user's applications and services. In most cases, Mesh Service protocol.
public key credentials will be provisioned to enable transport layer
and end-to-end encryption.
1.2. Mesh Services IV. Schema Reference . Describes the syntax and semantics of Mesh
Profiles, Container Entries and Mesh Messages and their use in
Mesh Applications.
Mesh service provide a means of exchanging profiles when connecting V. Protocol Reference . Describes the Mesh Service Protocol.
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 VI. The Trust Mesh . Describes the social work factor metric used
same time. A user might have separate Mesh service accounts for work to evaluate the effectiveness of different approaches to exchange
and personal use for example. of credentials between users and organizations in various contexts
and argues for a hybrid approach taking advantage of direct trust,
Web of Trust and Trusted Third Party models to provide
introductions.
The connection of a device to a profile is represented by VII. Security Considerations . Describes the security
cryptographic keys stored on the connected devices, this ensures that considerations for the Mesh protocol suite.
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 VIII Cryptographic Algorithms . Describes the recommended and
exchanging profile updates, thus providing users with a guarantee of required algorithm suites for Mesh applications and the
continued service should the original service they selected become implementation of the multi-party cryptography techniques used in
unavailable. The Merkle Tree integrity mechanisms supported by the the Mesh.
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 following documents describe technologies that are used in the
Mesh but do not form part of the Mesh standards suite:
The specifications describing the Mesh protocols are divided into JSON-BCD Encoding . Describes extensions to the JSON serialization
three main groups. First set of documents describe the architecture, format to allow direct encoding of binary data (JSON-B),
data structures and protocols that make up the Mesh core. The second compressed encoding (JSON-C) and extended binary data encoding
set describes the use of the Mesh to secure existing and experimental (JSON-D). Each of these encodings is a superset of the previous
documents. The third set of documents describe building blocks that one so that JSON-B is a superset of JSON, JSON-C is a superset of
were developed to meet requirements arising from the Mesh but are not JSON-B and JSON-D is a superset of JSON-C.
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 DNS Web Service Discovery . Describes the means by which prefixed
Mesh architecture and mode of use. Detailed specifications DNS SRV and TXT records are used to perform discovery of Web
including schemas and examples are specified in the accompanying Services.
Mesh Reference document [draft-hallambaker-mesh-reference] .
Mesh Services The Mesh Service protocol. The following documents describe aspects of the Mesh Reference
implementation:
Mesh Platform Specifications that the Mesh builds on that are not Mesh Developer . Describes the reference code distribution license
specific to the Mesh. These include JSON Web Service Binding terms, implementation status and currently supported functions.
[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 Mesh Platform . Describes how platform specific functionality such
reference code base [draft-hallambaker-mesh-developer] and as secure key storage and trustworthy computing features are
recommendations for implementing Mesh enabled applications to take employed in the Mesh.
advantage of the cryptographic facilities offered by specific
operating system platforms [draft-hallambaker-mesh-platform] .
2. Definitions 2. Definitions
This section presents the related specifications and standards on This section presents the related specifications and standards on
which the Mesh is built, the terms that are used as terms of art 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 within the Mesh protocols and applications and the terms used as
requirements language. requirements language.
2.1. Related Specifications 2.1. Related Specifications
Besides the documents that form the Mesh core, the Mesh makes use of Besides the documents that form the Mesh core, the Mesh makes use of
many existing Internet standards, including: many existing Internet standards, including:
Cryptographic Algorithms Mesh applications use the cryptographic Cryptographic Algorithms Mesh applications use the cryptographic
algorithm suites specified by the application. The cryptographic algorithm suites specified by the application. The cryptographic
algorithms used in the Mesh itself are limited to SHA-2 [SHA-2] algorithms used in the Mesh itself are limited to SHA-2 [SHA-2]
and SHA-3 [SHA-3] digest functions, AES Encryption [FIPS197] and and SHA-3 [SHA-3] digest functions and AES Encryption [FIPS197]
RSA Signature, and Encryption [RFC8017] . and RSA Signature.
The use of the Ed25519 and Ed448 algorithms is currently being The Ed25519 and Ed448 algorithms are currently used for both
explored for use with both signature [RFC8032] and encryption. signature [RFC8032] and encryption. The Edwards Curve being
The Edwards Curve is preferred over the Montgomery for Encryption preferred over the Montgomery for Encryption as it afforded a more
as it affords a more straightforward implementation of techniques straightforward implementation of techniques such as co-generation
such as co-generation of public key pairs and proxy re-encryption. of public key pairs and proxy re-encryption.
Transport All Mesh Services make use of multiple layers of security. Transport All Mesh Services make use of multiple layers of security.
Protection against traffic analysis and metadata attacks are Protection against traffic analysis and metadata attacks are
provided by use of Transport Layer Security [RFC5246] . At provided by use of Transport Layer Security [RFC5246] . At
present, the HTTP/1.1 [RFC7231] protocol is used to provide present, the HTTP/1.1 [RFC7231] protocol is used to provide
framing of transaction messages. framing of transaction messages.
Encoding All Mesh protocols and data structures are expressed in the Encoding All Mesh protocols and data structures are expressed in the
JSON data model and all Mesh applications accept data in standard JSON data model and all Mesh applications accept data in standard
JSON encoding [RFC7159] . The JOSE Signature [RFC7515] and JSON encoding [RFC7159] . The JOSE Signature [RFC7515] and
skipping to change at page 7, line 10 skipping to change at page 6, line 5
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119] . document are to be interpreted as described in RFC 2119 [RFC2119] .
2.4. Implementation Status 2.4. Implementation Status
The implementation status of the reference code base is described in The implementation status of the reference code base is described in
the companion document [draft-hallambaker-mesh-developer] . the companion document [draft-hallambaker-mesh-developer] .
3. Mesh Services 3. Architecture
The Mesh supports multiple mechanisms for connecting devices to an
account:
o Over a trusted physical link (i.e. a cable).
o Optical exchange (e.g. a QR code). The Mathematical Mesh (Mesh) is a user centered Public Key
Infrastructure that uses cryptography to make computers easier to
use.
o Connection broker service. 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.
Each of these mechanisms provides for strong mutual authentication of The Mesh is based on the principle that if the Internet is to be
the device profile to the personal profile it is being connected to secure, if must become effortless to use applications securely.
and vice versa. In each case, the connection request MUST be Rather than beginning the design process by imagining all the
authorized by the profile owner from a device that has already been possible modes of attack and working out how to address these with
connected to the profile and granted administration privileges. 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.
While the first two mechanisms provide a satisfactory means of 3.1. A Personal PKI
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: 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.
Portal The Portal services support creation of a Mesh Service Processing of Mesh assertions is similar to processing of PKIX
account and management of the owner's Mesh profile. 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.
Catalog The Catalog services support communication of application As in SAML, the basic unit in the Mesh PKI is a signed assertion. A
data between the devices an owner has connected to their profile. Mesh Profile is a self-signed Mesh Assertion. Currently, three types
These include configuration profiles for legacy applications such of Mesh Profile are defined:
as SMTP mail and SSH, lists of contacts, tasks and calendar
entries, and credential storage.
Messaging The messaging services are Mesh services that accept Device Profile Specifies the public keys to be used by a device for
requests that come from third parties. These include the contact Encryption, Signature and Authentication and additional device
request service, the confirmation service and the message service. description information.
The Portal, Catalog and Messaging services are built on a common Master Profile Specifies a master signature key that is used as the
platform that reduces the involvement of the service to the bare axiom of trust for a 'life-long' cryptographic identity and
minimum. All data that is not required to support the service is specifies a set of administration keys authorized to sign Mesh
encrypted. One important (and useful) consequence of this approach assertions on behalf of that identity.
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 Service Profile Binds a Master profile to a Mesh Service account
wasting their time to providing a means of attack, messaging services that acts as a co-ordination service for all the devices connected
SHOULD be either highly constrained to mitigate such attacks or to that profile and a point of presence at which Mesh Messages may
require requests be subjected to access control. The authentication be exchanged with other Mesh Services.
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 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.
The portal service supports Connection Assertion A Mesh Assertion signed by an authorized
administration key binding a device to a Mesh profile by means of
the UDF Content Digest of its Device profile. A device may have
multiple connection assertions for different purposes which may
include authorizations for specific actions (e.g. permission to
read or write specific types of data in a Mesh Service Account).
o Management of Mesh service accounts (account creation, deletion) Device Private Data A DARE Message encrypted under the device
encryption key containing device specific configuration
information allowing it to connect to one of more applications.
o Connection of new devices to a profile 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:
o Publishing profile updates to devices [[This figure is not viewable in this format. The figure is
available at http://mathmesh.com/Documents/draft-hallambaker-mesh-
architecture.html [2].]]
o Storage of key recovery information Alice's Personal PKI
The first step in creating a Mesh service account is to create a Mesh If its purpose requires, a connection assertion MAY be public. This
personal profile if the user doesn't own one already. A user MAY use allows a device to authenticate to Web Services and authenticate
the same profile to register multiple accounts at the same Mesh messages using its embedded public key credentials by presenting a
service and at multiple services. suitable connection assertion.
Having established a profile on their first device, a user will For example, Alice submits an update to a source code repository.
typically connect more devices. Figure XX shows Alice connecting a The device keys are used to authenticate access to the service and
new desktop computer to her profile, the connection request is then sign them. The source code repository only has knowledge of
initiated from the new device (desktop) and approved from the Alice's Master Profile fingerprint but can verify the access request
administration device (tablet). 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 [[This figure is not viewable in this format. The figure is
available at http://mathmesh.com/Documents/draft-hallambaker-mesh- available at http://mathmesh.com/Documents/draft-hallambaker-mesh-
architecture.html [3].]] architecture.html [3].]]
Alice connects a new device. 3.2. Support for Legacy and Future Applications
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:
o An object has an identifier that is unique (within the context of
the container) and immutable.
o An object has a state that is either undefined, active(value) or
inactive. Where value is the value associated with the object in
the active state. An object only has a defined value in the
active state.
o The state of an object is affected by the events create, update
and delete.
o The event create(x) is only valid in the undefined state and
causes the state of the object to become active(x).
o The event update(y) is valid in any state and causes the state of
the object to become active(y).
o The event delete is only valid in the state active() and causes
the state of the object to become inactive.
o The value of the object over time may thus be represented as a
trace of the state values in the CSP or similar models.
A catalog service will accept any request to update the catalog that
is properly authenticated, that is:
o The service request is properly authenticated for that purpose by
the profile associated with the account.
o The updated value is signed by a signature key authorized for that
purpose by the profile associated with the account.
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 The Mesh provides an infrastructure for supporting existing Internet
associated attributes some of which may be identified as serving as security applications and a set security features that may be used to
retrieval keys. build new ones.
Examples of retrieval keys include 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:
o Application identifier [[This figure is not viewable in this format. The figure is
available at http://mathmesh.com/Documents/draft-hallambaker-mesh-
architecture.html [4].]]
o Contact email address The Mesh design is highly modular allowing components that were
originally designed to support a specific requirement within the Mesh
to be applied generally.
o Date and time 3.2.1. Confirmation Protocol
o Geographic location 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.
3.3. Messaging Services 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.
Messaging services are functionally identical to catalog services 3.2.2. Encrypted Authenticated Resource Locators
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: 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.
o Contact request service 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:
o Task service (including calendar appointments) ```` Example ArchitectureConnectEARL ````
o Confirmation service The EARL may be expressed as a QR code:
o Message service
4. Requirements [[This figure is not viewable in this format. The figure is
available at http://mathmesh.com/Documents/draft-hallambaker-mesh-
architecture.html [5].]]
Before the Web, most trade was performed in person. Mail order QR Code representation of the EARL
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 An EARL is resolved by presenting the content digest fingerprint of
drawback: It Authenticates the bank to the customer but it does not the encryption key to a Web service hosted at the specified domain.
authenticate the customer to the bank. The use of passwords instead The service returns a DARE Message whose payload is encrypted and
of strong cryptographic credentials makes users vulnerable to authenticated under the specified master key. Since the content is
phishing. 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.
Design of a public key authentication protocol is straightforward. 3.2.3. Friendly Names
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 Internet addressing schemes are designed to provide a globally unique
enough and they tend to stay in one place (at least until recently). (or at minimum unambiguous) name for a host, service or account. In
Managing private keys for users is much more challenging than the early days of the Internet, this resulted in addresses such as
managing server keys because: 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.
o Users typically own multiple devices and expect them all to work Friendly names provide a user or community specific means of
in the same way. 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.
o User devices are considerably more complex than servers. They The Mesh Contacts Catalog provides a directory mapping friendly names
have many functions. 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.
o Users are more likely to lose devices or lend them to other 3.2.4. Uniform Data Fingerprints.
people.
o Users cannot be expected to be experts. 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.
What has made matters worse is the notion that because users are less The following are examples of UDF values:
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 ```` NAAM-RIUA-RI5L-ASA7-OWSU-2ZOJ-YV4A EDJH-MWNL-ZDNG-YRLW-H2UU-
any form of Internet interaction. In almost every case, the main 4IOB-5NCQ SAQH-PKX2-BAIJ-I7EC-XGAL-7GWT-DDFP-C MB5S-R4AJ-3FBT-7NHO-
constraint that holds us back is the impracticality of using client- T26Z-2E6Y-WFH4 KCM5-7VB6-IJXJ-WKHX-NZQF-OKGZ-EWVN AA3O-LLJI-32OP-
side private keys: 4CJB-WTYI-B34V-PV4H ````
o OpenPGP [RFC4880] 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.
o S/MIME [RFC5751] 3.2.5. Secure Internet Names
o Jabber [RFC6120] 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.
o IPSEC [RFC4301] ```` Example ArchSIN ````
o SSH [RFC4251] 3.3. Cryptography
The SSH protocol supports the use of public key cryptography for All the cryptographic algorithms used in the Mesh are either industry
authentication, of course. But this is the exception that proves the standards or present a work factor that is provably equivalent to an
rule. The use of client side keys in SSH is highly effective for the industry standard approach.
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 Existing Internet security protocols are based on approaches
them do their job in peace. The VPN access token works when they developed in the 1990s when performance tradeoffs were a prime
gain access to the corporate network, SSH works when they gain access consideration in the design of cryptographic protocols. Security was
to the server, passwords work when they can log into their bank Web focused on the transport layer as it provided the best security
site and pay their bills. But when evaluating a security protocol, possible given the available resources.
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 With rare exceptions, most computing devices manufactured in the past
parties. Prevent unauthorized parties inferring confidential ten years offer either considerably more computing power than was
information from traffic analysis. 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.
Integrity Protect data from unauthorized modification. Establish [[This figure is not viewable in this format. The figure is
and verify data authenticity. available at http://mathmesh.com/Documents/draft-hallambaker-mesh-
architecture.html [6].]]
Availability Ensure that data and data services are available when Constrained Devices connected through a Mesh Hub.
needed. Restrict access to authorized parties. Establish
accountability.
While Confidentiality is usually the paramount concern of users, 3.3.1. Best Practice by Default
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 Except where external applications demand otherwise, the Mesh
operational challenges: requires that the following 'best practices' be followed:
Separation of Cryptographic Purpose Each private key SHOULD be used Industry Standard Algorithms All cryptographic protocols make use of
for exactly one cryptographic function. Keys used for encryption the most recently adopted industry standard algorithms.
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. Strongest Work Factor Only the strongest modes of each cipher
algorithm are used. All symmetric encryption is performed with
256-bit session keys and all digest algorithms are used in 512-bit
output length mode.
Key Rotation It SHOULD be possible to periodically refresh keys used Key Hygiene Separate public key pairs are used for all cryptographic
to secure applications, thus ensuring that any compromise of the functions: Encryption, Signature and Authentication. This enables
keying material is time bounded. separate control regimes for the separate functions and
partitioning of cryptographic functions within the application
itself.
Device Isolation Each device SHOULD have separate keys to protect Bound Device Keys Each device has a separate set of Encryption,
applications on that device. This limits the consequences should Signature and Authentication key pairs. These MAY be bound to the
the device be compromised, lost or stolen and permits revocation device to which they are assigned using hardware or other
to be limited to the keys used in that device. techniques to prevent or discourage export.
Key Escrow Whenever a key is used to encrypt static data (i.e. data No Optional Extras Traditional approaches to security have treated
stored on a disk or other storage device), provision MUST be made many functions as being 'advanced' and thus suited for use by only
to permit (but not require) the decryption key to be escrowed to the most sophisticated users. The Mesh rejects this approach
permit recovery should the need arise. noting that all users operate in precisely the same environment
facing precisely the same threats.
Provision of Key Escrow is controversial since any mechanism that 3.3.2. Multi-Level Security
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 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.
Alice works with Bob, Carol, and Doug. As part of her work she 3.3.3. Multi-Party Cryptography
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:
o The ability to send and receive S/MIME end-to-end encrypted email Existing Internet security protocols only make use of cryptographic
with Bob and Carol as per corporate policy. 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.
o The ability to send and receive OpenPGP end-to-end encrypted email For example, Alice uses secure Mesh messaging on her mobile device.
with Doug who does not use S/MIME. 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.
o The ability to connect to Server1, Server2 and Server3 from any of [[This figure is not viewable in this format. The figure is
her personal devices. available at http://mathmesh.com/Documents/draft-hallambaker-mesh-
architecture.html [7].]]
o The ability to quickly configure a new device for her personal Split Key Decryption.
use.
o The ability to quickly disable further use of a device should it This configuration allows the device to be used to decrypt messages
be stolen. 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.
This use case is deliberately limited to configuring Alice's devices Multi-party techniques are also used in key generation. This allows
to enable her to use current security protocols. A large number of an administration application to ensure that devices use key pairs
use cases and applications were considered during the design that are sufficiently random without having access to the private key
including configuring IoT devices in Alice's home and configuring a information itself.
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 [[This figure is not viewable in this format. The figure is
configuring end-to-end email and SSH for herself was configuring end- available at http://mathmesh.com/Documents/draft-hallambaker-mesh-
to-end email and other secure applications for a remote co-worker. architecture.html [8].]]
Meeting these requirements is deferred as a future work item.
4.2. What Makes PKI Hard Key Pair Co-Generation.
Every day, billions of people access Web sites using PKI encryption 3.3.4. Data At Rest 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 The Data At Rest Encryption (DARE) format is used for all
design choices taken by technologists rather than an intrinsic confidentiality and integrity enhancements. The DARE format is based
restriction of PKI. In particular: on the JOSE Signature and Encryption formats and the use of an
extended version of the JSON encoding allowing direct encoding of
binary objects.
o Expiry of private keys and credentials. 3.3.4.1. DARE Message
o Poorly designed enrollment protocols. 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.
o No provision for use of multiple devices. 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.
o Inappropriate trust models. 3.3.4.2. Dare Container
o Intrusive user experience. 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.
S/MIME and other client centered security technologies were added to Containers may be authenticated by means of a Merkle tree of digest
many Internet applications in the 1990s in response to enterprise values on the individual frames. This allows similar demonstrations
requirements. The people who make the purchasing decisions for of integrity to those afforded by Blockchain to be provided but with
enterprise software and those who use it on a daily basis are often much greater efficiency.
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 Unlike traditional encryption formats which require a new public key
very popular email client to make use of the built in S/MIME exchange for each encrypted payload, the DARE Container format allows
capabilities. Even with 25 years of experience, this took over half multiple entries to be encrypted under a single key exchange
an hour and required the user to follow a procedure with 17 different operation. This is particularly useful in applications such as
steps involving three different applications. Even though the encrypting server transaction logs. The server need only perform a
certificate was being issued for use with email, the user had to use single key exchange operation is performed each time it starts to
a Web browser to enroll for the certificate, validate the request establish a master key. The master key is then used to create fresh
using the email client, download the certificate using the Web symmetric keying material for each entry in the log using a unique
browser and then install it using a key management tool. 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.
The bar for security usability is much higher than most security [[This figure is not viewable in this format. The figure is
specialists, even those who focus on security admit. Experience available at http://mathmesh.com/Documents/draft-hallambaker-mesh-
should teach us that the iron law of security usability is that a architecture.html [9].]]
security application that requires the user to think about security
will fail.
It is noted in passing that security usability is not achieved by DARE Container containing a transaction log.
preventing the user seeing the information they need to make their
own security decisions.
4.3. The Devil is in the Deployment 3.3.5. Personal Key Escrow
One of the most important reasons for the failure of PKI applications One of the core objectives of the Mesh is to make data level
has been the failure of PKI applications. As with any communication encryption ubiquitous. While data level encryption provides robust
tool, the value of end-to-end secure email is a function of the size protection of data confidentiality, loss of the ability to decrypt
of the network that can be reached. The community of S/MIME users means data loss.
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 For many Internet users, data availability is a considerably greater
use is the norm and not the vanishingly rare exception. 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.
After a time, failure becomes a self-reinforcing vicious circle. [[This figure is not viewable in this format. The figure is
Very few people use end-to-end secure email applications because they available at http://mathmesh.com/Documents/draft-hallambaker-mesh-
are difficult to use. Application providers refuse to invest in architecture.html [10].]]
developing end-to-end secure email applications because 'there is no
demand'.
The Mesh is designed for deployment by providing a stand-alone value Key escrow and recovery
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 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.
All four of the open standards based PKIs that have been developed in 3.4. Mesh Services
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 Mesh Services provide an 'always available' network presence for one
can be bought for $5 and public key algorithms are available that or more Mesh profiles. This allows a device that is connected to a
provide a higher level of security than was achievable in the 1990s Mesh profile but not always available on the network to receive Mesh
for less computation time. In 1995, the idea that a single user messages from other Mesh users and to share information with other
might need a hundred public key pairs and a personal PKI to manage devices connected to the same profile.
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 The Mesh currently supports eight separate application profiles
have been impractical even for financial applications as recently as through operations on two basic data collection types: Catalogs and
15 years ago. Today, the performance and memory overhead is Spools. Both of which are implemented as DARE containers. This
negligible. 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.
5. Architectural Principles 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.
Over the course of the first quarter century of commercial use of 3.4.1. Catalogs
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 Mesh Catalogs are a DARE Container whose entries represent a set of
consensus but departs from existing practice in certain areas as set objects with no inherent ordering. Examples of Mesh catalogs
out in the following. include:
5.1. User Centered Design Devices The devices connected to the corresponding Mesh profile.
Traditional enterprise centered PKI keeps the enterprise (and to an Contacts Logical and physical contact information for people and
extent the users) secure but only as long as the users follow a long organizations.
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 Bookmarks Web bookmarks and citations.
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. Credentials Username and password information for network resources.
One of the principal ideological battles that has been fought in the Calendar Appointments and tasks.
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 Network Network access configuration information allowing access to
attempting to apply these models to real world applications is that WiFi networks and VPNs.
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 Application Configuration information for applications including
context in which it is to be used. If Alice is sending Bob a mail (SMTP, IMAP, OpenPGP, S/MIME, etc) and SSH.
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 The first two of these catalogs have special functions within the
does not impose a model for mapping human to machine interaction Mesh. The Devices Catalog tracks the devices connected to a Mesh
identifiers but it does allow the user to put that mapping under Profile and the Contacts Catalog is used to support the use of
their personal control. Devices connected to a Mesh Personal Profile Friendly Names in place of Internet addresses and to perform access
share the same view of the world; the same set of bookmarks and control on inbound messages.
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 3.4.2. Spools
discovery. The credential issued by the CA is verified each time the
user visits the site.
[[This figure is not viewable in this format. The figure is Mesh Spools are DARE Container whose entries comprise a sequence of
available at http://mathmesh.com/Documents/draft-hallambaker-mesh- Mesh Messages.
architecture.html [4].]]
Traditional PKI role. The inbound spool contains Messages received from other parties and
the outbound spool contains Messages queued to be sent to other Mesh
users.
In the Mesh trust model, the primary role of the CA is to provide The Mesh Messaging model enforces a four-corner approach in which all
introductions. When the user first visits the site, to buy goods, messages exchanged between devices pass through an inbound and
the site (and often the vendor it belongs to) is unknown. At this outbound Mesh Service. This approach permits ingress and egress
point, the user is looking to the Authority to help decide if they controls to be enforced on the messages and that every message is
wish to purchase from. properly recorded in the appropriate spools.
[[This figure is not viewable in this format. The figure is [[This figure is not viewable in this format. The figure is
available at http://mathmesh.com/Documents/draft-hallambaker-mesh- available at http://mathmesh.com/Documents/draft-hallambaker-mesh-
architecture.html [5].]] architecture.html [11].]]
Trusted Authority as Introducer 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.
Once users can easily maintain a personal directory of trusted This approach makes transfers of very large data sets (i.e. multiple
vendors and share it across all the devices they use, their personal Terabytes) practical as the 'push' phase of the protocol is limited
trust directory becomes their primary trust provider. Thus, the role to the transfer of the initial control message. The bulk transfer is
of the authority changes once a trust relationship has been implemented as a 'pull' protocol allowing support for features such
established from trust provider to trust revoker. The user does not as continuous integrity checking and resumption of an interrupted
need the authority to tell them to trust a vendor they are already transfer.
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 3.4.3. Future Applications
One of the main difficulties in using S/MIME for email security is Since a wide range of network applications may be reduced to
that many users stop using the system when their certificate expires. synchronization of sets and lists, the basic primitives of Catalogs
It is likely that one of the main reasons that OpenPGP is more and Spools may be applied to apply end-to-end security to an even
popular amongst system administrators is that a maintenance-free user wider variety of applications.
experience is available to anyone who decides to neglect key
rollover.
A Mesh Master Profile fingerprint is designed to provide a user with For example, a Spool may be used to maintain a mailing list, track
a credential that can be used for a lifetime. Using the same comments on a Web forum or record annotations on a document.
offline/online key management approaches that have been applied to Encrypting the container entries under a multi-party encryption group
root key management in the WebPKI since it began provides users with allows such communications to be shared with a group of users while
a credential with a cryptographic lifetime of 20-30 years. The maintaining full end-to-end security and without requiring every
addition of linked notary log technology in the Mesh Portals allows party writing to the spool to know the public encryption key of every
such credentials to be securely renewed should the need arise and recipient.
thus enabling indefinite use.
5.4. Eliminate unnecessary options 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.
Traditionally cryptographic applications give the user a bewildering 4. User Experience
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 This section describes the Mesh in use. These use cases described
required by an application, the Mesh always uses separate keys for here are re-visited in the companion Mesh Schema Reference
encryption and signature operations and only uses the highest [draft-hallambaker-mesh-schema] and Mesh Protocol Reference
strength on offer. Currently, Mesh profiles are always encrypted [draft-hallambaker-mesh-protocol] with additional examples and
using RSAES-PKCS1-v1_5 with a 2048 bit key [RFC8017] , AES with a 256 details.
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. For clarity and for compactness, these use cases are illustrated
The use of key escrow by applications is optional, but every profile using the command line tool meshman.
has the capability of using it should circumstances require.
5.5. Strong Public Key Identifiers 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.
A key departure from traditional PKI approaches is that all The key to meeting this constraint is that any set of instructions
cryptographic keys are identified in every circumstance by either the that can be written down to be followed by a user can be turned into
UDF fingerprint of the public key in the case of a public key pair or code and executed by machine. Provided that the necessary
the UDF fingerprint of the symmetric key in the case of a symmetric authentication, integrity and confidentiality controls are provided.
key pair. No other form of key identifier is used. 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.
This approach greatly simplifies the processes of key discovery, The user experience is thus at the heart of the design of the Mesh
management and signature verification. and a description of the Mesh Architecture properly begins with
consideration of the view of the system that matters most: that of
the user.
Since a UDF fingerprint of sufficient length, uniquely identifies a The principle security protocols in use today were designed at a time
public key pair, it follows that if the attempt to verify the when most Internet users made use of either a single machine or one
signature under a public key whose fingerprint matches that specified of a number of shared machines connected to a shared file store. The
returns the result false, that the signature is invalid. Contrawise, problem of transferring cryptographic keys and configuration data
if the result returned is true, the data is validly signed for a between machines was rarely considered and when it was considered was
given purpose if and only if the key identifier is authorized for usually implemented badly. Today the typical user owns or makes use
that purpose. 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).
6. Mesh Profiles [[This figure is not viewable in this format. The figure is
available at http://mathmesh.com/Documents/draft-hallambaker-mesh-
architecture.html [12].]]
All information exchanged through the Mesh is described in a profile. 4.1. Creating and Registering a Mesh Profile
Profiles have the following properties.
o Profiles are first class objects with a unique, immutable The first step in using the Mesh is to create a personal profile.
identifier that either is or contains a UDF fingerprint of a From the user's point of view a profile is a collection of all the
signature key configuration data for all the Mesh enabled devices and services that
they interact with.
o All profiles are digitally signed. ```` Example ArchitectureCreate ````
o Profiles are encoded in JSON [RFC7159] . 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.
At present, four types of Mesh Profile are defined: 4.2. Mesh Service
Master Profile Describes the criteria for validating a user's A Mesh Service provides an 'always available' point of presence that
personal profile. is used to exchange data between devices connected to the connected
profile and send and receive Mesh Messages to and from other Mesh
users.
Personal Profile Describes the user's personal Trust Mesh, the set To use a Mesh Service, a user creates a Mesh Service account. This
of device and application profiles connected to it. 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.
Application Profile Describes the use of a particular application. 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:
Device Profile Describes a device and cryptographic keys specific to ```` Example ArchitectureRegister ````
that device.
A profile is Valid if and only if it is Verified, Current and As with any other Internet service provision, Mesh Service providers
Correct: 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.
Verified A signature is verified if the key identifier specified 4.3. Mesh Catalogs
maps to a
Current A profile is current if and only if it has not been A Mesh Catalog contains a set of entries, each of which has a unique
superseded by a new profile published to the Mesh Portal. object identifier. Catalog entries may be added, updated or deleted.
Correct A profile is correct if the signing key identifier specified By default, all catalog entries are encrypted. Applying the Default
in the signature data is a legitimate signing key for that type of Deny principle, in normal circumstances, the Mesh Service is not
profile as specified in Section YY below. 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.
A profile is connected to a personal profile if and only if: 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:
o The Personal Profile contains an entry for its profile identifier ```` Example ArchitectureCredential ````
that is consistent with the profile type.
o The Personal Profile is Valid. 4.4. Connecting and Authorizing Additional Devices
o The Application Profile is Valid. 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.
This trust model allows Application Profiles and Device Profiles to Although any type of network capable device may be connected to a
be connected to a Personal Profile by enumerating the identifiers of Mesh profile, some devices are better suited for use with certain
the connected profile in the personal profile. 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.
[[This figure is not viewable in this format. The figure is Three connection mechanisms are currently specified, each of which
available at http://mathmesh.com/Documents/draft-hallambaker-mesh- provides strong mutual authentication: Direct, PIN and QR.
architecture.html [6].]]
A Master/Personal Profile connected to Application and Device Since approval of a connection request requires the creation of a
profiles. 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.
6.1. Master and Personal Profiles 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'.
Each Mesh user has a Master Profile and a Personal Profile. 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.
Personal Profile Contains a list of all the device profiles and 4.4.1. Direct Connection
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 The direct connection mechanism requires that both the administration
personal profiles and the master signature key used to sign the device and the device originating the connection request have data
Master Profile. 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.
The use of master signature keys and administration keys to ```` Example ArchitectureConnectDirect ````
authenticate the Master and Personal profiles needs further
explanation.
[[This figure is not viewable in this format. The figure is 4.4.2. Pin Connection
available at http://mathmesh.com/Documents/draft-hallambaker-mesh-
architecture.html [7].]]
Master and Personal Profile Signature The PIN Connection mechanism is similar to the Direct connection
This separation allows the user to add devices and/or change mechanism except that the process is initiated on an administration
application settings frequently without the need for changes to their device by requesting assignment of a new authentication PIN. The PIN
master profile or to access their master signature key. This allows is then input to the connecting device to authenticate the request.
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 ```` Example ArchitectureConnectPIN ````
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 If the Device Profile fingerprint is known at the time the PIN is
fingerprint of the master signature key is a persistent identifier generated, this can be bound to the PIN authorization assertion to
that will remain constant and only ever refer to exactly one Master permit connection of a specific device.
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 4.4.3. EARL/QR Code Connection
A device profile contains a description of the device and the public The EARL/QR code connection mechanisms are used to connect a
keys to be used as the basis for encryption, authentication and constrained device to a Mesh profile by means of an Encrypted
signature on that device (Figure XXX). Ideally, the private keys Authenticated Resource Locator, typically presented as a QR code on
associated with the device are generated using a secure procedure on the device itself or its packaging.
the device itself and are bound to the device so that they cannot be
exported from it.
[[This figure is not viewable in this format. The figure is [[This figure is not viewable in this format. The figure is
available at http://mathmesh.com/Documents/draft-hallambaker-mesh- available at http://mathmesh.com/Documents/draft-hallambaker-mesh-
architecture.html [8].]] architecture.html [13].]]
Since the meshman tool does not support QR input, it is decoded using
Device Profile a separate tool to recover the UDF EARL which is presented as a
command line parameter:
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 ```` Example ArchitectureConnectQR ````
of profile as follows:
Master Profile The Key Identifier of the key that signs the profile 4.5. Contact Requests
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 As previously stated, every inbound Mesh message is subject to access
profile MUST be listed as the identifier of an Administrator Key control. The user's contact catalog is used as part of the access
specified in the corresponding Master Profile. control authentication and authorization mechanism.
Device Profile The Key Identifier of the key that signs the profile By default, the only form of inbound message that is accepted without
MUST be the UDF fingerprint of the Device Signature Key specified authorization in the contact catalog is a contact request. Though
in that Device Profile. 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).
Application Profile The Key Identifier of the key that signs the A Mesh Contact Assertion may be limited to stating the user's profile
profile MUST be listed as the identifier of an Administrator key fingerprint and Mesh Service Account(s). For most purposes however,
for that Application Profile in the corresponding Personal it is more convenient to present a Contact Assertion that contains at
Profile. least as much information as is typically provided on a business or
calling card:
6.5. Key Escrow and Recovery ```` Example ArchitectureContactDefinition ````
Key Escrow and Recovery capabilities are built into the core of the User's may create multiple Contact Assertions for use in different
Mesh. Use of these capabilities is RECOMMENDED but not required. circumstances. A user might not want to give their home address to a
business contact or their business address to a personal friend.
Encryption of stored data such as email messages and personal 4.5.1. Remote
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. In the most general case, the participants are remote from each other
and one user must make a contact request of the other:
Offline Key Escrow Is used to escrow Master Signature Keys, Master ```` Example ArchitectureContactRequest ````
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 4.5.2. Static QR Code
key under a Master Escrow Key.
6.5.1. Offline Escrow 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:
The use of Shamir Secret Sharing [ShamirXX] to escrow private keys is ```` Example ArchitectureContactQR ````
supported as follows:
o A 256 bit random session key is generated. The resulting QR code may be printed on a business card, laser
engraved on a luggage tag, etc.
o The private key and related data is encrypted under the session [[This figure is not viewable in this format. The figure is
key to form the key escrow data blob. available at http://mathmesh.com/Documents/draft-hallambaker-mesh-
architecture.html [14].]]
o The unique identifier for the key escrow data blob is the UDF QR Code representation of the EARL
fingerprint of the session key.
o The key escrow data blob is stored in some form of persistent To accept the contact request, the recipient merely scans the code
storage that is believed to provide a very high degree of with a Mesh capable QR code reader. They are asked if they wish to
availability. accept the contact request and what privileges they wish to authorize
for the new contact.
o The session key is split into n of m shares using Shamir secret 4.5.3. Dynamic QR Code
sharing.
Since the purpose of the Mesh Portal is in part to provide a high If it is possible for the device to generate a new QR code for the
availability data storage facility, the use of the Mesh to store the contact request, it is possible to support bi-directional exchange of
key recovery blob is preferred. credentials with strong mutual authentication.
Data recovery is the reverse of the escrow process: 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.
o The shared secret is recovered from at least n of the key shares. 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.
o The unique identifier for the key escrow data blob is calculated 4.6. Storing and Sharing Data in the Cloud
from the session key
o The unique identifier is used to retrieve the key recovery blob. 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.
o The key recovery blob is decrypted using the session key. 4.6.1. EARL Exchange
It will be noted that this process is anonymous. The key recovery An EARL is a form of URI that specifies a means of locating and
blob does not identify the profile or user to which it refers in any decrypting a DARE Message stored on a Web Service.
way.
6.5.2. Online Escrow [[This figure is not viewable in this format. The figure is
available at http://mathmesh.com/Documents/draft-hallambaker-mesh-
architecture.html [15].]]
Support for Online escrow requires only that decryption keys for Preparing data for delivery using an EARL is a task more typically
application use be encrypted under the master escrow key as if it was performed by a document management system than an individual user.
another device connected to a Personal Profile.
7. The CryptoMesh 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:
As described earlier, a Mesh Portal Service is an untrusted cloud ```` Example ArchitectureEARL ````
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 4.6.2. Encryption Groups
makes use of account identifiers in the traditional [RFC5322] format
<user>@<domain>. Transactions supported by the Portal Protocol
include:
o Create Account 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.
o Add profile 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.
o Update profile [[This figure is not viewable in this format. The figure is
available at http://mathmesh.com/Documents/draft-hallambaker-mesh-
architecture.html [16].]]
o Request device connection* 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.
o View pending requests* ```` 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.
o Accept or reject a connection request* 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).
Transactions marked with an asterisk* require administration Thus, if the set of administrators is A, B and C and the private key
privileges for the personal profile. 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).
Although the Mesh Architecture regards the Mesh Portal to be an 4.7. Escrow and Recovery of Keys
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 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.
A Mesh Portal MAY belong to a Federation. Portals belonging to a The use of a 'life-long' Mesh profiles raises a similar concern.
Federation periodically synchronize their transaction logs so that Loss of a Master Signature Key potentially means the loss of the
all the members of the federation have access to the complete set of ability to control devices connected to the profile and the
transaction logs for all the portals belonging to the federation. accumulated trust endorsements of other users.
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. 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.
The CryptoMesh is proposed open federation of Mesh Portals that Users may use the key escrow mechanism of their choice including the
permits any portal willing to accept its terms of service to join. 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.
Due to the nature of the network effect it is expected that there To escrow a key set, the user specifies the number of key shares to
would be only one such open federation baring major disagreements as be created and the number required for recovery.
to terms of service. Figure XXX
[[This figure is not viewable in this format. The figure is ```` Example ArchitectureEscrow ````
available at http://mathmesh.com/Documents/draft-hallambaker-mesh- Recovery of the key data requires the key recovery record and a
architecture.html [9].]] quorum of the key shares:
The Cryptomesh. ```` Example ArchitectureRecovery ````
Mesh Portals that are a member of a Federation have a mutual Having recovered the Master Signature Key, the user can now create a
responsibility to protect availability by acting to mitigate abuse by new master profile authorizing a new administration device which can
users attempting to create excessive numbers of profiles or perform be used to authenticate access to the Mesh Service Account(s)
excessive numbers of updates. connected to the master profile.
8. Security Considerations 5. Security Considerations
NYI The security considerations for use and implementation of Mesh
services and applications are described in the Mesh Security
Considerations guide [draft-hallambaker-mesh-security] .
9. IANA Considerations 6. IANA Considerations
This document does not contain actions for IANA This document does not contain actions for IANA
10. Acknowledgements 7. Acknowledgements
Comodo Group: Egemen Tas, Melhi Abdulhayo?lu, Rob Stradling, Robin Comodo Group: Egemen Tas, Melhi Abdulhayo?lu, Rob Stradling, Robin
Alden. Alden.
11. References 8. References
11.1. Normative References 8.1. Normative References
[draft-hallambaker-dare-container] [draft-hallambaker-jsonbcd]
Hallam-Baker, P., "Data At Rest Encryption Part 2: DARE Hallam-Baker, P., "Binary Encodings for JavaScript Object
Container", draft-hallambaker-dare-container-02 (work in Notation: JSON-B, JSON-C, JSON-D", draft-hallambaker-
progress), August 2018. jsonbcd-13 (work in progress), July 2018.
[draft-hallambaker-dare-message] [draft-hallambaker-mesh-algorithms]
Hallam-Baker, P., "Data At Rest Encryption Part 1: DARE "[Reference Not Found!]".
Message Syntax", draft-hallambaker-dare-message-02 (work
in progress), August 2018.
[draft-hallambaker-json-web-service] [draft-hallambaker-mesh-dare]
Hallam-Baker, P., "JSON Web Service Binding Version 1.0", Hallam-Baker, P., "Mathematical Mesh Part III : Data At
draft-hallambaker-json-web-service-10 (work in progress), Rest Encryption (DARE)", draft-hallambaker-mesh-dare-00
April 2018. (work in progress), February 2019.
[draft-hallambaker-mesh-developer] [draft-hallambaker-mesh-developer]
Hallam-Baker, P., "Mathematical Mesh: Reference Hallam-Baker, P., "Mathematical Mesh: Reference
Implementation", draft-hallambaker-mesh-developer-07 (work Implementation", draft-hallambaker-mesh-developer-07 (work
in progress), April 2018. in progress), April 2018.
[draft-hallambaker-mesh-platform] [draft-hallambaker-mesh-platform]
Hallam-Baker, P., "Mathematical Mesh: Platform Hallam-Baker, P., "Mathematical Mesh: Platform
Configuration", draft-hallambaker-mesh-platform-03 (work Configuration", draft-hallambaker-mesh-platform-03 (work
in progress), April 2018. in progress), April 2018.
[draft-hallambaker-mesh-reference] [draft-hallambaker-mesh-protocol]
Hallam-Baker, P., "Mathematical Mesh: Reference", draft- "[Reference Not Found!]".
hallambaker-mesh-reference-09 (work in progress), April
2018.
[draft-hallambaker-sin] [draft-hallambaker-mesh-schema]
Hallam-Baker, P., "Strong Internet Names (SIN)", draft- "[Reference Not Found!]".
hallambaker-sin-03 (work in progress), April 2018.
[draft-hallambaker-udf] [draft-hallambaker-mesh-security]
Hallam-Baker, P., "Uniform Data Fingerprint (UDF)", draft- "[Reference Not Found!]".
hallambaker-udf-10 (work in progress), April 2018.
[draft-hallambaker-mesh-trust]
Hallam-Baker, P., "Mathematical Mesh Part IV: The Trust
Mesh", draft-hallambaker-mesh-trust-00 (work in progress),
January 2019.
[draft-hallambaker-mesh-udf]
Hallam-Baker, P., "Mathematical Mesh Part II: Uniform Data
Fingerprint.", draft-hallambaker-mesh-udf-01 (work in
progress), February 2019.
[draft-hallambaker-web-service-discovery]
Hallam-Baker, P., "DNS Web Service Discovery", draft-
hallambaker-web-service-discovery-01 (work in progress),
February 2019.
[FIPS197] "[Reference Not Found!]". [FIPS197] "[Reference Not Found!]".
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997. DOI 10.17487/RFC2119, March 1997.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008. DOI 10.17487/RFC5246, August 2008.
skipping to change at page 29, line 5 skipping to change at page 27, line 12
(HTTP/1.1): Semantics and Content", RFC 7231, (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014. DOI 10.17487/RFC7231, June 2014.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015. 2015.
[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
RFC 7516, DOI 10.17487/RFC7516, May 2015. RFC 7516, DOI 10.17487/RFC7516, May 2015.
[RFC8017] Moriarty, K., Kaliski, B., Jonsson, J., and A. Rusch,
"PKCS #1: RSA Cryptography Specifications Version 2.2",
RFC 8017, DOI 10.17487/RFC8017, November 2016.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032, Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017. DOI 10.17487/RFC8032, January 2017.
[SHA-2] NIST, "Secure Hash Standard", August 2015. [SHA-2] NIST, "Secure Hash Standard", August 2015.
[SHA-3] Dworkin, M., "SHA-3 Standard: Permutation-Based Hash and [SHA-3] Dworkin, M., "SHA-3 Standard: Permutation-Based Hash and
Extendable-Output Functions", August 2015. Extendable-Output Functions", August 2015.
[ShamirXX] 8.2. URIs
"[Reference Not Found!]".
11.2. Informative References
[BLOCKCHAIN]
Chain.com, "Blockchain Specification".
[PHB-CoKey]
"[Reference Not Found!]".
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251,
January 2006.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005.
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
Thayer, "OpenPGP Message Format", RFC 4880,
DOI 10.17487/RFC4880, November 2007.
[RFC5322] Resnick, P., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, DOI 10.17487/RFC5751, January
2010.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120,
March 2011.
11.3. URIs
[1] http://mathmesh.com/Documents/draft-hallambaker-mesh- [1] http://mathmesh.com/Documents/draft-hallambaker-mesh-
architecture.html architecture.html
[2] http://mathmesh.com/Documents/draft-hallambaker-mesh- [2] http://mathmesh.com/Documents/draft-hallambaker-mesh-
architecture.html architecture.html
[3] http://mathmesh.com/Documents/draft-hallambaker-mesh- [3] http://mathmesh.com/Documents/draft-hallambaker-mesh-
architecture.html architecture.html
skipping to change at page 30, line 34 skipping to change at page 27, line 50
[7] http://mathmesh.com/Documents/draft-hallambaker-mesh- [7] http://mathmesh.com/Documents/draft-hallambaker-mesh-
architecture.html architecture.html
[8] http://mathmesh.com/Documents/draft-hallambaker-mesh- [8] http://mathmesh.com/Documents/draft-hallambaker-mesh-
architecture.html architecture.html
[9] http://mathmesh.com/Documents/draft-hallambaker-mesh- [9] http://mathmesh.com/Documents/draft-hallambaker-mesh-
architecture.html architecture.html
[10] http://mathmesh.com/Documents/draft-hallambaker-mesh-
architecture.html
[11] http://mathmesh.com/Documents/draft-hallambaker-mesh-
architecture.html
[12] http://mathmesh.com/Documents/draft-hallambaker-mesh-
architecture.html
[13] http://mathmesh.com/Documents/draft-hallambaker-mesh-
architecture.html
[14] http://mathmesh.com/Documents/draft-hallambaker-mesh-
architecture.html
[15] http://mathmesh.com/Documents/draft-hallambaker-mesh-
architecture.html
[16] http://mathmesh.com/Documents/draft-hallambaker-mesh-
architecture.html
Author's Address Author's Address
Phillip Hallam-Baker Phillip Hallam-Baker
Comodo Group Inc.
Email: philliph@comodo.com Email: phill@hallambaker.com
 End of changes. 244 change blocks. 
992 lines changed or deleted 871 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/