idnits 2.17.1 draft-hallambaker-mesh-architecture-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (27 July 2020) is 1366 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. M. Hallam-Baker 3 Internet-Draft ThresholdSecrets.com 4 Intended status: Informational 27 July 2020 5 Expires: 28 January 2021 7 Mathematical Mesh 3.0 Part I: Architecture Guide 8 draft-hallambaker-mesh-architecture-14 10 Abstract 12 The Mathematical Mesh 'The Mesh' is an end-to-end secure 13 infrastructure that makes computers easier to use by making them more 14 secure. The Mesh provides a set of protocol and cryptographic 15 building blocks that enable encrypted data stored in the cloud to be 16 accessed, managed and exchanged between users with the same or better 17 ease of use than traditional approaches which leave the data 18 vulnerable to attack. 20 This document provides an overview of the Mesh data structures, 21 protocols and examples of its use. 23 [Note to Readers] 25 Discussion of this draft takes place on the MATHMESH mailing list 26 (mathmesh@ietf.org), which is archived at 27 https://mailarchive.ietf.org/arch/search/?email_list=mathmesh. 29 This document is also available online at 30 http://mathmesh.com/Documents/draft-hallambaker-mesh- 31 architecture.html. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 28 January 2021. 50 Copyright Notice 52 Copyright (c) 2020 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 2.1. Related Specifications . . . . . . . . . . . . . . . . . 6 66 2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 6 67 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 6 68 2.4. Implementation Status . . . . . . . . . . . . . . . . . . 6 69 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 7 70 3.1. A Personal PKI . . . . . . . . . . . . . . . . . . . . . 9 71 3.1.1. Device Management . . . . . . . . . . . . . . . . . . 9 72 3.1.2. Exchange of trusted credentials. . . . . . . . . . . 10 73 3.1.3. Application configuration management . . . . . . . . 10 74 3.1.4. The Mesh as platform . . . . . . . . . . . . . . . . 11 75 3.2. Mesh Architecture . . . . . . . . . . . . . . . . . . . . 11 76 3.2.1. Mesh Device Management . . . . . . . . . . . . . . . 12 77 3.2.2. Mesh Account . . . . . . . . . . . . . . . . . . . . 13 78 3.2.3. Mesh Service . . . . . . . . . . . . . . . . . . . . 15 79 3.2.4. Mesh Messaging . . . . . . . . . . . . . . . . . . . 15 80 3.3. Using the Mesh with Applications . . . . . . . . . . . . 16 81 3.3.1. Contact Exchange . . . . . . . . . . . . . . . . . . 17 82 3.3.2. Confirmation Protocol . . . . . . . . . . . . . . . . 17 83 3.3.3. Future Applications . . . . . . . . . . . . . . . . . 17 84 4. Mesh Cryptography . . . . . . . . . . . . . . . . . . . . . . 18 85 4.1. Best Practice by Default . . . . . . . . . . . . . . . . 19 86 4.2. Multi-Level Security . . . . . . . . . . . . . . . . . . 19 87 4.3. Multi-Key Decryption . . . . . . . . . . . . . . . . . . 19 88 4.4. Multi-Party Key Generation . . . . . . . . . . . . . . . 20 89 4.5. Data At Rest Encryption . . . . . . . . . . . . . . . . . 20 90 4.5.1. DARE Envelope . . . . . . . . . . . . . . . . . . . . 21 91 4.5.2. Dare Container . . . . . . . . . . . . . . . . . . . 21 92 4.6. Uniform Data Fingerprints. . . . . . . . . . . . . . . . 22 93 4.6.1. Friendly Names . . . . . . . . . . . . . . . . . . . 22 94 4.6.2. Encrypted Authenticated Resource Locators . . . . . . 23 95 4.6.3. Secure Internet Names . . . . . . . . . . . . . . . . 24 96 4.7. Personal Key Escrow . . . . . . . . . . . . . . . . . . . 24 97 5. User Experience . . . . . . . . . . . . . . . . . . . . . . . 25 98 5.1. Creating a Mesh Profile and Administration Device. . . . 26 99 5.2. Mesh Accounts . . . . . . . . . . . . . . . . . . . . . . 27 100 5.3. Using a Mesh Service . . . . . . . . . . . . . . . . . . 27 101 5.4. Connecting and Authorizing Additional Devices . . . . . . 28 102 5.4.1. Direct Connection . . . . . . . . . . . . . . . . . . 29 103 5.4.2. Pin Connection . . . . . . . . . . . . . . . . . . . 30 104 5.4.3. EARL/QR Code Connection . . . . . . . . . . . . . . . 31 105 5.5. Contact Requests . . . . . . . . . . . . . . . . . . . . 32 106 5.5.1. Remote . . . . . . . . . . . . . . . . . . . . . . . 32 107 5.5.2. Static QR Code . . . . . . . . . . . . . . . . . . . 33 108 5.5.3. Dynamic QR Code . . . . . . . . . . . . . . . . . . . 33 109 5.6. Sharing Confidential Data in the Cloud . . . . . . . . . 34 110 5.7. Escrow and Recovery of Keys . . . . . . . . . . . . . . . 37 111 6. Security Considerations . . . . . . . . . . . . . . . . . . . 37 112 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 113 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 114 9. Normative References . . . . . . . . . . . . . . . . . . . . 38 116 1. Introduction 118 The Mathematical Mesh (Mesh) is a user centered Public Key 119 Infrastructure that uses cryptography to make computers easier to 120 use. The Mesh provides an infrastructure that addresses the three 121 concerns that have proved obstacles to the use of end-to-end security 122 in computer applications: 124 * Device management. 126 * Exchange of trusted credentials. 128 * Application configuration management. 130 The infrastructure developed to address these original motivating 131 concerns can be used to facilitate deployment and use of existing 132 security protocols (OpenPGP, S/MIME, SSH) and as a platform for 133 building end-to-end secure network applications. Current Mesh 134 applications include: 136 * Multi-factor authentication and confirmation 138 * Credential management 140 * Bookmark/Citation management 142 * Task and workflow management 143 A core principle of the design of the Mesh is that each person is 144 their own source of authority. They may choose to delegate that 145 authority to another to act on their behalf (i.e. a Trusted Third 146 Party) and they may choose to surrender parts of that authority to 147 others (e.g. an employer) for limited times and limited purposes. 149 Thus, from the user's point of view, the Mesh is divided into two 150 parts. The first and most important of these from their point of 151 view being their own personal Mesh. The second being the ensemble of 152 every Mesh to which their Mesh is connected. As with the Internet, 153 which is a network of networks, a Mesh of Meshes has certain 154 properties that are similar to those of its constituent parts and 155 some that are very different. 157 This document is not normative. It provides an overview of the Mesh 158 comprising a description of the architecture, and a discussion of 159 typical use cases and requirements. The remainder of the document 160 series provides a summary of the principal components of the Mesh 161 architecture and their relationship to each other. 163 Normative descriptions of the individual Mesh encodings, data 164 structures and protocols are provided in separate documents 165 addressing each component in turn. 167 The currently available Mesh document series comprises: 169 I. Architecture (This document.) Provides an overview of the Mesh 170 as a system and the relationship between its constituent parts. 172 II. Uniform Data Fingerprint [draft-hallambaker-mesh-udf]. Describe 173 s the UDF format used to represent cryptographic nonces, keys and 174 content digests in the Mesh and the use of Encrypted Authenticated 175 Resource Locators (EARLs) and Strong Internet Names (SINs) that 176 build on the UDF platform. 178 III. Data at Rest Encryption [draft-hallambaker-mesh-dare]. Describ 179 es the cryptographic message and append-only sequence formats used 180 in Mesh applications and the Mesh Service protocol. 182 IV. Schema Reference [draft-hallambaker-mesh-schema]. Describes the 183 syntax and semantics of Mesh Profiles, Container Entries and Mesh 184 Messages and their use in Mesh Applications. 186 V. Protocol Reference [draft-hallambaker-mesh-protocol]. Describes 187 the Mesh Service Protocol. 189 VI. The Trust Mesh [draft-hallambaker-mesh-trust]. Describes the 190 social work factor metric used to evaluate the effectiveness of 191 different approaches to exchange of credentials between users and 192 organizations in various contexts and argues for a hybrid approach 193 taking advantage of direct trust, Web of Trust and Trusted Third 194 Party models to provide introductions. 196 VII. Security Considerations [draft-hallambaker-mesh-security] Desc 197 ribes the security considerations for the Mesh protocol suite. 199 VIII Cryptographic Algorithms 200 [draft-hallambaker-mesh-cryptography]. Describes the recommended and 201 required algorithm suites for Mesh applications and the 202 implementation of the multi-party cryptography techniques used in 203 the Mesh. 205 The following documents describe technologies that are used in the 206 Mesh but do not form part of the Mesh specification suite: 208 JSON-BCD Encoding [draft-hallambaker-jsonbcd]. Describes extensions 209 to the JSON serialization format to allow direct encoding of 210 binary data (JSON-B), compressed encoding (JSON-C) and extended 211 binary data encoding (JSON-D). Each of these encodings is a 212 superset of the previous one so that JSON-B is a superset of JSON, 213 JSON-C is a superset of JSON-B and JSON-D is a superset of JSON-C. 215 DNS Web Service Discovery 216 [draft-hallambaker-web-service-discovery]. Describes the means by 217 which prefixed DNS SRV and TXT records are used to perform 218 discovery of Web Services. 220 The following documents describe aspects of the Mesh Reference 221 implementation: 223 Mesh Developer [draft-hallambaker-mesh-developer]. Describes the 224 reference code distribution license terms, implementation status 225 and currently supported functions. 227 Mesh Platform [draft-hallambaker-mesh-platform]. Describes how 228 platform specific functionality such as secure key storage and 229 trustworthy computing features are employed in the Mesh. 231 2. Definitions 233 This section presents the related specifications and standards on 234 which the Mesh is built, the terms that are used as terms of art 235 within the Mesh protocols and applications and the terms used as 236 requirements language. 238 2.1. Related Specifications 240 Besides the documents that form the Mesh core, the Mesh makes use of 241 many existing Internet standards, including: 243 Cryptographic Algorithms The RECOMMENDED and REQUIRED cryptographic 244 algorithms for Mesh implementations are specified in 245 [draft-hallambaker-mesh-cryptography]. 247 In addition Mesh Devices used to administer non-Mesh applications 248 must support the cryptographic algorithm suites specified by the 249 application. 251 Transport All Mesh Services make use of multiple layers of security. 252 Protection against traffic analysis and metadata attacks are 253 provided by use of Transport Layer Security [RFC5246]. At 254 present, the HTTP/1.1 [RFC7231] protocol is used to provide 255 framing of transaction messages. 257 Encoding All Mesh protocols and data structures are expressed in the 258 JSON data model and all Mesh applications accept data in standard 259 JSON encoding [RFC7159]. The JOSE Signature [RFC7515] and 260 Encryption [RFC7516] standards are used as the basis for object 261 signing and encryption. 263 2.2. Defined Terms 265 TBS 267 2.3. Requirements Language 269 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 270 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 271 document are to be interpreted as described in RFC 2119 [RFC2119]. 273 2.4. Implementation Status 275 The implementation status of the reference code base is described in 276 the companion document [draft-hallambaker-mesh-developer]. 278 The examples in this document were created on 7/27/2020 9:45:34 AM. 279 Out of 167 examples, 74 were not functional. 281 [Note: Example data is now being produced using the mesh command line 282 tool which is currently substantially less complete than the Mesh 283 reference code it is intended to provide an interface to. As a 284 result, the documentation currently lags the code by more than is 285 usual.] 287 3. Architecture 289 The Mathematical Mesh (Mesh) is a user centered Public Key 290 Infrastructure that uses cryptography to make computers easier to 291 use. This document describes version 3.0 of the Mesh architecture 292 and protocols. 294 For several decades, it has been widely noted that most users are 295 either unwilling or unable to make even the slightest efforts to 296 protect their security, still less those of other parties. Yet 297 despite this observation being widespread, the efforts of the IT 298 security community have largely focused on changing this user 299 behavior rather that designing applications that respect it. Real 300 users have real work to do and have neither the time nor the 301 inclination to use tools that will negatively impact their 302 performance. 304 The Mesh is based on the principle that if the Internet is to be 305 secure, if must become effortless to use applications securely. 306 Rather than beginning the design process by imagining all the 307 possible modes of attack and working out how to address these with 308 the least possible inconvenience, we must reverse the question and 309 ask how much security can be provided without requiring any effort on 310 the user's part to address it. 312 Today's technology requires users to put their trust in an endless 313 variety of devices, software and services they cannot fully 314 understand let alone control. Even the humble television of the 315 20^(th) century has been replaced by a 'smart' TV with 15 million 316 lines of code. Whose undeclared capabilities may well include 317 placing the room in which it is placed under continuous audio and 318 video surveillance. 320 Every technology deployment by necessity requires some degree of 321 trust on the owner/user's part. But this trust should be limited and 322 subject to accountability. If manufacturers continue to fail in this 323 regard, they risk a backlash in which users seek to restore their 324 rights through litigation, legislation or worst of all, simply not 325 buying more technology that they have learned to distrust through 326 their own experience. 328 The Mesh is based on the principle of radical distrust, that is, if a 329 party is capable of defecting, we assume that they will. As the 330 Russian proverb goes: ???????, ?? ????????: trust, but verify. 332 In the 1990s, the suggestion that 'hackers' might seek to make 333 financial gains from their activities was denounced as 'fear- 334 mongering'. The suggestion that email or anonymous currencies might 335 be abused received a similar response. Today malware, ransomware and 336 spam have become so ubiquitous that they are no longer news unless 337 the circumstances are particularly egregious. 339 We must dispense with the notion that it is improper or impolite to 340 question the good faith of technology suppliers of any kind whether 341 they be manufacturers, service providers, software authors or 342 reviewers. Modern supply chains are complex, typically involving 343 hundreds if not thousands of potential points of deliberate or 344 accidental compromise. The technology provider who relies on the 345 presumption of good faith on their part risks serious damage to their 346 reputation when others assert that a capability added to their 347 product may have malign uses. 349 Radical distrust means that we apply the principles of least 350 principle and accountability at every level in the design: 352 * Cryptographic keys installed in a product during manufacture are 353 only used for the limited purpose of putting that device under 354 control of the user. 356 * Cryptographic keys and assertions related to management of devices 357 are only visible to the user they belong to and are never exposed 358 to external parties. 360 * Mesh Accounts belong to and are under control of the user they 361 belong to and not the Mesh Service provider which the user can 362 change at will with minimal inconvenience. 364 * Mesh Services do not have access to the plaintext of any Mesh 365 Messages or Mesh Catalog data except for the Contacts catalog. 367 * All Mesh Messages are subject to access control by both the 368 inbound and outbound Mesh Service to mitigate messaging abuse. 370 Security is risk management and not the elimination of all 371 possibility of any risk. Radical distrust means that we raise the 372 bar for attackers to the point where for most attackers the risk is 373 greater than the reward. 375 In addition to distrusting technology providers the Mesh Architecture 376 allows the user to limit the degree of trust they place in 377 themselves. In the real world, devices are lost or stolen, passwords 378 and activation codes are forgotten, natural or man-made catastrophes 379 cause property and data to be lost. The Mesh permits but does not 380 require use of escrow techniques that allow recovery from such 381 situations. 383 3.1. A Personal PKI 385 The Mesh is a Public Key Infrastructure (PKI) that is designed to 386 address the three major obstacles to deployment of end-to-end secure 387 applications: 389 * Device management. 391 * Exchange of trusted credentials. 393 * Application configuration management. 395 Each Mesh user is the ultimate source of authority in their Personal 396 Mesh which specifies the set of devices, contacts and applications 397 that they trust and for what purposes. 399 The Mesh 1.0 architecture described a PKI designed to meet these 400 limited requirements to enable use of existing end-to-end secure 401 Internet protocols such as OpenPGP, S/MIME and SSH. Since these 402 protocols only secure data in transit and the vast majority of data 403 breaches involve data at rest, the Data At Rest Encryption (DARE) was 404 added as a layered application resulting in the Mesh 2.0 405 architecture. This document describes the Mesh 3.0 architecture 406 which has been entirely re-worked so that DARE provides the platform 407 on which all other Mesh functions are built. 409 3.1.1. Device Management 411 Existing PKIs were developed in an era when the 'personal computer' 412 was still coming into being. Only a small number of people owned a 413 computer and an even smaller number owned more than one. Today, 414 computers are ubiquitous and a typical home in the developed world 415 contains several hundred of which a dozen or more may have some form 416 of network access. 418 The modern consumer faces a problem of device management that is 419 considerably more complex than the IT administrator of a small 420 business might have faced in the 1990s but without any of the network 421 management tools such an administrator would expect to have 422 available. 424 One important consequence of the proliferation of devices is that 425 end-to-end security is no longer sufficient. To be acceptable to 426 users, a system must be ends-to-ends secure. That is, a user must be 427 able to read their encrypted email message on their laptop, tablet, 428 phone, or watch with exactly the same ease of use as if the mail was 429 unencrypted. 431 Each personal Mesh contains a device catalog in which the 432 cryptographic credentials and device specific application 433 configurations for each connected device are stored. 435 Management of the device catalog is restricted to a subset of devices 436 that the owner of the Mesh has specifically authorized for that 437 purpose as administration devices. Only a device with access to a 438 duly authorized administration key can add or remove devices from a 439 personal Mesh. 441 3.1.2. Exchange of trusted credentials. 443 One of the most challenging, certainly the most contentious issues in 444 PKI is the means by which cryptographic credentials are published and 445 validated. 447 The Mesh does not attempt to impose criteria for accepting 448 credentials as valid as no such set of criteria can be comprehensive. 449 Rather the Mesh allows users to make use of the credential validation 450 criteria that are appropriate to the purpose for which they intend to 451 use them and Mesh Services provides protocol support for exchange of 452 credentials between users and to synchronize credential information 453 between all the devices belonging to a user. 455 In some circumstances, only a direct trust model is acceptable, in 456 others, only a trusted third-party model is possible and in the vast 457 majority of cases opportunistic approaches are more than sufficient. 458 Both approaches may be reinforced by use of chained notary 459 certificate (e.g. BlockChain) technology affords a means of 460 establishing that a particular assertion was made before a certain 461 date. The management of Trust in the Mesh is described in detail in 462 [draft-hallambaker-mesh-trust]. 464 3.1.3. Application configuration management 466 Configuration of cryptographic applications is typically worse than 467 an afterthought. Configuration of one popular mail user agent to use 468 S/MIME security requires 17 steps to be performed using four separate 469 application programs. And since S/MIME certificates expire, the user 470 is required to repeat these steps every few years. Contrary to the 471 public claims made by one major software vendor it is not necessary 472 to perform 'usability testing' to recognize abject stupidity. 474 Rather than writing down configuration steps and giving them to the 475 user, we should turn them into code and give them to a machine. 476 Users should never be required to do the work of the machine. Nor 477 should any programmer be allowed to insult the user by casting their 478 effort aside and requiring it to be re-entered. 480 While most computer professionals who are required to do such tasks 481 on a regular basis will create a tool for the purpose, most users do 482 not have that option. And of those who do write their own tools, 483 only a few have the time and the knowledge to do the job without 484 introducing security vulnerabilities. 486 3.1.4. The Mesh as platform 488 Meeting the core objectives of the Mesh required new naming, 489 communication and cryptographic capabilities provided to be 490 developed. These capabilities may in turn be used to develop new 491 end-to-end secure applications. 493 For example, a DARE Catalog is a cryptographic container in which the 494 entries represent a set of objects which may be added, updated and 495 deleted over time. The Mesh Service protocol allows DARE Catalogs to 496 be synchronized between devices connected to a Mesh Account. DARE 497 Catalogs are used as the basis for the device and contacts catalogs 498 referred to above. 500 The Mesh Credentials Catalog uses the same DARE Catalog format and 501 Mesh Service protocol to share passwords between devices with end-to- 502 end encryption so that no password data is ever left unencrypted in 503 the cloud. 505 3.2. Mesh Architecture 507 The Mesh has four principal components: 509 Mesh Device Management Each user has a personal Mesh profile that is 510 used for management of their personal devices. A user may connect 511 devices to or remove devices from their personal Mesh by use of a 512 connected device that has been granted the 'administration' role. 514 Mesh Account A Mesh account is similar in concept to a traditional 515 email or messaging account but with the important difference that 516 it belongs to the user and not a service provider. Users may 517 maintain multiple Mesh accounts for different purposes. 519 Mesh Service A Mesh Service provides a service identifier (e.g. 520 "alice@example.com") through which devices and other Mesh users 521 may interact with a Mesh Account. It is not necessary for a Mesh 522 Account to be connected to a Mesh Service and users may change 523 their Mesh service provider at any time. It is even possible for 524 a Mesh Account to be connected to multiple services at the same 525 time but only one such account is regarded as the primary account 526 at a given time. 528 Mesh Messaging Mesh Messaging allows short messages (less than 32KB) 529 to be exchanged between Mesh devices connected to an account and 530 between Mesh Accounts. One of the key differences between Mesh 531 Messaging and legacy services such as SMTP is that every message 532 received is subjected to access control. 534 A user's Personal Mesh is the set of their Personal Mesh Profiles, 535 Mesh Accounts and the Mesh Services to which they are bound. 537 For example, Figure X shows Alice's personal Mesh which have separate 538 accounts for her personal and business affairs. She has many 539 devices, two of which are shown here. Both are linked to her 540 personal account but only one is linked to her business account. 541 Besides allowing Alice to separate work and pleasure, this separation 542 means that she does not need to worry about her business affairs 543 being compromised if the device "Alice2" is stolen. 545 (Artwork only available as svg: No external link available, see 546 draft-hallambaker-mesh-architecture-14.html for artwork.) 548 Figure 1 550 Alice's ProfileMaster contains a Master Signature Key used to sign 551 the profile itself and one or more Administrator Signature Keys used 552 to sign assertions binding devices and/or assertions to her Mesh. 554 (Artwork only available as svg: No external link available, see 555 draft-hallambaker-mesh-architecture-14.html for artwork.) 557 Figure 2 559 If desired, Alice can escrow the master key associated with her 560 Profile Master and delete it from her device(s), thus ensuring that 561 compromise of the device does not result in a permanent compromise of 562 her personal Mesh. Recovery of the Master Signature Key and the 563 associated Master Encryption Escrow keys (not shown) allows Alice to 564 recover her entire digital life. 566 To eliminate the risk of hardware failure, the escrow scheme offered 567 by the Mesh itself uses key shares printed on paper and an encrypted 568 escrow record stored in the cloud. Mesh users are of course free to 569 use alternative escrow means of their choice. 571 3.2.1. Mesh Device Management 573 Mesh devices are added to or removed from a user's personal Mesh by 574 adding or removing Device catalog entries from the CatalogDevice 575 associated with the Master Profile. 577 Device catalog entries are created by devices that have been 578 provisioned with an administration key specified in the corresponding 579 ProfileMaster 581 The keying material used by a device in the context of a user's 582 personal Mesh comes from two separate sources: 584 * Keying material specified in the ProfileDevice which is either 585 generated on the device itself or installed during manufacture. 587 * Keying material provided by the Administration Device during the 588 connection process. 590 This approach mitigates the risk of keying material used by the 591 device being compromised during or after manufacture and the risks 592 associated with use of weak keys. The key combination mechanism is 593 shown in section XX below and described in detail in 594 [draft-hallambaker-mesh-cryptography]. 596 (Artwork only available as svg: No external link available, see 597 draft-hallambaker-mesh-architecture-14.html for artwork.) 599 Figure 3 601 In accordance with the principle of maintaining cryptographic 602 hygiene, separate keys are generated for signature, authentication 603 and encryption purposes. 605 3.2.2. Mesh Account 607 Mesh Accounts comprise a collection of persistent data stores 608 associated with a particular persona associated with a personal Mesh. 609 The connection between a Mesh Account and the personal Mesh to which 610 it belongs may or may not be public. For example, Alice might allow 611 her contacts to know that her business and personal accounts belong 612 to the same personal Mesh and thus the same person but Bob might not. 614 Mesh Accounts afford similar functionality to the accounts provided 615 by traditional Internet protocols and applications but with the 616 important distinction that they belong to the user and not the 617 service provider. A Mesh Account may be connected to one, many or no 618 Mesh Services and the user may add or delete service providers at any 619 time. 621 A Mesh Account that is not connected to a Service is called an 622 offline account. Offline accounts cannot send or receive Mesh 623 Messages and cannot be synchronized using the Mesh Service protocol 624 (but may be synchronized through other means). 626 When a Mesh Account is connected to multiple services, only the first 627 service is normally regarded as being primary with the others being 628 secondary accounts for use in case of need. 630 Alice's personal account is connected to two devices and two services 631 ("alice@example.com" and "alice@example.net"). 633 (Artwork only available as svg: No external link available, see 634 draft-hallambaker-mesh-architecture-14.html for artwork.) 636 Figure 4 638 As with the connection of the device to Alice's personal Mesh, the 639 connection of each device to each account requires the creation of a 640 separate set of keying using the same key combination mechanism 641 described above. This information is contained in the 642 ActivationAccount record corresponding to the account in the 643 CatalogEntryDevice. 645 (Artwork only available as svg: No external link available, see 646 draft-hallambaker-mesh-architecture-14.html for artwork.) 648 Figure 5 650 Note that even though Alice's personal account is connected to two 651 separate Mesh Services, the same cryptographic keys are used for 652 both. However separate keys are used for her personal and business 653 accounts so as to prevent these accounts being linked through use of 654 the same device keys. 656 3.2.2.1. Account Catalogs 658 Mesh Catalogs are a DARE Containers whose entries represent a set of 659 objects with no inherent ordering. Examples of Mesh catalogs 660 include: 662 Devices The devices connected to the corresponding Mesh profile. 664 Contacts Logical and physical contact information for people and 665 organizations. 667 Application 669 Bookmarks Web bookmarks and citations. 671 Credentials Username and password information for network resources. 673 Calendar Appointments and tasks. 675 Network Network access configuration information allowing access to 676 WiFi networks and VPNs. 678 Configuration information for applications including mail (SMTP, 679 IMAP, OpenPGP, S/MIME, etc) and SSH. 681 The Devices and Contacts catalogues have special functions in the 682 Mesh as they describe the set of devices and other users that a Mesh 683 user interacts with. 685 These catalogs are also used as the basis for providing a consistent 686 set of friendly names to the users devices and contacts that is 687 accessible to all her devices. This (in principle) allows Alice to 688 give a voice command to her car or her watch or her phone to call a 689 person or open a door and expect consistent results. 691 3.2.3. Mesh Service 693 Each Mesh Service is described by a ProfileService signed by a long- 694 lived signature key. As with the ProfileMaster, a separate set of 695 Administrator keys is used to sign the Assertion Host objects used to 696 credential Service Hosts. 698 (Artwork only available as svg: No external link available, see 699 draft-hallambaker-mesh-architecture-14.html for artwork.) 701 Figure 6 703 Note that the Mesh Service Authentication mechanism only provides 704 trust after first use. It does not provide a mechanism for secure 705 introduction. A Mesh Service SHOULD be credentialed by means of a 706 validation process that establishes the accountability. For example, 707 the CA-Browser Forum Extended Validation Requirements. 709 3.2.4. Mesh Messaging 711 The Mesh Messaging layer supports the exchange of short (less than 712 32KB) messages. Mesh devices connected to the same Mesh profile may 713 exchange Mesh Messages directly. Messages exchanged between Mesh 714 Users MUST be mediated by a Mesh Service for both sending and 715 receipt. This 'four corner' pattern permits ingress and egress 716 controls to be enforced on the messages and that every message is 717 properly recorded in the appropriate spools. 719 For example, To send a message to Alice, Bob posts it to one of the 720 Mesh Services connected to the Mesh Account from which the message is 721 to be sent. The Mesh Service checks to see that both the message and 722 Bob's pattern of behavior comply with their acceptable use policy and 723 if satisfactory, forwards the message to the receiving service 724 example.com. 726 (Artwork only available as svg: No external link available, see 727 draft-hallambaker-mesh-architecture-14.html for artwork.) 729 Figure 7 731 The receiving service uses the recipient's contact catalog and other 732 information to determine if the message should be accepted. If 733 accepted, the message is added to the recipient's inbound message 734 spool to be collected by her device(s) when needed. 736 (Artwork only available as svg: No external link available, see 737 draft-hallambaker-mesh-architecture-14.html for artwork.) 739 Figure 8 741 For efficiency and to limit the scope for abuse, all inbound Mesh 742 Messages are subject to access control and limited in size to 32KB or 743 less. This limit has proved adequate to support transfer of complex 744 control messages and short content messages. Transfer of data 745 objects of arbitrary size may be achieved by sending a control 746 message containing a URI for the main content which may then be 747 fetched using a protocol such as HTTP. 749 This approach makes transfers of very large data sets (i.e. multiple 750 Terabytes) practical as the 'push' phase of the protocol is limited 751 to the transfer of the initial control message. The bulk transfer is 752 implemented as a 'pull' protocol allowing support for features such 753 as continuous integrity checking and resumption of an interrupted 754 transfer. 756 3.3. Using the Mesh with Applications 758 The Mesh provides an infrastructure for supporting existing Internet 759 security applications and a set security features that may be used to 760 build new ones. 762 For example, Alice uses the Mesh to provision and maintain the keys 763 she uses for OpenPGP, S/MIME, SSH and IPSEC. She also uses the 764 credential catalog for end-to-end secure management of the usernames 765 and passwords for her Web browsing and other purposes: 767 (Artwork only available as svg: No external link available, see 768 draft-hallambaker-mesh-architecture-14.html for artwork.) 770 Figure 9 772 The Mesh design is highly modular allowing components that were 773 originally designed to support a specific requirement within the Mesh 774 to be applied generally. 776 3.3.1. Contact Exchange 778 One of the chief concerns in any PKI is the means by which the public 779 keys of other users are obtained and validated. This is of 780 particular importance in the Mesh since every Mesh Message is subject 781 to access control and it is thus necessary for Alice to accept Bob's 782 credentials before Bob send most types of message to Alice. 784 The Mesh supports multiple mechanisms for credential exchange. If 785 Alice and Bob meet in person and are carrying their smart phones, a 786 secure mutual exchange of credentials can be achieved by means of a 787 QR code mechanism. If they are at separate locations, Alice can 788 choose between accepting Bob's contact information with or without 789 additional verification according to the intended use. 791 3.3.2. Confirmation Protocol 793 The basic device connection protocol requires the ability for one 794 device to send a connection request to the Mesh service hosting the 795 user's profile. To accept the device connection, the user connects 796 to the service using an administration device, reviews the pending 797 requests and creates the necessary device connection assertion if it 798 is accepted. 800 The confirmation protocol generalizes this communication pattern 801 allowing any authorized party to post a short accept/reject question 802 to the user who may (or may not) return a signed response. This 803 feature can be used as improvement on traditional second factor 804 authentication providing resistance to man-in-the-middle attacks and 805 providing a permanent non-repudiable indication of the user's 806 specific intent. 808 3.3.3. Future Applications 810 Since a wide range of network applications may be reduced to 811 synchronization of sets and lists, the basic primitives of Catalogs 812 and Spools may be applied to achieve end-to-end security in an even 813 wider variety of applications. 815 For example, a Spool may be used to maintain a mailing list, track 816 comments on a Web forum or record annotations on a document. 817 Encrypting the container entries under a multi-party encryption group 818 allows such communications to be shared with a group of users while 819 maintaining full end-to-end security and without requiring every 820 party writing to the spool to know the public encryption key of every 821 recipient. 823 Another interesting possibility is the use of DARE Containers as a 824 file archive mechanism. A single signature on the final Merkle Tree 825 digest value would be sufficient to authenticate every file in the 826 archive. Updates to the archive might be performed using the same 827 container synchronization primitives provided by a Mesh Service. 828 This approach could afford a robust, secure and efficient mechanism 829 for software distribution and update. 831 4. Mesh Cryptography 833 All the cryptographic algorithms used in the Mesh are either industry 834 standards or present a work factor that is provably equivalent to an 835 industry standard approach. 837 Existing Internet security protocols are based on approaches 838 developed in the 1990s when performance tradeoffs were a prime 839 consideration in the design of cryptographic protocols. Security was 840 focused on the transport layer as it provided the best security 841 possible given the available resources. 843 With rare exceptions, most computing devices manufactured in the past 844 ten years offer either considerably more computing power than was 845 typical of 1990s era Internet connected machines or considerably 846 less. The Mesh architecture is designed to provide security 847 infrastructure both classes of machine but with the important 848 constraint that the less capable 'constrained' devices are considered 849 to be 'network capable' rather than 'Internet capable' and that the 850 majority of Mesh related processing will be offloaded to another 851 device. 853 For example, Alice uses her Desktop and Laptop to exchange end-to-end 854 secure Mesh Messages and documents but her Internet-of-Things food 855 blender and light bulb are limited in the range of functions they 856 support and the telemetry information they provide. The IoT devices 857 connect to a Mesh Hub which acts as an always-on point of presence 858 for the device state and allows complex cryptographic operations to 859 be offloaded if necessary. 861 (Artwork only available as svg: No external link available, see 862 draft-hallambaker-mesh-architecture-14.html for artwork.) 863 Figure 10 865 4.1. Best Practice by Default 867 Except where support for external applications demand otherwise, the 868 Mesh requires that the following 'best practices' be followed: 870 Industry Standard Algorithms All cryptographic protocols make use of 871 the most recently adopted industry standard algorithms. 873 Strongest Work Factor Only the strongest modes of each cipher 874 algorithm are used. All symmetric encryption is performed with 875 256-bit session keys and all digest algorithms are used in 512-bit 876 output length mode. 878 Key Hygiene Separate public key pairs are used for all cryptographic 879 functions: Encryption, Signature and Authentication. This enables 880 separate control regimes for the separate functions and 881 partitioning of cryptographic functions within the application 882 itself. 884 Bound Device Keys Each device has a separate set of Encryption, 885 Signature and Authentication key pairs. These MAY be bound to the 886 device to which they are assigned using hardware or other 887 techniques to prevent or discourage export. 889 No Optional Extras Traditional approaches to security have treated 890 many functions as being 'advanced' and thus suited for use by only 891 the most sophisticated users. The Mesh rejects this approach 892 noting that all users operate in precisely the same environment 893 facing precisely the same threats. 895 4.2. Multi-Level Security 897 All Mesh protocol transactions are protected at the Transport, 898 Message and Data level. This provides security in depth that cannot 899 be achieved by applying security at the separate levels 900 independently. Data level encryption provides end-to-end 901 confidentiality and non-repudiation, Message level authentication 902 provides the basis for access control and Transport level encryption 903 provides a degree of protection against traffic analysis. 905 4.3. Multi-Key Decryption 907 Traditional public key encryption algorithms have two keys, one for 908 encryption and another for decryption. The Mesh makes use of 909 threshold cryptography techniques to allow the decryption key to be 910 split into two or more parts. 912 For example, if we have a private key _z_, we can use this to perform 913 a key agreement with a public key _S_ to obtain the key agreement 914 value A. But if _z_ = (_x+y_) mod _g_ (where g is the order of the 915 group). we can obtain the exact same result by applying the private 916 keys _x_ and _y_ to _S_ separately and combining the results: 918 (Artwork only available as svg: No external link available, see 919 draft-hallambaker-mesh-architecture-14.html for artwork.) 921 Figure 11 923 The approach to Multi-Key Decryption used in the Mesh was originally 924 inspired by the work of Matt Blaze et. al. on proxy re-encryption. 925 But the approach used may also be considered a form of Torben 926 Pedersen's Distributed Key generation. 928 This technique is used in the Mesh to allow use of decryption key 929 held by a user to be controlled by a cloud service without giving the 930 cloud service the ability to decrypt by itself. 932 4.4. Multi-Party Key Generation 934 The mathematics that support multi-key decryption are also the basis 935 for the multi-party key generation mechanism that is applied at 936 multiple levels in the Mesh. The basis for the multi-party key 937 generation used in the Mesh is that for any Diffie-Hellman type 938 cryptographic scheme, given two keypairs { _x_, _X_ }, { _y_, _Y_ }, 939 we calculate the public key corresponding to the private key _x_+ _y_ 940 using just the public key values _X_and _Y_. 942 (Artwork only available as svg: No external link available, see 943 draft-hallambaker-mesh-architecture-14.html for artwork.) 945 Figure 12 947 Multi-party key generation ensures that keys used to bind devices to 948 a personal Mesh or within a Mesh account are 'safe' if any of the 949 contributions to the generation process are safe. 951 4.5. Data At Rest Encryption 953 The Data At Rest Encryption (DARE) format is used for all 954 confidentiality and integrity enhancements. The DARE format is based 955 on the JOSE Signature and Encryption formats and the use of an 956 extended version of the JSON encoding allowing direct encoding of 957 binary objects. 959 4.5.1. DARE Envelope 961 The DARE Envelope format offers similar capabilities to existing 962 formats such as OpenPGP and CMS without the need for onerous encoding 963 schemes. DARE Assertions are presented as DARE Envelopes. 965 A feature of the DARE Envelope format not supported in existing 966 schemes is the ability to encrypt and authenticate sets of data 967 attributes separately from the payload. This allows features such as 968 the ability to encrypt a subject line or content type for a message 969 separately from the payload. 971 4.5.2. Dare Container 973 A DARE Container is an append-only sequence of DARE Envelopes. A key 974 feature of the DARE Container format is that entries MAY be encrypted 975 and/or authenticated incrementally. Individual entries MAY be 976 extracted from a DARE Container to create a stand-alone DARE 977 Envelope. 979 Containers may be authenticated by means of a Merkle tree of digest 980 values on the individual frames. This allows similar demonstrations 981 of integrity to those afforded by Blockchain to be provided but with 982 much greater efficiency. 984 Unlike traditional encryption formats which require a new public key 985 exchange for each encrypted payload, the DARE Container format allows 986 multiple entries to be encrypted under a single key exchange 987 operation. This is particularly useful in applications such as 988 encrypting server transaction logs. The server need only perform a 989 single key exchange operation is performed each time it starts to 990 establish a master key. The master key is then used to create fresh 991 symmetric keying material for each entry in the log using a unique 992 nonce per entry. 994 (Artwork only available as svg: No external link available, see 995 draft-hallambaker-mesh-architecture-14.html for artwork.) 997 Figure 13 999 Integrity is provided by a Merkle tree calculated over the sequence 1000 of log entries. The tree apex is signed at regular intervals to 1001 provide non-repudiation. 1003 Three types of DARE Containers are used in the mesh 1005 Catalogs A DARE Container whose entries track the status of a set of 1006 related objects which may be added, updated or deleted. 1008 Spools A DARE Container whose entries track the status of a series 1009 of Mesh Messages. 1011 Archives A DARE Container used to provide a file archive with 1012 optional confidentiality and/or integrity enhancements. 1014 4.6. Uniform Data Fingerprints. 1016 The Uniform Data Fingerprint (UDF) format provides a compact means of 1017 presenting cryptographic nonces, keys and digest values using Base32 1018 encoding that resists semantic substitution attacks. UDF provides a 1019 convenient format for data entry. Since the encoding used is case- 1020 insensitive, UDFs may if necessary be read out over a voice link 1021 without excessive inconvenience. 1023 The following are examples of UDF values: 1025 NC6X-EVQA-M7FV-F7LJ-FFHY-SMDY-UACA 1026 EAML-INHA-2635-5SKT-46SH-XKSL-HAZA 1027 SAQH-SBPX-XEXR-RYGS-RCVV-DTPA-JUPD-G 1028 MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4 1029 KCM5-7VB6-IJXJ-WKHX-NZQF-OKGZ-EWVN 1030 ADRU-4UV2-EGB2-7QW5-DKZZ-GDGJ-42YC 1032 UDF content digests are used to support a direct trust model similar 1033 to that of OpenPGP. Every Mesh Profile is authenticated by the UDF 1034 fingerprint of its signature key. Mesh Friendly Names and UDF 1035 Fingerprints thus serve analogous functions to DNS names and IP 1036 Addresses. Like DNS names, Friendly Names provide the basis for 1037 application-layer interactions while the UDF Fingerprints are used as 1038 to provide the foundation for security. 1040 4.6.1. Friendly Names 1042 Internet addressing schemes are designed to provide a globally unique 1043 (or at minimum unambiguous) name for a host, service or account. In 1044 the early days of the Internet, this resulted in addresses such as 1045 10.2.3.4 and alice@example.com which from a usability point of view 1046 might be considered serviceable if not ideal. Today the Internet is 1047 a global infrastructure servicing billions of users and tens of 1048 billions of devices and accounts are more likely to be 1049 alice.lastname.1934@example.com than something memorable. 1051 Friendly names provide a user or community specific means of 1052 identifying resources that may take advantage of geographic location 1053 or other cues to resolve possible ambiguity. If Alice says to her 1054 voice activated device "close the garage door" it is implicit that it 1055 is her garage door that she wishes to close. And should Alice be 1056 fortunate enough to own two houses with a garage, it is implicit that 1057 it is the garage door of the house she is presently using that she 1058 wishes to close. 1060 The Mesh Device Catalog provides a directory mapping friendly names 1061 to devices that is available to all Alice's connected devices so that 1062 she may give and instruction to any of her devices using the same 1063 friendly name and expect consistent results. 1065 4.6.2. Encrypted Authenticated Resource Locators 1067 Various schemes have been used to employ QR Codes as a means of 1068 device and/or user authentication. In many of these schemes a QR 1069 code contains a challenge nonce that is used to authenticate the 1070 connection request. 1072 The Mesh supports a QR code connection mode employing the Encrypted 1073 Authenticated Resource Locator (EARL) format. An EARL is an 1074 identifier which allows an encrypted data object to be retrieved and 1075 decrypted. In this case, the encrypted data object contains the 1076 information needed to complete the interaction. 1078 An EARL contains the domain name of the service providing the 1079 resolution service and an encryption master key: 1081 udf://example.com/ECWP-WH46-6W3Q-53IM-VPVO-B5DJ-GLZG-TB 1083 The EARL may be expressed as a QR code: 1085 (Artwork only available as svg: No external link available, see 1086 draft-hallambaker-mesh-architecture-14.html for artwork.) 1088 Figure 14 1090 An EARL is resolved by presenting the content digest fingerprint of 1091 the encryption key to a Web service hosted at the specified domain. 1092 The service returns a DARE Envelope whose payload is encrypted and 1093 authenticated under the specified master key. Since the content is 1094 stored on the service under the fingerprint of the key and not the 1095 key itself, the service cannot decrypt the plaintext. Only a party 1096 that has access to the encryption key in the QR code can decrypt the 1097 message. 1099 4.6.3. Secure Internet Names 1101 Secure Internet Names bind an Internet address such as a URL or an 1102 email address to a Security Policy by means of a UDF content digest 1103 of a document describing the security policy. This binding enables a 1104 SIN-aware Internet client to ensure that the security policy is 1105 applied when connecting to the address. For example, ensuring that 1106 an email sent to an address must be end-to-end encrypted under a 1107 particular public key or that access to a Web Service requires a 1108 particular set of security enhancements. 1110 alice@example.com Alice's regular email address (not a SIN). 1112 alice@mm--uuuu-uuuu-uuuu.example.com A strong email address for 1113 Alice that can be used by a regular email client. 1115 alice@example.com.mm--uuuu-uuuu-uuuu A strong email address for 1116 Alice that can only used by an email client that can process SINs. 1118 Using an email address that has the Security Policy element as a 1119 prefix allows a DNS wildcard element to be defined that allows the 1120 address to be used with any email client. Presenting the Security 1121 Policy element as a suffix means it can only be resolved by a SIN- 1122 aware client. 1124 4.7. Personal Key Escrow 1126 One of the core objectives of the Mesh is to make data level 1127 encryption ubiquitous. While data level encryption provides robust 1128 protection of data confidentiality, loss of the ability to decrypt 1129 means data loss. 1131 For many Internet users, data availability is a considerably greater 1132 concern than confidentiality. Ten years later, there is no way to 1133 replace pictures of the children at five years old. Recognizing the 1134 need to guarantee data recovery, the Mesh provides a robust personal 1135 key escrow and recovery mechanism. Lawful access is not supported as 1136 a requirement. 1138 Besides supporting key recovery in the case of loss, the Mesh 1139 protocols potentially support key recovery in the case of the key 1140 holder's death. The chief difficulty faced in implementing such a 1141 scheme being developing an acceptable user interface which allows the 1142 user to specify which of their data should survive them and which 1143 should not. As the apothegm goes: Mallet wants his beneficiaries to 1144 know where he buried Aunt Agatha's jewels but not where he buried 1145 Aunt Agatha. 1147 The Mesh supports use of Shamir Secret Sharing to split a secret key 1148 into a set of shares, a predetermined number of which may be used to 1149 recover the original secret. For convenience secret shares are 1150 represented using UDF allowing presentation in Base32 (i.e. text 1151 format) for easy transcription or QR code presentation if preferred. 1153 A Mesh Profile is escrowed by creating a recovery record containing 1154 the private keys corresponding to the master signature and master 1155 escrow keys associated with the profile. A master secret is then 1156 generated which is used to generate a symmetric encryption key used 1157 to encrypt the recovery record and to generate the desired number of 1158 recovery shares. For example, Alice escrows her Mesh Profile 1159 creating three recovery shares, two of which are required to recover 1160 the master secret: 1162 (Artwork only available as svg: No external link available, see 1163 draft-hallambaker-mesh-architecture-14.html for artwork.) 1165 Figure 15 1167 To recover the master secret, Alice presents the necessary number of 1168 key shares. These are used to recover the master secret which is 1169 used to generate the decryption key. 1171 (Artwork only available as svg: No external link available, see 1172 draft-hallambaker-mesh-architecture-14.html for artwork.) 1174 Figure 16 1176 A user may choose to store their encrypted recovery record themselves 1177 or make use of the EARL mechanism to store the information at one or 1178 more cloud services using the fingerprint of the master secret as the 1179 locator. 1181 5. User Experience 1183 This section describes the Mesh in use. These use cases described 1184 here are re-visited in the companion Mesh Schema Reference 1185 [draft-hallambaker-mesh-schema] and Mesh Protocol Reference 1186 [draft-hallambaker-mesh-protocol] with additional examples and 1187 details. 1189 For clarity and for compactness, these use cases are illustrated 1190 using the command line tool meshman. 1192 The original design brief for the Mesh was to make it easier to use 1193 the Internet securely. Over time, it was realized that users are 1194 almost never prepared to sacrifice usability or convenience for 1195 security. It is therefore insufficient to minimize the cost of 1196 security, if secure applications are to be used securely they must be 1197 at least as easy to use as those they replace. If security features 1198 are to be used, they must not require the user to make any additional 1199 effort whatsoever. 1201 The key to meeting this constraint is that any set of instructions 1202 that can be written down to be followed by a user can be turned into 1203 code and executed by machine. Provided that the necessary 1204 authentication, integrity and confidentiality controls are provided. 1205 Thus, the Mesh is not just a cryptographic infrastructure that makes 1206 use of computer systems more secure, it is a usability infrastructure 1207 that makes computers easier to use by providing security. 1209 The user experience is thus at the heart of the design of the Mesh 1210 and a description of the Mesh Architecture properly begins with 1211 consideration of the view of the system that matters most: that of 1212 the user. 1214 The principle security protocols in use today were designed at a time 1215 when most Internet users made use of either a single machine or one 1216 of a number of shared machines connected to a shared file store. The 1217 problem of transferring cryptographic keys and configuration data 1218 between machines was rarely considered and when it was considered was 1219 usually implemented badly. Today the typical user owns or makes use 1220 of multiple devices they recognize as a computer (laptop, tablet) and 1221 an even greater number of devices that they do not recognize as 1222 computers but are (almost any device with a display). 1224 (Artwork only available as svg: No external link available, see 1225 draft-hallambaker-mesh-architecture-14.html for artwork.) 1227 Figure 17 1229 5.1. Creating a Mesh Profile and Administration Device. 1231 The first step in using the Mesh is to create a personal profile. 1232 From the user's point of view a profile is a collection of all the 1233 configuration data for all the Mesh enabled devices and services that 1234 they interact with. 1236 Alice> mesh create 1237 Device Profile UDF=MB25-BJYV-2I3W-JHRQ-Z4KF-BPMC-BYUG 1238 Personal Profile UDF=MBU4-C4AJ-TGTO-AETP-LQDC-R3L6-VMX7 1239 Note that the user does not specify the cryptographic algorithms to 1240 use. Choice of cryptographic algorithm is primarily the concern of 1241 the protocol designer, not the user. The only circumstance in which 1242 users would normally be involved in algorithm selection is when there 1243 is a transition in progress from one algorithm suite to another. 1245 5.2. Mesh Accounts 1247 Add an account to the personal Mesh: 1249 Alice> account create personal 1250 Account=MCXI-75JG-RVBH-NK5X-IUWM-G2BE-JML6 1252 A Mesh Catalog contains a set of entries, each of which has a unique 1253 object identifier. Catalog entries may be added, updated or deleted. 1255 By default, all catalog entries are encrypted. Applying the Default 1256 Deny principle, in normal circumstances, the Mesh Service is not 1257 capable of decrypting any catalog excepting the Contacts catalog 1258 which is used as a source of authorization data in the Access Control 1259 applied to inbound messaging requests. 1261 For example, the entries in the credentials catalog specify username 1262 and password credentials used to access Internet services. Adding 1263 credentials to her catalog allows Alice to write scripts that access 1264 password protected resources without including the passwords in the 1265 scripts themselves: 1267 Alice> password add ftp.example.com alice1 password 1268 alice1@ftp.example.com = [password] 1269 Alice> password add www.example.com alice@example.com newpassword 1270 alice@example.com@www.example.com = [newpassword] 1271 Alice> password list 1272 CatalogedCredential 1274 CatalogedCredential 1276 Alice> password add ftp.example.com alice1 newpassword 1277 alice1@ftp.example.com = [newpassword] 1278 Alice> password get ftp.example.com 1279 alice1@ftp.example.com = [newpassword] 1281 5.3. Using a Mesh Service 1283 A Mesh Service provides an 'always available' point of presence that 1284 is used to exchange data between devices connected to the connected 1285 profile and send and receive Mesh Messages to and from other Mesh 1286 users. 1288 To use a Mesh Service, a user creates a Mesh Service account. This 1289 is analogous to an SMTP email service but with the important 1290 distinction that the protocol is designed to allow users to change 1291 their Mesh Service provider at any time they choose with minimal 1292 impact. 1294 The account is created by sending an account registration request to 1295 the chosen Mesh Service. If accepted, the Mesh Service creates a new 1296 account and creates containers to hold the associated catalogs and 1297 spools: 1299 Alice> account register alice@example.com 1300 Account=MCXI-75JG-RVBH-NK5X-IUWM-G2BE-JML6 1301 AccountAddress=alice@example.com 1303 As with any other Internet service provision, Mesh Service providers 1304 may impose constraints on the use of their service such as the amount 1305 of data they send, store and receive and charge a fee for their 1306 service. 1308 5.4. Connecting and Authorizing Additional Devices 1310 Having established a Mesh profile, a user may connect any number of 1311 devices to it. Connecting a device to a Mesh profile allows it to 1312 share data with, control and be controlled by other devices connected 1313 to the profile. 1315 Although any type of network capable device may be connected to a 1316 Mesh profile, some devices are better suited for use with certain 1317 applications than others. Connecting an oven to a Mesh profile could 1318 allow it to be controlled through entries to the user's recipe and 1319 calendar catalogs and alert the user when the meal is ready but 1320 attempting to use it to read emails or manage Mesh profiles. 1322 Three connection mechanisms are currently specified, each of which 1323 provides strong mutual authentication: Direct, PIN and QR. 1325 Since approval of a connection request requires the creation of a 1326 signed Connection Assertion, requests must be approved by a device 1327 that has access to an administration key authorized by the user's 1328 Master Profile. Such devices are referred to as Administration 1329 devices. Administration devices must have data entry (e.g. keyboard) 1330 and output (e.g. display) affordances to support any of the currently 1331 defined connection mechanisms. The QR code connection mechanism also 1332 requires a suitable camera. 1334 It will be noted that the process of connecting a device that 1335 contains a preconfigured set of device keys might in principle expose 1336 the user to the risk that the manufacturer has retained knowledge of 1337 these keys and that this might be used to create a 'backdoor'. 1339 This risk is controlled using the key co-generation technique 1340 described earlier. The original device profile is combined with a 1341 device profile provided by the user to create a composite device 1342 profile. This ensures that every device uses a unique profile even 1343 if they are initialized from a shared firmware image containing a 1344 fixed set of device key pairs. 1346 5.4.1. Direct Connection 1348 The direct connection mechanism requires that both the administration 1349 device and the device originating the connection request have data 1350 entry and output affordances and that it is possible for the user to 1351 compare the authentication codes presented by the two devices to 1352 check that they are identical. 1354 The connection request is initiated on the device being connected: 1356 Alice2> device request alice@example.com 1357 Device UDF = MC6T-FX77-ABC5-BVJ5-U3C4-MYCH-PQVR 1358 Witness value = XP3F-7HEO-OYBH-SKCJ-EO7P-Q54P-6HED 1359 Personal Mesh = MBU4-C4AJ-TGTO-AETP-LQDC-R3L6-VMX7 1361 Using her administration device, Alice gets a list of pending 1362 requests. Seeing that there is a pending request matching the 1363 witness value presented by the device, Alice accepts it: 1365 Alice> device pending 1366 MessageID: CIGO-WAFU-OAYI-PF7E-5L4H-DOG2-SY3Z 1367 Connection Request:: 1368 MessageID: CIGO-WAFU-OAYI-PF7E-5L4H-DOG2-SY3Z 1369 To: From: 1370 Device: MD7W-S6XF-V4EL-7QEO-MUPK-B5JL-MLPY 1371 Witness: CIGO-WAFU-OAYI-PF7E-5L4H-DOG2-SY3Z 1372 MessageID: XP3F-7HEO-OYBH-SKCJ-EO7P-Q54P-6HED 1373 Connection Request:: 1374 MessageID: XP3F-7HEO-OYBH-SKCJ-EO7P-Q54P-6HED 1375 To: From: 1376 Device: MC6T-FX77-ABC5-BVJ5-U3C4-MYCH-PQVR 1377 Witness: XP3F-7HEO-OYBH-SKCJ-EO7P-Q54P-6HED 1378 Alice> device accept CIGO-WAFU-OAYI-PF7E-5L4H-DOG2-SY3Z 1379 Result: Accept 1380 Added device: MD7W-S6XF-V4EL-7QEO-MUPK-B5JL-MLPY 1381 The new device will now synchronize automatically in response to any 1382 Mesh commands. For example, listing the password catalog: 1384 Alice2> password list 1385 ERROR - Unspecified error 1387 5.4.2. Pin Connection 1389 The PIN Connection mechanism is similar to the Direct connection 1390 mechanism except that the process is initiated on an administration 1391 device by requesting assignment of a new authentication PIN. The PIN 1392 is then input to the connecting device to authenticate the request. 1394 The PIN connection mechanism begins with the issue of the PIN: 1396 Alice> account pin 1397 PIN=ADDA-NJ7O-ZQS3-4KR6-N7OA-CEZR-FRUR (Expires=2020-07-28T09:45:24Z) 1399 The PIN code is transmitted out of band to the device being 1400 connected: 1402 Alice3> device request alice@example.com /pin=ADDA-NJ7O-ZQS3-4KR6-N7O 1403 A-CEZR-FRUR 1404 ERROR - The requested cryptographic operation is not supported 1406 Since the request was pre-authorized, it is not necessary for Alice 1407 to explicitly accept the connection request but the administration 1408 device is needed to create the connection assertion: 1410 Alice> device pending 1411 MessageID: CIGO-WAFU-OAYI-PF7E-5L4H-DOG2-SY3Z 1412 Connection Request:: 1413 MessageID: CIGO-WAFU-OAYI-PF7E-5L4H-DOG2-SY3Z 1414 To: From: 1415 Device: MD7W-S6XF-V4EL-7QEO-MUPK-B5JL-MLPY 1416 Witness: CIGO-WAFU-OAYI-PF7E-5L4H-DOG2-SY3Z 1417 MessageID: XP3F-7HEO-OYBH-SKCJ-EO7P-Q54P-6HED 1418 Connection Request:: 1419 MessageID: XP3F-7HEO-OYBH-SKCJ-EO7P-Q54P-6HED 1420 To: From: 1421 Device: MC6T-FX77-ABC5-BVJ5-U3C4-MYCH-PQVR 1422 Witness: XP3F-7HEO-OYBH-SKCJ-EO7P-Q54P-6HED 1424 We can check the device connection by attempting to synchronize to 1425 the profile account: 1427 Alice3> account sync 1428 ERROR - Unspecified error 1429 Note that this connection mechanism could be adapted to allow a 1430 device with a camera affordance to connect by scanning a QR code on 1431 the administration device. 1433 If the Device Profile fingerprint is known at the time the PIN is 1434 generated, this can be bound to the PIN authorization assertion to 1435 permit connection of a specific device. 1437 5.4.3. EARL/QR Code Connection 1439 The EARL/QR code connection mechanisms are used to connect a 1440 constrained device to a Mesh profile by means of an Encrypted 1441 Authenticated Resource Locator, typically presented as a QR code on 1442 the device itself or its packaging. 1444 Since the meshman tool does not support QR input, it is decoded using 1445 a separate tool to recover the UDF EARL which is presented as a 1446 command line parameter: 1448 To use the device QR code connection mechanism, we require a Web 1449 service that will host the connection document example.com and a 1450 MeshService account that the device will attempt to complete the 1451 connection by requesting synchronization devices@example.com. 1453 To begin the process we generate a new random key and combine it with 1454 the service to create an EARL: 1456 udf://example.com/ECWP-WH46-6W3Q-53IM-VPVO-B5DJ-GLZG-TB 1458 Next a device profile is created and preregistered on with the Mesh 1459 Service that will provide the hailing service. Since we are only 1460 preparing one device it is convenient to do this on the device 1461 itself. In a manufacturing scenario, these steps would typically be 1462 performed offline in bulk. 1464 Alice4> device pre devices@example.com /key=udf://example.com/ECWP-WH 1465 46-6W3Q-53IM-VPVO-B5DJ-GLZG-TB 1466 ERROR - The command System.Object[] is not known. 1468 Once initialized the device attempts to poll the service for a 1469 connection each time it is powered on, when a connection button 1470 affordance on the device is pressed or at other times as agreed with 1471 the Mesh Service Provider: 1473 Alice4> account sync 1474 ERROR - Unspecified error 1475 To connect the device to her profile, Alice scans the device with her 1476 administration device to obtain the UDF. The administration device 1477 retrieves the connection description, decrypts it and then uses the 1478 information in the description to create the necessary Device 1479 Connection Assertion and connect to the device hailing Mesh Service 1480 Account to complete the process: 1482 Alice> device earl udf://example.com/ECWP-WH46-6W3Q-53IM-VPVO-B5DJ-GL 1483 ZG-TB 1484 ERROR - The command System.Object[] is not known. 1486 When the device next attempts to connect to the hailing service, it 1487 receives the Device Connection Assertion: 1489 Alice4> account sync 1490 ERROR - Unspecified error 1492 5.5. Contact Requests 1494 As previously stated, every inbound Mesh message is subject to access 1495 control. The user's contact catalog is used as part of the access 1496 control authentication and authorization mechanism. 1498 By default, the only form of inbound message that is accepted without 1499 authorization in the contact catalog is a contact request. Though 1500 for certain Mesh users (e.g. politicians, celebrities) even contact 1501 requests might require some form of prior approval (e.g. endorsement 1502 by a mutual friend). 1504 A Mesh Contact Assertion may be limited to stating the user's profile 1505 fingerprint and Mesh Service Account(s). For most purposes however, 1506 it is more convenient to present a Contact Assertion that contains at 1507 least as much information as is typically provided on a business or 1508 calling card: 1510 Alice creates a contact entry for herself: 1512 Alice> contact self email alice@example.com 1513 ERROR - The feature has not been implemented 1515 User's may create multiple Contact Assertions for use in different 1516 circumstances. A user might not want to give their home address to a 1517 business contact or their business address to a personal friend. 1519 5.5.1. Remote 1521 In the most general case, the participants are remote from each other 1522 and one user must make a contact request of the other: 1524 Bob requests Alice add him to her contacts catalog: 1526 Bob> message contact alice@example.com 1528 When Alice next checks her messages, she sees the pending contact 1529 request from Bob and accepts it. Bob's contact details are added to 1530 her catalog and Bob receives a response containing Alice's 1531 credentials: 1533 Alice> message pending 1534 MessageID: NAKQ-VJU5-XERR-C3C2-YBFL-HZXN-TWGD 1535 Contact Request:: 1536 MessageID: NAKQ-VJU5-XERR-C3C2-YBFL-HZXN-TWGD 1537 To: alice@example.com From: bob@example.com 1538 PIN: ECFX-4MRD-ALZE-QDW2-242H-5LXI-OM7N 1539 MessageID: CIGO-WAFU-OAYI-PF7E-5L4H-DOG2-SY3Z 1540 Connection Request:: 1541 MessageID: CIGO-WAFU-OAYI-PF7E-5L4H-DOG2-SY3Z 1542 To: From: 1543 Device: MD7W-S6XF-V4EL-7QEO-MUPK-B5JL-MLPY 1544 Witness: CIGO-WAFU-OAYI-PF7E-5L4H-DOG2-SY3Z 1545 MessageID: XP3F-7HEO-OYBH-SKCJ-EO7P-Q54P-6HED 1546 Connection Request:: 1547 MessageID: XP3F-7HEO-OYBH-SKCJ-EO7P-Q54P-6HED 1548 To: From: 1549 Device: MC6T-FX77-ABC5-BVJ5-U3C4-MYCH-PQVR 1550 Witness: XP3F-7HEO-OYBH-SKCJ-EO7P-Q54P-6HED 1551 Alice> message accept tbs 1552 ERROR - The specified message could not be found. 1554 5.5.2. Static QR Code 1556 A DARE contact entry may be exchanged by means of an EARL UDF. This 1557 is typically presented by means of a QR code which may be created 1558 using the "meshman" tool and a QR code generator. The resulting QR 1559 code may be printed on a business card, laser engraved on a luggage 1560 tag, etc. 1562 To accept the contact request, the recipient merely scans the code 1563 with a Mesh capable QR code reader. They are asked if they wish to 1564 accept the contact request and what privileges they wish to authorize 1565 for the new contact. 1567 5.5.3. Dynamic QR Code 1569 If it is possible for the device to generate a new QR code for the 1570 contact request, it is possible to support bi-directional exchange of 1571 credentials with strong mutual authentication. 1573 For example, Alice selects the contact credential she wishes to pass 1574 to Bob on her mobile device which presents an EARL as a QR code. Bob 1575 scans the QR code with his mobile device which retrieves Alice's 1576 credential and asks if Bob wishes to accept it and if he wishes to 1577 share his credential with Alice. If Bob agrees, his device makes a 1578 Remote Contact request authenticated under a key passed to his device 1579 with Alice's Contact Assertion. 1581 The Dynamic QR Code protocol may be applied to support exchange of 1582 credentials between larger groups. Enrolling the contact assertions 1583 collected in such circumstances in a notarized append only log (e.g. 1584 a DARE Container) provides a powerful basis for building a Web of 1585 Trust that is equivalent to but considerably more convenient than 1586 participation in PGP Key Signing parties. 1588 5.6. Sharing Confidential Data in the Cloud 1590 As previously discussed, the Mesh makes use of multi-party encryption 1591 techniques to mitigate the risk of a device compromise leading to 1592 disclosure of confidential data. The Mesh also allows these 1593 techniques to be applied to provide Confidential Document Control. 1594 This provides data encryption capabilities that are particularly 1595 suited to 'cloud computing' environments. 1597 A Mesh Encryption Group is a special type of Mesh Service Account 1598 that is controlled by one of more group administrators. The 1599 Encryption Group Key is a normal ECDH public key used in the normal 1600 manner. The decryption key is held by the group administrator. To 1601 add a user to the group, the administrator splits the group private 1602 key into two parts, a service key and a user key. These parts are 1603 encrypted under the public encryption keys of their assigned parties. 1604 The encrypted key parts form a decryption entry for the user is added 1605 to the Members Catalog of the Encryption Group at the Mesh Service. 1607 (Artwork only available as svg: No external link available, see 1608 draft-hallambaker-mesh-architecture-14.html for artwork.) 1610 Figure 18 1612 When a user needs to decrypt a document encrypted under the group 1613 key, they make a request to the Mesh Service which checks to see that 1614 they are authorized to read that particular document, have not 1615 exceeded their decryption quota, etc. If the request is approved, 1616 the service returns the partial decryption result obtained from the 1617 service's key part together with the encrypted user key part. To 1618 complete the decryption process, the user decrypts their key part and 1619 uses it to create a second partial decryption result which is 1620 combined with the first to obtain the key agreement value needed to 1621 complete the decryption process. 1623 Alice creates the recryption group groupw@example.com to share 1624 confidential information with her closest friends: 1626 Alice> group create groupw@example.com 1627 { 1628 "Key": "groupw@example.com", 1629 "Profile": { 1630 "KeyOfflineSignature": { 1631 "UDF": "MC7M-VCLK-M42M-AUE6-L5QT-2Z4G-QNDW", 1632 "PublicParameters": { 1633 "PublicKeyECDH": { 1634 "crv": "Ed448", 1635 "Public": "sERuuOQfOYYFTGLhPbH1NOrF2RT1hXCIveZc1Zk9NfSg45cs 1636 I30V 1637 GEXAXZweDMfRfPFIkIEqovOA"}}}, 1638 "KeyEncryption": { 1639 "UDF": "MAWX-U6RL-AMTZ-3TXN-KM7D-OOIC-YWFH", 1640 "PublicParameters": { 1641 "PublicKeyECDH": { 1642 "crv": "X448", 1643 "Public": "SW9tWFmDEfLS4KzdhojHHK2bK8uQ7D9s3K5lpnKBs8VebgKm 1644 sAr1 1645 orx4zpZxB-NaQCyZHUCMSpGA"}}}}} 1647 Bob encrypts a test file but he can't decrypt it because he isn't in 1648 the group: 1650 Bob> dare encodeTestFile1.txt /out=TestFile1-group.dare /encrypt=grou 1651 pw@example.com 1652 ERROR - The command System.Object[] is not known. 1653 Bob> dare decode TestFile1-group.dare 1654 ERROR - Could not find file 'C:\Users\hallam\Test\WorkingDirectory\Te 1655 stFile1-group.dare'. 1657 Since she is the group administrator, Alice can decrypt the test file 1658 using the group decryption key: 1660 Alice> dare decode TestFile1-group.dare 1661 ERROR - Could not find file 'C:\Users\hallam\Test\WorkingDirectory\Te 1662 stFile1-group.dare'. 1664 Adding Bob to the group gives him immediate access to any file 1665 encrypted under the group key without making any change to the 1666 encrypted files: 1668 Alice> dare decode TestFile1-group.dare 1669 ERROR - Could not find file 'C:\Users\hallam\Test\WorkingDirectory\Te 1670 stFile1-group.dare'. 1672 Removing Bob from the group immediately withdraws his access. 1674 Alice> group delete groupw@example.com bob@example.com 1675 ERROR - The entry could not be found in the store. 1677 Bob cannot decrypt any more files (but he may have kept copies of 1678 files he decrypted earlier). 1680 Alice> dare decode TestFile1-group.dare 1681 ERROR - Could not find file 'C:\Users\hallam\Test\WorkingDirectory\Te 1682 stFile1-group.dare'. 1684 Should requirements demand, the same principle may be applied to 1685 achieve separation of duties in the administration roles. Instead of 1686 provisioning the group private key to a single administrator, it may 1687 be split into two or more parts. Adding a user to the group requires 1688 each of the administrators to create a decryption entry for the user 1689 and for the service and user to apply the appropriate operations to 1690 combine the key parts available to them before use. 1692 These techniques could even be extended to support complex 1693 authorization requirements such as the need for 2 out of 3 1694 administrators to approve membership of the group. A set of 1695 decryption entries is complete if the sum of the key parts is equal 1696 to the private key (modulo the order of the curve). 1698 Thus, if the set of administrators is A, B and C and the private key 1699 is _k_, we can ensure that it requires exactly two administrators to 1700 create a complete set of decryption entries by issuing key set { _a_ 1701 } to A, the key set {_k-a_ , _b_ } to B and the key set {_k-a_ , _k- 1702 b_ } to C (where _a_ and _b_ are randomly generated keys). 1704 5.7. Escrow and Recovery of Keys 1706 One of the chief objections made against deployment of Data Level 1707 encryption is that although it provides the strongest possible 1708 protection of the confidentiality of the data, loss of the decryption 1709 keys means loss of the encrypted data. Thus, a robust and effective 1710 key escrow mechanism is essential if use of encryption is to ever 1711 become commonplace for stored data. 1713 The use of a 'life-long' Mesh profiles raises a similar concern. 1714 Loss of a Master Signature Key potentially means the loss of the 1715 ability to control devices connected to the profile and the 1716 accumulated trust endorsements of other users. 1718 Because of these requirements, Mesh users are strongly advised but 1719 not required to create a backup copy of the private keys 1720 corresponding to their Master Profile Signature and Escrow keys. 1722 Users may use the key escrow mechanism of their choice including the 1723 escrow mechanism supported by the Mesh itself which uses Shamir 1724 Secret Sharing to escrow the encryption key for a DARE Envelope 1725 containing the private key information. 1727 To escrow a key set, the user specifies the number of key shares to 1728 be created and the number required for recovery. 1730 Recovery of the key data requires the key recovery record and a 1731 quorum of the key shares: 1733 Having recovered the Master Signature Key, the user can now create a 1734 new master profile authorizing a new administration device which can 1735 be used to authenticate access to the Mesh Service Account(s) 1736 connected to the master profile. 1738 6. Security Considerations 1740 The security considerations for use and implementation of Mesh 1741 services and applications are described in the Mesh Security 1742 Considerations guide . [draft-hallambaker-mesh-security] 1744 7. IANA Considerations 1746 This document does not contain actions for IANA 1748 8. Acknowledgements 1750 Comodo Group: Egemen Tas, Melhi Abdulhayo?lu, Rob Stradling, Robin 1751 Alden. 1753 9. Normative References 1755 [draft-hallambaker-jsonbcd] 1756 Hallam-Baker, P., "Binary Encodings for JavaScript Object 1757 Notation: JSON-B, JSON-C, JSON-D", Work in Progress, 1758 Internet-Draft, draft-hallambaker-jsonbcd-15, 23 October 1759 2019, . 1762 [draft-hallambaker-mesh-cryptography] 1763 Hallam-Baker, P., "Mathematical Mesh 3.0 Part VIII: 1764 Cryptographic Algorithms", Work in Progress, Internet- 1765 Draft, draft-hallambaker-mesh-cryptography-05, 16 January 1766 2020, . 1769 [draft-hallambaker-mesh-dare] 1770 Hallam-Baker, P., "Mathematical Mesh 3.0 Part III : Data 1771 At Rest Encryption (DARE)", Work in Progress, Internet- 1772 Draft, draft-hallambaker-mesh-dare-07, 9 March 2020, 1773 . 1776 [draft-hallambaker-mesh-developer] 1777 Hallam-Baker, P., "Mathematical Mesh: Reference 1778 Implementation", Work in Progress, Internet-Draft, draft- 1779 hallambaker-mesh-developer-09, 23 October 2019, 1780 . 1783 [draft-hallambaker-mesh-platform] 1784 Hallam-Baker, P., "Mathematical Mesh: Platform 1785 Configuration", Work in Progress, Internet-Draft, draft- 1786 hallambaker-mesh-platform-05, 23 October 2019, 1787 . 1790 [draft-hallambaker-mesh-protocol] 1791 Hallam-Baker, P., "Mathematical Mesh 3.0 Part V: Protocol 1792 Reference", Work in Progress, Internet-Draft, draft- 1793 hallambaker-mesh-protocol-05, 9 March 2020, 1794 . 1797 [draft-hallambaker-mesh-schema] 1798 Hallam-Baker, P., "Mathematical Mesh 3.0 Part IV: Schema 1799 Reference", Work in Progress, Internet-Draft, draft- 1800 hallambaker-mesh-schema-05, 16 January 2020, 1801 . 1804 [draft-hallambaker-mesh-security] 1805 Hallam-Baker, P., "Mathematical Mesh 3.0 Part VII: 1806 Security Considerations", Work in Progress, Internet- 1807 Draft, draft-hallambaker-mesh-security-04, 9 March 2020, 1808 . 1811 [draft-hallambaker-mesh-trust] 1812 Hallam-Baker, P., "Mathematical Mesh 3.0 Part VI: The 1813 Trust Mesh", Work in Progress, Internet-Draft, draft- 1814 hallambaker-mesh-trust-05, 9 March 2020, 1815 . 1818 [draft-hallambaker-mesh-udf] 1819 Hallam-Baker, P., "Mathematical Mesh 3.0 Part II: Uniform 1820 Data Fingerprint.", Work in Progress, Internet-Draft, 1821 draft-hallambaker-mesh-udf-09, 9 March 2020, 1822 . 1825 [draft-hallambaker-web-service-discovery] 1826 Hallam-Baker, P., "DNS Web Service Discovery", Work in 1827 Progress, Internet-Draft, draft-hallambaker-web-service- 1828 discovery-03, 23 October 2019, 1829 . 1832 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1833 Requirement Levels", BCP 14, RFC 2119, 1834 DOI 10.17487/RFC2119, March 1997, 1835 . 1837 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1838 (TLS) Protocol Version 1.2", RFC 5246, 1839 DOI 10.17487/RFC5246, August 2008, 1840 . 1842 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 1843 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1844 2014, . 1846 [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 1847 (HTTP/1.1): Semantics and Content", RFC 7231, 1848 DOI 10.17487/RFC7231, June 2014, 1849 . 1851 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 1852 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 1853 2015, . 1855 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 1856 RFC 7516, DOI 10.17487/RFC7516, May 2015, 1857 .