idnits 2.17.1 draft-hallambaker-mesh-architecture-10.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 4 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 1597 has weird spacing: '...command is no...' -- The document date (August 13, 2019) is 1711 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 1781 -- Looks like a reference, but probably isn't: '2' on line 1784 -- Looks like a reference, but probably isn't: '3' on line 1787 -- Looks like a reference, but probably isn't: '4' on line 1790 -- Looks like a reference, but probably isn't: '5' on line 1793 -- Looks like a reference, but probably isn't: '6' on line 1796 -- Looks like a reference, but probably isn't: '7' on line 1799 -- Looks like a reference, but probably isn't: '8' on line 1802 -- Looks like a reference, but probably isn't: '9' on line 1805 -- Looks like a reference, but probably isn't: '10' on line 1808 -- Looks like a reference, but probably isn't: '11' on line 1811 -- Looks like a reference, but probably isn't: '12' on line 1814 -- Looks like a reference, but probably isn't: '13' on line 1817 -- Looks like a reference, but probably isn't: '14' on line 1820 -- Looks like a reference, but probably isn't: '15' on line 1823 -- Looks like a reference, but probably isn't: '16' on line 1826 -- Looks like a reference, but probably isn't: '17' on line 1829 -- Looks like a reference, but probably isn't: '18' on line 1832 -- Looks like a reference, but probably isn't: '19' on line 1835 ** 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 August 13, 2019 4 Intended status: Informational 5 Expires: February 14, 2020 7 Mathematical Mesh 3.0 Part I: Architecture Guide 8 draft-hallambaker-mesh-architecture-10 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 This document is also available online at 24 http://mathmesh.com/Documents/draft-hallambaker-mesh- 25 architecture.html [1] . 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on February 14, 2020. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 2.1. Related Specifications . . . . . . . . . . . . . . . . . 5 64 2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 6 65 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 6 66 2.4. Implementation Status . . . . . . . . . . . . . . . . . . 6 67 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 6 68 3.1. A Personal PKI . . . . . . . . . . . . . . . . . . . . . 8 69 3.1.1. Device Management . . . . . . . . . . . . . . . . . . 9 70 3.1.2. Exchange of trusted credentials. . . . . . . . . . . 9 71 3.1.3. Application configuration management . . . . . . . . 10 72 3.1.4. The Mesh as platform . . . . . . . . . . . . . . . . 10 73 3.2. Mesh Architecture . . . . . . . . . . . . . . . . . . . . 11 74 3.2.1. Mesh Device Management . . . . . . . . . . . . . . . 12 75 3.2.2. Mesh Account . . . . . . . . . . . . . . . . . . . . 13 76 3.2.3. Mesh Service . . . . . . . . . . . . . . . . . . . . 15 77 3.2.4. Mesh Messaging . . . . . . . . . . . . . . . . . . . 15 78 3.3. Using the Mesh with Applications . . . . . . . . . . . . 16 79 3.3.1. Contact Exchange . . . . . . . . . . . . . . . . . . 17 80 3.3.2. Confirmation Protocol . . . . . . . . . . . . . . . . 17 81 3.3.3. Future Applications . . . . . . . . . . . . . . . . . 18 82 4. Mesh Cryptography . . . . . . . . . . . . . . . . . . . . . . 18 83 4.1. Best Practice by Default . . . . . . . . . . . . . . . . 19 84 4.2. Multi-Level Security . . . . . . . . . . . . . . . . . . 19 85 4.3. Multi-Key Decryption . . . . . . . . . . . . . . . . . . 20 86 4.4. Multi-Party Key Generation . . . . . . . . . . . . . . . 20 87 4.5. Data At Rest Encryption . . . . . . . . . . . . . . . . . 21 88 4.5.1. DARE Envelope . . . . . . . . . . . . . . . . . . . . 21 89 4.5.2. Dare Container . . . . . . . . . . . . . . . . . . . 21 90 4.6. Uniform Data Fingerprints. . . . . . . . . . . . . . . . 22 91 4.6.1. Friendly Names . . . . . . . . . . . . . . . . . . . 23 92 4.6.2. Encrypted Authenticated Resource Locators . . . . . . 23 93 4.6.3. Secure Internet Names . . . . . . . . . . . . . . . . 24 94 4.7. Personal Key Escrow . . . . . . . . . . . . . . . . . . . 24 95 5. User Experience . . . . . . . . . . . . . . . . . . . . . . . 26 96 5.1. Creating a Mesh Profile and Administration Device. . . . 27 97 5.2. Mesh Accounts . . . . . . . . . . . . . . . . . . . . . . 27 98 5.3. Mesh Service . . . . . . . . . . . . . . . . . . . . . . 28 99 5.4. Connecting and Authorizing Additional Devices . . . . . . 29 100 5.4.1. Direct Connection . . . . . . . . . . . . . . . . . . 29 101 5.4.2. Pin Connection . . . . . . . . . . . . . . . . . . . 30 102 5.4.3. EARL/QR Code Connection . . . . . . . . . . . . . . . 31 103 5.5. Contact Requests . . . . . . . . . . . . . . . . . . . . 32 104 5.5.1. Remote . . . . . . . . . . . . . . . . . . . . . . . 33 105 5.5.2. Static QR Code . . . . . . . . . . . . . . . . . . . 33 106 5.5.3. Dynamic QR Code . . . . . . . . . . . . . . . . . . . 33 107 5.6. Sharing Confidential Data in the Cloud . . . . . . . . . 34 108 5.7. Escrow and Recovery of Keys . . . . . . . . . . . . . . . 36 109 6. Security Considerations . . . . . . . . . . . . . . . . . . . 36 110 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 111 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 112 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 113 9.1. Normative References . . . . . . . . . . . . . . . . . . 37 114 9.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 38 115 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 40 117 1. Introduction 119 The Mathematical Mesh (Mesh) is a user centered Public Key 120 Infrastructure that uses cryptography to make computers easier to 121 use. The Mesh provides an infrastructure that addresses the three 122 concerns that have proved obstacles to the use of end-to-end security 123 in computer applications: 125 o Device management. 127 o Exchange of trusted credentials. 129 o Application configuration management. 131 The infrastructure developed to address these original motivating 132 concerns can be used to facilitate deployment and use of existing 133 security protocols (OpenPGP, S/MIME, SSH) and as a platform for 134 building end-to-end secure network applications. Current Mesh 135 applications include: 137 o Multi-factor authentication and confirmation 139 o Credential management 141 o Bookmark/Citation management 143 o Task and workflow management 144 This document is not normative. It provides an overview of the Mesh 145 comprising a description of the architecture, and a discussion of 146 typical use cases and requirements. The remainder of the document 147 series provides a summary of the principal components of the Mesh 148 architecture and their relationship to each other. 150 Normative descriptions of the individual Mesh encodings, data 151 structures and protocols are provided in separate documents 152 addressing each component in turn. 154 The currently available Mesh document series comprises: 156 I. Architecture (This document.) Provides an overview of the Mesh 157 as a system and the relationship between its constituent parts. 159 II. Uniform Data Fingerprint . Describes the UDF format used to 160 represent cryptographic nonces, keys and content digests in the 161 Mesh and the use of Encrypted Authenticated Resource Locators 162 (EARLs) and Strong Internet Names (SINs) that build on the UDF 163 platform. 165 III. Data at Rest Encryption . Describes the cryptographic message 166 and append-only sequence formats used in Mesh applications and the 167 Mesh Service protocol. 169 IV. Schema Reference . Describes the syntax and semantics of Mesh 170 Profiles, Container Entries and Mesh Messages and their use in 171 Mesh Applications. 173 V. Protocol Reference . Describes the Mesh Service Protocol. 175 VI. The Trust Mesh . Describes the social work factor metric used 176 to evaluate the effectiveness of different approaches to exchange 177 of credentials between users and organizations in various contexts 178 and argues for a hybrid approach taking advantage of direct trust, 179 Web of Trust and Trusted Third Party models to provide 180 introductions. 182 VII. Security Considerations . Describes the security 183 considerations for the Mesh protocol suite. 185 VIII Cryptographic Algorithms . Describes the recommended and 186 required algorithm suites for Mesh applications and the 187 implementation of the multi-party cryptography techniques used in 188 the Mesh. 190 The following documents describe technologies that are used in the 191 Mesh but do not form part of the Mesh standards suite: 193 JSON-BCD Encoding . Describes extensions to the JSON serialization 194 format to allow direct encoding of binary data (JSON-B), 195 compressed encoding (JSON-C) and extended binary data encoding 196 (JSON-D). Each of these encodings is a superset of the previous 197 one so that JSON-B is a superset of JSON, JSON-C is a superset of 198 JSON-B and JSON-D is a superset of JSON-C. 200 DNS Web Service Discovery . Describes the means by which prefixed 201 DNS SRV and TXT records are used to perform discovery of Web 202 Services. 204 The following documents describe aspects of the Mesh Reference 205 implementation: 207 Mesh Developer . Describes the reference code distribution license 208 terms, implementation status and currently supported functions. 210 Mesh Platform . Describes how platform specific functionality such 211 as secure key storage and trustworthy computing features are 212 employed in the Mesh. 214 2. Definitions 216 This section presents the related specifications and standards on 217 which the Mesh is built, the terms that are used as terms of art 218 within the Mesh protocols and applications and the terms used as 219 requirements language. 221 2.1. Related Specifications 223 Besides the documents that form the Mesh core, the Mesh makes use of 224 many existing Internet standards, including: 226 Cryptographic Algorithms The RECOMMENDED and REQUIRED cryptographic 227 algorithms for Mesh implementations are specified in 228 [draft-hallambaker-mesh-cryptography] . 230 In addition Mesh Devices used to administer non-Mesh applications 231 must support the cryptographic algorithm suites specified by the 232 application. 234 Transport All Mesh Services make use of multiple layers of security. 235 Protection against traffic analysis and metadata attacks are 236 provided by use of Transport Layer Security [RFC5246] . At 237 present, the HTTP/1.1 [RFC7231] protocol is used to provide 238 framing of transaction messages. 240 Encoding All Mesh protocols and data structures are expressed in the 241 JSON data model and all Mesh applications accept data in standard 242 JSON encoding [RFC7159] . The JOSE Signature [RFC7515] and 243 Encryption [RFC7516] standards are used as the basis for object 244 signing and encryption. 246 2.2. Defined Terms 248 TBS 250 2.3. Requirements Language 252 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 253 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 254 document are to be interpreted as described in RFC 2119 [RFC2119] . 256 2.4. Implementation Status 258 The implementation status of the reference code base is described in 259 the companion document [draft-hallambaker-mesh-developer] . 261 The examples in this document were created on 8/13/2019 11:36:45 AM. 262 Out of 169 examples, 71 were not functional. 264 [Note: Example data is now being produced using the mesh command line 265 tool which is currently substantially less complete than the Mesh 266 reference code it is intended to provide an interface to. As a 267 result, the documentation currently lags the code by more than is 268 usual.] 270 3. Architecture 272 The Mathematical Mesh (Mesh) is a user centered Public Key 273 Infrastructure that uses cryptography to make computers easier to 274 use. This document describes version 3.0 of the Mesh architecture 275 and protocols. 277 For several decades, it has been widely noted that most users are 278 either unwilling or unable to make even the slightest efforts to 279 protect their security, still less those of other parties. Yet 280 despite this observation being widespread, the efforts of the IT 281 security community have largely focused on changing this user 282 behavior rather that designing applications that respect it. Real 283 users have real work to do and have neither the time nor the 284 inclination to use tools that will negatively impact their 285 performance. 287 The Mesh is based on the principle that if the Internet is to be 288 secure, if must become effortless to use applications securely. 289 Rather than beginning the design process by imagining all the 290 possible modes of attack and working out how to address these with 291 the least possible inconvenience, we must reverse the question and 292 ask how much security can be provided without requiring any effort on 293 the user's part to address it. 295 Today's technology requires users to put their trust in an endless 296 variety of devices, software and services they cannot fully 297 understand let alone control. Even the humble television of the 298 20^th century has been replaced by a 'smart' TV with 15 million lines 299 of code. Whose undeclared capabilities may well include placing the 300 room in which it is placed under continuous audio and video 301 surveillance. 303 Every technology deployment by necessity requires some degree of 304 trust on the owner/user's part. But this trust should be limited and 305 subject to accountability. If manufacturers continue to fail in this 306 regard, they risk a backlash in which users seek to restore their 307 rights through litigation, legislation or worst of all, simply not 308 buying more technology that they have learned to distrust through 309 their own experience. 311 The Mesh is based on the principle of radical distrust, that is, if a 312 party is capable of defecting, we assume that they will. As the 313 Russian proverb goes: ???????, ?? ????????: trust, but verify. 315 In the 1990s, the suggestion that 'hackers' might seek to make 316 financial gains from their activities was denounced as 'fear- 317 mongering'. The suggestion that email or anonymous currencies might 318 be abused received a similar response. Today malware, ransomware and 319 spam have become so ubiquitous that they are no longer news unless 320 the circumstances are particularly egregious. 322 We must dispense with the notion that it is improper or impolite to 323 question the good faith of technology suppliers of any kind whether 324 they be manufacturers, service providers, software authors or 325 reviewers. Modern supply chains are complex, typically involving 326 hundreds if not thousands of potential points of deliberate or 327 accidental compromise. The technology provider who relies on the 328 presumption of good faith on their part risks serious damage to their 329 reputation when others assert that a capability added to their 330 product may have malign uses. 332 Radical distrust means that we apply the principles of least 333 principle and accountability at every level in the design: 335 o Cryptographic keys installed in a product during manufacture are 336 only used for the limited purpose of putting that device under 337 control of the user. 339 o Cryptographic keys and assertions related to management of devices 340 are only visible to the user they belong to and are never exposed 341 to external parties. 343 o Mesh Accounts belong to and are under control of the user they 344 belong to and not the Mesh Service provider which the user can 345 change at will with minimal inconvenience. 347 o Mesh Services do not have access to the plaintext of any Mesh 348 Messages or Mesh Catalog data except for the Contacts catalog. 350 o All Mesh Messages are subject to access control by both the 351 inbound and outbound Mesh Service to mitigate messaging abuse. 353 Security is risk management and not the elimination of all 354 possibility of any risk. Radical distrust means that we raise the 355 bar for attackers to the point where for most attackers the risk is 356 greater than the reward. 358 In addition to distrusting technology providers the Mesh Architecture 359 allows the user to limit the degree of trust they place in 360 themselves. In the real world, devices are lost or stolen, passwords 361 and activation codes are forgotten, natural or man-made catastrophes 362 cause property and data to be lost. The Mesh permits but does not 363 require use of escrow techniques that allow recovery from such 364 situations. 366 3.1. A Personal PKI 368 The Mesh is a Public Key Infrastructure (PKI) that is designed to 369 address the three major obstacles to deployment of end-to-end secure 370 applications: 372 o Device management. 374 o Exchange of trusted credentials. 376 o Application configuration management. 378 Each Mesh user is the ultimate source of authority in their Personal 379 Mesh which specifies the set of devices, contacts and applications 380 that they trust and for what purposes. 382 The Mesh 1.0 architecture described a PKI designed to meet these 383 limited requirements to enable use of existing end-to-end secure 384 Internet protocols such as OpenPGP, S/MIME and SSH. Since these 385 protocols only secure data in transit and the vast majority of data 386 breaches involve data at rest, the Data At Rest Encryption (DARE) was 387 added as a layered application resulting in the Mesh 2.0 388 architecture. This document describes the Mesh 3.0 architecture 389 which has been entirely re-worked so that DARE provides the platform 390 on which all other Mesh functions are built. 392 3.1.1. Device Management 394 Existing PKIs were developed in an era when the 'personal computer' 395 was still coming into being. Only a small number of people owned a 396 computer and an even smaller number owned more than one. Today, 397 computers are ubiquitous and a typical home in the developed world 398 contains several hundred of which a dozen or more may have some form 399 of network access. 401 The modern consumer faces a problem of device management that is 402 considerably more complex than the IT administrator of a small 403 business might have faced in the 1990s but without any of the network 404 management tools such an administrator would expect to have 405 available. 407 One important consequence of the proliferation of devices is that 408 end-to-end security is no longer sufficient. To be acceptable to 409 users, a system must be ends-to-ends secure. That is, a user must be 410 able to read their encrypted email message on their laptop, tablet, 411 phone, or watch with exactly the same ease of use as if the mail was 412 unencrypted. 414 Each personal Mesh contains a device catalog in which the 415 cryptographic credentials and device specific application 416 configurations for each connected device are stored. 418 Management of the device catalog is restricted to a subset of devices 419 that the owner of the Mesh has specifically authorized for that 420 purpose as administration devices. Only a device with access to a 421 duly authorized administration key can add or remove devices from a 422 personal Mesh. 424 3.1.2. Exchange of trusted credentials. 426 One of the most challenging, certainly the most contentious issues in 427 PKI is the means by which cryptographic credentials are published and 428 validated. 430 The Mesh does not attempt to impose criteria for accepting 431 credentials as valid as no such set of criteria can be comprehensive. 432 Rather the Mesh allows users to make use of the credential validation 433 criteria that are appropriate to the purpose for which they intend to 434 use them and Mesh Services provides protocol support for exchange of 435 credentials between users and to synchronize credential information 436 between all the devices belonging to a user. 438 In some circumstances, only a direct trust model is acceptable, in 439 others, only a trusted third-party model is possible and in the vast 440 majority of cases opportunistic approaches are more than sufficient. 441 Both approaches may be reinforced by use of chained notary 442 certificate (e.g. BlockChain) technology affords a means of 443 establishing that a particular assertion was made before a certain 444 date. The management of Trust in the Mesh is described in detail in 445 [draft-hallambaker-mesh-trust] . 447 3.1.3. Application configuration management 449 Configuration of cryptographic applications is typically worse than 450 an afterthought. Configuration of one popular mail user agent to use 451 S/MIME security requires 17 steps to be performed using four separate 452 application programs. And since S/MIME certificates expire, the user 453 is required to repeat these steps every few years. Contrary to the 454 public claims made by one major software vendor it is not necessary 455 to perform 'usability testing' to recognize abject stupidity. 457 Rather than writing down configuration steps and giving them to the 458 user, we should turn them into code and give them to a machine. 459 Users should never be required to do the work of the machine. Nor 460 should any programmer be allowed to insult the user by casting their 461 effort aside and requiring it to be re-entered. 463 While most computer professionals who are required to do such tasks 464 on a regular basis will create a tool for the purpose, most users do 465 not have that option. And of those who do write their own tools, 466 only a few have the time and the knowledge to do the job without 467 introducing security vulnerabilities. 469 3.1.4. The Mesh as platform 471 Meeting the core objectives of the Mesh required new naming, 472 communication and cryptographic capabilities provided to be 473 developed. These capabilities may in turn be used to develop new 474 end-to-end secure applications. 476 For example, a DARE Catalog is a cryptographic container in which the 477 entries represent a set of objects which may be added, updated and 478 deleted over time. The Mesh Service protocol allows DARE Catalogs to 479 be synchronized between devices connected to a Mesh Account. DARE 480 Catalogs are used as the basis for the device and contacts catalogs 481 referred to above. 483 The Mesh Credentials Catalog uses the same DARE Catalog format and 484 Mesh Service protocol to share passwords between devices with end-to- 485 end encryption so that no password data is ever left unencrypted in 486 the cloud. 488 3.2. Mesh Architecture 490 The Mesh has four principal components: 492 Mesh Device Management Each user has a personal Mesh profile that is 493 used for management of their personal devices. A user may connect 494 devices to or remove devices from their personal Mesh by use of a 495 connected device that has been granted the 'administration' role. 497 Mesh Account A Mesh account is similar in concept to a traditional 498 email or messaging account but with the important difference that 499 it belongs to the user and not a service provider. Users may 500 maintain multiple Mesh accounts for different purposes. 502 Mesh Service A Mesh Service provides a service identifier (e.g. 503 alice@example.com) through which devices and other Mesh users may 504 interact with a Mesh Account. It is not necessary for a Mesh 505 Account to be connected to a Mesh Service and users may change 506 their Mesh service provider at any time. It is even possible for 507 a Mesh Account to be connected to multiple services at the same 508 time but only one such account is regarded as the primary account 509 at a given time. 511 Mesh Messaging Mesh Messaging allows short messages (less than 32KB) 512 to be exchanged between Mesh devices connected to an account and 513 between Mesh Accounts. One of the key differences between Mesh 514 Messaging and legacy services such as SMTP is that every message 515 received is subjected to access control. 517 A user's Personal Mesh is the set of their Personal Mesh Profiles, 518 Mesh Accounts and the Mesh Services to which they are bound. 520 For example, Figure X shows Alice's personal Mesh which have separate 521 accounts for her personal and business affairs. She has many 522 devices, two of which are shown here. Both are linked to her 523 personal account but only one is linked to her business account. 524 Besides allowing Alice to separate work and pleasure, this separation 525 means that she does not need to worry about her business affairs 526 being compromised if the device Alice2 is stolen. 528 [[This figure is not viewable in this format. The figure is 529 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 530 architecture.html [2].]] 532 Master Profile and Subordinate Devices and Accounts. 534 Alice's ProfileMaster contains a Master Signature Key used to sign 535 the profile itself and one or more Administrator Signature Keys used 536 to sign assertions binding devices and/or assertions to her Mesh. 538 [[This figure is not viewable in this format. The figure is 539 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 540 architecture.html [3].]] 542 Master Profile and Associated Device and Account Connection 543 Assertions. 545 If desired, Alice can escrow the master key associated with her 546 Profile Master and delete it from her device(s), thus ensuring that 547 compromise of the device does not result in a permanent compromise of 548 her personal Mesh. Recovery of the Master Signature Key and the 549 associated Master Encryption Escrow keys (not shown) allows Alice to 550 recover her entire digital life. 552 To eliminate the risk of hardware failure, the escrow scheme offered 553 by the Mesh itself uses key shares printed on paper and an encrypted 554 escrow record stored in the cloud. Mesh users are of course free to 555 use alternative escrow means of their choice. 557 3.2.1. Mesh Device Management 559 Mesh devices are added to or removed from a user's personal Mesh by 560 adding or removing Device catalog entries from the CatalogDevice 561 associated with the Master Profile. 563 Device catalog entries are created by devices that have been 564 provisioned with an administration key specified in the corresponding 565 ProfileMaster 567 The keying material used by a device in the context of a user's 568 personal Mesh comes from two separate sources: 570 o Keying material specified in the ProfileDevice which is either 571 generated on the device itself or installed during manufacture. 573 o Keying material provided by the Administration Device during the 574 connection process. 576 This approach mitigates the risk of keying material used by the 577 device being compromised during or after manufacture and the risks 578 associated with use of weak keys. The key combination mechanism is 579 shown in section XX below and described in detail in 580 [draft-hallambaker-mesh-cryptography] . 582 [[This figure is not viewable in this format. The figure is 583 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 584 architecture.html [4].]] 586 Mapping of Device Profile and Device Private to Device Connection 587 Keys. 589 In accordance with the principle of maintaining cryptographic 590 hygiene, separate keys are generated for signature, authentication 591 and encryption purposes. 593 3.2.2. Mesh Account 595 Mesh Accounts comprise a collection of persistent data stores 596 associated with a particular persona associated with a personal Mesh. 597 The connection between a Mesh Account and the personal Mesh to which 598 it belongs may or may not be public. For example, Alice might allow 599 her contacts to know that her business and personal accounts belong 600 to the same personal Mesh and thus the same person but Bob might not. 602 Mesh Accounts afford similar functionality to the accounts provided 603 by traditional Internet protocols and applications but with the 604 important distinction that they belong to the user and not the 605 service provider. A Mesh Account may be connected to one, many or no 606 Mesh Services and the user may add or delete service providers at any 607 time. 609 A Mesh Account that is not connected to a Service is called an 610 offline account. Offline accounts cannot send or receive Mesh 611 Messages and cannot be synchronized using the Mesh Service protocol 612 (but may be synchronized through other means). 614 When a Mesh Account is connected to multiple services, only the first 615 service is normally regarded as being primary with the others being 616 secondary accounts for use in case of need. 618 Alice's personal account is connected to two devices and two services 619 (alice@example.com and alice@example.net). 621 [[This figure is not viewable in this format. The figure is 622 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 623 architecture.html [5].]] 625 Account Profile Connected to Devices and Services. 627 As with the connection of the device to Alice's personal Mesh, the 628 connection of each device to each account requires the creation of a 629 separate set of keying using the same key combination mechanism 630 described above. This information is contained in the 631 ActivationAccount record corresponding to the account in the 632 CatalogEntryDevice. 634 [[This figure is not viewable in this format. The figure is 635 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 636 architecture.html [6].]] 638 Account Key Set. 640 Note that even though Alice's personal account is connected to two 641 separate Mesh Services, the same cryptographic keys are used for 642 both. However separate keys are used for her personal and business 643 accounts so as to prevent these accounts being linked through use of 644 the same device keys. 646 3.2.2.1. Account Catalogs 648 Mesh Catalogs are a DARE Containers whose entries represent a set of 649 objects with no inherent ordering. Examples of Mesh catalogs 650 include: 652 Devices The devices connected to the corresponding Mesh profile. 654 Contacts Logical and physical contact information for people and 655 organizations. 657 Application 659 Application 661 Bookmarks Web bookmarks and citations. 663 Credentials Username and password information for network resources. 665 Calendar Appointments and tasks. 667 Network Network access configuration information allowing access to 668 WiFi networks and VPNs. 670 Configuration information for applications including mail (SMTP, 671 IMAP, OpenPGP, S/MIME, etc) and SSH. 673 The Devices and Contacts catalogues have special functions in the 674 Mesh as they describe the set of devices and other users that a Mesh 675 user interacts with. 677 These catalogs are also used as the basis for providing a consistent 678 set of friendly names to the users devices and contacts that is 679 accessible to all her devices. This (in principle) allows Alice to 680 give a voice command to her car or her watch or her phone to call a 681 person or open a door and expect consistent results. 683 3.2.3. Mesh Service 685 Each Mesh Service is described by a ProfileService signed by a long- 686 lived signature key. As with the ProfileMaster, a separate set of 687 Administrator keys is used to sign the Assertion Host objects used to 688 credential Service Hosts. 690 [[This figure is not viewable in this format. The figure is 691 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 692 architecture.html [7].]] 694 Service Profile and Delegated Host Assertion. 696 Note that the Mesh Service Authentication mechanism only provides 697 trust after first use. It does not provide a mechanism for secure 698 introduction. A Mesh Service SHOULD be credentialed by means of a 699 validation process that establishes the accountability. For example, 700 the CA-Browser Forum Extended Validation Requirements. 702 3.2.4. Mesh Messaging 704 The Mesh Messaging layer supports the exchange of short (less than 705 32KB) messages. Mesh devices connected to the same Mesh profile may 706 exchange Mesh Messages directly. Messages exchanged between Mesh 707 Users MUST be mediated by a Mesh Service for both sending and 708 receipt. This 'four corner' pattern permits ingress and egress 709 controls to be enforced on the messages and that every message is 710 properly recorded in the appropriate spools. 712 For example, To send a message to Alice, Bob posts it to one of the 713 Mesh Services connected to the Mesh Account from which the message is 714 to be sent. The Mesh Service checks to see that both the message and 715 Bob's pattern of behavior comply with their acceptable use policy and 716 if satisfactory, forwards the message to the receiving service 717 example.com. 719 [[This figure is not viewable in this format. The figure is 720 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 721 architecture.html [8].]] 723 Performing Access Control on Outbound Messages 725 The receiving service uses the recipient's contact catalog and other 726 information to determine if the message should be accepted. If 727 accepted, the message is added to the recipient's inbound message 728 spool to be collected by her device(s) when needed. 730 [[This figure is not viewable in this format. The figure is 731 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 732 architecture.html [9].]] 734 Performing Access Control on Inbound Messages 736 For efficiency and to limit the scope for abuse, all inbound Mesh 737 Messages are subject to access control and limited in size to 32KB or 738 less. This limit has proved adequate to support transfer of complex 739 control messages and short content messages. Transfer of data 740 objects of arbitrary size may be achieved by sending a control 741 message containing a URI for the main content which may then be 742 fetched using a protocol such as HTTP. 744 This approach makes transfers of very large data sets (i.e. multiple 745 Terabytes) practical as the 'push' phase of the protocol is limited 746 to the transfer of the initial control message. The bulk transfer is 747 implemented as a 'pull' protocol allowing support for features such 748 as continuous integrity checking and resumption of an interrupted 749 transfer. 751 3.3. Using the Mesh with Applications 753 The Mesh provides an infrastructure for supporting existing Internet 754 security applications and a set security features that may be used to 755 build new ones. 757 For example, Alice uses the Mesh to provision and maintain the keys 758 she uses for OpenPGP, S/MIME, SSH and IPSEC. She also uses the 759 credential catalog for end-to-end secure management of the usernames 760 and passwords for her Web browsing and other purposes: 762 [[This figure is not viewable in this format. The figure is 763 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 764 architecture.html [10].]] 766 Each of Alice's devices have access to the shared context of her 767 personal account. 769 The Mesh design is highly modular allowing components that were 770 originally designed to support a specific requirement within the Mesh 771 to be applied generally. 773 3.3.1. Contact Exchange 775 One of the chief concerns in any PKI is the means by which the public 776 keys of other users are obtained and validated. This is of 777 particular importance in the Mesh since every Mesh Message is subject 778 to access control and it is thus necessary for Alice to accept Bob's 779 credentials before Bob send most types of message to Alice. 781 The Mesh supports multiple mechanisms for credential exchange. If 782 Alice and Bob meet in person and are carrying their smart phones, a 783 secure mutual exchange of credentials can be achieved by means of a 784 QR code mechanism. If they are at separate locations, Alice can 785 choose between accepting Bob's contact information with or without 786 additional verification according to the intended use. 788 3.3.2. Confirmation Protocol 790 The basic device connection protocol requires the ability for one 791 device to send a connection request to the Mesh service hosting the 792 user's profile. To accept the device connection, the user connects 793 to the service using an administration device, reviews the pending 794 requests and creates the necessary device connection assertion if it 795 is accepted. 797 The confirmation protocol generalizes this communication pattern 798 allowing any authorized party to post a short accept/reject question 799 to the user who may (or may not) return a signed response. This 800 feature can be used as improvement on traditional second factor 801 authentication providing resistance to man-in-the-middle attacks and 802 providing a permanent non-repudiable indication of the user's 803 specific intent. 805 3.3.3. Future Applications 807 Since a wide range of network applications may be reduced to 808 synchronization of sets and lists, the basic primitives of Catalogs 809 and Spools may be applied to achieve end-to-end security in an even 810 wider variety of applications. 812 For example, a Spool may be used to maintain a mailing list, track 813 comments on a Web forum or record annotations on a document. 814 Encrypting the container entries under a multi-party encryption group 815 allows such communications to be shared with a group of users while 816 maintaining full end-to-end security and without requiring every 817 party writing to the spool to know the public encryption key of every 818 recipient. 820 Another interesting possibility is the use of DARE Containers as a 821 file archive mechanism. A single signature on the final Merkle Tree 822 digest value would be sufficient to authenticate every file in the 823 archive. Updates to the archive might be performed using the same 824 container synchronization primitives provided by a Mesh Service. 825 This approach could afford a robust, secure and efficient mechanism 826 for software distribution and update. 828 4. Mesh Cryptography 830 All the cryptographic algorithms used in the Mesh are either industry 831 standards or present a work factor that is provably equivalent to an 832 industry standard approach. 834 Existing Internet security protocols are based on approaches 835 developed in the 1990s when performance tradeoffs were a prime 836 consideration in the design of cryptographic protocols. Security was 837 focused on the transport layer as it provided the best security 838 possible given the available resources. 840 With rare exceptions, most computing devices manufactured in the past 841 ten years offer either considerably more computing power than was 842 typical of 1990s era Internet connected machines or considerably 843 less. The Mesh architecture is designed to provide security 844 infrastructure both classes of machine but with the important 845 constraint that the less capable 'constrained' devices are considered 846 to be 'network capable' rather than 'Internet capable' and that the 847 majority of Mesh related processing will be offloaded to another 848 device. 850 For example, Alice uses her Desktop and Laptop to exchange end-to-end 851 secure Mesh Messages and documents but her Internet-of-Things food 852 blender and light bulb are limited in the range of functions they 853 support and the telemetry information they provide. The IoT devices 854 connect to a Mesh Hub which acts as an always-on point of presence 855 for the device state and allows complex cryptographic operations to 856 be offloaded if necessary. 858 [[This figure is not viewable in this format. The figure is 859 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 860 architecture.html [11].]] 862 Constrained Devices connected through a Mesh Hub. 864 4.1. Best Practice by Default 866 Except where support for external applications demand otherwise, the 867 Mesh requires that the following 'best practices' be followed: 869 Industry Standard Algorithms All cryptographic protocols make use of 870 the most recently adopted industry standard algorithms. 872 Strongest Work Factor Only the strongest modes of each cipher 873 algorithm are used. All symmetric encryption is performed with 874 256-bit session keys and all digest algorithms are used in 512-bit 875 output length mode. 877 Key Hygiene Separate public key pairs are used for all cryptographic 878 functions: Encryption, Signature and Authentication. This enables 879 separate control regimes for the separate functions and 880 partitioning of cryptographic functions within the application 881 itself. 883 Bound Device Keys Each device has a separate set of Encryption, 884 Signature and Authentication key pairs. These MAY be bound to the 885 device to which they are assigned using hardware or other 886 techniques to prevent or discourage export. 888 No Optional Extras Traditional approaches to security have treated 889 many functions as being 'advanced' and thus suited for use by only 890 the most sophisticated users. The Mesh rejects this approach 891 noting that all users operate in precisely the same environment 892 facing precisely the same threats. 894 4.2. Multi-Level Security 896 All Mesh protocol transactions are protected at the Transport, 897 Message and Data level. This provides security in depth that cannot 898 be achieved by applying security at the separate levels 899 independently. Data level encryption provides end-to-end 900 confidentiality and non-repudiation, Message level authentication 901 provides the basis for access control and Transport level encryption 902 provides a degree of protection against traffic analysis. 904 4.3. Multi-Key Decryption 906 Traditional public key encryption algorithms have two keys, one for 907 encryption and another for decryption. The Mesh makes use of 908 threshold cryptography techniques to allow the decryption key to be 909 split into two or more parts. 911 For example, if we have a private key z, we can use this to perform a 912 key agreement with a public key S to obtain the key agreement value 913 A. But if z = (x+y) mod g (where g is the order of the group). we 914 can obtain the exact same result by applying the private keys x and y 915 to S separately and combining the results: 917 [[This figure is not viewable in this format. The figure is 918 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 919 architecture.html [12].]] 921 Two key decryption. 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 }, we 939 calculate the public key corresponding to the private key x + y using 940 just the public key values X and Y. 942 [[This figure is not viewable in this format. The figure is 943 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 944 architecture.html [13].]] 946 Two party key pair generation. 948 Multi-party key generation ensures that keys used to bind devices to 949 a personal Mesh or within a Mesh account are 'safe' if any of the 950 contributions to the generation process are safe. 952 4.5. Data At Rest Encryption 954 The Data At Rest Encryption (DARE) format is used for all 955 confidentiality and integrity enhancements. The DARE format is based 956 on the JOSE Signature and Encryption formats and the use of an 957 extended version of the JSON encoding allowing direct encoding of 958 binary objects. 960 4.5.1. DARE Envelope 962 The DARE Envelope format offers similar capabilities to existing 963 formats such as OpenPGP and CMS without the need for onerous encoding 964 schemes. DARE Assertions are presented as DARE Envelopes. 966 A feature of the DARE Envelope format not supported in existing 967 schemes is the ability to encrypt and authenticate sets of data 968 attributes separately from the payload. This allows features such as 969 the ability to encrypt a subject line or content type for a message 970 separately from the payload. 972 4.5.2. Dare Container 974 A DARE Container is an append-only sequence of DARE Envelopes. A key 975 feature of the DARE Container format is that entries MAY be encrypted 976 and/or authenticated incrementally. Individual entries MAY be 977 extracted from a DARE Container to create a stand-alone DARE 978 Envelope. 980 Containers may be authenticated by means of a Merkle tree of digest 981 values on the individual frames. This allows similar demonstrations 982 of integrity to those afforded by Blockchain to be provided but with 983 much greater efficiency. 985 Unlike traditional encryption formats which require a new public key 986 exchange for each encrypted payload, the DARE Container format allows 987 multiple entries to be encrypted under a single key exchange 988 operation. This is particularly useful in applications such as 989 encrypting server transaction logs. The server need only perform a 990 single key exchange operation is performed each time it starts to 991 establish a master key. The master key is then used to create fresh 992 symmetric keying material for each entry in the log using a unique 993 nonce per entry. 995 [[This figure is not viewable in this format. The figure is 996 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 997 architecture.html [14].]] 999 DARE Container containing a transaction log. 1001 Integrity is provided by a Merkle tree calculated over the sequence 1002 of log entries. The tree apex is signed at regular intervals to 1003 provide non-repudiation. 1005 Three types of DARE Containers are used in the mesh 1007 Catalogs A DARE Container whose entries track the status of a set of 1008 related objects which may be added, updated or deleted. 1010 Spools A DARE Container whose entries track the status of a series 1011 of Mesh Messages. 1013 Archives A DARE Container used to provide a file archive with 1014 optional confidentiality and/or integrity enhancements. 1016 4.6. Uniform Data Fingerprints. 1018 The Uniform Data Fingerprint (UDF) format provides a compact means of 1019 presenting cryptographic nonces, keys and digest values using Base32 1020 encoding that resists semantic substitution attacks. UDF provides a 1021 convenient format for data entry. Since the encoding used is case- 1022 insensitive, UDFs may if necessary be read out over a voice link 1023 without excessive inconvenience. 1025 The following are examples of UDF values: 1027 NBIK-OM6U-OJ4F-DOUC-AQ74-W7B6-3Z6Q 1028 EBWM-M66M-3HA5-DPB5-DQJT-HBNE-7WUQ 1029 SAQL-VVJQ-VJQY-MC2Y-OLIR-GWT7-AAQS-K 1030 MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4 1031 KCM5-7VB6-IJXJ-WKHX-NZQF-OKGZ-EWVN 1032 ABUK-NC4K-SSIV-HVKZ-A3Z7-SNPA-ZAQP 1034 UDF content digests are used to support a direct trust model similar 1035 to that of OpenPGP. Every Mesh Profile is authenticated by the UDF 1036 fingerprint of its signature key. Mesh Friendly Names and UDF 1037 Fingerprints thus serve analogous functions to DNS names and IP 1038 Addresses. Like DNS names, Friendly Names provide the basis for 1039 application-layer interactions while the UDF Fingerprints are used as 1040 to provide the foundation for security. 1042 4.6.1. Friendly Names 1044 Internet addressing schemes are designed to provide a globally unique 1045 (or at minimum unambiguous) name for a host, service or account. In 1046 the early days of the Internet, this resulted in addresses such as 1047 10.2.3.4 and alice@example.com which from a usability point of view 1048 might be considered serviceable if not ideal. Today the Internet is 1049 a global infrastructure servicing billions of users and tens of 1050 billions of devices and accounts are more likely to be 1051 alice.lastname.1934@example.com than something memorable. 1053 Friendly names provide a user or community specific means of 1054 identifying resources that may take advantage of geographic location 1055 or other cues to resolve possible ambiguity. If Alice says to her 1056 voice activated device "close the garage door" it is implicit that it 1057 is her garage door that she wishes to close. And should Alice be 1058 fortunate enough to own two houses with a garage, it is implicit that 1059 it is the garage door of the house she is presently using that she 1060 wishes to close. 1062 The Mesh Device Catalog provides a directory mapping friendly names 1063 to devices that is available to all Alice's connected devices so that 1064 she may give and instruction to any of her devices using the same 1065 friendly name and expect consistent results. 1067 4.6.2. Encrypted Authenticated Resource Locators 1069 Various schemes have been used to employ QR Codes as a means of 1070 device and/or user authentication. In many of these schemes a QR 1071 code contains a challenge nonce that is used to authenticate the 1072 connection request. 1074 The Mesh supports a QR code connection mode employing the Encrypted 1075 Authenticated Resource Locator (EARL) format. An EARL is an 1076 identifier which allows an encrypted data object to be retrieved and 1077 decrypted. In this case, the encrypted data object contains the 1078 information needed to complete the interaction. 1080 An EARL contains the domain name of the service providing the 1081 resolution service and an encryption master key: 1083 udf://example.com/EBLD-J4FF-5G63-FS7P-TEHG-HMIW-FCMV-E7 1084 The EARL may be expressed as a QR code: 1086 [[This figure is not viewable in this format. The figure is 1087 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 1088 architecture.html [15].]] 1090 QR Code representation of the EARL 1092 An EARL is resolved by presenting the content digest fingerprint of 1093 the encryption key to a Web service hosted at the specified domain. 1094 The service returns a DARE Envelope whose payload is encrypted and 1095 authenticated under the specified master key. Since the content is 1096 stored on the service under the fingerprint of the key and not the 1097 key itself, the service cannot decrypt the plaintext. Only a party 1098 that has access to the encryption key in the QR code can decrypt the 1099 message. 1101 4.6.3. Secure Internet Names 1103 Secure Internet Names bind an Internet address such as a URL or an 1104 email address to a Security Policy by means of a UDF content digest 1105 of a document describing the security policy. This binding enables a 1106 SIN-aware Internet client to ensure that the security policy is 1107 applied when connecting to the address. For example, ensuring that 1108 an email sent to an address must be end-to-end encrypted under a 1109 particular public key or that access to a Web Service requires a 1110 particular set of security enhancements. 1112 alice@example.com Alice's regular email address (not a SIN). 1114 alice@mm--uuuu-uuuu-uuuu.example.com A strong email address for 1115 Alice that can be used by a regular email client. 1117 alice@example.com.mm--uuuu-uuuu-uuuu A strong email address for 1118 Alice that can only used by an email client that can process SINs. 1120 Using an email address that has the Security Policy element as a 1121 prefix allows a DNS wildcard element to be defined that allows the 1122 address to be used with any email client. Presenting the Security 1123 Policy element as a suffix means it can only be resolved by a SIN- 1124 aware client. 1126 4.7. Personal Key Escrow 1128 One of the core objectives of the Mesh is to make data level 1129 encryption ubiquitous. While data level encryption provides robust 1130 protection of data confidentiality, loss of the ability to decrypt 1131 means data loss. 1133 For many Internet users, data availability is a considerably greater 1134 concern than confidentiality. Ten years later, there is no way to 1135 replace pictures of the children at five years old. Recognizing the 1136 need to guarantee data recovery, the Mesh provides a robust personal 1137 key escrow and recovery mechanism. Lawful access is not supported as 1138 a requirement. 1140 Besides supporting key recovery in the case of loss, the Mesh 1141 protocols potentially support key recovery in the case of the key 1142 holder's death. The chief difficulty faced in implementing such a 1143 scheme being developing an acceptable user interface which allows the 1144 user to specify which of their data should survive them and which 1145 should not. As the apothegm goes: Mallet wants his beneficiaries to 1146 know where he buried Aunt Agatha's jewels but not where he buried 1147 Aunt Agatha. 1149 The Mesh supports use of Shamir Secret Sharing to split a secret key 1150 into a set of shares, a predetermined number of which may be used to 1151 recover the original secret. For convenience secret shares are 1152 represented using UDF allowing presentation in Base32 (i.e. text 1153 format) for easy transcription or QR code presentation if preferred. 1155 A Mesh Profile is escrowed by creating a recovery record containing 1156 the private keys corresponding to the master signature and master 1157 escrow keys associated with the profile. A master secret is then 1158 generated which is used to generate a symmetric encryption key used 1159 to encrypt the recovery record and to generate the desired number of 1160 recovery shares. For example, Alice escrows her Mesh Profile 1161 creating three recovery shares, two of which are required to recover 1162 the master secret: 1164 [[This figure is not viewable in this format. The figure is 1165 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 1166 architecture.html [16].]] 1168 Use of Shamir Secret Sharing to create a recovery record. 1170 To recover the master secret, Alice presents the necessary number of 1171 key shares. These are used to recover the master secret which is 1172 used to generate the decryption key. 1174 [[This figure is not viewable in this format. The figure is 1175 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 1176 architecture.html [17].]] 1178 Use of Shamir Secret Recovery to recover a master key set. 1180 A user may choose to store their encrypted recovery record themselves 1181 or make use of the EARL mechanism to store the information at one or 1182 more cloud services using the fingerprint of the master secret as the 1183 locator. 1185 5. User Experience 1187 This section describes the Mesh in use. These use cases described 1188 here are re-visited in the companion Mesh Schema Reference 1189 [draft-hallambaker-mesh-schema] and Mesh Protocol Reference 1190 [draft-hallambaker-mesh-protocol] with additional examples and 1191 details. 1193 For clarity and for compactness, these use cases are illustrated 1194 using the command line tool meshman. 1196 The original design brief for the Mesh was to make it easier to use 1197 the Internet securely. Over time, it was realized that users are 1198 almost never prepared to sacrifice usability or convenience for 1199 security. It is therefore insufficient to minimize the cost of 1200 security, if secure applications are to be used securely they must be 1201 at least as easy to use as those they replace. If security features 1202 are to be used, they must not require the user to make any additional 1203 effort whatsoever. 1205 The key to meeting this constraint is that any set of instructions 1206 that can be written down to be followed by a user can be turned into 1207 code and executed by machine. Provided that the necessary 1208 authentication, integrity and confidentiality controls are provided. 1209 Thus, the Mesh is not just a cryptographic infrastructure that makes 1210 use of computer systems more secure, it is a usability infrastructure 1211 that makes computers easier to use by providing security. 1213 The user experience is thus at the heart of the design of the Mesh 1214 and a description of the Mesh Architecture properly begins with 1215 consideration of the view of the system that matters most: that of 1216 the user. 1218 The principle security protocols in use today were designed at a time 1219 when most Internet users made use of either a single machine or one 1220 of a number of shared machines connected to a shared file store. The 1221 problem of transferring cryptographic keys and configuration data 1222 between machines was rarely considered and when it was considered was 1223 usually implemented badly. Today the typical user owns or makes use 1224 of multiple devices they recognize as a computer (laptop, tablet) and 1225 an even greater number of devices that they do not recognize as 1226 computers but are (almost any device with a display). 1228 [[This figure is not viewable in this format. The figure is 1229 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 1230 architecture.html [18].]] 1232 Alice's personal Mesh. 1234 5.1. Creating a Mesh Profile and Administration Device. 1236 The first step in using the Mesh is to create a personal profile. 1237 From the user's point of view a profile is a collection of all the 1238 configuration data for all the Mesh enabled devices and services that 1239 they interact with. 1241 Alice> mesh create 1242 Device Profile UDF=MDAA-75W5-HOD4-LSSU-JNYG-WHML-34DU 1243 Personal Profile UDF=MAOZ-3MVE-G5EN-64BI-I3RM-ODFJ-H5W4 1245 Note that the user does not specify the cryptographic algorithms to 1246 use. Choice of cryptographic algorithm is primarily the concern of 1247 the protocol designer, not the user. The only circumstance in which 1248 users would normally be involved in algorithm selection is when there 1249 is a transition in progress from one algorithm suite to another. 1251 5.2. Mesh Accounts 1253 Add an account to the personal Mesh: 1255 Alice> account create personal 1256 Account=MAFZ-VUMP-7PU3-4TP7-7MRZ-BKBQ-VMNN 1258 A Mesh Catalog contains a set of entries, each of which has a unique 1259 object identifier. Catalog entries may be added, updated or deleted. 1261 By default, all catalog entries are encrypted. Applying the Default 1262 Deny principle, in normal circumstances, the Mesh Service is not 1263 capable of decrypting any catalog excepting the Contacts catalog 1264 which is used as a source of authorization data in the Access Control 1265 applied to inbound messaging requests. 1267 For example, the entries in the credentials catalog specify username 1268 and password credentials used to access Internet services. Adding 1269 credentials to her catalog allows Alice to write scripts that access 1270 password protected resources without including the passwords in the 1271 scripts themselves: 1273 Alice> password add ftp.example.com alice1 password 1274 alice1@ftp.example.com = [password] 1275 Alice> password add www.example.com alice@example.com newpassword 1276 alice@example.com@www.example.com = [newpassword] 1277 Alice> password list 1278 alice1@ftp.example.com = [password] 1279 alice@example.com@www.example.com = [newpassword] 1280 Alice> password add ftp.example.com alice1 newpassword 1281 alice1@ftp.example.com = [newpassword] 1282 Alice> password get ftp.example.com 1283 alice1@ftp.example.com = [newpassword] 1285 5.3. Mesh Service 1287 A Mesh Service provides an 'always available' point of presence that 1288 is used to exchange data between devices connected to the connected 1289 profile and send and receive Mesh Messages to and from other Mesh 1290 users. 1292 To use a Mesh Service, a user creates a Mesh Service account. This 1293 is analogous to an SMTP email service but with the important 1294 distinction that the protocol is designed to allow users to change 1295 their Mesh Service provider at any time they choose with minimal 1296 impact. 1298 The account is created by sending an account registration request to 1299 the chosen Mesh Service. If accepted, the Mesh Service creates a new 1300 account and creates containers to hold the associated catalogs and 1301 spools: 1303 Alice> account register alice@example.com 1304 ERROR - Object reference not set to an instance of an object. 1306 As with any other Internet service provision, Mesh Service providers 1307 may impose constraints on the use of their service such as the amount 1308 of data they send, store and receive and charge a fee for their 1309 service. 1311 5.4. Connecting and Authorizing Additional Devices 1313 Having established a Mesh profile, a user may connect any number of 1314 devices to it. Connecting a device to a Mesh profile allows it to 1315 share data with, control and be controlled by other devices connected 1316 to the profile. 1318 Although any type of network capable device may be connected to a 1319 Mesh profile, some devices are better suited for use with certain 1320 applications than others. Connecting an oven to a Mesh profile could 1321 allow it to be controlled through entries to the user's recipe and 1322 calendar catalogs and alert the user when the meal is ready but 1323 attempting to use it to read emails or manage Mesh profiles. 1325 Three connection mechanisms are currently specified, each of which 1326 provides strong mutual authentication: Direct, PIN and QR. 1328 Since approval of a connection request requires the creation of a 1329 signed Connection Assertion, requests must be approved by a device 1330 that has access to an administration key authorized by the user's 1331 Master Profile. Such devices are referred to as Administration 1332 devices. Administration devices must have data entry (e.g. keyboard) 1333 and output (e.g. display) affordances to support any of the currently 1334 defined connection mechanisms. The QR code connection mechanism also 1335 requires a suitable camera. 1337 It will be noted that the process of connecting a device that 1338 contains a preconfigured set of device keys might in principle expose 1339 the user to the risk that the manufacturer has retained knowledge of 1340 these keys and that this might be used to create a 'backdoor'. 1342 This risk is controlled using the key co-generation technique 1343 described earlier. The original device profile is combined with a 1344 device profile provided by the user to create a composite device 1345 profile. This ensures that every device uses a unique profile even 1346 if they are initialized from a shared firmware image containing a 1347 fixed set of device key pairs. 1349 5.4.1. Direct Connection 1351 The direct connection mechanism requires that both the administration 1352 device and the device originating the connection request have data 1353 entry and output affordances and that it is possible for the user to 1354 compare the authentication codes presented by the two devices to 1355 check that they are identical. 1357 The connection request is initiated on the device being connected: 1359 Alice2> device request alice@example.com 1360 Witness value = ZHVP-GQK3-2BZU-NBLU-XDD4-BIJ2-PZCG 1361 Personal Mesh = MAOZ-3MVE-G5EN-64BI-I3RM-ODFJ-H5W4 1363 Using her administration device, Alice gets a list of pending 1364 requests. Seeing that there is a pending request matching the 1365 witness value presented by the device, Alice accepts it: 1367 Alice> device pending 1368 Alice> device accept NDKO-YOY7-Z6VX-A7LZ-A4SC-SI2W-ZMAX 1370 The new device will now synchronize automatically in response to any 1371 Mesh commands. For example, listing the password catalog: 1373 Alice2> password list 1374 ERROR - The feature has not been implemented 1376 5.4.2. Pin Connection 1378 The PIN Connection mechanism is similar to the Direct connection 1379 mechanism except that the process is initiated on an administration 1380 device by requesting assignment of a new authentication PIN. The PIN 1381 is then input to the connecting device to authenticate the request. 1383 The PIN connection mechanism begins with the issue of the PIN: 1385 Alice> account pin 1386 PIN=NBYN-CATU-35TJ-GE6H-CI (Expires=2019-08-14T11:36:37Z) 1388 The PIN code is transmitted out of band to the device being 1389 connected: 1391 Alice3> device request alice@example.com /pin=NBYN-CATU-35TJ-GE6H-CI 1392 Witness value = Y5CA-PUCH-MIFW-H3QL-2QV7-L4W5-HLT3 1393 Personal Mesh = MAOZ-3MVE-G5EN-64BI-I3RM-ODFJ-H5W4 1395 Since the request was pre-authorized, it is not necessary for Alice 1396 to explicitly accept the connection request but the administration 1397 device is needed to create the connection assertion: 1399 Alice> device pending 1401 We can check the device connection by attempting to synchronize to 1402 the profile account: 1404 Alice3> account sync 1405 ERROR - The feature has not been implemented 1406 Note that this connection mechanism could be addapted to allow a 1407 device with a camera affordance to connect by scanning a QR code on 1408 the administration device. 1410 If the Device Profile fingerprint is known at the time the PIN is 1411 generated, this can be bound to the PIN authorization assertion to 1412 permit connection of a specific device. 1414 5.4.3. EARL/QR Code Connection 1416 The EARL/QR code connection mechanisms are used to connect a 1417 constrained device to a Mesh profile by means of an Encrypted 1418 Authenticated Resource Locator, typically presented as a QR code on 1419 the device itself or its packaging. 1421 Since the meshman tool does not support QR input, it is decoded using 1422 a separate tool to recover the UDF EARL which is presented as a 1423 command line parameter: 1425 To use the device QR code connection mechanism, we require a Web 1426 service that will host the connection document example.com and a 1427 MeshService account that the device will attempt to complete the 1428 connection by requesting synchronization devices@example.com. 1430 To begin the process we generate a new random key and combine it with 1431 the service to create an EARL: 1433 udf://example.com/EBLD-J4FF-5G63-FS7P-TEHG-HMIW-FCMV-E7 1435 Next a device profile is created and preregistered on with the Mesh 1436 Service that will provide the hailing service. Since we are only 1437 preparing one device it is convenient to do this on the device 1438 itself. In a manufacturing scenario, these steps would typically be 1439 performed offline in bulk. 1441 Alice4> device pre devices@example.com /key=udf://example.com/EBLD-J4FF-5G63-FS7P-TEHG-HMIW-FCMV-E7 1442 ERROR - Object reference not set to an instance of an object. 1444 Once initialized the device attempts to poll the service for a 1445 connection each time it is powered on, when a connection button 1446 affordance on the device is pressed or at other times as agreed with 1447 the Mesh Service Provider: 1449 Alice4> account sync 1450 ERROR - The feature has not been implemented 1452 To connect the device to her profile, Alice scans the device with her 1453 administration device to obtain the UDF. The administration device 1454 retrieves the connection description, decrypts it and then uses the 1455 information in the description to create the necessary Device 1456 Connection Assertion and connect to the device hailing Mesh Service 1457 Account to complete the process: 1459 Alice> device earl udf://example.com/EBLD-J4FF-5G63-FS7P-TEHG-HMIW-FCMV-E7 1460 ERROR - Object reference not set to an instance of an object. 1462 When the device next attempts to connect to the hailing service, it 1463 receives the Device Connection Assertion: 1465 Alice4> account sync 1466 ERROR - The feature has not been implemented 1468 5.5. Contact Requests 1470 As previously stated, every inbound Mesh message is subject to access 1471 control. The user's contact catalog is used as part of the access 1472 control authentication and authorization mechanism. 1474 By default, the only form of inbound message that is accepted without 1475 authorization in the contact catalog is a contact request. Though 1476 for certain Mesh users (e.g. politicians, celebrities) even contact 1477 requests might require some form of prior approval (e.g. endorsement 1478 by a mutual friend). 1480 A Mesh Contact Assertion may be limited to stating the user's profile 1481 fingerprint and Mesh Service Account(s). For most purposes however, 1482 it is more convenient to present a Contact Assertion that contains at 1483 least as much information as is typically provided on a business or 1484 calling card: 1486 Alice creates a contact entry for herself: 1488 Alice> contact self email alice@example.com 1489 { 1490 "Self": true, 1491 "Key": "NCYX-WCHS-VBNU-KDZT-NW5A-553A-U6CZ", 1492 "EnvelopedContact": [{}, 1493 "ewogICJDb250YWN0IjogewogICAgIkFkZHJlc3Nlcy 1494 I6IFt7CiAgICAgICAgIlVSSSI6ICJtYWlsdG86e2VtYWlsfSJ9XX19"]}~~~~ 1496 User's may create multiple Contact Assertions for use in different 1497 circumstances. A user might not want to give their home address to a 1498 business contact or their business address to a personal friend. 1500 5.5.1. Remote 1502 In the most general case, the participants are remote from each other 1503 and one user must make a contact request of the other: 1505 Bob requests Alice add him to her contacts catalog: 1507 Bob> message contact alice@example.com 1508 ERROR - The feature has not been implemented 1510 When Alice next checks her messages, she sees the pending contact 1511 request from Bob and accepts it. Bob's contact details are added to 1512 her catalog and Bob receives a response containing Alice's 1513 credentials: 1515 Alice> message pending 1516 Alice> message accept tbs 1518 5.5.2. Static QR Code 1520 A DARE contact entry may be exchanged by means of an EARL UDF. This 1521 is typically presented by means of a QR code which may be created 1522 using the meshman tool and a QR code generator. The resulting QR 1523 code may be printed on a business card, laser engraved on a luggage 1524 tag, etc. 1526 To accept the contact request, the recipient merely scans the code 1527 with a Mesh capable QR code reader. They are asked if they wish to 1528 accept the contact request and what privileges they wish to authorize 1529 for the new contact. 1531 5.5.3. Dynamic QR Code 1533 If it is possible for the device to generate a new QR code for the 1534 contact request, it is possible to support bi-directional exchange of 1535 credentials with strong mutual authentication. 1537 For example, Alice selects the contact credential she wishes to pass 1538 to Bob on her mobile device which presents an EARL as a QR code. Bob 1539 scans the QR code with his mobile device which retrieves Alice's 1540 credential and asks if Bob wishes to accept it and if he wishes to 1541 share his credential with Alice. If Bob agrees, his device makes a 1542 Remote Contact request authenticated under a key passed to his device 1543 with Alice's Contact Assertion. 1545 The Dynamic QR Code protocol may be applied to support exchange of 1546 credentials between larger groups. Enrolling the contact assertions 1547 collected in such circumstances in a notarized append only log (e.g. 1549 a DARE Container) provides a powerful basis for building a Web of 1550 Trust that is equivalent to but considerably more convenient than 1551 participation in PGP Key Signing parties. 1553 5.6. Sharing Confidential Data in the Cloud 1555 As previously discussed, the Mesh makes use of multi-party encryption 1556 techniques to mitigate the risk of a device compromise leading to 1557 disclosure of confidential data. The Mesh also allows these 1558 techniques to be applied to provide Confidential Document Control. 1559 This provides data encryption capabilities that are particularly 1560 suited to 'cloud computing' environments. 1562 A Mesh Encryption Group is a special type of Mesh Service Account 1563 that is controlled by one of more group administrators. The 1564 Encryption Group Key is a normal ECDH public key used in the normal 1565 manner. The decryption key is held by the group administrator. To 1566 add a user to the group, the administrator splits the group private 1567 key into two parts, a service key and a user key. These parts are 1568 encrypted under the public encryption keys of their assigned parties. 1569 The encrypted key parts form a decryption entry for the user is added 1570 to the Members Catalog of the Encryption Group at the Mesh Service. 1572 [[This figure is not viewable in this format. The figure is 1573 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 1574 architecture.html [19].]] 1576 When a user needs to decrypt a document encrypted under the group 1577 key, they make a request to the Mesh Service which checks to see that 1578 they are authorized to read that particular document, have not 1579 exceeded their decryption quota, etc. If the request is approved, 1580 the service returns the partial decryption result obtained from the 1581 service's key part together with the encrypted user key part. To 1582 complete the decryption process, the user decrypts their key part and 1583 uses it to create a second partial decryption result which is 1584 combined with the first to obtain the key agreement value needed to 1585 complete the decryption process. 1587 Alice creates the recryption group groupw@example.com to share 1588 confidential information with her closest friends: 1590 Alice> group create groupw@example.com 1591 ERROR - The feature has not been implemented 1593 Bob encrypts a test file but he can't decrypt it because he isn't in 1594 the group: 1596 Bob> dare encodeTestFile1.txt /out=TestFile1-group.dare /encrypt=groupw@example.com 1597 ERROR - The command is not known. 1598 Bob> dare decode TestFile1-group.dare 1599 ERROR - The feature has not been implemented 1601 Since she is the group administrator, Alice can decrypt the test file 1602 using the group decryption key: 1604 Alice> dare decode TestFile1-group.dare 1605 ERROR - The feature has not been implemented 1607 Adding Bob to the group gives him immediate access to any file 1608 encrypted under the group key without making any change to the 1609 encrypted files: 1611 Alice> dare decode TestFile1-group.dare 1612 ERROR - The feature has not been implemented 1614 Removing Bob from the group immediately withdraws his access. 1616 Alice> group delete groupw@example.com bob@example.com 1617 ERROR - The feature has not been implemented 1619 Bob cannot decrypt any more files (but he may have kept copies of 1620 files he decrypted earlier). 1622 Alice> dare decode TestFile1-group.dare 1623 ERROR - The feature has not been implemented 1625 Should requirements demand, the same principle may be applied to 1626 achieve separation of duties in the administration roles. Instead of 1627 provisioning the group private key to a single administrator, it may 1628 be split into two or more parts. Adding a user to the group requires 1629 each of the administrators to create a decryption entry for the user 1630 and for the service and user to apply the appropriate operations to 1631 combine the key parts available to them before use. 1633 These techniques could even be extended to support complex 1634 authorization requirements such as the need for 2 out of 3 1635 administrators to approve membership of the group. A set of 1636 decryption entries is complete if the sum of the key parts is equal 1637 to the private key (modulo the order of the curve). 1639 Thus, if the set of administrators is A, B and C and the private key 1640 is k, we can ensure that it requires exactly two administrators to 1641 create a complete set of decryption entries by issuing key set { a } 1642 to A, the key set {k-a , b } to B and the key set {k-a , k-b } to C 1643 (where a and b are randomly generated keys). 1645 5.7. Escrow and Recovery of Keys 1647 One of the chief objections made against deployment of Data Level 1648 encryption is that although it provides the strongest possible 1649 protection of the confidentiality of the data, loss of the decryption 1650 keys means loss of the encrypted data. Thus, a robust and effective 1651 key escrow mechanism is essential if use of encryption is to ever 1652 become commonplace for stored data. 1654 The use of a 'life-long' Mesh profiles raises a similar concern. 1655 Loss of a Master Signature Key potentially means the loss of the 1656 ability to control devices connected to the profile and the 1657 accumulated trust endorsements of other users. 1659 Because of these requirements, Mesh users are strongly advised but 1660 not required to create a backup copy of the private keys 1661 corresponding to their Master Profile Signature and Escrow keys. 1663 Users may use the key escrow mechanism of their choice including the 1664 escrow mechanism supported by the Mesh itself which uses Shamir 1665 Secret Sharing to escrow the encryption key for a DARE Envelope 1666 containing the private key information. 1668 To escrow a key set, the user specifies the number of key shares to 1669 be created and the number required for recovery. 1671 Alice> mesh escrow 1672 ERROR - The cryptographic provider does not permit export of the private key parameters 1674 Recovery of the key data requires the key recovery record and a 1675 quorum of the key shares: 1677 Having recovered the Master Signature Key, the user can now create a 1678 new master profile authorizing a new administration device which can 1679 be used to authenticate access to the Mesh Service Account(s) 1680 connected to the master profile. 1682 6. Security Considerations 1684 The security considerations for use and implementation of Mesh 1685 services and applications are described in the Mesh Security 1686 Considerations guide [draft-hallambaker-mesh-security] . 1688 7. IANA Considerations 1690 This document does not contain actions for IANA 1692 8. Acknowledgements 1694 Comodo Group: Egemen Tas, Melhi Abdulhayo?lu, Rob Stradling, Robin 1695 Alden. 1697 9. References 1699 9.1. Normative References 1701 [draft-hallambaker-jsonbcd] 1702 Hallam-Baker, P., "Binary Encodings for JavaScript Object 1703 Notation: JSON-B, JSON-C, JSON-D", draft-hallambaker- 1704 jsonbcd-14 (work in progress), April 2019. 1706 [draft-hallambaker-mesh-cryptography] 1707 Hallam-Baker, P., "Mathematical Mesh 3.0 Part VIII: 1708 Cryptographic Algorithms", draft-hallambaker-mesh- 1709 cryptography-02 (work in progress), July 2019. 1711 [draft-hallambaker-mesh-dare] 1712 Hallam-Baker, P., "Mathematical Mesh 3.0 Part III : Data 1713 At Rest Encryption (DARE)", draft-hallambaker-mesh-dare-03 1714 (work in progress), July 2019. 1716 [draft-hallambaker-mesh-developer] 1717 Hallam-Baker, P., "Mathematical Mesh: Reference 1718 Implementation", draft-hallambaker-mesh-developer-08 (work 1719 in progress), April 2019. 1721 [draft-hallambaker-mesh-platform] 1722 Hallam-Baker, P., "Mathematical Mesh: Platform 1723 Configuration", draft-hallambaker-mesh-platform-04 (work 1724 in progress), April 2019. 1726 [draft-hallambaker-mesh-protocol] 1727 Hallam-Baker, P., "Mathematical Mesh Part V: Protocol 1728 Reference", draft-hallambaker-mesh-protocol-01 (work in 1729 progress), July 2019. 1731 [draft-hallambaker-mesh-schema] 1732 Hallam-Baker, P., "Mathematical Mesh 3.0 Part IV: Schema 1733 Reference", draft-hallambaker-mesh-schema-02 (work in 1734 progress), July 2019. 1736 [draft-hallambaker-mesh-security] 1737 Hallam-Baker, P., "Mathematical Mesh Part VII: Security 1738 Considerations", draft-hallambaker-mesh-security-01 (work 1739 in progress), July 2019. 1741 [draft-hallambaker-mesh-trust] 1742 Hallam-Baker, P., "Mathematical Mesh Part VI: The Trust 1743 Mesh", draft-hallambaker-mesh-trust-02 (work in progress), 1744 July 2019. 1746 [draft-hallambaker-mesh-udf] 1747 Hallam-Baker, P., "Mathematical Mesh 3.0 Part II: Uniform 1748 Data Fingerprint.", draft-hallambaker-mesh-udf-04 (work in 1749 progress), July 2019. 1751 [draft-hallambaker-web-service-discovery] 1752 Hallam-Baker, P., "DNS Web Service Discovery", draft- 1753 hallambaker-web-service-discovery-02 (work in progress), 1754 April 2019. 1756 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1757 Requirement Levels", BCP 14, RFC 2119, 1758 DOI 10.17487/RFC2119, March 1997. 1760 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1761 (TLS) Protocol Version 1.2", RFC 5246, 1762 DOI 10.17487/RFC5246, August 2008. 1764 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 1765 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1766 2014. 1768 [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 1769 (HTTP/1.1): Semantics and Content", RFC 7231, 1770 DOI 10.17487/RFC7231, June 2014. 1772 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 1773 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 1774 2015. 1776 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 1777 RFC 7516, DOI 10.17487/RFC7516, May 2015. 1779 9.2. URIs 1781 [1] http://mathmesh.com/Documents/draft-hallambaker-mesh- 1782 architecture.html 1784 [2] http://mathmesh.com/Documents/draft-hallambaker-mesh- 1785 architecture.html 1787 [3] http://mathmesh.com/Documents/draft-hallambaker-mesh- 1788 architecture.html 1790 [4] http://mathmesh.com/Documents/draft-hallambaker-mesh- 1791 architecture.html 1793 [5] http://mathmesh.com/Documents/draft-hallambaker-mesh- 1794 architecture.html 1796 [6] http://mathmesh.com/Documents/draft-hallambaker-mesh- 1797 architecture.html 1799 [7] http://mathmesh.com/Documents/draft-hallambaker-mesh- 1800 architecture.html 1802 [8] http://mathmesh.com/Documents/draft-hallambaker-mesh- 1803 architecture.html 1805 [9] http://mathmesh.com/Documents/draft-hallambaker-mesh- 1806 architecture.html 1808 [10] http://mathmesh.com/Documents/draft-hallambaker-mesh- 1809 architecture.html 1811 [11] http://mathmesh.com/Documents/draft-hallambaker-mesh- 1812 architecture.html 1814 [12] http://mathmesh.com/Documents/draft-hallambaker-mesh- 1815 architecture.html 1817 [13] http://mathmesh.com/Documents/draft-hallambaker-mesh- 1818 architecture.html 1820 [14] http://mathmesh.com/Documents/draft-hallambaker-mesh- 1821 architecture.html 1823 [15] http://mathmesh.com/Documents/draft-hallambaker-mesh- 1824 architecture.html 1826 [16] http://mathmesh.com/Documents/draft-hallambaker-mesh- 1827 architecture.html 1829 [17] http://mathmesh.com/Documents/draft-hallambaker-mesh- 1830 architecture.html 1832 [18] http://mathmesh.com/Documents/draft-hallambaker-mesh- 1833 architecture.html 1835 [19] http://mathmesh.com/Documents/draft-hallambaker-mesh- 1836 architecture.html 1838 Author's Address 1840 Phillip Hallam-Baker 1842 Email: phill@hallambaker.com