idnits 2.17.1 draft-hallambaker-mesh-architecture-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 31, 2018) is 2066 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 1371 -- Looks like a reference, but probably isn't: '2' on line 1374 -- Looks like a reference, but probably isn't: '3' on line 1377 == Missing Reference: 'TBS' is mentioned on line 405, but not defined -- Looks like a reference, but probably isn't: '4' on line 1380 -- Looks like a reference, but probably isn't: '5' on line 1383 -- Looks like a reference, but probably isn't: '6' on line 1386 -- Looks like a reference, but probably isn't: '7' on line 1389 -- Looks like a reference, but probably isn't: '8' on line 1392 -- Looks like a reference, but probably isn't: '9' on line 1395 ** 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) -- Obsolete informational reference (is this intentional?): RFC 5751 (Obsoleted by RFC 8551) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 11 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 Comodo Group Inc. 4 Intended status: Informational August 31, 2018 5 Expires: March 4, 2019 7 Mathematical Mesh Part I: Architecture Guide 8 draft-hallambaker-mesh-architecture-06 10 Abstract 12 The Mathematical Mesh ?The Mesh? is an end-to-end secure 13 infrastructure that facilitates the exchange of configuration and 14 credential data between multiple user devices. The architecture of 15 the Mesh and examples of typical applications are described. 17 This document is also available online at 18 http://mathmesh.com/Documents/draft-hallambaker-mesh- 19 architecture.html [1] . 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on March 4, 2019. 38 Copyright Notice 40 Copyright (c) 2018 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Mesh Profiles . . . . . . . . . . . . . . . . . . . . . . 4 57 1.2. Mesh Services . . . . . . . . . . . . . . . . . . . . . . 4 58 1.3. Document Roadmap . . . . . . . . . . . . . . . . . . . . 5 59 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 2.1. Related Specifications . . . . . . . . . . . . . . . . . 6 61 2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 6 62 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 6 63 2.4. Implementation Status . . . . . . . . . . . . . . . . . . 7 64 3. Mesh Services . . . . . . . . . . . . . . . . . . . . . . . . 7 65 3.1. Portal Service . . . . . . . . . . . . . . . . . . . . . 8 66 3.2. Catalog Services . . . . . . . . . . . . . . . . . . . . 9 67 3.2.1. Persistence Model . . . . . . . . . . . . . . . . . . 9 68 3.2.2. Retrieval Model . . . . . . . . . . . . . . . . . . . 10 69 3.3. Messaging Services . . . . . . . . . . . . . . . . . . . 10 70 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 11 71 4.1. Use Case . . . . . . . . . . . . . . . . . . . . . . . . 14 72 4.2. What Makes PKI Hard . . . . . . . . . . . . . . . . . . . 14 73 4.3. The Devil is in the Deployment . . . . . . . . . . . . . 15 74 4.4. Why change is possible . . . . . . . . . . . . . . . . . 16 75 5. Architectural Principles . . . . . . . . . . . . . . . . . . 17 76 5.1. User Centered Design . . . . . . . . . . . . . . . . . . 17 77 5.2. User Centered Trust. . . . . . . . . . . . . . . . . . . 17 78 5.3. A Credential Designed for Persistence . . . . . . . . . . 19 79 5.4. Eliminate unnecessary options . . . . . . . . . . . . . . 19 80 5.5. Strong Public Key Identifiers . . . . . . . . . . . . . . 19 81 6. Mesh Profiles . . . . . . . . . . . . . . . . . . . . . . . . 20 82 6.1. Master and Personal Profiles . . . . . . . . . . . . . . 21 83 6.2. Device Profiles . . . . . . . . . . . . . . . . . . . . . 22 84 6.3. Application Profiles . . . . . . . . . . . . . . . . . . 23 85 6.4. Verifying Profiles . . . . . . . . . . . . . . . . . . . 23 86 6.5. Key Escrow and Recovery . . . . . . . . . . . . . . . . . 24 87 6.5.1. Offline Escrow . . . . . . . . . . . . . . . . . . . 25 88 6.5.2. Online Escrow . . . . . . . . . . . . . . . . . . . . 25 89 7. The CryptoMesh . . . . . . . . . . . . . . . . . . . . . . . 26 90 7.1. Federated Portals . . . . . . . . . . . . . . . . . . . . 26 91 8. Security Considerations . . . . . . . . . . . . . . . . . . . 27 92 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 93 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 94 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 95 11.1. Normative References . . . . . . . . . . . . . . . . . . 27 96 11.2. Informative References . . . . . . . . . . . . . . . . . 29 97 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 30 98 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30 100 1. Introduction 102 The Mathematical Mesh is a user centered Public Key Infrastructure 103 that uses cryptography to make computers easier to use. One of the 104 chief difficulties users face when using network applications is that 105 they need to be configured before use. Configuration of applications 106 that use cryptography to provide security controls it often 107 particularly difficult as they require the user to manage 108 cryptographic keys. The challenge of configuring devices increases 109 exponentially as the number of devices the user is required to manage 110 increases. Users no longer read their email on a single desktop 111 computer, they have laptops, tablets, phones and even watches. 113 For over 25 years, implementations of S/MIME and OpenPGP have made 114 demands of the user that are clearly preposterous. 116 S/MIME users are expected to apply to a Certification Authority for a 117 certificate, to authenticate themselves and then install the 118 certificate in their email client. If they have multiple devices, 119 they are expected to export the private key from one device and 120 install it in another. In some cases, the mechanism for installing 121 the private key is not even documented. And the user is required to 122 repeat this travesty on an annual basis despite the fact that 99% of 123 the people they exchange email would never consider engaging in such 124 a degrading experience. 126 OpenPGP attempts to convince users that Third Party Trust providers 127 are unnecessary by making every user a Third Party Trust provider. A 128 role for which the user is provided with neither instruction nor 129 tools to support the effort. 131 The Mesh uses cryptography and an untrusted cloud service to make 132 management of computer configuration data transparent to the end 133 user. Each Mesh user has a personal profile that is unique to them. 134 A user may link devices and applications to their Mesh profile to 135 enable transparent sharing of data between them. 137 The user of the Mesh need never give a seconds thought to the 138 management of their cryptographic keys for one singular reason: Any 139 set of instructions that can be given to a user to perform can be 140 turned into program code and performed by the machines. 142 For example, Alice has a laptop computer and a tablet. They are both 143 linked to her Mesh profile which allows either to be used for email 144 or to control any devices in her smart home. Alice has chosen to 145 only make her cloud documents available on her laptop but she could 146 change that to add her tablet should the need arise (Figure XX). 148 [[This figure is not viewable in this format. The figure is 149 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 150 architecture.html [2].]] 152 Alice's Mesh profile connections. 154 Computer security professionals have been telling users to take 155 security seriously for 25 years. It is now time to realize that 156 security is our responsibility, not theirs. We have failed to 157 deliver secure applications most users can use. 159 1.1. Mesh Profiles 161 All the configuration data that a user needs to configure and use a 162 device, an application or a network service is stored in a Mesh 163 Profile. All Mesh profiles are authenticated using digital 164 signatures and all private material protected using industry standard 165 end-to-end encryption. 167 Devices connected to a profile are provisioned with all the network 168 configuration settings and credentials required for the device to be 169 used with the user's applications and services. In most cases, 170 public key credentials will be provisioned to enable transport layer 171 and end-to-end encryption. 173 1.2. Mesh Services 175 Mesh service provide a means of exchanging profiles when connecting 176 new devices to an existing profile. To connect a new device to her 177 profile using the basic connection mechanism, Alice begins the 178 process by giving her Mesh service account address to the new device. 179 This causes a connection request to be sent to the Mesh service where 180 a device connection request is posted. Some time later, Alice 181 reviews pending connection requests on a device she has authorized 182 for this purpose, approving or rejecting them. The results of her 183 decisions are then posted back to the Mesh Service on which they 184 originated so that the devices can complete (or abort) the connection 185 process. 187 A Mesh user's profile may be active on multiple Mesh services at the 188 same time. A user might have separate Mesh service accounts for work 189 and personal use for example. 191 The connection of a device to a profile is represented by 192 cryptographic keys stored on the connected devices, this ensures that 193 the user remains in full and sole control of their personal profile. 194 The only control a Mesh service can exert is to deny a user the use 195 of that particular service. A user always has the option of 196 connecting their profile to an account at a different service. 198 It is envisaged that Mesh services might be members of a federation 199 exchanging profile updates, thus providing users with a guarantee of 200 continued service should the original service they selected become 201 unavailable. The Merkle Tree integrity mechanisms supported by the 202 DARE Container format allow for distributed integrity proofs to be 203 maintained for such a federation in a manner similar to BlockChain 204 [BLOCKCHAIN] . 206 1.3. Document Roadmap 208 The specifications describing the Mesh protocols are divided into 209 three main groups. First set of documents describe the architecture, 210 data structures and protocols that make up the Mesh core. The second 211 set describes the use of the Mesh to secure existing and experimental 212 documents. The third set of documents describe building blocks that 213 were developed to meet requirements arising from the Mesh but are not 214 specific to the Mesh and could be applied to the development of other 215 Web Services that do not involve the Mesh. 217 Mesh Core This document provides a high level description of the 218 Mesh architecture and mode of use. Detailed specifications 219 including schemas and examples are specified in the accompanying 220 Mesh Reference document [draft-hallambaker-mesh-reference] . 222 Mesh Services The Mesh Service protocol. 224 Mesh Platform Specifications that the Mesh builds on that are not 225 specific to the Mesh. These include JSON Web Service Binding 226 [draft-hallambaker-json-web-service] , Uniform Data Fingerprint 227 [draft-hallambaker-udf] , Strong Internet Names 228 [draft-hallambaker-sin] , JSON-BCD 229 [draft-hallambaker-dare-message] , DARE Message 230 [draft-hallambaker-json-web-service] and DARE Container 231 [draft-hallambaker-dare-container] . 233 In addition, two additional documents describe the use of the 234 reference code base [draft-hallambaker-mesh-developer] and 235 recommendations for implementing Mesh enabled applications to take 236 advantage of the cryptographic facilities offered by specific 237 operating system platforms [draft-hallambaker-mesh-platform] . 239 2. Definitions 241 This section presents the related specifications and standards on 242 which the Mesh is built, the terms that are used as terms of art 243 within the Mesh protocols and applications and the terms used as 244 requirements language. 246 2.1. Related Specifications 248 Besides the documents that form the Mesh core, the Mesh makes use of 249 many existing Internet standards, including: 251 Cryptographic Algorithms Mesh applications use the cryptographic 252 algorithm suites specified by the application. The cryptographic 253 algorithms used in the Mesh itself are limited to SHA-2 [SHA-2] 254 and SHA-3 [SHA-3] digest functions, AES Encryption [FIPS197] and 255 RSA Signature, and Encryption [RFC8017] . 257 The use of the Ed25519 and Ed448 algorithms is currently being 258 explored for use with both signature [RFC8032] and encryption. 259 The Edwards Curve is preferred over the Montgomery for Encryption 260 as it affords a more straightforward implementation of techniques 261 such as co-generation of public key pairs and proxy re-encryption. 263 Transport All Mesh Services make use of multiple layers of security. 264 Protection against traffic analysis and metadata attacks are 265 provided by use of Transport Layer Security [RFC5246] . At 266 present, the HTTP/1.1 [RFC7231] protocol is used to provide 267 framing of transaction messages. 269 Encoding All Mesh protocols and data structures are expressed in the 270 JSON data model and all Mesh applications accept data in standard 271 JSON encoding [RFC7159] . The JOSE Signature [RFC7515] and 272 Encryption [RFC7516] standards are used as the basis for object 273 signing and encryption. 275 2.2. Defined Terms 277 TBS 279 2.3. Requirements Language 281 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 282 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 283 document are to be interpreted as described in RFC 2119 [RFC2119] . 285 2.4. Implementation Status 287 The implementation status of the reference code base is described in 288 the companion document [draft-hallambaker-mesh-developer] . 290 3. Mesh Services 292 The Mesh supports multiple mechanisms for connecting devices to an 293 account: 295 o Over a trusted physical link (i.e. a cable). 297 o Optical exchange (e.g. a QR code). 299 o Connection broker service. 301 Each of these mechanisms provides for strong mutual authentication of 302 the device profile to the personal profile it is being connected to 303 and vice versa. In each case, the connection request MUST be 304 authorized by the profile owner from a device that has already been 305 connected to the profile and granted administration privileges. 307 While the first two mechanisms provide a satisfactory means of 308 establishing an initial connection to a Mesh profile, they are only 309 possible when the devices being connected have the necessary 310 affordances and they are impractical as a means of maintaining 311 profiles. Except in unusual circumstances such as offline management 312 of private keys in an air-gapped environment, the process of 313 establishing and managing Mesh profiles is mediated by a Mesh 314 service. 316 The Mesh Service protocol is divided into three parts as follows: 318 Portal The Portal services support creation of a Mesh Service 319 account and management of the owner's Mesh profile. 321 Catalog The Catalog services support communication of application 322 data between the devices an owner has connected to their profile. 323 These include configuration profiles for legacy applications such 324 as SMTP mail and SSH, lists of contacts, tasks and calendar 325 entries, and credential storage. 327 Messaging The messaging services are Mesh services that accept 328 requests that come from third parties. These include the contact 329 request service, the confirmation service and the message service. 331 The Portal, Catalog and Messaging services are built on a common 332 platform that reduces the involvement of the service to the bare 333 minimum. All data that is not required to support the service is 334 encrypted. One important (and useful) consequence of this approach 335 is that from the point of view of the Mesh service, the set of 336 Catalog and Messaging services supported are a single interface to a 337 set of data stores distinguished only by the service name. 339 Since messaging requests may impose a cost on the owner ranging from 340 wasting their time to providing a means of attack, messaging services 341 SHOULD be either highly constrained to mitigate such attacks or 342 require requests be subjected to access control. The authentication 343 and authorization statements used to enforce this access control is 344 stored in the owner's contact catalog. A owner's contact catalog is 345 thus the mediator of messaging requests. 347 3.1. Portal Service 349 The portal service supports 351 o Management of Mesh service accounts (account creation, deletion) 353 o Connection of new devices to a profile 355 o Publishing profile updates to devices 357 o Storage of key recovery information 359 The first step in creating a Mesh service account is to create a Mesh 360 personal profile if the user doesn't own one already. A user MAY use 361 the same profile to register multiple accounts at the same Mesh 362 service and at multiple services. 364 Having established a profile on their first device, a user will 365 typically connect more devices. Figure XX shows Alice connecting a 366 new desktop computer to her profile, the connection request is 367 initiated from the new device (desktop) and approved from the 368 administration device (tablet). 370 [[This figure is not viewable in this format. The figure is 371 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 372 architecture.html [3].]] 374 Alice connects a new device. 376 Implementing a pure peer-to-peer protocol in which the desktop and 377 tablet communicate directly would require both machines to be turned 378 on at the same time and able to communicate. Experience has shown 379 that this process is considerably more reliable when mediated by some 380 form of broker. 382 3.2. Catalog Services 384 Catalog services track data that is created by the user for their own 385 use. Catalog services include: 387 Contact Catalog Contains user's contacts. The contact catalog has a 388 special purpose in a Mesh Service as it MAY be required as a 389 source of authorization and authentication information for 390 performing access control on requests to messaging services. 392 Credential Catalog Contains username/password data for accessing 393 other services. 395 Application Configuration Catalog D 397 A Mesh Service is not required to support any particular service. 398 However a Mesh service that supports Messaging services MUST support 399 the catalog service so that requests from third parties can be 400 subjected to access control. 402 3.2.1. Persistence Model 404 Each service maintains a catalog that represents the state of a set 405 of objects according to the DARE Persistence Model [TBS]. In that 406 model an object is defined as follows: 408 o An object has an identifier that is unique (within the context of 409 the container) and immutable. 411 o An object has a state that is either undefined, active(value) or 412 inactive. Where value is the value associated with the object in 413 the active state. An object only has a defined value in the 414 active state. 416 o The state of an object is affected by the events create, update 417 and delete. 419 o The event create(x) is only valid in the undefined state and 420 causes the state of the object to become active(x). 422 o The event update(y) is valid in any state and causes the state of 423 the object to become active(y). 425 o The event delete is only valid in the state active() and causes 426 the state of the object to become inactive. 428 o The value of the object over time may thus be represented as a 429 trace of the state values in the CSP or similar models. 431 A catalog service will accept any request to update the catalog that 432 is properly authenticated, that is: 434 o The service request is properly authenticated for that purpose by 435 the profile associated with the account. 437 o The updated value is signed by a signature key authorized for that 438 purpose by the profile associated with the account. 440 A request MUST meet both criteria to be accepted. The first ensures 441 that the update requests are current at the time they are accepted. 442 The second ensures that the update requests can be authenticated by 443 the devices connected to the profile. 445 3.2.2. Retrieval Model 447 The value associated with an object consists of a body and a set of 448 associated attributes some of which may be identified as serving as 449 retrieval keys. 451 Examples of retrieval keys include 453 o Application identifier 455 o Contact email address 457 o Date and time 459 o Geographic location 461 3.3. Messaging Services 463 Messaging services are functionally identical to catalog services 464 except while a request to create or update an object to a catalog 465 entry can only come from the profile owner, requests received by an 466 messaging service MAY come from an external party and MUST therefore 467 be subjected to access control to prevent various forms of abuse. 469 Examples of messaging services include: 471 o Contact request service 473 o Task service (including calendar appointments) 475 o Confirmation service 476 o Message service 478 4. Requirements 480 Before the Web, most trade was performed in person. Mail order 481 existed but was limited in scope. Most banking transactions other 482 than withdrawing cash from an ATM had to be performed in-line at a 483 branch rather than online through the Web. Trade in stocks and shares 484 barely existed in its modern form. The TLS protocol and the WebPKI 485 that supported it enabled the e-commerce economy that we live in 486 today. 488 The WebPKI is a powerful infrastructure but it does have one major 489 drawback: It Authenticates the bank to the customer but it does not 490 authenticate the customer to the bank. The use of passwords instead 491 of strong cryptographic credentials makes users vulnerable to 492 phishing. 494 Design of a public key authentication protocol is straightforward. 495 Making the use of such a protocol practical is a much greater 496 challenge because it requires the user to manage a private key. 497 Users cannot perform even the simplest public key cryptography 498 algorithm in their head and so some sort of device must perform the 499 calculations and this in turn must be provisioned with the private 500 key. 502 Management of the server private keys for the WebPKI is challenging 503 enough and they tend to stay in one place (at least until recently). 504 Managing private keys for users is much more challenging than 505 managing server keys because: 507 o Users typically own multiple devices and expect them all to work 508 in the same way. 510 o User devices are considerably more complex than servers. They 511 have many functions. 513 o Users are more likely to lose devices or lend them to other 514 people. 516 o Users cannot be expected to be experts. 518 What has made matters worse is the notion that because users are less 519 sophisticated than system administrators, they cannot use 520 sophisticated technology. In practice, the exact opposite is the 521 case. To make the user experience completely frictionless, we must 522 embrace technologies that are more sophisticated, not avoid them. 523 Systems administrators are usually willing to accept technology that 524 is less than perfect and shows many 'rough edges' because they are 525 experts and using those tools is their job. Users are much less 526 tolerant of technology that meets their needs. 528 Modern cryptography provides us with the tools to secure practically 529 any form of Internet interaction. In almost every case, the main 530 constraint that holds us back is the impracticality of using client- 531 side private keys: 533 o OpenPGP [RFC4880] 535 o S/MIME [RFC5751] 537 o Jabber [RFC6120] 539 o IPSEC [RFC4301] 541 o SSH [RFC4251] 543 The SSH protocol supports the use of public key cryptography for 544 authentication, of course. But this is the exception that proves the 545 rule. The use of client side keys in SSH is highly effective for the 546 developer or the systems administrator who only makes use of one 547 machine as their client. Attempting to manage SSH credentials across 548 multiple client and server machines under strict operational controls 549 is not for the fait hearted. Not only is it not uncommon for users 550 to use a single private key for SSH on all the machines they use, 551 there are Web sites that 'explain' how to do this by emailing their 552 private key to themselves over SMTP. 554 From the user's perspective, a security protocol 'works' when it lets 555 them do their job in peace. The VPN access token works when they 556 gain access to the corporate network, SSH works when they gain access 557 to the server, passwords work when they can log into their bank Web 558 site and pay their bills. But when evaluating a security protocol, 559 it is equally important that the attacker is defeated and that no new 560 failure modes are introduced. The acronym C.I.A. provides a useful 561 mnemonic: 563 Confidentiality Protect data from disclosure to unauthorized 564 parties. Prevent unauthorized parties inferring confidential 565 information from traffic analysis. 567 Integrity Protect data from unauthorized modification. Establish 568 and verify data authenticity. 570 Availability Ensure that data and data services are available when 571 needed. Restrict access to authorized parties. Establish 572 accountability. 574 While Confidentiality is usually the paramount concern of users, 575 Integrity attacks almost invariably inflict more serious damage and 576 Availability attacks include some that inflict the greatest damage of 577 all. The typical consumer gets irritated if their bank carelessly 578 reveals details of their account but is considerably angrier if it 579 has been depleted by fraud. But as the recent spate of ransomware 580 attacks prove, while the consumer becomes angry when they are a 581 victim of fraud, many will actually pay money to the criminals if the 582 alternative is to lose the pictures of their grandchildren when they 583 were five. 585 Best practices for managing cryptographic keys present multiple 586 operational challenges: 588 Separation of Cryptographic Purpose Each private key SHOULD be used 589 for exactly one cryptographic function. Keys used for encryption 590 SHOULD NOT be used for authentication. Keys used to secure one 591 application SHOULD NOT be used to secure another. 593 Key Compromise Revocation of compromised keys MUST be supported. 595 Key Rotation It SHOULD be possible to periodically refresh keys used 596 to secure applications, thus ensuring that any compromise of the 597 keying material is time bounded. 599 Device Isolation Each device SHOULD have separate keys to protect 600 applications on that device. This limits the consequences should 601 the device be compromised, lost or stolen and permits revocation 602 to be limited to the keys used in that device. 604 Key Escrow Whenever a key is used to encrypt static data (i.e. data 605 stored on a disk or other storage device), provision MUST be made 606 to permit (but not require) the decryption key to be escrowed to 607 permit recovery should the need arise. 609 Provision of Key Escrow is controversial since any mechanism that 610 enables the user to recover a cryptographic key voluntarily enables 611 the user to disclose the key in case of coercion. But this state of 612 affairs, while unsatisfactory, is a lot more satisfactory than the 613 current state of affairs which is to rarely encrypt static data at 614 all. 616 4.1. Use Case 618 Alice works with Bob, Carol, and Doug. As part of her work she 619 exchanges email messages with them which may contain confidential 620 information. She also connects to the machines Server1, Server2 and 621 Server3 to perform system administration tasks. She has a personal 622 desktop, a laptop, and a tablet computer. She requires: 624 o The ability to send and receive S/MIME end-to-end encrypted email 625 with Bob and Carol as per corporate policy. 627 o The ability to send and receive OpenPGP end-to-end encrypted email 628 with Doug who does not use S/MIME. 630 o The ability to connect to Server1, Server2 and Server3 from any of 631 her personal devices. 633 o The ability to quickly configure a new device for her personal 634 use. 636 o The ability to quickly disable further use of a device should it 637 be stolen. 639 This use case is deliberately limited to configuring Alice's devices 640 to enable her to use current security protocols. A large number of 641 use cases and applications were considered during the design 642 including configuring IoT devices in Alice's home and configuring a 643 borrowed or rented device. It was discovered that considering the 644 end-to-end email case was sufficient because the requirements it 645 exposes are a superset of the requirements of the others. 647 The only use case that introduced requirements beyond Alice 648 configuring end-to-end email and SSH for herself was configuring end- 649 to-end email and other secure applications for a remote co-worker. 650 Meeting these requirements is deferred as a future work item. 652 4.2. What Makes PKI Hard 654 Every day, billions of people access Web sites using PKI encryption 655 without even being aware that they are doing so. A smaller but still 656 large number of people use PKI for secure payments, the only 657 difference they are aware of being that they insert their card rather 658 than swiping it through the reader. 660 Many of the issues that have made PKI hard in the past are due to 661 design choices taken by technologists rather than an intrinsic 662 restriction of PKI. In particular: 664 o Expiry of private keys and credentials. 666 o Poorly designed enrollment protocols. 668 o No provision for use of multiple devices. 670 o Inappropriate trust models. 672 o Intrusive user experience. 674 S/MIME and other client centered security technologies were added to 675 many Internet applications in the 1990s in response to enterprise 676 requirements. The people who make the purchasing decisions for 677 enterprise software and those who use it on a daily basis are often 678 if not invariably different, the enterprise software market has 679 prioritized functionality over usability. An email client that 680 requires the user to remember to click on the right button to encrypt 681 an email is considered acceptable in the enterprise space, it is not 682 acceptable in the consumer space. 684 While working on this project, the author attempted to configure a 685 very popular email client to make use of the built in S/MIME 686 capabilities. Even with 25 years of experience, this took over half 687 an hour and required the user to follow a procedure with 17 different 688 steps involving three different applications. Even though the 689 certificate was being issued for use with email, the user had to use 690 a Web browser to enroll for the certificate, validate the request 691 using the email client, download the certificate using the Web 692 browser and then install it using a key management tool. 694 The bar for security usability is much higher than most security 695 specialists, even those who focus on security admit. Experience 696 should teach us that the iron law of security usability is that a 697 security application that requires the user to think about security 698 will fail. 700 It is noted in passing that security usability is not achieved by 701 preventing the user seeing the information they need to make their 702 own security decisions. 704 4.3. The Devil is in the Deployment 706 One of the most important reasons for the failure of PKI applications 707 has been the failure of PKI applications. As with any communication 708 tool, the value of end-to-end secure email is a function of the size 709 of the network that can be reached. The community of S/MIME users 710 and the community of OpenPGP users have both stalled in the low 711 millions, a significant number but falling far short of ubiquity. 713 End to end secure email can only realize its full potential when its 714 use is the norm and not the vanishingly rare exception. 716 After a time, failure becomes a self-reinforcing vicious circle. 717 Very few people use end-to-end secure email applications because they 718 are difficult to use. Application providers refuse to invest in 719 developing end-to-end secure email applications because 'there is no 720 demand'. 722 The Mesh is designed for deployment by providing a stand-alone value 723 proposition to early adopters. The ability to automate the use of 724 end-to-end secure email is not a highly attractive proposition for 725 most when less than 0.1% of the Internet user population have ever 726 registered an S/MIME or OpenPGP key. But an end-to-end secure 727 password manager for Web browsers, or an SSH credential management 728 tool do provide a stand-alone value proposition. 730 4.4. Why change is possible 732 All four of the open standards based PKIs that have been developed in 733 the IETF are based on designs that emerged in the mid-1990s. 734 Performing the computations necessary for public key cryptography 735 without noticeable impact on the speed of user interaction was a 736 constraint for even the fastest machines of the day. Consequently, 737 PKI designs attempted to limit the number of cryptographic operations 738 required to the bare minimum necessary. There were long debates over 739 the question of whether certificate chains of more than 3 740 certificates were acceptable. 742 Today a 32-bit computer with two processing cores running at 1.2GHz 743 can be bought for $5 and public key algorithms are available that 744 provide a higher level of security than was achievable in the 1990s 745 for less computation time. In 1995, the idea that a single user 746 might need a hundred public key pairs and a personal PKI to manage 747 them as an extreme scenario. Today when the typical user has a 748 phone, a tablet and a laptop and their home is about to fill up 749 dozens if not hundreds of network connected devices, the need to 750 manage large numbers of keys for individual users is clear. 752 Use of public key cryptography on the scale used in the Mesh would 753 have been impractical even for financial applications as recently as 754 15 years ago. Today, the performance and memory overhead is 755 negligible. 757 5. Architectural Principles 759 Over the course of the first quarter century of commercial use of 760 PKI, a consensus has emerged as to the principles of robust protocol 761 design; All aspects of the design should be public, all cryptographic 762 algorithms should be open standards that have been widely reviewed by 763 domain experts, etc. 765 The Mathematical Mesh is appropriately aligned with this established 766 consensus but departs from existing practice in certain areas as set 767 out in the following. 769 5.1. User Centered Design 771 Traditional enterprise centered PKI keeps the enterprise (and to an 772 extent the users) secure but only as long as the users follow a long 773 list of often complex instructions. Even the US National Security 774 Agency, an institution whose core competence is cryptography and 775 whose principle purpose is to protect US government information 776 failed to protect some of its greatest secrets because it was just 777 too hard to use the right cryptography. 779 A key principle that guides the design of the Mesh is that any set of 780 instructions that can be written down and given to a user can be 781 written down as code and executed by the computer. Public key 782 cryptography is used to automate the process of managing public keys. 783 Instead of telling the user how to register for a certificate and 784 install it in their mail client, we tell the computer how to do the 785 task for them. 787 5.2. User Centered Trust. 789 One of the principal ideological battles that has been fought in the 790 development of end-to-end email security has been the manner in which 791 trust is provided. In the S/MIME protocol, trust is established 792 through a hierarchy of trust providers. In the OpenPGP protocol, 793 trust is in theory established through a 'Web of Trust' but is in 794 practice almost invariably established through either a direct trust 795 model (exchange of key fingerprints) or on a trust after first use 796 basis. 798 Perhaps, what we should be willing to learn from the experience of 799 attempting to apply these models to real world applications is that 800 none is sufficient by itself. Rather than attempting to impose a 801 single model of trust on every circumstance, multiple trust models 802 should be supported. 804 The trust model appropriate for validating a key depends on the 805 context in which it is to be used. If Alice is sending Bob a 806 personal email, it is likely that the best key to use will be the one 807 that matches the key fingerprint from the business card he gave her 808 when they met in person. But when Alice is sending Bob an email as 809 her stockbroker, the best key is going to be the one that is issued 810 to Bob as an employee of the brokerage company. 812 Any trust model must be built around the needs of the user. The Mesh 813 does not impose a model for mapping human to machine interaction 814 identifiers but it does allow the user to put that mapping under 815 their personal control. Devices connected to a Mesh Personal Profile 816 share the same view of the world; the same set of bookmarks and 817 contacts for defining personal names and the same set of trust roots 818 for Certification Authorities trusted to provide brokered trust. 820 In the traditional model, PKI is used to validate network hosts after 821 discovery. The credential issued by the CA is verified each time the 822 user visits the site. 824 [[This figure is not viewable in this format. The figure is 825 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 826 architecture.html [4].]] 828 Traditional PKI role. 830 In the Mesh trust model, the primary role of the CA is to provide 831 introductions. When the user first visits the site, to buy goods, 832 the site (and often the vendor it belongs to) is unknown. At this 833 point, the user is looking to the Authority to help decide if they 834 wish to purchase from. 836 [[This figure is not viewable in this format. The figure is 837 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 838 architecture.html [5].]] 840 Trusted Authority as Introducer 842 Once users can easily maintain a personal directory of trusted 843 vendors and share it across all the devices they use, their personal 844 trust directory becomes their primary trust provider. Thus, the role 845 of the authority changes once a trust relationship has been 846 established from trust provider to trust revoker. The user does not 847 need the authority to tell them to trust a vendor they are already 848 doing business with but they may need the authority to warn them if 849 the vendor has defaulted on purchases made by other customers or has 850 suffered a major breach, etc. 852 5.3. A Credential Designed for Persistence 854 One of the main difficulties in using S/MIME for email security is 855 that many users stop using the system when their certificate expires. 856 It is likely that one of the main reasons that OpenPGP is more 857 popular amongst system administrators is that a maintenance-free user 858 experience is available to anyone who decides to neglect key 859 rollover. 861 A Mesh Master Profile fingerprint is designed to provide a user with 862 a credential that can be used for a lifetime. Using the same 863 offline/online key management approaches that have been applied to 864 root key management in the WebPKI since it began provides users with 865 a credential with a cryptographic lifetime of 20-30 years. The 866 addition of linked notary log technology in the Mesh Portals allows 867 such credentials to be securely renewed should the need arise and 868 thus enabling indefinite use. 870 5.4. Eliminate unnecessary options 872 Traditionally cryptographic applications give the user a bewildering 873 choice of algorithms and options. They can choose to have one RSA 874 keypair used for encryption and signature or they can have separate 875 keys for both, they can encrypt their messages using 3DES or AES at 876 128, 192 or 256 bit security. And so on. 878 The Mesh eliminates such choices as unnecessary. Except where 879 required by an application, the Mesh always uses separate keys for 880 encryption and signature operations and only uses the highest 881 strength on offer. Currently, Mesh profiles are always encrypted 882 using RSAES-PKCS1-v1_5 with a 2048 bit key [RFC8017] , AES with a 256 883 bit key [FIPS197] and SHA-2-512 [SHA-2] . The use of RSA 2048 will be 884 replaced with Ed448 [RFC8032] when sufficiently mature 885 implementations become available. 887 For similar reasons, every Mesh master profile has an escrow key. 888 The use of key escrow by applications is optional, but every profile 889 has the capability of using it should circumstances require. 891 5.5. Strong Public Key Identifiers 893 A key departure from traditional PKI approaches is that all 894 cryptographic keys are identified in every circumstance by either the 895 UDF fingerprint of the public key in the case of a public key pair or 896 the UDF fingerprint of the symmetric key in the case of a symmetric 897 key pair. No other form of key identifier is used. 899 This approach greatly simplifies the processes of key discovery, 900 management and signature verification. 902 Since a UDF fingerprint of sufficient length, uniquely identifies a 903 public key pair, it follows that if the attempt to verify the 904 signature under a public key whose fingerprint matches that specified 905 returns the result false, that the signature is invalid. Contrawise, 906 if the result returned is true, the data is validly signed for a 907 given purpose if and only if the key identifier is authorized for 908 that purpose. 910 6. Mesh Profiles 912 All information exchanged through the Mesh is described in a profile. 913 Profiles have the following properties. 915 o Profiles are first class objects with a unique, immutable 916 identifier that either is or contains a UDF fingerprint of a 917 signature key 919 o All profiles are digitally signed. 921 o Profiles are encoded in JSON [RFC7159] . 923 At present, four types of Mesh Profile are defined: 925 Master Profile Describes the criteria for validating a user's 926 personal profile. 928 Personal Profile Describes the user's personal Trust Mesh, the set 929 of device and application profiles connected to it. 931 Application Profile Describes the use of a particular application. 933 Device Profile Describes a device and cryptographic keys specific to 934 that device. 936 A profile is Valid if and only if it is Verified, Current and 937 Correct: 939 Verified A signature is verified if the key identifier specified 940 maps to a 942 Current A profile is current if and only if it has not been 943 superseded by a new profile published to the Mesh Portal. 945 Correct A profile is correct if the signing key identifier specified 946 in the signature data is a legitimate signing key for that type of 947 profile as specified in Section YY below. 949 A profile is connected to a personal profile if and only if: 951 o The Personal Profile contains an entry for its profile identifier 952 that is consistent with the profile type. 954 o The Personal Profile is Valid. 956 o The Application Profile is Valid. 958 This trust model allows Application Profiles and Device Profiles to 959 be connected to a Personal Profile by enumerating the identifiers of 960 the connected profile in the personal profile. 962 [[This figure is not viewable in this format. The figure is 963 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 964 architecture.html [6].]] 966 A Master/Personal Profile connected to Application and Device 967 profiles. 969 6.1. Master and Personal Profiles 971 Each Mesh user has a Master Profile and a Personal Profile. 973 Personal Profile Contains a list of all the device profiles and 974 application profiles that are currently connected to the user's 975 personal Mesh. The personal profile is signed by an 976 administrative key. 978 Master Profile Contains a list of administrative keys used to sign 979 personal profiles and the master signature key used to sign the 980 Master Profile. 982 The use of master signature keys and administration keys to 983 authenticate the Master and Personal profiles needs further 984 explanation. 986 [[This figure is not viewable in this format. The figure is 987 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 988 architecture.html [7].]] 990 Master and Personal Profile Signature 991 This separation allows the user to add devices and/or change 992 application settings frequently without the need for changes to their 993 master profile or to access their master signature key. This allows 994 the master signature key to be stored in a safe place, preferably 995 using a Hardware Security Module or other precautions without the 996 inconvenience this would entail if regular use of the key was 997 required. 999 A typical user might modify their personal profile hundreds of times 1000 over their lifetime, conceivably even more in a world where homes are 1001 filled with hundreds of IoT devices. Adding or removing 1002 administrative devices is likely to occur much less frequently. The 1003 master signature key used to authenticate the Master Profile never 1004 changes. If it becomes necessary to replace the master signature 1005 key, it will be necessary to create a new Master profile and perform 1006 a secure transition to the new key. 1008 Since the master signature key does not change by definition, the 1009 fingerprint of the master signature key is a persistent identifier 1010 that will remain constant and only ever refer to exactly one Master 1011 Profile. Furthermore, since at any given time a Master Profile has 1012 exactly one Personal Profile attached to it (and vice versa), the 1013 fingerprint of the master signature key is a persistent identifier 1014 for the Personal Profile as well. 1016 6.2. Device Profiles 1018 A device profile contains a description of the device and the public 1019 keys to be used as the basis for encryption, authentication and 1020 signature on that device (Figure XXX). Ideally, the private keys 1021 associated with the device are generated using a secure procedure on 1022 the device itself and are bound to the device so that they cannot be 1023 exported from it. 1025 [[This figure is not viewable in this format. The figure is 1026 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 1027 architecture.html [8].]] 1029 Device Profile 1031 Application profiles MAY specify additional profiles to be used with 1032 a particular device for an application specific purpose. 1034 While it is usually desirable for such keys to be generated on the 1035 device itself, this is not always possible. If, for example, the 1036 application profile is connected to a personal profile with multiple 1037 existing devices. In this circumstance, the use of a co-operative 1038 key generation approach [PHB-CoKey] is preferred but not always 1039 possible. If no other options are available, additional application 1040 private keys may be provisioned to the device by encrypting them 1041 under the device private key. 1043 Device profiles are connected to a personal profile by enumerating 1044 them in the Personal Profile. 1046 6.3. Application Profiles 1048 An application profile describes the configuration of an application. 1049 An Application Profile MAY contain: 1051 Public data Information that is intended for public use that applies 1052 to all devices. For example, the user's public encryption key for 1053 end to end secure email. 1055 Private Data Information that applies to all devices that is only 1056 intended for use by connected devices. For example, the network 1057 configuration information describing how to access the messaging 1058 and outbound mail servers. 1060 Public Per Device Data Information that is intended for public use 1061 that applies to a specific device. For example, the user's public 1062 signature key might be different for each device. 1064 Private Per Device Data Information that applies to a specific 1065 device and is only for the use of that device. For example, a 1066 per-device signature key. 1068 Application Profiles are connected to a Personal Profile by an 1069 Application Device Entry. The Application Device Entry specifies the 1070 identifier of the device and the set of privileges delegated to it 1071 with respect to that application. These privileges MAY include the 1072 privilege of signing Application Profile updates. This allows a 1073 device that is not an administration device for the personal profile 1074 to be permitted to update the application profile. Thus, Alice might 1075 not want her laptop to be an administration device but would likely 1076 want to be able to add or update Web Site usernames and passwords. 1078 6.4. Verifying Profiles 1080 As described in section XXX, the key identifier in a Mesh Profile 1081 signature is the UDF fingerprint of the public key to be used for 1082 verification. Therefore, a Profile is invalid if either: 1084 Attempting to validate the profile under a public key whose UDF 1085 fingerprint matches that specified in the key identifier returns the 1086 result false. 1088 The Key Identifier specified in the signature is not explicitly 1089 authorized for the purpose as described below. 1091 The Key Identifiers authorized to sign a profile depend on the type 1092 of profile as follows: 1094 Master Profile The Key Identifier of the key that signs the profile 1095 MUST be the UDF fingerprint of the Master Signature Key specified 1096 in that Master Profile. 1098 Personal Profile The Key Identifier of the key that signs the 1099 profile MUST be listed as the identifier of an Administrator Key 1100 specified in the corresponding Master Profile. 1102 Device Profile The Key Identifier of the key that signs the profile 1103 MUST be the UDF fingerprint of the Device Signature Key specified 1104 in that Device Profile. 1106 Application Profile The Key Identifier of the key that signs the 1107 profile MUST be listed as the identifier of an Administrator key 1108 for that Application Profile in the corresponding Personal 1109 Profile. 1111 6.5. Key Escrow and Recovery 1113 Key Escrow and Recovery capabilities are built into the core of the 1114 Mesh. Use of these capabilities is RECOMMENDED but not required. 1116 Encryption of stored data such as email messages and personal 1117 photographs protects confidentiality but introduces a major 1118 availability risk: The data will be lost if the user loses access to 1119 the decryption key. While the risk of being coerced into disclosure 1120 of material is a risk for some users, availability is a concern for 1121 all users. 1123 The Mesh supports two types of key escrow, Offline and Online. 1125 Offline Key Escrow Is used to escrow Master Signature Keys, Master 1126 Escrow Keys and other private keys that are particularly important 1127 to a user and are to be preserved. 1129 Online Key Escrow Is used to protect all other keys by escrowing the 1130 key under a Master Escrow Key. 1132 6.5.1. Offline Escrow 1134 The use of Shamir Secret Sharing [ShamirXX] to escrow private keys is 1135 supported as follows: 1137 o A 256 bit random session key is generated. 1139 o The private key and related data is encrypted under the session 1140 key to form the key escrow data blob. 1142 o The unique identifier for the key escrow data blob is the UDF 1143 fingerprint of the session key. 1145 o The key escrow data blob is stored in some form of persistent 1146 storage that is believed to provide a very high degree of 1147 availability. 1149 o The session key is split into n of m shares using Shamir secret 1150 sharing. 1152 Since the purpose of the Mesh Portal is in part to provide a high 1153 availability data storage facility, the use of the Mesh to store the 1154 key recovery blob is preferred. 1156 Data recovery is the reverse of the escrow process: 1158 o The shared secret is recovered from at least n of the key shares. 1160 o The unique identifier for the key escrow data blob is calculated 1161 from the session key 1163 o The unique identifier is used to retrieve the key recovery blob. 1165 o The key recovery blob is decrypted using the session key. 1167 It will be noted that this process is anonymous. The key recovery 1168 blob does not identify the profile or user to which it refers in any 1169 way. 1171 6.5.2. Online Escrow 1173 Support for Online escrow requires only that decryption keys for 1174 application use be encrypted under the master escrow key as if it was 1175 another device connected to a Personal Profile. 1177 7. The CryptoMesh 1179 As described earlier, a Mesh Portal Service is an untrusted cloud 1180 services that facilitates the management of Mesh profiles by 1181 providing persistent storage. A personal profile MAY be registered 1182 to one, many or no Mesh Portal Services at a time. 1184 For the sake of convenience and familiarity, the Mesh Portal Protocol 1185 makes use of account identifiers in the traditional [RFC5322] format 1186 @. Transactions supported by the Portal Protocol 1187 include: 1189 o Create Account 1191 o Add profile 1193 o Update profile 1195 o Request device connection* 1197 o View pending requests* 1199 o Accept or reject a connection request* 1201 Transactions marked with an asterisk* require administration 1202 privileges for the personal profile. 1204 Although the Mesh Architecture regards the Mesh Portal to be an 1205 untrusted cloud service with respect to Confidentiality and 1206 Integrity, the information transferred between devices and the portal 1207 could be susceptible to traffic analysis. For this reason, all 1208 exchanges between devices and the portal MUST be protected using a 1209 transport layer security enhancement such as TLS [RFC5246] . 1211 7.1. Federated Portals 1213 A Mesh Portal MAY belong to a Federation. Portals belonging to a 1214 Federation periodically synchronize their transaction logs so that 1215 all the members of the federation have access to the complete set of 1216 transaction logs for all the portals belonging to the federation. 1217 This allows the federation to collectively guarantee the availability 1218 of the user's profile data should one or more portals become 1219 unavailable either temporarily or permanently. 1221 The InterMesh protocol is supports Portal Federation. 1223 The CryptoMesh is proposed open federation of Mesh Portals that 1224 permits any portal willing to accept its terms of service to join. 1226 Due to the nature of the network effect it is expected that there 1227 would be only one such open federation baring major disagreements as 1228 to terms of service. Figure XXX 1230 [[This figure is not viewable in this format. The figure is 1231 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 1232 architecture.html [9].]] 1234 The Cryptomesh. 1236 Mesh Portals that are a member of a Federation have a mutual 1237 responsibility to protect availability by acting to mitigate abuse by 1238 users attempting to create excessive numbers of profiles or perform 1239 excessive numbers of updates. 1241 8. Security Considerations 1243 NYI 1245 9. IANA Considerations 1247 This document does not contain actions for IANA 1249 10. Acknowledgements 1251 Comodo Group: Egemen Tas, Melhi Abdulhayo?lu, Rob Stradling, Robin 1252 Alden. 1254 11. References 1256 11.1. Normative References 1258 [draft-hallambaker-dare-container] 1259 Hallam-Baker, P., "Data At Rest Encryption Part 2: DARE 1260 Container", draft-hallambaker-dare-container-02 (work in 1261 progress), August 2018. 1263 [draft-hallambaker-dare-message] 1264 Hallam-Baker, P., "Data At Rest Encryption Part 1: DARE 1265 Message Syntax", draft-hallambaker-dare-message-02 (work 1266 in progress), August 2018. 1268 [draft-hallambaker-json-web-service] 1269 Hallam-Baker, P., "JSON Web Service Binding Version 1.0", 1270 draft-hallambaker-json-web-service-10 (work in progress), 1271 April 2018. 1273 [draft-hallambaker-mesh-developer] 1274 Hallam-Baker, P., "Mathematical Mesh: Reference 1275 Implementation", draft-hallambaker-mesh-developer-07 (work 1276 in progress), April 2018. 1278 [draft-hallambaker-mesh-platform] 1279 Hallam-Baker, P., "Mathematical Mesh: Platform 1280 Configuration", draft-hallambaker-mesh-platform-03 (work 1281 in progress), April 2018. 1283 [draft-hallambaker-mesh-reference] 1284 Hallam-Baker, P., "Mathematical Mesh: Reference", draft- 1285 hallambaker-mesh-reference-09 (work in progress), April 1286 2018. 1288 [draft-hallambaker-sin] 1289 Hallam-Baker, P., "Strong Internet Names (SIN)", draft- 1290 hallambaker-sin-03 (work in progress), April 2018. 1292 [draft-hallambaker-udf] 1293 Hallam-Baker, P., "Uniform Data Fingerprint (UDF)", draft- 1294 hallambaker-udf-10 (work in progress), April 2018. 1296 [FIPS197] "[Reference Not Found!]". 1298 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1299 Requirement Levels", BCP 14, RFC 2119, 1300 DOI 10.17487/RFC2119, March 1997. 1302 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1303 (TLS) Protocol Version 1.2", RFC 5246, 1304 DOI 10.17487/RFC5246, August 2008. 1306 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 1307 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1308 2014. 1310 [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 1311 (HTTP/1.1): Semantics and Content", RFC 7231, 1312 DOI 10.17487/RFC7231, June 2014. 1314 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 1315 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 1316 2015. 1318 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 1319 RFC 7516, DOI 10.17487/RFC7516, May 2015. 1321 [RFC8017] Moriarty, K., Kaliski, B., Jonsson, J., and A. Rusch, 1322 "PKCS #1: RSA Cryptography Specifications Version 2.2", 1323 RFC 8017, DOI 10.17487/RFC8017, November 2016. 1325 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 1326 Signature Algorithm (EdDSA)", RFC 8032, 1327 DOI 10.17487/RFC8032, January 2017. 1329 [SHA-2] NIST, "Secure Hash Standard", August 2015. 1331 [SHA-3] Dworkin, M., "SHA-3 Standard: Permutation-Based Hash and 1332 Extendable-Output Functions", August 2015. 1334 [ShamirXX] 1335 "[Reference Not Found!]". 1337 11.2. Informative References 1339 [BLOCKCHAIN] 1340 Chain.com, "Blockchain Specification". 1342 [PHB-CoKey] 1343 "[Reference Not Found!]". 1345 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 1346 Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, 1347 January 2006. 1349 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1350 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1351 December 2005. 1353 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 1354 Thayer, "OpenPGP Message Format", RFC 4880, 1355 DOI 10.17487/RFC4880, November 2007. 1357 [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, 1358 DOI 10.17487/RFC5322, October 2008. 1360 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 1361 Mail Extensions (S/MIME) Version 3.2 Message 1362 Specification", RFC 5751, DOI 10.17487/RFC5751, January 1363 2010. 1365 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 1366 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 1367 March 2011. 1369 11.3. URIs 1371 [1] http://mathmesh.com/Documents/draft-hallambaker-mesh- 1372 architecture.html 1374 [2] http://mathmesh.com/Documents/draft-hallambaker-mesh- 1375 architecture.html 1377 [3] http://mathmesh.com/Documents/draft-hallambaker-mesh- 1378 architecture.html 1380 [4] http://mathmesh.com/Documents/draft-hallambaker-mesh- 1381 architecture.html 1383 [5] http://mathmesh.com/Documents/draft-hallambaker-mesh- 1384 architecture.html 1386 [6] http://mathmesh.com/Documents/draft-hallambaker-mesh- 1387 architecture.html 1389 [7] http://mathmesh.com/Documents/draft-hallambaker-mesh- 1390 architecture.html 1392 [8] http://mathmesh.com/Documents/draft-hallambaker-mesh- 1393 architecture.html 1395 [9] http://mathmesh.com/Documents/draft-hallambaker-mesh- 1396 architecture.html 1398 Author's Address 1400 Phillip Hallam-Baker 1401 Comodo Group Inc. 1403 Email: philliph@comodo.com