idnits 2.17.1 draft-hallambaker-mesh-architecture-11.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 : ---------------------------------------------------------------------------- ** There are 8 instances of too long lines in the document, the longest one being 27 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == 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 == Line 1615 has weird spacing: '...command is no...' -- The document date (October 23, 2019) is 1647 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 1799 -- Looks like a reference, but probably isn't: '2' on line 1802 -- Looks like a reference, but probably isn't: '3' on line 1805 -- Looks like a reference, but probably isn't: '4' on line 1808 -- Looks like a reference, but probably isn't: '5' on line 1811 -- Looks like a reference, but probably isn't: '6' on line 1814 -- Looks like a reference, but probably isn't: '7' on line 1817 -- Looks like a reference, but probably isn't: '8' on line 1820 -- Looks like a reference, but probably isn't: '9' on line 1823 -- Looks like a reference, but probably isn't: '10' on line 1826 -- Looks like a reference, but probably isn't: '11' on line 1829 -- Looks like a reference, but probably isn't: '12' on line 1832 -- Looks like a reference, but probably isn't: '13' on line 1835 -- Looks like a reference, but probably isn't: '14' on line 1838 -- Looks like a reference, but probably isn't: '15' on line 1841 -- Looks like a reference, but probably isn't: '16' on line 1844 -- Looks like a reference, but probably isn't: '17' on line 1847 -- Looks like a reference, but probably isn't: '18' on line 1850 -- Looks like a reference, but probably isn't: '19' on line 1853 ** 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: 5 errors (**), 0 flaws (~~), 3 warnings (==), 20 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hallam-Baker 3 Internet-Draft October 23, 2019 4 Intended status: Informational 5 Expires: April 25, 2020 7 Mathematical Mesh 3.0 Part I: Architecture Guide 8 draft-hallambaker-mesh-architecture-11 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 [1] . 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 April 25, 2020. 50 Copyright Notice 52 Copyright (c) 2019 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 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 2.1. Related Specifications . . . . . . . . . . . . . . . . . 6 70 2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 6 71 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 6 72 2.4. Implementation Status . . . . . . . . . . . . . . . . . . 6 73 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 7 74 3.1. A Personal PKI . . . . . . . . . . . . . . . . . . . . . 9 75 3.1.1. Device Management . . . . . . . . . . . . . . . . . . 9 76 3.1.2. Exchange of trusted credentials. . . . . . . . . . . 10 77 3.1.3. Application configuration management . . . . . . . . 10 78 3.1.4. The Mesh as platform . . . . . . . . . . . . . . . . 11 79 3.2. Mesh Architecture . . . . . . . . . . . . . . . . . . . . 11 80 3.2.1. Mesh Device Management . . . . . . . . . . . . . . . 13 81 3.2.2. Mesh Account . . . . . . . . . . . . . . . . . . . . 13 82 3.2.3. Mesh Service . . . . . . . . . . . . . . . . . . . . 15 83 3.2.4. Mesh Messaging . . . . . . . . . . . . . . . . . . . 16 84 3.3. Using the Mesh with Applications . . . . . . . . . . . . 17 85 3.3.1. Contact Exchange . . . . . . . . . . . . . . . . . . 17 86 3.3.2. Confirmation Protocol . . . . . . . . . . . . . . . . 18 87 3.3.3. Future Applications . . . . . . . . . . . . . . . . . 18 88 4. Mesh Cryptography . . . . . . . . . . . . . . . . . . . . . . 19 89 4.1. Best Practice by Default . . . . . . . . . . . . . . . . 19 90 4.2. Multi-Level Security . . . . . . . . . . . . . . . . . . 20 91 4.3. Multi-Key Decryption . . . . . . . . . . . . . . . . . . 20 92 4.4. Multi-Party Key Generation . . . . . . . . . . . . . . . 21 93 4.5. Data At Rest Encryption . . . . . . . . . . . . . . . . . 21 94 4.5.1. DARE Envelope . . . . . . . . . . . . . . . . . . . . 22 95 4.5.2. Dare Container . . . . . . . . . . . . . . . . . . . 22 96 4.6. Uniform Data Fingerprints. . . . . . . . . . . . . . . . 23 97 4.6.1. Friendly Names . . . . . . . . . . . . . . . . . . . 23 98 4.6.2. Encrypted Authenticated Resource Locators . . . . . . 24 99 4.6.3. Secure Internet Names . . . . . . . . . . . . . . . . 25 100 4.7. Personal Key Escrow . . . . . . . . . . . . . . . . . . . 25 101 5. User Experience . . . . . . . . . . . . . . . . . . . . . . . 26 102 5.1. Creating a Mesh Profile and Administration Device. . . . 27 103 5.2. Mesh Accounts . . . . . . . . . . . . . . . . . . . . . . 28 104 5.3. Mesh Service . . . . . . . . . . . . . . . . . . . . . . 29 105 5.4. Connecting and Authorizing Additional Devices . . . . . . 29 106 5.4.1. Direct Connection . . . . . . . . . . . . . . . . . . 30 107 5.4.2. Pin Connection . . . . . . . . . . . . . . . . . . . 30 108 5.4.3. EARL/QR Code Connection . . . . . . . . . . . . . . . 31 109 5.5. Contact Requests . . . . . . . . . . . . . . . . . . . . 32 110 5.5.1. Remote . . . . . . . . . . . . . . . . . . . . . . . 33 111 5.5.2. Static QR Code . . . . . . . . . . . . . . . . . . . 34 112 5.5.3. Dynamic QR Code . . . . . . . . . . . . . . . . . . . 34 113 5.6. Sharing Confidential Data in the Cloud . . . . . . . . . 34 114 5.7. Escrow and Recovery of Keys . . . . . . . . . . . . . . . 36 115 6. Security Considerations . . . . . . . . . . . . . . . . . . . 37 116 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 117 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 118 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 119 9.1. Normative References . . . . . . . . . . . . . . . . . . 37 120 9.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 39 121 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 40 123 1. Introduction 125 The Mathematical Mesh (Mesh) is a user centered Public Key 126 Infrastructure that uses cryptography to make computers easier to 127 use. The Mesh provides an infrastructure that addresses the three 128 concerns that have proved obstacles to the use of end-to-end security 129 in computer applications: 131 o Device management. 133 o Exchange of trusted credentials. 135 o Application configuration management. 137 The infrastructure developed to address these original motivating 138 concerns can be used to facilitate deployment and use of existing 139 security protocols (OpenPGP, S/MIME, SSH) and as a platform for 140 building end-to-end secure network applications. Current Mesh 141 applications include: 143 o Multi-factor authentication and confirmation 145 o Credential management 146 o Bookmark/Citation management 148 o Task and workflow management 150 A core principle of the design of the Mesh is that each person is 151 their own source of authority. They may choose to delegate that 152 authority to another to act on their behalf (i.e. a Trusted Third 153 Party) and they may choose to surrender parts of that authority to 154 others (e.g. an employer) for limited times and limited purposes. 156 Thus, from the user's point of view, the Mesh is divided into two 157 parts. The first and most important of these from their point of 158 view being their own personal Mesh. The second being the ensemble of 159 every Mesh to which their Mesh is connected. As with the Internet, 160 which is a network of networks, a Mesh of Meshes has certain 161 properties that are similar to those of its constituent parts and 162 some that are very different. 164 This document is not normative. It provides an overview of the Mesh 165 comprising a description of the architecture, and a discussion of 166 typical use cases and requirements. The remainder of the document 167 series provides a summary of the principal components of the Mesh 168 architecture and their relationship to each other. 170 Normative descriptions of the individual Mesh encodings, data 171 structures and protocols are provided in separate documents 172 addressing each component in turn. 174 The currently available Mesh document series comprises: 176 I. Architecture (This document.) Provides an overview of the Mesh 177 as a system and the relationship between its constituent parts. 179 II. Uniform Data Fingerprint . Describes the UDF format used to 180 represent cryptographic nonces, keys and content digests in the 181 Mesh and the use of Encrypted Authenticated Resource Locators 182 (EARLs) and Strong Internet Names (SINs) that build on the UDF 183 platform. 185 III. Data at Rest Encryption . Describes the cryptographic message 186 and append-only sequence formats used in Mesh applications and the 187 Mesh Service protocol. 189 IV. Schema Reference . Describes the syntax and semantics of Mesh 190 Profiles, Container Entries and Mesh Messages and their use in 191 Mesh Applications. 193 V. Protocol Reference . Describes the Mesh Service Protocol. 195 VI. The Trust Mesh . Describes the social work factor metric used 196 to evaluate the effectiveness of different approaches to exchange 197 of credentials between users and organizations in various contexts 198 and argues for a hybrid approach taking advantage of direct trust, 199 Web of Trust and Trusted Third Party models to provide 200 introductions. 202 VII. Security Considerations . Describes the security 203 considerations for the Mesh protocol suite. 205 VIII Cryptographic Algorithms . Describes the recommended and 206 required algorithm suites for Mesh applications and the 207 implementation of the multi-party cryptography techniques used in 208 the Mesh. 210 The following documents describe technologies that are used in the 211 Mesh but do not form part of the Mesh specification suite: 213 JSON-BCD Encoding . Describes extensions to the JSON serialization 214 format to allow direct encoding of binary data (JSON-B), 215 compressed encoding (JSON-C) and extended binary data encoding 216 (JSON-D). Each of these encodings is a superset of the previous 217 one so that JSON-B is a superset of JSON, JSON-C is a superset of 218 JSON-B and JSON-D is a superset of JSON-C. 220 DNS Web Service Discovery . Describes the means by which prefixed 221 DNS SRV and TXT records are used to perform discovery of Web 222 Services. 224 The following documents describe aspects of the Mesh Reference 225 implementation: 227 Mesh Developer . Describes the reference code distribution license 228 terms, implementation status and currently supported functions. 230 Mesh Platform . Describes how platform specific functionality such 231 as secure key storage and trustworthy computing features are 232 employed in the Mesh. 234 2. Definitions 236 This section presents the related specifications and standards on 237 which the Mesh is built, the terms that are used as terms of art 238 within the Mesh protocols and applications and the terms used as 239 requirements language. 241 2.1. Related Specifications 243 Besides the documents that form the Mesh core, the Mesh makes use of 244 many existing Internet standards, including: 246 Cryptographic Algorithms The RECOMMENDED and REQUIRED cryptographic 247 algorithms for Mesh implementations are specified in 248 [draft-hallambaker-mesh-cryptography] . 250 In addition Mesh Devices used to administer non-Mesh applications 251 must support the cryptographic algorithm suites specified by the 252 application. 254 Transport All Mesh Services make use of multiple layers of security. 255 Protection against traffic analysis and metadata attacks are 256 provided by use of Transport Layer Security [RFC5246] . At 257 present, the HTTP/1.1 [RFC7231] protocol is used to provide 258 framing of transaction messages. 260 Encoding All Mesh protocols and data structures are expressed in the 261 JSON data model and all Mesh applications accept data in standard 262 JSON encoding [RFC7159] . The JOSE Signature [RFC7515] and 263 Encryption [RFC7516] standards are used as the basis for object 264 signing and encryption. 266 2.2. Defined Terms 268 TBS 270 2.3. Requirements Language 272 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 273 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 274 document are to be interpreted as described in RFC 2119 [RFC2119] . 276 2.4. Implementation Status 278 The implementation status of the reference code base is described in 279 the companion document [draft-hallambaker-mesh-developer] . 281 The examples in this document were created on 10/23/2019 4:59:01 PM. 282 Out of 170 examples, 68 were not functional. 284 [Note: Example data is now being produced using the mesh command line 285 tool which is currently substantially less complete than the Mesh 286 reference code it is intended to provide an interface to. As a 287 result, the documentation currently lags the code by more than is 288 usual.] 290 3. Architecture 292 The Mathematical Mesh (Mesh) is a user centered Public Key 293 Infrastructure that uses cryptography to make computers easier to 294 use. This document describes version 3.0 of the Mesh architecture 295 and protocols. 297 For several decades, it has been widely noted that most users are 298 either unwilling or unable to make even the slightest efforts to 299 protect their security, still less those of other parties. Yet 300 despite this observation being widespread, the efforts of the IT 301 security community have largely focused on changing this user 302 behavior rather that designing applications that respect it. Real 303 users have real work to do and have neither the time nor the 304 inclination to use tools that will negatively impact their 305 performance. 307 The Mesh is based on the principle that if the Internet is to be 308 secure, if must become effortless to use applications securely. 309 Rather than beginning the design process by imagining all the 310 possible modes of attack and working out how to address these with 311 the least possible inconvenience, we must reverse the question and 312 ask how much security can be provided without requiring any effort on 313 the user's part to address it. 315 Today's technology requires users to put their trust in an endless 316 variety of devices, software and services they cannot fully 317 understand let alone control. Even the humble television of the 318 20^th century has been replaced by a 'smart' TV with 15 million lines 319 of code. Whose undeclared capabilities may well include placing the 320 room in which it is placed under continuous audio and video 321 surveillance. 323 Every technology deployment by necessity requires some degree of 324 trust on the owner/user's part. But this trust should be limited and 325 subject to accountability. If manufacturers continue to fail in this 326 regard, they risk a backlash in which users seek to restore their 327 rights through litigation, legislation or worst of all, simply not 328 buying more technology that they have learned to distrust through 329 their own experience. 331 The Mesh is based on the principle of radical distrust, that is, if a 332 party is capable of defecting, we assume that they will. As the 333 Russian proverb goes: ???????, ?? ????????: trust, but verify. 335 In the 1990s, the suggestion that 'hackers' might seek to make 336 financial gains from their activities was denounced as 'fear- 337 mongering'. The suggestion that email or anonymous currencies might 338 be abused received a similar response. Today malware, ransomware and 339 spam have become so ubiquitous that they are no longer news unless 340 the circumstances are particularly egregious. 342 We must dispense with the notion that it is improper or impolite to 343 question the good faith of technology suppliers of any kind whether 344 they be manufacturers, service providers, software authors or 345 reviewers. Modern supply chains are complex, typically involving 346 hundreds if not thousands of potential points of deliberate or 347 accidental compromise. The technology provider who relies on the 348 presumption of good faith on their part risks serious damage to their 349 reputation when others assert that a capability added to their 350 product may have malign uses. 352 Radical distrust means that we apply the principles of least 353 principle and accountability at every level in the design: 355 o Cryptographic keys installed in a product during manufacture are 356 only used for the limited purpose of putting that device under 357 control of the user. 359 o Cryptographic keys and assertions related to management of devices 360 are only visible to the user they belong to and are never exposed 361 to external parties. 363 o Mesh Accounts belong to and are under control of the user they 364 belong to and not the Mesh Service provider which the user can 365 change at will with minimal inconvenience. 367 o Mesh Services do not have access to the plaintext of any Mesh 368 Messages or Mesh Catalog data except for the Contacts catalog. 370 o All Mesh Messages are subject to access control by both the 371 inbound and outbound Mesh Service to mitigate messaging abuse. 373 Security is risk management and not the elimination of all 374 possibility of any risk. Radical distrust means that we raise the 375 bar for attackers to the point where for most attackers the risk is 376 greater than the reward. 378 In addition to distrusting technology providers the Mesh Architecture 379 allows the user to limit the degree of trust they place in 380 themselves. In the real world, devices are lost or stolen, passwords 381 and activation codes are forgotten, natural or man-made catastrophes 382 cause property and data to be lost. The Mesh permits but does not 383 require use of escrow techniques that allow recovery from such 384 situations. 386 3.1. A Personal PKI 388 The Mesh is a Public Key Infrastructure (PKI) that is designed to 389 address the three major obstacles to deployment of end-to-end secure 390 applications: 392 o Device management. 394 o Exchange of trusted credentials. 396 o Application configuration management. 398 Each Mesh user is the ultimate source of authority in their Personal 399 Mesh which specifies the set of devices, contacts and applications 400 that they trust and for what purposes. 402 The Mesh 1.0 architecture described a PKI designed to meet these 403 limited requirements to enable use of existing end-to-end secure 404 Internet protocols such as OpenPGP, S/MIME and SSH. Since these 405 protocols only secure data in transit and the vast majority of data 406 breaches involve data at rest, the Data At Rest Encryption (DARE) was 407 added as a layered application resulting in the Mesh 2.0 408 architecture. This document describes the Mesh 3.0 architecture 409 which has been entirely re-worked so that DARE provides the platform 410 on which all other Mesh functions are built. 412 3.1.1. Device Management 414 Existing PKIs were developed in an era when the 'personal computer' 415 was still coming into being. Only a small number of people owned a 416 computer and an even smaller number owned more than one. Today, 417 computers are ubiquitous and a typical home in the developed world 418 contains several hundred of which a dozen or more may have some form 419 of network access. 421 The modern consumer faces a problem of device management that is 422 considerably more complex than the IT administrator of a small 423 business might have faced in the 1990s but without any of the network 424 management tools such an administrator would expect to have 425 available. 427 One important consequence of the proliferation of devices is that 428 end-to-end security is no longer sufficient. To be acceptable to 429 users, a system must be ends-to-ends secure. That is, a user must be 430 able to read their encrypted email message on their laptop, tablet, 431 phone, or watch with exactly the same ease of use as if the mail was 432 unencrypted. 434 Each personal Mesh contains a device catalog in which the 435 cryptographic credentials and device specific application 436 configurations for each connected device are stored. 438 Management of the device catalog is restricted to a subset of devices 439 that the owner of the Mesh has specifically authorized for that 440 purpose as administration devices. Only a device with access to a 441 duly authorized administration key can add or remove devices from a 442 personal Mesh. 444 3.1.2. Exchange of trusted credentials. 446 One of the most challenging, certainly the most contentious issues in 447 PKI is the means by which cryptographic credentials are published and 448 validated. 450 The Mesh does not attempt to impose criteria for accepting 451 credentials as valid as no such set of criteria can be comprehensive. 452 Rather the Mesh allows users to make use of the credential validation 453 criteria that are appropriate to the purpose for which they intend to 454 use them and Mesh Services provides protocol support for exchange of 455 credentials between users and to synchronize credential information 456 between all the devices belonging to a user. 458 In some circumstances, only a direct trust model is acceptable, in 459 others, only a trusted third-party model is possible and in the vast 460 majority of cases opportunistic approaches are more than sufficient. 461 Both approaches may be reinforced by use of chained notary 462 certificate (e.g. BlockChain) technology affords a means of 463 establishing that a particular assertion was made before a certain 464 date. The management of Trust in the Mesh is described in detail in 465 [draft-hallambaker-mesh-trust] . 467 3.1.3. Application configuration management 469 Configuration of cryptographic applications is typically worse than 470 an afterthought. Configuration of one popular mail user agent to use 471 S/MIME security requires 17 steps to be performed using four separate 472 application programs. And since S/MIME certificates expire, the user 473 is required to repeat these steps every few years. Contrary to the 474 public claims made by one major software vendor it is not necessary 475 to perform 'usability testing' to recognize abject stupidity. 477 Rather than writing down configuration steps and giving them to the 478 user, we should turn them into code and give them to a machine. 479 Users should never be required to do the work of the machine. Nor 480 should any programmer be allowed to insult the user by casting their 481 effort aside and requiring it to be re-entered. 483 While most computer professionals who are required to do such tasks 484 on a regular basis will create a tool for the purpose, most users do 485 not have that option. And of those who do write their own tools, 486 only a few have the time and the knowledge to do the job without 487 introducing security vulnerabilities. 489 3.1.4. The Mesh as platform 491 Meeting the core objectives of the Mesh required new naming, 492 communication and cryptographic capabilities provided to be 493 developed. These capabilities may in turn be used to develop new 494 end-to-end secure applications. 496 For example, a DARE Catalog is a cryptographic container in which the 497 entries represent a set of objects which may be added, updated and 498 deleted over time. The Mesh Service protocol allows DARE Catalogs to 499 be synchronized between devices connected to a Mesh Account. DARE 500 Catalogs are used as the basis for the device and contacts catalogs 501 referred to above. 503 The Mesh Credentials Catalog uses the same DARE Catalog format and 504 Mesh Service protocol to share passwords between devices with end-to- 505 end encryption so that no password data is ever left unencrypted in 506 the cloud. 508 3.2. Mesh Architecture 510 The Mesh has four principal components: 512 Mesh Device Management Each user has a personal Mesh profile that is 513 used for management of their personal devices. A user may connect 514 devices to or remove devices from their personal Mesh by use of a 515 connected device that has been granted the 'administration' role. 517 Mesh Account A Mesh account is similar in concept to a traditional 518 email or messaging account but with the important difference that 519 it belongs to the user and not a service provider. Users may 520 maintain multiple Mesh accounts for different purposes. 522 Mesh Service A Mesh Service provides a service identifier (e.g. 523 alice@example.com) through which devices and other Mesh users may 524 interact with a Mesh Account. It is not necessary for a Mesh 525 Account to be connected to a Mesh Service and users may change 526 their Mesh service provider at any time. It is even possible for 527 a Mesh Account to be connected to multiple services at the same 528 time but only one such account is regarded as the primary account 529 at a given time. 531 Mesh Messaging Mesh Messaging allows short messages (less than 32KB) 532 to be exchanged between Mesh devices connected to an account and 533 between Mesh Accounts. One of the key differences between Mesh 534 Messaging and legacy services such as SMTP is that every message 535 received is subjected to access control. 537 A user's Personal Mesh is the set of their Personal Mesh Profiles, 538 Mesh Accounts and the Mesh Services to which they are bound. 540 For example, Figure X shows Alice's personal Mesh which have separate 541 accounts for her personal and business affairs. She has many 542 devices, two of which are shown here. Both are linked to her 543 personal account but only one is linked to her business account. 544 Besides allowing Alice to separate work and pleasure, this separation 545 means that she does not need to worry about her business affairs 546 being compromised if the device Alice2 is stolen. 548 [[This figure is not viewable in this format. The figure is 549 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 550 architecture.html [2].]] 552 Master Profile and Subordinate Devices and Accounts. 554 Alice's ProfileMaster contains a Master Signature Key used to sign 555 the profile itself and one or more Administrator Signature Keys used 556 to sign assertions binding devices and/or assertions to her Mesh. 558 [[This figure is not viewable in this format. The figure is 559 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 560 architecture.html [3].]] 562 Master Profile and Associated Device and Account Connection 563 Assertions. 565 If desired, Alice can escrow the master key associated with her 566 Profile Master and delete it from her device(s), thus ensuring that 567 compromise of the device does not result in a permanent compromise of 568 her personal Mesh. Recovery of the Master Signature Key and the 569 associated Master Encryption Escrow keys (not shown) allows Alice to 570 recover her entire digital life. 572 To eliminate the risk of hardware failure, the escrow scheme offered 573 by the Mesh itself uses key shares printed on paper and an encrypted 574 escrow record stored in the cloud. Mesh users are of course free to 575 use alternative escrow means of their choice. 577 3.2.1. Mesh Device Management 579 Mesh devices are added to or removed from a user's personal Mesh by 580 adding or removing Device catalog entries from the CatalogDevice 581 associated with the Master Profile. 583 Device catalog entries are created by devices that have been 584 provisioned with an administration key specified in the corresponding 585 ProfileMaster 587 The keying material used by a device in the context of a user's 588 personal Mesh comes from two separate sources: 590 o Keying material specified in the ProfileDevice which is either 591 generated on the device itself or installed during manufacture. 593 o Keying material provided by the Administration Device during the 594 connection process. 596 This approach mitigates the risk of keying material used by the 597 device being compromised during or after manufacture and the risks 598 associated with use of weak keys. The key combination mechanism is 599 shown in section XX below and described in detail in 600 [draft-hallambaker-mesh-cryptography] . 602 [[This figure is not viewable in this format. The figure is 603 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 604 architecture.html [4].]] 606 Mapping of Device Profile and Device Private to Device Connection 607 Keys. 609 In accordance with the principle of maintaining cryptographic 610 hygiene, separate keys are generated for signature, authentication 611 and encryption purposes. 613 3.2.2. Mesh Account 615 Mesh Accounts comprise a collection of persistent data stores 616 associated with a particular persona associated with a personal Mesh. 617 The connection between a Mesh Account and the personal Mesh to which 618 it belongs may or may not be public. For example, Alice might allow 619 her contacts to know that her business and personal accounts belong 620 to the same personal Mesh and thus the same person but Bob might not. 622 Mesh Accounts afford similar functionality to the accounts provided 623 by traditional Internet protocols and applications but with the 624 important distinction that they belong to the user and not the 625 service provider. A Mesh Account may be connected to one, many or no 626 Mesh Services and the user may add or delete service providers at any 627 time. 629 A Mesh Account that is not connected to a Service is called an 630 offline account. Offline accounts cannot send or receive Mesh 631 Messages and cannot be synchronized using the Mesh Service protocol 632 (but may be synchronized through other means). 634 When a Mesh Account is connected to multiple services, only the first 635 service is normally regarded as being primary with the others being 636 secondary accounts for use in case of need. 638 Alice's personal account is connected to two devices and two services 639 (alice@example.com and alice@example.net). 641 [[This figure is not viewable in this format. The figure is 642 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 643 architecture.html [5].]] 645 Account Profile Connected to Devices and Services. 647 As with the connection of the device to Alice's personal Mesh, the 648 connection of each device to each account requires the creation of a 649 separate set of keying using the same key combination mechanism 650 described above. This information is contained in the 651 ActivationAccount record corresponding to the account in the 652 CatalogEntryDevice. 654 [[This figure is not viewable in this format. The figure is 655 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 656 architecture.html [6].]] 658 Account Key Set. 660 Note that even though Alice's personal account is connected to two 661 separate Mesh Services, the same cryptographic keys are used for 662 both. However separate keys are used for her personal and business 663 accounts so as to prevent these accounts being linked through use of 664 the same device keys. 666 3.2.2.1. Account Catalogs 668 Mesh Catalogs are a DARE Containers whose entries represent a set of 669 objects with no inherent ordering. Examples of Mesh catalogs 670 include: 672 Devices The devices connected to the corresponding Mesh profile. 674 Contacts Logical and physical contact information for people and 675 organizations. 677 Application 679 Application 681 Bookmarks Web bookmarks and citations. 683 Credentials Username and password information for network resources. 685 Calendar Appointments and tasks. 687 Network Network access configuration information allowing access to 688 WiFi networks and VPNs. 690 Configuration information for applications including mail (SMTP, 691 IMAP, OpenPGP, S/MIME, etc) and SSH. 693 The Devices and Contacts catalogues have special functions in the 694 Mesh as they describe the set of devices and other users that a Mesh 695 user interacts with. 697 These catalogs are also used as the basis for providing a consistent 698 set of friendly names to the users devices and contacts that is 699 accessible to all her devices. This (in principle) allows Alice to 700 give a voice command to her car or her watch or her phone to call a 701 person or open a door and expect consistent results. 703 3.2.3. Mesh Service 705 Each Mesh Service is described by a ProfileService signed by a long- 706 lived signature key. As with the ProfileMaster, a separate set of 707 Administrator keys is used to sign the Assertion Host objects used to 708 credential Service Hosts. 710 [[This figure is not viewable in this format. The figure is 711 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 712 architecture.html [7].]] 714 Service Profile and Delegated Host Assertion. 716 Note that the Mesh Service Authentication mechanism only provides 717 trust after first use. It does not provide a mechanism for secure 718 introduction. A Mesh Service SHOULD be credentialed by means of a 719 validation process that establishes the accountability. For example, 720 the CA-Browser Forum Extended Validation Requirements. 722 3.2.4. Mesh Messaging 724 The Mesh Messaging layer supports the exchange of short (less than 725 32KB) messages. Mesh devices connected to the same Mesh profile may 726 exchange Mesh Messages directly. Messages exchanged between Mesh 727 Users MUST be mediated by a Mesh Service for both sending and 728 receipt. This 'four corner' pattern permits ingress and egress 729 controls to be enforced on the messages and that every message is 730 properly recorded in the appropriate spools. 732 For example, To send a message to Alice, Bob posts it to one of the 733 Mesh Services connected to the Mesh Account from which the message is 734 to be sent. The Mesh Service checks to see that both the message and 735 Bob's pattern of behavior comply with their acceptable use policy and 736 if satisfactory, forwards the message to the receiving service 737 example.com. 739 [[This figure is not viewable in this format. The figure is 740 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 741 architecture.html [8].]] 743 Performing Access Control on Outbound Messages 745 The receiving service uses the recipient's contact catalog and other 746 information to determine if the message should be accepted. If 747 accepted, the message is added to the recipient's inbound message 748 spool to be collected by her device(s) when needed. 750 [[This figure is not viewable in this format. The figure is 751 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 752 architecture.html [9].]] 754 Performing Access Control on Inbound Messages 755 For efficiency and to limit the scope for abuse, all inbound Mesh 756 Messages are subject to access control and limited in size to 32KB or 757 less. This limit has proved adequate to support transfer of complex 758 control messages and short content messages. Transfer of data 759 objects of arbitrary size may be achieved by sending a control 760 message containing a URI for the main content which may then be 761 fetched using a protocol such as HTTP. 763 This approach makes transfers of very large data sets (i.e. multiple 764 Terabytes) practical as the 'push' phase of the protocol is limited 765 to the transfer of the initial control message. The bulk transfer is 766 implemented as a 'pull' protocol allowing support for features such 767 as continuous integrity checking and resumption of an interrupted 768 transfer. 770 3.3. Using the Mesh with Applications 772 The Mesh provides an infrastructure for supporting existing Internet 773 security applications and a set security features that may be used to 774 build new ones. 776 For example, Alice uses the Mesh to provision and maintain the keys 777 she uses for OpenPGP, S/MIME, SSH and IPSEC. She also uses the 778 credential catalog for end-to-end secure management of the usernames 779 and passwords for her Web browsing and other purposes: 781 [[This figure is not viewable in this format. The figure is 782 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 783 architecture.html [10].]] 785 Each of Alice's devices have access to the shared context of her 786 personal account. 788 The Mesh design is highly modular allowing components that were 789 originally designed to support a specific requirement within the Mesh 790 to be applied generally. 792 3.3.1. Contact Exchange 794 One of the chief concerns in any PKI is the means by which the public 795 keys of other users are obtained and validated. This is of 796 particular importance in the Mesh since every Mesh Message is subject 797 to access control and it is thus necessary for Alice to accept Bob's 798 credentials before Bob send most types of message to Alice. 800 The Mesh supports multiple mechanisms for credential exchange. If 801 Alice and Bob meet in person and are carrying their smart phones, a 802 secure mutual exchange of credentials can be achieved by means of a 803 QR code mechanism. If they are at separate locations, Alice can 804 choose between accepting Bob's contact information with or without 805 additional verification according to the intended use. 807 3.3.2. Confirmation Protocol 809 The basic device connection protocol requires the ability for one 810 device to send a connection request to the Mesh service hosting the 811 user's profile. To accept the device connection, the user connects 812 to the service using an administration device, reviews the pending 813 requests and creates the necessary device connection assertion if it 814 is accepted. 816 The confirmation protocol generalizes this communication pattern 817 allowing any authorized party to post a short accept/reject question 818 to the user who may (or may not) return a signed response. This 819 feature can be used as improvement on traditional second factor 820 authentication providing resistance to man-in-the-middle attacks and 821 providing a permanent non-repudiable indication of the user's 822 specific intent. 824 3.3.3. Future Applications 826 Since a wide range of network applications may be reduced to 827 synchronization of sets and lists, the basic primitives of Catalogs 828 and Spools may be applied to achieve end-to-end security in an even 829 wider variety of applications. 831 For example, a Spool may be used to maintain a mailing list, track 832 comments on a Web forum or record annotations on a document. 833 Encrypting the container entries under a multi-party encryption group 834 allows such communications to be shared with a group of users while 835 maintaining full end-to-end security and without requiring every 836 party writing to the spool to know the public encryption key of every 837 recipient. 839 Another interesting possibility is the use of DARE Containers as a 840 file archive mechanism. A single signature on the final Merkle Tree 841 digest value would be sufficient to authenticate every file in the 842 archive. Updates to the archive might be performed using the same 843 container synchronization primitives provided by a Mesh Service. 844 This approach could afford a robust, secure and efficient mechanism 845 for software distribution and update. 847 4. Mesh Cryptography 849 All the cryptographic algorithms used in the Mesh are either industry 850 standards or present a work factor that is provably equivalent to an 851 industry standard approach. 853 Existing Internet security protocols are based on approaches 854 developed in the 1990s when performance tradeoffs were a prime 855 consideration in the design of cryptographic protocols. Security was 856 focused on the transport layer as it provided the best security 857 possible given the available resources. 859 With rare exceptions, most computing devices manufactured in the past 860 ten years offer either considerably more computing power than was 861 typical of 1990s era Internet connected machines or considerably 862 less. The Mesh architecture is designed to provide security 863 infrastructure both classes of machine but with the important 864 constraint that the less capable 'constrained' devices are considered 865 to be 'network capable' rather than 'Internet capable' and that the 866 majority of Mesh related processing will be offloaded to another 867 device. 869 For example, Alice uses her Desktop and Laptop to exchange end-to-end 870 secure Mesh Messages and documents but her Internet-of-Things food 871 blender and light bulb are limited in the range of functions they 872 support and the telemetry information they provide. The IoT devices 873 connect to a Mesh Hub which acts as an always-on point of presence 874 for the device state and allows complex cryptographic operations to 875 be offloaded if necessary. 877 [[This figure is not viewable in this format. The figure is 878 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 879 architecture.html [11].]] 881 Constrained Devices connected through a Mesh Hub. 883 4.1. Best Practice by Default 885 Except where support for external applications demand otherwise, the 886 Mesh requires that the following 'best practices' be followed: 888 Industry Standard Algorithms All cryptographic protocols make use of 889 the most recently adopted industry standard algorithms. 891 Strongest Work Factor Only the strongest modes of each cipher 892 algorithm are used. All symmetric encryption is performed with 893 256-bit session keys and all digest algorithms are used in 512-bit 894 output length mode. 896 Key Hygiene Separate public key pairs are used for all cryptographic 897 functions: Encryption, Signature and Authentication. This enables 898 separate control regimes for the separate functions and 899 partitioning of cryptographic functions within the application 900 itself. 902 Bound Device Keys Each device has a separate set of Encryption, 903 Signature and Authentication key pairs. These MAY be bound to the 904 device to which they are assigned using hardware or other 905 techniques to prevent or discourage export. 907 No Optional Extras Traditional approaches to security have treated 908 many functions as being 'advanced' and thus suited for use by only 909 the most sophisticated users. The Mesh rejects this approach 910 noting that all users operate in precisely the same environment 911 facing precisely the same threats. 913 4.2. Multi-Level Security 915 All Mesh protocol transactions are protected at the Transport, 916 Message and Data level. This provides security in depth that cannot 917 be achieved by applying security at the separate levels 918 independently. Data level encryption provides end-to-end 919 confidentiality and non-repudiation, Message level authentication 920 provides the basis for access control and Transport level encryption 921 provides a degree of protection against traffic analysis. 923 4.3. Multi-Key Decryption 925 Traditional public key encryption algorithms have two keys, one for 926 encryption and another for decryption. The Mesh makes use of 927 threshold cryptography techniques to allow the decryption key to be 928 split into two or more parts. 930 For example, if we have a private key z, we can use this to perform a 931 key agreement with a public key S to obtain the key agreement value 932 A. But if z = (x+y) mod g (where g is the order of the group). we 933 can obtain the exact same result by applying the private keys x and y 934 to S separately and combining the results: 936 [[This figure is not viewable in this format. The figure is 937 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 938 architecture.html [12].]] 940 Two key decryption. 942 The approach to Multi-Key Decryption used in the Mesh was originally 943 inspired by the work of Matt Blaze et. al. on proxy re-encryption. 944 But the approach used may also be considered a form of Torben 945 Pedersen's Distributed Key generation. 947 This technique is used in the Mesh to allow use of decryption key 948 held by a user to be controlled by a cloud service without giving the 949 cloud service the ability to decrypt by itself. 951 4.4. Multi-Party Key Generation 953 The mathematics that support multi-key decryption are also the basis 954 for the multi-party key generation mechanism that is applied at 955 multiple levels in the Mesh. The basis for the multi-party key 956 generation used in the Mesh is that for any Diffie-Hellman type 957 cryptographic scheme, given two keypairs { x, X }, { y, Y }, we 958 calculate the public key corresponding to the private key x + y using 959 just the public key values X and Y. 961 [[This figure is not viewable in this format. The figure is 962 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 963 architecture.html [13].]] 965 Two party key pair generation. 967 Multi-party key generation ensures that keys used to bind devices to 968 a personal Mesh or within a Mesh account are 'safe' if any of the 969 contributions to the generation process are safe. 971 4.5. Data At Rest Encryption 973 The Data At Rest Encryption (DARE) format is used for all 974 confidentiality and integrity enhancements. The DARE format is based 975 on the JOSE Signature and Encryption formats and the use of an 976 extended version of the JSON encoding allowing direct encoding of 977 binary objects. 979 4.5.1. DARE Envelope 981 The DARE Envelope format offers similar capabilities to existing 982 formats such as OpenPGP and CMS without the need for onerous encoding 983 schemes. DARE Assertions are presented as DARE Envelopes. 985 A feature of the DARE Envelope format not supported in existing 986 schemes is the ability to encrypt and authenticate sets of data 987 attributes separately from the payload. This allows features such as 988 the ability to encrypt a subject line or content type for a message 989 separately from the payload. 991 4.5.2. Dare Container 993 A DARE Container is an append-only sequence of DARE Envelopes. A key 994 feature of the DARE Container format is that entries MAY be encrypted 995 and/or authenticated incrementally. Individual entries MAY be 996 extracted from a DARE Container to create a stand-alone DARE 997 Envelope. 999 Containers may be authenticated by means of a Merkle tree of digest 1000 values on the individual frames. This allows similar demonstrations 1001 of integrity to those afforded by Blockchain to be provided but with 1002 much greater efficiency. 1004 Unlike traditional encryption formats which require a new public key 1005 exchange for each encrypted payload, the DARE Container format allows 1006 multiple entries to be encrypted under a single key exchange 1007 operation. This is particularly useful in applications such as 1008 encrypting server transaction logs. The server need only perform a 1009 single key exchange operation is performed each time it starts to 1010 establish a master key. The master key is then used to create fresh 1011 symmetric keying material for each entry in the log using a unique 1012 nonce per entry. 1014 [[This figure is not viewable in this format. The figure is 1015 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 1016 architecture.html [14].]] 1018 DARE Container containing a transaction log. 1020 Integrity is provided by a Merkle tree calculated over the sequence 1021 of log entries. The tree apex is signed at regular intervals to 1022 provide non-repudiation. 1024 Three types of DARE Containers are used in the mesh 1025 Catalogs A DARE Container whose entries track the status of a set of 1026 related objects which may be added, updated or deleted. 1028 Spools A DARE Container whose entries track the status of a series 1029 of Mesh Messages. 1031 Archives A DARE Container used to provide a file archive with 1032 optional confidentiality and/or integrity enhancements. 1034 4.6. Uniform Data Fingerprints. 1036 The Uniform Data Fingerprint (UDF) format provides a compact means of 1037 presenting cryptographic nonces, keys and digest values using Base32 1038 encoding that resists semantic substitution attacks. UDF provides a 1039 convenient format for data entry. Since the encoding used is case- 1040 insensitive, UDFs may if necessary be read out over a voice link 1041 without excessive inconvenience. 1043 The following are examples of UDF values: 1045 NAOG-SO34-PZST-L4CS-NUBM-CZ3M-JBPQ 1046 ED7V-Z4UG-RSR6-Q7YA-BRZI-7DJU-CZCA 1047 SAQJ-6SLQ-HYGR-2TPY-WN3W-K4PB-KXQU-Q 1048 MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4 1049 KCM5-7VB6-IJXJ-WKHX-NZQF-OKGZ-EWVN 1050 ADFL-RVVV-BFZS-JVSD-TUIR-PTWF-YEZ2 1052 UDF content digests are used to support a direct trust model similar 1053 to that of OpenPGP. Every Mesh Profile is authenticated by the UDF 1054 fingerprint of its signature key. Mesh Friendly Names and UDF 1055 Fingerprints thus serve analogous functions to DNS names and IP 1056 Addresses. Like DNS names, Friendly Names provide the basis for 1057 application-layer interactions while the UDF Fingerprints are used as 1058 to provide the foundation for security. 1060 4.6.1. Friendly Names 1062 Internet addressing schemes are designed to provide a globally unique 1063 (or at minimum unambiguous) name for a host, service or account. In 1064 the early days of the Internet, this resulted in addresses such as 1065 10.2.3.4 and alice@example.com which from a usability point of view 1066 might be considered serviceable if not ideal. Today the Internet is 1067 a global infrastructure servicing billions of users and tens of 1068 billions of devices and accounts are more likely to be 1069 alice.lastname.1934@example.com than something memorable. 1071 Friendly names provide a user or community specific means of 1072 identifying resources that may take advantage of geographic location 1073 or other cues to resolve possible ambiguity. If Alice says to her 1074 voice activated device "close the garage door" it is implicit that it 1075 is her garage door that she wishes to close. And should Alice be 1076 fortunate enough to own two houses with a garage, it is implicit that 1077 it is the garage door of the house she is presently using that she 1078 wishes to close. 1080 The Mesh Device Catalog provides a directory mapping friendly names 1081 to devices that is available to all Alice's connected devices so that 1082 she may give and instruction to any of her devices using the same 1083 friendly name and expect consistent results. 1085 4.6.2. Encrypted Authenticated Resource Locators 1087 Various schemes have been used to employ QR Codes as a means of 1088 device and/or user authentication. In many of these schemes a QR 1089 code contains a challenge nonce that is used to authenticate the 1090 connection request. 1092 The Mesh supports a QR code connection mode employing the Encrypted 1093 Authenticated Resource Locator (EARL) format. An EARL is an 1094 identifier which allows an encrypted data object to be retrieved and 1095 decrypted. In this case, the encrypted data object contains the 1096 information needed to complete the interaction. 1098 An EARL contains the domain name of the service providing the 1099 resolution service and an encryption master key: 1101 udf://example.com/EDPP-F6IN-LFYU-DTE4-5IF4-IDKL-BFOP-IA 1103 The EARL may be expressed as a QR code: 1105 [[This figure is not viewable in this format. The figure is 1106 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 1107 architecture.html [15].]] 1109 QR Code representation of the EARL 1111 An EARL is resolved by presenting the content digest fingerprint of 1112 the encryption key to a Web service hosted at the specified domain. 1113 The service returns a DARE Envelope whose payload is encrypted and 1114 authenticated under the specified master key. Since the content is 1115 stored on the service under the fingerprint of the key and not the 1116 key itself, the service cannot decrypt the plaintext. Only a party 1117 that has access to the encryption key in the QR code can decrypt the 1118 message. 1120 4.6.3. Secure Internet Names 1122 Secure Internet Names bind an Internet address such as a URL or an 1123 email address to a Security Policy by means of a UDF content digest 1124 of a document describing the security policy. This binding enables a 1125 SIN-aware Internet client to ensure that the security policy is 1126 applied when connecting to the address. For example, ensuring that 1127 an email sent to an address must be end-to-end encrypted under a 1128 particular public key or that access to a Web Service requires a 1129 particular set of security enhancements. 1131 alice@example.com Alice's regular email address (not a SIN). 1133 alice@mm--uuuu-uuuu-uuuu.example.com A strong email address for 1134 Alice that can be used by a regular email client. 1136 alice@example.com.mm--uuuu-uuuu-uuuu A strong email address for 1137 Alice that can only used by an email client that can process SINs. 1139 Using an email address that has the Security Policy element as a 1140 prefix allows a DNS wildcard element to be defined that allows the 1141 address to be used with any email client. Presenting the Security 1142 Policy element as a suffix means it can only be resolved by a SIN- 1143 aware client. 1145 4.7. Personal Key Escrow 1147 One of the core objectives of the Mesh is to make data level 1148 encryption ubiquitous. While data level encryption provides robust 1149 protection of data confidentiality, loss of the ability to decrypt 1150 means data loss. 1152 For many Internet users, data availability is a considerably greater 1153 concern than confidentiality. Ten years later, there is no way to 1154 replace pictures of the children at five years old. Recognizing the 1155 need to guarantee data recovery, the Mesh provides a robust personal 1156 key escrow and recovery mechanism. Lawful access is not supported as 1157 a requirement. 1159 Besides supporting key recovery in the case of loss, the Mesh 1160 protocols potentially support key recovery in the case of the key 1161 holder's death. The chief difficulty faced in implementing such a 1162 scheme being developing an acceptable user interface which allows the 1163 user to specify which of their data should survive them and which 1164 should not. As the apothegm goes: Mallet wants his beneficiaries to 1165 know where he buried Aunt Agatha's jewels but not where he buried 1166 Aunt Agatha. 1168 The Mesh supports use of Shamir Secret Sharing to split a secret key 1169 into a set of shares, a predetermined number of which may be used to 1170 recover the original secret. For convenience secret shares are 1171 represented using UDF allowing presentation in Base32 (i.e. text 1172 format) for easy transcription or QR code presentation if preferred. 1174 A Mesh Profile is escrowed by creating a recovery record containing 1175 the private keys corresponding to the master signature and master 1176 escrow keys associated with the profile. A master secret is then 1177 generated which is used to generate a symmetric encryption key used 1178 to encrypt the recovery record and to generate the desired number of 1179 recovery shares. For example, Alice escrows her Mesh Profile 1180 creating three recovery shares, two of which are required to recover 1181 the master secret: 1183 [[This figure is not viewable in this format. The figure is 1184 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 1185 architecture.html [16].]] 1187 Use of Shamir Secret Sharing to create a recovery record. 1189 To recover the master secret, Alice presents the necessary number of 1190 key shares. These are used to recover the master secret which is 1191 used to generate the decryption key. 1193 [[This figure is not viewable in this format. The figure is 1194 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 1195 architecture.html [17].]] 1197 Use of Shamir Secret Recovery to recover a master key set. 1199 A user may choose to store their encrypted recovery record themselves 1200 or make use of the EARL mechanism to store the information at one or 1201 more cloud services using the fingerprint of the master secret as the 1202 locator. 1204 5. User Experience 1206 This section describes the Mesh in use. These use cases described 1207 here are re-visited in the companion Mesh Schema Reference 1208 [draft-hallambaker-mesh-schema] and Mesh Protocol Reference 1209 [draft-hallambaker-mesh-protocol] with additional examples and 1210 details. 1212 For clarity and for compactness, these use cases are illustrated 1213 using the command line tool meshman. 1215 The original design brief for the Mesh was to make it easier to use 1216 the Internet securely. Over time, it was realized that users are 1217 almost never prepared to sacrifice usability or convenience for 1218 security. It is therefore insufficient to minimize the cost of 1219 security, if secure applications are to be used securely they must be 1220 at least as easy to use as those they replace. If security features 1221 are to be used, they must not require the user to make any additional 1222 effort whatsoever. 1224 The key to meeting this constraint is that any set of instructions 1225 that can be written down to be followed by a user can be turned into 1226 code and executed by machine. Provided that the necessary 1227 authentication, integrity and confidentiality controls are provided. 1228 Thus, the Mesh is not just a cryptographic infrastructure that makes 1229 use of computer systems more secure, it is a usability infrastructure 1230 that makes computers easier to use by providing security. 1232 The user experience is thus at the heart of the design of the Mesh 1233 and a description of the Mesh Architecture properly begins with 1234 consideration of the view of the system that matters most: that of 1235 the user. 1237 The principle security protocols in use today were designed at a time 1238 when most Internet users made use of either a single machine or one 1239 of a number of shared machines connected to a shared file store. The 1240 problem of transferring cryptographic keys and configuration data 1241 between machines was rarely considered and when it was considered was 1242 usually implemented badly. Today the typical user owns or makes use 1243 of multiple devices they recognize as a computer (laptop, tablet) and 1244 an even greater number of devices that they do not recognize as 1245 computers but are (almost any device with a display). 1247 [[This figure is not viewable in this format. The figure is 1248 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 1249 architecture.html [18].]] 1251 Alice's personal Mesh. 1253 5.1. Creating a Mesh Profile and Administration Device. 1255 The first step in using the Mesh is to create a personal profile. 1256 From the user's point of view a profile is a collection of all the 1257 configuration data for all the Mesh enabled devices and services that 1258 they interact with. 1260 Alice> mesh create 1261 Device Profile UDF=MBSX-KFPC-MKKB-RXMV-XLGT-7HPQ-NYKM 1262 Personal Profile UDF=MA4D-JPBO-ZPEK-JU62-RQWE-WO3F-77DD 1264 Note that the user does not specify the cryptographic algorithms to 1265 use. Choice of cryptographic algorithm is primarily the concern of 1266 the protocol designer, not the user. The only circumstance in which 1267 users would normally be involved in algorithm selection is when there 1268 is a transition in progress from one algorithm suite to another. 1270 5.2. Mesh Accounts 1272 Add an account to the personal Mesh: 1274 Alice> account create personal 1275 Account=MCW6-7L5H-5VSD-QG4G-AZLG-QMQA-MLVG 1277 A Mesh Catalog contains a set of entries, each of which has a unique 1278 object identifier. Catalog entries may be added, updated or deleted. 1280 By default, all catalog entries are encrypted. Applying the Default 1281 Deny principle, in normal circumstances, the Mesh Service is not 1282 capable of decrypting any catalog excepting the Contacts catalog 1283 which is used as a source of authorization data in the Access Control 1284 applied to inbound messaging requests. 1286 For example, the entries in the credentials catalog specify username 1287 and password credentials used to access Internet services. Adding 1288 credentials to her catalog allows Alice to write scripts that access 1289 password protected resources without including the passwords in the 1290 scripts themselves: 1292 Alice> password add ftp.example.com alice1 password 1293 alice1@ftp.example.com = [password] 1294 Alice> password add www.example.com alice@example.com newpassword 1295 alice@example.com@www.example.com = [newpassword] 1296 Alice> password list 1297 alice1@ftp.example.com = [password] 1298 alice@example.com@www.example.com = [newpassword] 1299 Alice> password add ftp.example.com alice1 newpassword 1300 alice1@ftp.example.com = [newpassword] 1301 Alice> password get ftp.example.com 1302 alice1@ftp.example.com = [newpassword] 1304 5.3. Mesh Service 1306 A Mesh Service provides an 'always available' point of presence that 1307 is used to exchange data between devices connected to the connected 1308 profile and send and receive Mesh Messages to and from other Mesh 1309 users. 1311 To use a Mesh Service, a user creates a Mesh Service account. This 1312 is analogous to an SMTP email service but with the important 1313 distinction that the protocol is designed to allow users to change 1314 their Mesh Service provider at any time they choose with minimal 1315 impact. 1317 The account is created by sending an account registration request to 1318 the chosen Mesh Service. If accepted, the Mesh Service creates a new 1319 account and creates containers to hold the associated catalogs and 1320 spools: 1322 Alice> account register alice@example.com 1323 Account=MCW6-7L5H-5VSD-QG4G-AZLG-QMQA-MLVG 1325 As with any other Internet service provision, Mesh Service providers 1326 may impose constraints on the use of their service such as the amount 1327 of data they send, store and receive and charge a fee for their 1328 service. 1330 5.4. Connecting and Authorizing Additional Devices 1332 Having established a Mesh profile, a user may connect any number of 1333 devices to it. Connecting a device to a Mesh profile allows it to 1334 share data with, control and be controlled by other devices connected 1335 to the profile. 1337 Although any type of network capable device may be connected to a 1338 Mesh profile, some devices are better suited for use with certain 1339 applications than others. Connecting an oven to a Mesh profile could 1340 allow it to be controlled through entries to the user's recipe and 1341 calendar catalogs and alert the user when the meal is ready but 1342 attempting to use it to read emails or manage Mesh profiles. 1344 Three connection mechanisms are currently specified, each of which 1345 provides strong mutual authentication: Direct, PIN and QR. 1347 Since approval of a connection request requires the creation of a 1348 signed Connection Assertion, requests must be approved by a device 1349 that has access to an administration key authorized by the user's 1350 Master Profile. Such devices are referred to as Administration 1351 devices. Administration devices must have data entry (e.g. keyboard) 1352 and output (e.g. display) affordances to support any of the currently 1353 defined connection mechanisms. The QR code connection mechanism also 1354 requires a suitable camera. 1356 It will be noted that the process of connecting a device that 1357 contains a preconfigured set of device keys might in principle expose 1358 the user to the risk that the manufacturer has retained knowledge of 1359 these keys and that this might be used to create a 'backdoor'. 1361 This risk is controlled using the key co-generation technique 1362 described earlier. The original device profile is combined with a 1363 device profile provided by the user to create a composite device 1364 profile. This ensures that every device uses a unique profile even 1365 if they are initialized from a shared firmware image containing a 1366 fixed set of device key pairs. 1368 5.4.1. Direct Connection 1370 The direct connection mechanism requires that both the administration 1371 device and the device originating the connection request have data 1372 entry and output affordances and that it is possible for the user to 1373 compare the authentication codes presented by the two devices to 1374 check that they are identical. 1376 The connection request is initiated on the device being connected: 1378 Alice2> device request alice@example.com 1379 Witness value = QLY7-RGAN-OH27-Z6CX-KAIL-3LW4-J6O5 1380 Personal Mesh = MA4D-JPBO-ZPEK-JU62-RQWE-WO3F-77DD 1382 Using her administration device, Alice gets a list of pending 1383 requests. Seeing that there is a pending request matching the 1384 witness value presented by the device, Alice accepts it: 1386 Alice> device pending 1387 Alice> device accept NB5O-PB7O-FVX4-V6DX-AVJV-UEG5-X2FR 1389 The new device will now synchronize automatically in response to any 1390 Mesh commands. For example, listing the password catalog: 1392 Alice2> password list 1393 ERROR - Object reference not set to an instance of an object. 1395 5.4.2. Pin Connection 1397 The PIN Connection mechanism is similar to the Direct connection 1398 mechanism except that the process is initiated on an administration 1399 device by requesting assignment of a new authentication PIN. The PIN 1400 is then input to the connecting device to authenticate the request. 1402 The PIN connection mechanism begins with the issue of the PIN: 1404 Alice> account pin 1405 PIN=NCXT-R2AE-ZXAS-DSU7-QQ (Expires=2019-10-24T16:58:38Z) 1407 The PIN code is transmitted out of band to the device being 1408 connected: 1410 Alice3> device request alice@example.com /pin=NCXT-R2AE-ZXAS-DSU7-QQ 1411 Witness value = PS22-EOYE-MAEA-YMRM-B4U2-P63Y-U2RS 1412 Personal Mesh = MA4D-JPBO-ZPEK-JU62-RQWE-WO3F-77DD 1414 Since the request was pre-authorized, it is not necessary for Alice 1415 to explicitly accept the connection request but the administration 1416 device is needed to create the connection assertion: 1418 Alice> device pending 1420 We can check the device connection by attempting to synchronize to 1421 the profile account: 1423 Alice3> account sync 1424 ERROR - The feature has not been implemented 1426 Note that this connection mechanism could be addapted to allow a 1427 device with a camera affordance to connect by scanning a QR code on 1428 the administration device. 1430 If the Device Profile fingerprint is known at the time the PIN is 1431 generated, this can be bound to the PIN authorization assertion to 1432 permit connection of a specific device. 1434 5.4.3. EARL/QR Code Connection 1436 The EARL/QR code connection mechanisms are used to connect a 1437 constrained device to a Mesh profile by means of an Encrypted 1438 Authenticated Resource Locator, typically presented as a QR code on 1439 the device itself or its packaging. 1441 Since the meshman tool does not support QR input, it is decoded using 1442 a separate tool to recover the UDF EARL which is presented as a 1443 command line parameter: 1445 To use the device QR code connection mechanism, we require a Web 1446 service that will host the connection document example.com and a 1447 MeshService account that the device will attempt to complete the 1448 connection by requesting synchronization devices@example.com. 1450 To begin the process we generate a new random key and combine it with 1451 the service to create an EARL: 1453 udf://example.com/EDPP-F6IN-LFYU-DTE4-5IF4-IDKL-BFOP-IA 1455 Next a device profile is created and preregistered on with the Mesh 1456 Service that will provide the hailing service. Since we are only 1457 preparing one device it is convenient to do this on the device 1458 itself. In a manufacturing scenario, these steps would typically be 1459 performed offline in bulk. 1461 Alice4> device pre devices@example.com /key=udf://example.com/EDPP-F6IN-LFYU-DTE4-5IF4-IDKL-BFOP-IA 1462 ERROR - Object reference not set to an instance of an object. 1464 Once initialized the device attempts to poll the service for a 1465 connection each time it is powered on, when a connection button 1466 affordance on the device is pressed or at other times as agreed with 1467 the Mesh Service Provider: 1469 Alice4> account sync 1470 ERROR - The feature has not been implemented 1472 To connect the device to her profile, Alice scans the device with her 1473 administration device to obtain the UDF. The administration device 1474 retrieves the connection description, decrypts it and then uses the 1475 information in the description to create the necessary Device 1476 Connection Assertion and connect to the device hailing Mesh Service 1477 Account to complete the process: 1479 Alice> device earl udf://example.com/EDPP-F6IN-LFYU-DTE4-5IF4-IDKL-BFOP-IA 1480 ERROR - Object reference not set to an instance of an object. 1482 When the device next attempts to connect to the hailing service, it 1483 receives the Device Connection Assertion: 1485 Alice4> account sync 1486 ERROR - The feature has not been implemented 1488 5.5. Contact Requests 1490 As previously stated, every inbound Mesh message is subject to access 1491 control. The user's contact catalog is used as part of the access 1492 control authentication and authorization mechanism. 1494 By default, the only form of inbound message that is accepted without 1495 authorization in the contact catalog is a contact request. Though 1496 for certain Mesh users (e.g. politicians, celebrities) even contact 1497 requests might require some form of prior approval (e.g. endorsement 1498 by a mutual friend). 1500 A Mesh Contact Assertion may be limited to stating the user's profile 1501 fingerprint and Mesh Service Account(s). For most purposes however, 1502 it is more convenient to present a Contact Assertion that contains at 1503 least as much information as is typically provided on a business or 1504 calling card: 1506 Alice creates a contact entry for herself: 1508 Alice> contact self email alice@example.com 1509 { 1510 "Self": true, 1511 "Key": "NCON-XP6L-BXPS-HL45-KSNN-DJNE-CPQA", 1512 "EnvelopedContact": [{}, 1513 "ewogICJDb250YWN0IjogewogICAgIkFkZHJlc3Nlcy 1514 I6IFt7CiAgICAgICAgIlVSSSI6ICJtYWlsdG86e2VtYWlsfSJ9XX19"]}~~~~ 1516 User's may create multiple Contact Assertions for use in different 1517 circumstances. A user might not want to give their home address to a 1518 business contact or their business address to a personal friend. 1520 5.5.1. Remote 1522 In the most general case, the participants are remote from each other 1523 and one user must make a contact request of the other: 1525 Bob requests Alice add him to her contacts catalog: 1527 Bob> message contact alice@example.com 1529 When Alice next checks her messages, she sees the pending contact 1530 request from Bob and accepts it. Bob's contact details are added to 1531 her catalog and Bob receives a response containing Alice's 1532 credentials: 1534 Alice> message pending 1535 Alice> message accept tbs 1537 5.5.2. Static QR Code 1539 A DARE contact entry may be exchanged by means of an EARL UDF. This 1540 is typically presented by means of a QR code which may be created 1541 using the meshman tool and a QR code generator. The resulting QR 1542 code may be printed on a business card, laser engraved on a luggage 1543 tag, etc. 1545 To accept the contact request, the recipient merely scans the code 1546 with a Mesh capable QR code reader. They are asked if they wish to 1547 accept the contact request and what privileges they wish to authorize 1548 for the new contact. 1550 5.5.3. Dynamic QR Code 1552 If it is possible for the device to generate a new QR code for the 1553 contact request, it is possible to support bi-directional exchange of 1554 credentials with strong mutual authentication. 1556 For example, Alice selects the contact credential she wishes to pass 1557 to Bob on her mobile device which presents an EARL as a QR code. Bob 1558 scans the QR code with his mobile device which retrieves Alice's 1559 credential and asks if Bob wishes to accept it and if he wishes to 1560 share his credential with Alice. If Bob agrees, his device makes a 1561 Remote Contact request authenticated under a key passed to his device 1562 with Alice's Contact Assertion. 1564 The Dynamic QR Code protocol may be applied to support exchange of 1565 credentials between larger groups. Enrolling the contact assertions 1566 collected in such circumstances in a notarized append only log (e.g. 1567 a DARE Container) provides a powerful basis for building a Web of 1568 Trust that is equivalent to but considerably more convenient than 1569 participation in PGP Key Signing parties. 1571 5.6. Sharing Confidential Data in the Cloud 1573 As previously discussed, the Mesh makes use of multi-party encryption 1574 techniques to mitigate the risk of a device compromise leading to 1575 disclosure of confidential data. The Mesh also allows these 1576 techniques to be applied to provide Confidential Document Control. 1577 This provides data encryption capabilities that are particularly 1578 suited to 'cloud computing' environments. 1580 A Mesh Encryption Group is a special type of Mesh Service Account 1581 that is controlled by one of more group administrators. The 1582 Encryption Group Key is a normal ECDH public key used in the normal 1583 manner. The decryption key is held by the group administrator. To 1584 add a user to the group, the administrator splits the group private 1585 key into two parts, a service key and a user key. These parts are 1586 encrypted under the public encryption keys of their assigned parties. 1587 The encrypted key parts form a decryption entry for the user is added 1588 to the Members Catalog of the Encryption Group at the Mesh Service. 1590 [[This figure is not viewable in this format. The figure is 1591 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 1592 architecture.html [19].]] 1594 When a user needs to decrypt a document encrypted under the group 1595 key, they make a request to the Mesh Service which checks to see that 1596 they are authorized to read that particular document, have not 1597 exceeded their decryption quota, etc. If the request is approved, 1598 the service returns the partial decryption result obtained from the 1599 service's key part together with the encrypted user key part. To 1600 complete the decryption process, the user decrypts their key part and 1601 uses it to create a second partial decryption result which is 1602 combined with the first to obtain the key agreement value needed to 1603 complete the decryption process. 1605 Alice creates the recryption group groupw@example.com to share 1606 confidential information with her closest friends: 1608 Alice> group create groupw@example.com 1609 ERROR - The feature has not been implemented 1611 Bob encrypts a test file but he can't decrypt it because he isn't in 1612 the group: 1614 Bob> dare encodeTestFile1.txt /out=TestFile1-group.dare /encrypt=groupw@example.com 1615 ERROR - The command is not known. 1616 Bob> dare decode TestFile1-group.dare 1617 ERROR - Could not find file 'C:\Users\hallam\Test\WorkingDirectory\TestFile1-group.dare'. 1619 Since she is the group administrator, Alice can decrypt the test file 1620 using the group decryption key: 1622 Alice> dare decode TestFile1-group.dare 1623 ERROR - Could not find file 'C:\Users\hallam\Test\WorkingDirectory\TestFile1-group.dare'. 1625 Adding Bob to the group gives him immediate access to any file 1626 encrypted under the group key without making any change to the 1627 encrypted files: 1629 Alice> dare decode TestFile1-group.dare 1630 ERROR - Could not find file 'C:\Users\hallam\Test\WorkingDirectory\TestFile1-group.dare'. 1632 Removing Bob from the group immediately withdraws his access. 1634 Alice> group delete groupw@example.com bob@example.com 1635 ERROR - The feature has not been implemented 1637 Bob cannot decrypt any more files (but he may have kept copies of 1638 files he decrypted earlier). 1640 Alice> dare decode TestFile1-group.dare 1641 ERROR - Could not find file 'C:\Users\hallam\Test\WorkingDirectory\TestFile1-group.dare'. 1643 Should requirements demand, the same principle may be applied to 1644 achieve separation of duties in the administration roles. Instead of 1645 provisioning the group private key to a single administrator, it may 1646 be split into two or more parts. Adding a user to the group requires 1647 each of the administrators to create a decryption entry for the user 1648 and for the service and user to apply the appropriate operations to 1649 combine the key parts available to them before use. 1651 These techniques could even be extended to support complex 1652 authorization requirements such as the need for 2 out of 3 1653 administrators to approve membership of the group. A set of 1654 decryption entries is complete if the sum of the key parts is equal 1655 to the private key (modulo the order of the curve). 1657 Thus, if the set of administrators is A, B and C and the private key 1658 is k, we can ensure that it requires exactly two administrators to 1659 create a complete set of decryption entries by issuing key set { a } 1660 to A, the key set {k-a , b } to B and the key set {k-a , k-b } to C 1661 (where a and b are randomly generated keys). 1663 5.7. Escrow and Recovery of Keys 1665 One of the chief objections made against deployment of Data Level 1666 encryption is that although it provides the strongest possible 1667 protection of the confidentiality of the data, loss of the decryption 1668 keys means loss of the encrypted data. Thus, a robust and effective 1669 key escrow mechanism is essential if use of encryption is to ever 1670 become commonplace for stored data. 1672 The use of a 'life-long' Mesh profiles raises a similar concern. 1673 Loss of a Master Signature Key potentially means the loss of the 1674 ability to control devices connected to the profile and the 1675 accumulated trust endorsements of other users. 1677 Because of these requirements, Mesh users are strongly advised but 1678 not required to create a backup copy of the private keys 1679 corresponding to their Master Profile Signature and Escrow keys. 1681 Users may use the key escrow mechanism of their choice including the 1682 escrow mechanism supported by the Mesh itself which uses Shamir 1683 Secret Sharing to escrow the encryption key for a DARE Envelope 1684 containing the private key information. 1686 To escrow a key set, the user specifies the number of key shares to 1687 be created and the number required for recovery. 1689 Alice> mesh escrow 1690 ERROR - The cryptographic provider does not permit export of the private key parameters 1692 Recovery of the key data requires the key recovery record and a 1693 quorum of the key shares: 1695 Having recovered the Master Signature Key, the user can now create a 1696 new master profile authorizing a new administration device which can 1697 be used to authenticate access to the Mesh Service Account(s) 1698 connected to the master profile. 1700 6. Security Considerations 1702 The security considerations for use and implementation of Mesh 1703 services and applications are described in the Mesh Security 1704 Considerations guide [draft-hallambaker-mesh-security] . 1706 7. IANA Considerations 1708 This document does not contain actions for IANA 1710 8. Acknowledgements 1712 Comodo Group: Egemen Tas, Melhi Abdulhayo?lu, Rob Stradling, Robin 1713 Alden. 1715 9. References 1717 9.1. Normative References 1719 [draft-hallambaker-jsonbcd] 1720 Hallam-Baker, P., "Binary Encodings for JavaScript Object 1721 Notation: JSON-B, JSON-C, JSON-D", draft-hallambaker- 1722 jsonbcd-14 (work in progress), April 2019. 1724 [draft-hallambaker-mesh-cryptography] 1725 Hallam-Baker, P., "Mathematical Mesh 3.0 Part VIII: 1726 Cryptographic Algorithms", draft-hallambaker-mesh- 1727 cryptography-02 (work in progress), July 2019. 1729 [draft-hallambaker-mesh-dare] 1730 Hallam-Baker, P., "Mathematical Mesh 3.0 Part III : Data 1731 At Rest Encryption (DARE)", draft-hallambaker-mesh-dare-04 1732 (work in progress), August 2019. 1734 [draft-hallambaker-mesh-developer] 1735 Hallam-Baker, P., "Mathematical Mesh: Reference 1736 Implementation", draft-hallambaker-mesh-developer-08 (work 1737 in progress), April 2019. 1739 [draft-hallambaker-mesh-platform] 1740 Hallam-Baker, P., "Mathematical Mesh: Platform 1741 Configuration", draft-hallambaker-mesh-platform-04 (work 1742 in progress), April 2019. 1744 [draft-hallambaker-mesh-protocol] 1745 Hallam-Baker, P., "Mathematical Mesh 3.0 Part V: Protocol 1746 Reference", draft-hallambaker-mesh-protocol-02 (work in 1747 progress), August 2019. 1749 [draft-hallambaker-mesh-schema] 1750 Hallam-Baker, P., "Mathematical Mesh 3.0 Part IV: Schema 1751 Reference", draft-hallambaker-mesh-schema-03 (work in 1752 progress), August 2019. 1754 [draft-hallambaker-mesh-security] 1755 Hallam-Baker, P., "Mathematical Mesh Part VII: Security 1756 Considerations", draft-hallambaker-mesh-security-01 (work 1757 in progress), July 2019. 1759 [draft-hallambaker-mesh-trust] 1760 Hallam-Baker, P., "Mathematical Mesh Part VI: The Trust 1761 Mesh", draft-hallambaker-mesh-trust-02 (work in progress), 1762 July 2019. 1764 [draft-hallambaker-mesh-udf] 1765 Hallam-Baker, P., "Mathematical Mesh 3.0 Part II: Uniform 1766 Data Fingerprint.", draft-hallambaker-mesh-udf-07 (work in 1767 progress), October 2019. 1769 [draft-hallambaker-web-service-discovery] 1770 Hallam-Baker, P., "DNS Web Service Discovery", draft- 1771 hallambaker-web-service-discovery-02 (work in progress), 1772 April 2019. 1774 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1775 Requirement Levels", BCP 14, RFC 2119, 1776 DOI 10.17487/RFC2119, March 1997. 1778 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1779 (TLS) Protocol Version 1.2", RFC 5246, 1780 DOI 10.17487/RFC5246, August 2008. 1782 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 1783 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1784 2014. 1786 [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 1787 (HTTP/1.1): Semantics and Content", RFC 7231, 1788 DOI 10.17487/RFC7231, June 2014. 1790 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 1791 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 1792 2015. 1794 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 1795 RFC 7516, DOI 10.17487/RFC7516, May 2015. 1797 9.2. URIs 1799 [1] http://mathmesh.com/Documents/draft-hallambaker-mesh- 1800 architecture.html 1802 [2] http://mathmesh.com/Documents/draft-hallambaker-mesh- 1803 architecture.html 1805 [3] http://mathmesh.com/Documents/draft-hallambaker-mesh- 1806 architecture.html 1808 [4] http://mathmesh.com/Documents/draft-hallambaker-mesh- 1809 architecture.html 1811 [5] http://mathmesh.com/Documents/draft-hallambaker-mesh- 1812 architecture.html 1814 [6] http://mathmesh.com/Documents/draft-hallambaker-mesh- 1815 architecture.html 1817 [7] http://mathmesh.com/Documents/draft-hallambaker-mesh- 1818 architecture.html 1820 [8] http://mathmesh.com/Documents/draft-hallambaker-mesh- 1821 architecture.html 1823 [9] http://mathmesh.com/Documents/draft-hallambaker-mesh- 1824 architecture.html 1826 [10] http://mathmesh.com/Documents/draft-hallambaker-mesh- 1827 architecture.html 1829 [11] http://mathmesh.com/Documents/draft-hallambaker-mesh- 1830 architecture.html 1832 [12] http://mathmesh.com/Documents/draft-hallambaker-mesh- 1833 architecture.html 1835 [13] http://mathmesh.com/Documents/draft-hallambaker-mesh- 1836 architecture.html 1838 [14] http://mathmesh.com/Documents/draft-hallambaker-mesh- 1839 architecture.html 1841 [15] http://mathmesh.com/Documents/draft-hallambaker-mesh- 1842 architecture.html 1844 [16] http://mathmesh.com/Documents/draft-hallambaker-mesh- 1845 architecture.html 1847 [17] http://mathmesh.com/Documents/draft-hallambaker-mesh- 1848 architecture.html 1850 [18] http://mathmesh.com/Documents/draft-hallambaker-mesh- 1851 architecture.html 1853 [19] http://mathmesh.com/Documents/draft-hallambaker-mesh- 1854 architecture.html 1856 Author's Address 1858 Phillip Hallam-Baker 1860 Email: phill@hallambaker.com