idnits 2.17.1 draft-hallambaker-mesh-architecture-01.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: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 7, 2016) is 2971 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) ** Obsolete normative reference: RFC 6962 (Obsoleted by RFC 9162) ** Downref: Normative reference to an Not Issued RFC: RFC 5822 -- Obsolete informational reference (is this intentional?): RFC 822 (Obsoleted by RFC 2822) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 2 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: Standards Track March 7, 2016 5 Expires: September 8, 2016 7 Mathematical Mesh: Architecture 8 draft-hallambaker-mesh-architecture-01 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 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on September 8, 2016. 34 Copyright Notice 36 Copyright (c) 2016 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 1. Introduction 51 The Mathematical Mesh is a user centered Public Key Infrastructure 52 that uses cryptography to make computers easier to use. 54 The Mesh uses cryptography and an untrusted cloud service to make 55 management of computer configuration data transparent to the end 56 user. Each Mesh user has a personal profile that is unique to them 57 and contains a set of public keys for maintaining the user's Mesh 58 profile. 60 2. Definitions 62 2.1. Requirements Language 64 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 65 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 66 document are to be interpreted as described in RFC 2119 [RFC2119]. 68 3. Background 70 Public Key Cryptography permits Internet applications to be secure 71 but requires an infrastructure for key distribution. 73 WebPKI has been very successful for E-commerce. Client side PKI has 74 been remarkably less successful. 76 S/MIME and OpenPGP both have significant user bases but both have 77 been limited to a small community. Government for S/MIME, system 78 admins and security researchers for OpenPGP. Use of PKI for 79 authentication of Web users has seen negligible use. 81 One of the chief obstacles any network application has to overcome is 82 the critical mass problem. While S/MIME and OpenPGP both have 83 several million users, this is a small fraction of the number of 84 email users. 86 It is likely that the more significant obstacle to deployment is the 87 difficulty of using client side PKI applications. While S/MIME and 88 OpenPGP both claim to reduce the effort of sending secure email 'to a 89 single click', no security feature that requires the user to make a 90 conscious decision to use it every time it is used can ever hope to 91 achieve ubiquitous deployment. 93 Attempting to automate the process of sending encrypted mail 94 introduces a new problem. The fact that a user has configured a 95 client to receive encrypted mail the past does not mean that they are 96 capable of receiving and decrypting such mail today. And even if 97 they are still capable of receiving the encrypted mail today, this 98 capability may be limited to a single machine that they do not 99 currently have access to. 101 While such objections have been repeatedly dismissed as trivial and 102 'easily solved' by protocol designers, to ordinary email users, they 103 are anything but trivial. If a change is to be made to an 104 infrastructure they rely on daily, it must be completely transparent. 105 An email security infrastructure that interrupts or disrupts their 106 flow of work is totally unacceptable. 108 Equally overlooked by application designers is the difficulty of 109 configuring applications that support end-to-end security through 110 cryptography. While working on this project, the author attempted to 111 configure a very popular email client to make use of the built in S/ 112 MIME capabilities. Even with 25 years of experience, this took over 113 half an hour and required the user to follow a procedure with 17 114 different steps! 116 It is important to note that this complexity is not simply a 117 consequence of one poorly designed application, it is the result of 118 the functions of the PKI being divided across three poorly integrated 119 applications on the user's machine compounded by a set of network 120 protocols that are not designed to provide a seamless user 121 experience. 123 A similar problem is illustrated by the problem of configuring SSH. 124 There is a simple way to configure SSH and there is a secure way and 125 these are not the same. The simple way to configure SSH is for each 126 user to create a single keypair and copy it to each of the machines 127 they might need terminal access to. While this is straightforward it 128 means that there is no way to mitigate the possibility of the key 129 being compromised if a machine is lost or stolen. Sharing a private 130 key between machines is as bad as sharing a password between 131 accounts. But attempting to achieve cryptographic hygiene across a 132 diverse collection of devices requires user effort proportional to 133 the square of the number of devices. 135 3.1. What it means to be user-centered 137 A key principle that guides the design of the Mesh is that any set of 138 instructions that can be written down and given to a user can be 139 written down as code and executed by the computer. Public key 140 cryptography is used to automate the process of managing public keys. 142 Traditional PKI attempted to solve the problems that were of 143 paramount concern to the designers. The designers of S/MIME were 144 concerned with the problem of exchanging secure email within a 145 hierarchical organization and built a (mostly) hierarchical design. 146 The designers of OpenPGP were concerned with the risk of government 147 subversion of the trust infrastructure for nefarious ends. 149 But what does the user care about? What is the user's principal 150 concern? 152 The biggest concern I hear from users is not the risk that someone 153 else might get to see their confidential data, rather it is the risk 154 that they might lose their precious data by some unintended user- 155 error. 157 Being user centered means considering and addressing the requirements 158 that are set by users regardless of whether they are compatible with 159 the designer's view of optimal security. In particular a user- 160 centered PKI must address requirements such as: 162 Guaranteeing that data loss does not happen even in the most extreme 163 cases of total loss or destruction of all hardware they used to store 164 their keys. 166 Mitigating the consequences of user error or carelessness. 168 Mitigating the consequences of devices being lost or stolen. 170 Providing mechanisms that permit a user to permit access to their 171 digital assets after their death. 173 3.2. Eliminate unnecessary options 175 Traditionally cryptographic applications give the user a bewildering 176 choice of algorithms and options. They can choose to have one RSA 177 keypair used for encryption and signature or they can have separate 178 keys for both, they can encrypt their messages using 3DES or AES at 179 128, 192 or 256 bit security. And so on. 181 The Mesh eliminates such choices as unnecessary. Except where 182 required by an application, the Mesh always uses separate keys for 183 encryption and signature operations and only uses the highest 184 strength on offer. Currently, Mesh profiles are always encrypted 185 using RSA with a 2048 bit key, AES with a 256 bit key and SHA-2-512. 186 (The CFRG ECC curves will be added in the near future when 187 implementations become available.) 189 For similar reasons, every Mesh master profile has an escrow key. 190 The use of key escrow by applications is optional, but every profile 191 has the capability of using it should circumstances require. 193 3.3. Why change is possible 195 All four of the open standards based PKIs that have been developed in 196 the IETF are based on designs that emerged in the mid-1990s. 197 Performing the computations necessary for public key cryptography 198 without noticeable impact on the speed of user interaction was a 199 constraint for even the fastest machines of the day. Consequently, 200 PKI designs attempted to limit the number of cryptographic operations 201 required to the bare minimum necessary. There were long debates over 202 the question of whether certificate chains of more than 3 203 certificates were acceptable. 205 Today a 32 bit computer with two processing cores running at 1.2GHz 206 can be bought for $5 and public key algorithms are available that 207 provide a higher level of security for less computation time. In 208 1995, the idea that a single user might need a hundred public key 209 pairs and a personal PKI to manage them as an extreme scenario. 210 Today when the typical user has a phone, a tablet and a laptop and 211 their home is about to fill up dozens if not hundreds of network 212 connected devices, the need to manage large numbers of keys for 213 individual users is clear. 215 Almost any information security requirement has a straightforward 216 solution if you are prepared to commit the necessary resources. In 217 general, each degree of cryptographic separation that is required 218 will introduce an additional layer of hierarchy. 220 Traditionally PKI has focused on the problem of delegating trust from 221 one party to another. Such capabilities have been implicit in the 222 model but only expressed in applications to a limited degree. 224 In the WebPKI, Certificate Authorities maintain the private keys 225 corresponding to their widely distributed root keys in offline 226 facilities that are never connected to the Internet. These keys are 227 in turn used to sign 'intermediate root certificates' corresponding 228 to the keys used to sign end entity certificates. The CA has this 229 capability but the end entity does not. In the PKIX model it is 230 assumed that if the end entity needs to change their cryptographic 231 configuration, they will go back to their CA and get a new 232 certificate. 234 In the OpenPGP Web of trust, Alice signs the key of Bob who signs the 235 key of Carol. Since everyone is a trust provider in the OpenPGP 236 model, Alice can sign a key for Alice. This mechanism is used to 237 support key rollover but the task of distributing her new keys to the 238 devices where Alice needs them is a problem left to Alice. 240 While it is quite possible for a very capable and experienced PKI 241 expert to configure PKIX and OpenPGP applications in a fashion that 242 supports management of personal keys, such use is far beyond what can 243 reasonably be expected of typical users. 245 The Mesh applies PKI technology to the problem of making PKI use 246 effortless. Once an initial configuration is established, the user 247 is not required to think about PKI at all. Every PKI operation (e.g. 248 key and certificate rollover) is performed automatically. 250 4. Basic Concepts 252 4.1. Parties 254 The Mesh is a network infrastructure. As with any such 255 infrastructure it is formed not as a set of things but rather as the 256 relationship between those things. 258 4.1.1. User 260 A Mesh user is a person or organization that has established a Mesh 261 personal profile. A Mesh personal profile describes the 262 configuration of the set of devices and applications that the user 263 uses. Each Mesh profile is identified by a globally unique 264 fingerprint value. 266 A Mesh user MAY have multiple profiles for the purpose of 267 compartmentalizing their online identity and preventing activity in 268 one network context being linked to activity in another network 269 context. The extent to which such separation provides increased 270 privacy is not currently understood. From the point of view of the 271 Mesh protocols, such profiles are held by separate users. 273 At present the Mesh specifications are designed to support 274 requirements arising from personal use such as the user transferring 275 application settings from one device they own to another device they 276 own. To deploy the Mesh in an enterprise environment, features such 277 as the ability to import settings provided by the IT department are 278 highly desirable. 280 4.1.2. Devices 282 The Mesh may be used on any computer that has the ability to connect 283 to a network and perform public key cryptography. 285 Every device that uses the Mesh has a unique device profile that 286 specifies public key pairs that are unique to that device. 288 When a device is connected to a user's personal profile, it may be an 289 Administration Device or a Connected Device depending on whether it 290 has been assigned an Administration key. 292 Administration device A device that has access to an 293 administration key for the user's Mesh Personal Profile and is 294 thus authorized to authorize actions such as connecting a new 295 device to the profile, removing devices and creating or 296 removing application profiles. 298 Connected Device A device that is connected to the Mesh Personal 299 Profile that is not an administration device. 301 Note that a device MAY be connected to more than one Personal 302 Profile at the same time. For example, an embedded device such 303 as a thermostat might have a single device profile installed 304 during manufacture. If Alice and Bob share the same 305 accommodations where the thermostat is installed, both users 306 might have connected the device to their personal profile. 308 4.1.3. Portal Provider 310 Users do not interact with a Mesh Directly. All interaction with the 311 Mesh is mediated by a Portal Provider. The portal provider is 312 responsible for protecting the Mesh from abuse such as Denial of 313 Service attacks, resource exhaustion, spam, etc. 315 Users interact with a portal provider through an account which has an 316 account identifier in the traditional [RFC5822] format: 318 @ 320 Where is an account identifier that is unique to that portal service 321 and is the DNS name of the portal service. 323 4.1.4. Mesh Provider 325 4.1.5. InterMesh 327 4.2. Technology 329 4.2.1. UDF Fingerprints 331 The Uniform Data Fingerprint format (UDF) [draft-hallambaker-udf] is 332 used to construct names for Mesh data items. UDF employs Base32 334 [RFC3977] encoding and the SHA-2-512 and SHA-3-512 digest functions 335 to construct fingerprints of varying lengths. 337 The choice of fingerprint length is a balance between security and 338 compactness of the representation. Longer fingerprints offer higher 339 security but are less convenient. The minimum fingerprint size 340 recommended for use in the Mesh is 25 characters, this presents a 341 work factor of 2^117 to an attacker attempting to generate a 342 signature key matching a particular fingerprint, approximately the 343 same work factor as RSA with 2048 bit keys. 345 4.2.2. Resolving 347 In contrast to the URLs resolved by the HTTP protocol which identify 348 a resource by means of a location and a means of retrieval, a UDF 349 fingerprint only identifies a fixed data object and the data type. 351 A UDF resolution service resolves UDF fingerprints in the same manner 352 that a HTTP server resolves URLs but can only provide a response for 353 the set of fingerprints known to that specific server. Unlike the 354 HTTP service which the client must trust to return the correct 355 resource, every response returned by a UDF resolution service may be 356 validated against the fingerprint presented in the original request. 357 Thus a user of a UDF resolution service is not required to trust it 358 for the integrity of the result received. 360 4.2.3. Signed Resources 362 UDF fingerprints provide a probabilistically unique identifier for a 363 static data object but do not provide a direct means of identifying 364 resources that change over time. To identify such resources, digital 365 signatures are used. A public key signature pair is created and the 366 UDF fingerprint of the public key parameters serves as the 367 identifier. The private key is then used to sign either the data 368 object itself or a data object containing a further public key. 370 The application/pkix-keyinfo content type described in [draft- 371 hallambaker-udf] is used to create identifiers for public keys. 373 4.2.4. Profile 375 A Mesh profile is a set of configuration settings that is bound to a 376 persistent identifier (a UDF fingerprint). 378 The Mesh protocols do not put any limit on the size or complexity of 379 Mesh profiles but a Mesh Portal SHOULD impose such limits as are 380 appropriate to avoid abuse such as denial of service attacks. 382 4.2.5. JSON Encoding 384 Javascript Object Notation (JSON) [RFC7159] encoding is used to 385 encode all Mesh data objects except for low level cryptographic 386 formats where other encodings are already established. 388 4.2.6. HTTP Web Service 390 The Mesh defines two new protocols: 392 Mesh Portal Protocol (mmm) A client-server protocol that mediates 393 access to a Mesh. 395 Intermesh Protocol The Intermesh protocol is used to exchange 396 Mesh profile data between portals. It is a flood fill protocol 397 that applies the same principles demonstrated in NNTP 398 [RFC4644]. 400 The DNS SRV mechanism is used for 402 4.2.7. Transparency 404 The principle of transparency was introduced by the Certificate 405 Transparency specification [RFC6962]. Transparency is the ability to 406 audit a system using only information that is available to the users 407 of the system. If the system is a public service, all the data used 408 to audit the service must be public. 410 The Mesh uses strong encryption and 412 5. Mesh Profiles 414 5.1. Device Profile 416 Is unique to each device. If a device has multiple accounts, each 417 account would typically require a separate device profile. 419 Has separate keys for encryption, authentication and signature. 421 Typically generated on the device. 423 Once generated, is typically constant until the device is reset. 425 Used to provision application keys out to a device. 427 5.2. Master Profile 429 Is signed by the Master Signing Key which is in turn validated by the 430 fingerprint. 432 Contains a Master Signing Key, Set of Administration Keys and Set of 433 Escrow Keys. 435 Changes infrequently, usually only when the set of administration 436 devices changes or a new escrow key is added. 438 5.3. Personal Profile 440 Is signed by an administration key. 442 For convenience, the master profile is included as an attachment. 444 Changes when there is a significant change to the configuration, the 445 addition of a new device or application. 447 5.4. Application Profile 449 Is signed by an administration key or an application administration 450 key (if specified for the application). 452 Contains the application configuration data. Is encrypted to the 453 device keys. 455 Changes when the application configuration is changed or when devices 456 are added or removed. 458 5.5. Future Directions 460 It may be desirable to partition the Application profiles so that it 461 is not necessary for every device to download the whole thing. For 462 example, sign a manifest so that the portal can strip out just the 463 parts of the profile that are relevant to a device. 465 6. Mesh Portal Protocol 467 Not necessarily instantaneous, may be latency between an update being 468 published and it being available. 470 7. Intermesh Protocol 472 This is not a priority at the moment. 474 May be used to support local replication or replication between 475 providers. 477 It is anticipated that the Intermesh Protocol will operate at a 478 substantially greater latency than the Mesh Portal Protocol. 479 Probably resynchronizing on an hourly or even daily basis. 481 Portals are not required to forward every update to the Intermesh. 482 Only updates that have not been superseded within the time quanta 483 need be published. 485 Each Portal runs a local append only log of every transaction. This 486 is periodically closed and a new log started. Some time after the 487 log is closed, a hash structure is calculated across the log entries 488 and broadcast to the other participants in the InterMesh. After a 489 quorum of hash values has been received, each participant in the 490 exchange calculates a new master hash entry which will be added to 491 the log before the next checkpoint occurs. 493 The participants exchange log records, but this may be on a limited 494 basis. If the InterMesh has a hundred members, it is not necessary 495 for every single node to have every single entry in real time. It is 496 sufficient for each node to have knowledge of a partner that can 497 provide it on demand. 499 8. Protocol Overview 501 [Account request does not specify the portal in the request body, 502 only the HTTP package includes this information. This is probably a 503 bug.] 505 8.1. Creating a new portal account 507 A user interacts with a Mesh service through a Mesh portal provider 508 with which she establishes a portal account. 510 For user convenience, a portal account identifier has the familiar 511 @ format established in [RFC822]. 513 For example Alice selects example.com as her portal provider and 514 chooses the account name alice. Her portal account identifier is 515 alice. 517 A user MAY establish accounts with multiple portal providers and/or 518 change their portal provider at any time they choose. 520 8.1.1. Checking Account Identifier for uniqueness 522 The first step in creating a new account is to check to see if the 523 chosen account identifier is available. This allows a client to 524 validate user input and if necessary warn the user that they need to 525 choose a new account identifier when the data is first entered. 527 The ValidateRequest message contains the requested account identifier 528 and an optional language parameter to allow the service to provide 529 informative error messages in a language the user understands. The 530 Language field contains a list of ISO language identifier codes in 531 order of preference, most preferred first. 533 POST /.well-known/mmm/HTTP/1.1 534 Host: example.com 535 Content-Length: 88 537 { 538 "ValidateRequest": { 539 "Account": "alice@example.com", 540 "Language": ["en-uk"]}} 542 The ValidateResponse message returns the result of the validation 543 request in the Valid field. Note that even if the value true is 544 returned, a subsequent account creation request MAY still fail. 546 HTTP/1.1 200 OK 547 Date: Mon 07 Mar 2016 09:28:07 548 Content-Length: 190 550 { 551 "ValidateResponse": { 552 "Status": 201, 553 "StatusDescription": "Operation completed successfully", 554 "Valid": true, 555 "Minimum": 1, 556 "InvalidCharacters": ".,:;{}()[]<>?|\\@#"}} 558 [Note that for the sake of concise presentation, the HTTP binding 559 information is omitted from future examples.] 561 8.2. Creating a new user profile 563 The first step in creating a new personal profile is to create a 564 Master Profile object. This contains the long term Master Signing 565 Key that will remain constant for the life of the profile, at least 566 one Online Signature Key to be used for administering the personal 567 profile and (optionally), one or more master escrow keys. 569 For convenience, the descriptions of the Master Signing Key, Online 570 Signing Keys and Escrow Keys typically include PKIX certificates 571 signed by the Master Signing Key. This allows PKIX based applications 572 to make use of PKIX certificate chains to express the same trust 573 relationships described in the Mesh. 575 { 576 "MasterProfile": { 577 "Identifier": "MDJVA-GWBES-2YXPA-7FHWU-GNTHE-D2ELD", 578 "MasterSignatureKey": { 579 "UDF": "MDJVA-GWBES-2YXPA-7FHWU-GNTHE-D2ELD", 580 "X509Certificate": " 581 MIIDJjCCAg6gAwIBAgIQRZ59PlINY9TLiyORByDifTANBgkqhkiG9w0BAQ0FADAu 582 MSwwKgYDVQQDFiNNREpWQS1HV0JFUy0yWVhQQS03RkhXVS1HTlRIRS1EMkVMRDAe 583 ... 584 -zDRA53b1TnPYd5DNZBdF-zcF4oL-yxNqBw7BBMbyIg-72APECSAy1O9", 585 "PublicParameters": { 586 "PublicKeyRSA": { 587 "kid": "MDJVA-GWBES-2YXPA-7FHWU-GNTHE-D2ELD", 588 "n": " 589 x4WRJAFuUSZKqw0hx1CCKmjh_JfAgnTBUt8GCKjOLBMIteDQOG85o5CkfHEj5g3h 590 830JV_QRgGH4DK6YojP7sJflRPRpEgCII6kQ8S5LHtoWNLci83pHDX8IwMab4lqp 591 Yh6gNUdvhqfL9gyuKHqJLD0W6o9dKpxm-RgbmJlgxBelxfR8EoftBKC57VFwJ2UC 592 wKWOoo7vQAgTqXGrp_QSGpLra9BiZ1BvXR6S-uewCLNDNcaWrjPprrFp9vm_QCnw 593 AjkDUQyircs14jIZjVY5Qv5-L4OS8UemVp93keVj9wJ8ZxUDXiN6jbutCBkYXO1p 594 i37KwvBwn_vzlS3Cu2i3Pw", 595 "e": " 596 AQAB"}}}, 597 "MasterEscrowKeys": [{ 598 "UDF": "MDATK-6PWXI-DAQ7X-FOSO2-7CXCU-N46TJ", 599 "X509Certificate": " 600 MIIDJjCCAg6gAwIBAgIQYpsuNn5CHEmCr9Vmwg1JKTANBgkqhkiG9w0BAQ0FADAu 601 MSwwKgYDVQQDFiNNREpWQS1HV0JFUy0yWVhQQS03RkhXVS1HTlRIRS1EMkVMRDAe 602 ... 603 Bs3BIgqOng7cW-vSZHD-dLt2E5emY_EQ_yAiiWi8EFXL1221CA1iUIOR", 604 "PublicParameters": { 605 "PublicKeyRSA": { 606 "kid": "MDATK-6PWXI-DAQ7X-FOSO2-7CXCU-N46TJ", 607 "n": " 608 uyle9pmeONA5V9kPS2LPPIzinUD7S_Ev7SrV8gFLwcxECai7LE7K6NJIT-u8A2FI 609 3NOvgYpvaz7W9I-z5WSokEt72GwcNStI-kUwshem3KP-Qbg3QRkfLzv9B7E7v_KB 610 bm1wP_UEQ_Ap1D_gFbq_PIHJQR_chtxcH91rF5W-rUi_r-C2T3-JAnGtjPISbKXG 611 OgjQ7x1V0j-YX9s2tKDpfzlvGfSZpzbXiM4oKvPM_3lH6ZN0eIUF2CmUzr_cdems 612 pW_bPjZdtR12UyA8eI18J7mi89eP_dIx_P0q3YY_GpMICBa7Lz5rAZkZVq00iAeP 613 7r_1VPQ3msY9lZ5GE61seQ", 614 "e": " 615 AQAB"}}}], 616 "OnlineSignatureKeys": [{ 617 "UDF": "MDPI5-HRBPS-FWTDI-76I6Q-VDYZE-UTR2X", 618 "X509Certificate": " 619 MIIDJzCCAg-gAwIBAgIRAI630vDDvaT5nhLoNdGb1SEwDQYJKoZIhvcNAQENBQAw 620 LjEsMCoGA1UEAxYjTURKVkEtR1dCRVMtMllYUEEtN0ZIV1UtR05USEUtRDJFTEQw 621 ... 622 zEY0GG_uZCsIS9rULqu3rRtWFe3stzsKw6levDgFCdL8al-3lghyFasvug", 623 "PublicParameters": { 624 "PublicKeyRSA": { 625 "kid": "MDPI5-HRBPS-FWTDI-76I6Q-VDYZE-UTR2X", 626 "n": " 627 pdFrro2dJEv1kS-KAyQ4jq6dbX8uCIibNHecDA-og1slmVZy5PUFfZBzgr0Cy-tK 628 euV9ZrNVKQP-OCwp9W_ghkTjA3lmCkI_XAbZSD3luQhq4CZJo1dPKGVVZT6YNtvG 629 Z-uIy7au7jAiamB2wm64QsbrIAd16bgGngYPYHf58bYdE1Xrb5PMQxCqFLs3VfTO 630 qH9SAbgBHuwYSuSSboBPZD_pRiPbujWMXh5TnA_yttfZ0ISkyi18QZ1GEhG-Qwp_ 631 pjOPtjewh0nJNunC82E1LgBsHUlFgbot3JULsW9q9CfkpgHXN_8FXsUHdEHe_9rm 632 xb76--ouQhBchDA82rp1Zw", 633 "e": " 634 AQAB"}}}]}} 636 The Master Profile is always signed using the Master Signing Key: 638 { 639 "SignedMasterProfile": { 640 "Identifier": "MDJVA-GWBES-2YXPA-7FHWU-GNTHE-D2ELD", 641 "SignedData": { 642 "header": " 643 ewogICJhbGciOiAiUlM1MTIiLAogICJraWQiOiAiTURKVkEtR1dCRVMtMllYUEEt 644 N0ZIV1UtR05USEUtRDJFTEQifQ", 645 "payload": " 646 ewogICJNYXN0ZXJQcm9maWxlIjogewogICAgIklkZW50aWZpZXIiOiAiTURKVkEt 647 R1dCRVMtMllYUEEtN0ZIV1UtR05USEUtRDJFTEQiLAogICAgIk1hc3RlclNpZ25h 648 ... 649 QVFBQiJ9fX1dfX0", 650 "signature": " 651 BrTIIVhIuK4g0bzSjAmbIcoaYLtBoJhveJfS9R-QrsSwcBEpITxyfDbdKK8GjRey 652 hmZQSOogxnSaj4VJul6G-EnHFCMfq7DFlxI6BSim-dThjFIKq3XHPSVS1kwVX5IF 653 YoQBzWKjeGIPYfEFTliDjjpFg_Kx7vXRDaArk108PNb7_IVmo1aWEIMh86Izs776 654 -hX_1TktNCMTGORG5Z5O48YcwsJX-cMwB_6R_PcVlUja-saD42-vQc_ztU-_iMxx 655 p6maDB0vWCxSYvGDF3uxICRi2atcsc8P8arEv4dbyoRa9PArssUu2uYif8czXVEH 656 V9Ip6IEd6FWFFyNqab0cxA"}}} 658 Since the device used to create the personal profile is typically 659 connected to the profile, a Device profile entry is created for it. 660 This contains a Device Signing Key, a Device Encryption Key and a 661 Device Authentication Key: 663 { 664 "DeviceProfile": { 665 "Identifier": "MBKMG-6QV5K-5PSXF-6TLUP-XXLRB-FEMVT", 666 "Names": ["Alice Desktop"], 667 "Description": "A desktop computer built by Acme Computer Co.", 668 "DeviceSignatureKey": { 669 "UDF": "MBKMG-6QV5K-5PSXF-6TLUP-XXLRB-FEMVT", 670 "PublicParameters": { 671 "PublicKeyRSA": { 672 "kid": "MBKMG-6QV5K-5PSXF-6TLUP-XXLRB-FEMVT", 673 "n": " 674 1yqsmXfIHYqzWe5DcqLnrfa_Xfbh5vK-zagPosWcrce0122Yufm5hZb4Ujc-1ozQ 675 z3ssEYIK30I8A8H-0qe-y6oOcRRsANc0LnGwlpadk00fOjcV8WySxkO2aaFmiKNQ 676 236zOwC2wtHJS7DxVQhbRUhAfQthopq3ycu88N4Re2pxnS4SBWRIH48AAwydp8Rt 677 WGNhCbZT-N-NN8dYrPMCNHhftPKHt0xbgXMtf_49tv4-tKwmAs6uDNXPL3YPWnIK 678 aaNA4PqLZPWVtN_kowAFjmpT19ROKLYFHSzmyx6dX6W9-Whor5BOr8U4qbWAcDQJ 679 GNZAOa4pzXWLFk9dIaIi5Q", 680 "e": " 681 AQAB"}}}, 682 "DeviceAuthenticationKey": { 683 "UDF": "MDWGK-N4VTY-EF5N4-EBLTA-ITQZC-JZLOI", 684 "PublicParameters": { 685 "PublicKeyRSA": { 686 "kid": "MDWGK-N4VTY-EF5N4-EBLTA-ITQZC-JZLOI", 687 "n": " 688 pJCOo5Q_fQfZy8decCRCBrjy5QGDX6pRy1E_5SNaHZIjZHOUolN3Z_plXryPiFcu 689 9hEULTe4Tl--d1_GrY_5HJ06g2zw__-0q7d26Z0z7tJ7OTcyysfoXZ7HAhz8ODeY 690 GQ3_ocoW8ibiOj8nla3t3wCU8vnU4e8d2wHiZiyGxYLRH2-TQmCwDh8-mKMfUr0o 691 _p06xjwsUvPfDspRBlltkiNbM5wtHZRDiJR15tHw8QAV4EIJFrwZQmI28sJLLqrl 692 WZlUxbCZzdXYy4dczlkC9DvxO4qxru22hFtHSOOyArweqJXGWuUW7xkCkWl7oauT 693 5rIFzEM712RgNKxodBSotQ", 694 "e": " 695 AQAB"}}}, 696 "DeviceEncryptiontionKey": { 697 "UDF": "MBLYV-KC666-JGASF-7RCNB-DAHQ2-JMTA2", 698 "PublicParameters": { 699 "PublicKeyRSA": { 700 "kid": "MBLYV-KC666-JGASF-7RCNB-DAHQ2-JMTA2", 701 "n": " 702 wj9WxkNn_BBJHbi2QTOZFn28IFXjQT2dhoytLxt8zdEPyaz031YXIrINCFuK2Bsi 703 MsB1e8o-7kNWwOTtzXD-lB8U2mc7BH7PEMdcwlLypuKJcVX-MtXMVG4E8fqMYdUQ 704 6T3aKtvi1LzPZR8LFjxEx44YoN0juwcRcQkhp_pbsxaxdt4mHSd0_1CF2W5MufXb 705 q-sCnAGRAFiCKzT4jfn-MEoQvERqORpVJaiZDyT6z5RS7oIrTu8OPCHyfN8tPzH_ 706 QjMO5xQtBohms6uYWftiOtgmkV_VaQ4BZt-zZ0DFoDIZmAvMa-p4YZOpRofG-cii 707 rVaW4eYY5ELY-c2AGjOpeQ", 708 "e": " 709 AQAB"}}}}} 710 The Device Profile is signed using the Device Signing Key: 712 { 713 "SignedDeviceProfile": { 714 "Identifier": "MBKMG-6QV5K-5PSXF-6TLUP-XXLRB-FEMVT", 715 "SignedData": { 716 "header": " 717 ewogICJhbGciOiAiUlM1MTIiLAogICJraWQiOiAiTUJLTUctNlFWNUstNVBTWEYt 718 NlRMVVAtWFhMUkItRkVNVlQifQ", 719 "payload": " 720 ewogICJEZXZpY2VQcm9maWxlIjogewogICAgIklkZW50aWZpZXIiOiAiTUJLTUct 721 NlFWNUstNVBTWEYtNlRMVVAtWFhMUkItRkVNVlQiLAogICAgIk5hbWVzIjogWyJB 722 ... 723 ICAgICAiZSI6ICIKQVFBQiJ9fX19fQ", 724 "signature": " 725 vOMCqvNhnMIYnQWldv_2fiGEsYwTHdDJSrmGSnaeG5QrdcmaPqgXHQX-w8rcBy15 726 _7i8_9x9jhqytLfsU7dCzNePvyX87D3dPEmdL0-A7RsGp0goKrP3w8O6WMyGTk92 727 GrpqSgeNWcpejqxzoB2Mln21J_vRsmkWkHZznRvh5mDSVc5OAZ5-XI8Vg2v4IpV- 728 NJKkuAeChUGiOWUBwXsoCIXbU5tjtFYVLYii2F_a3vrVBXGY_hNfDl8DsLJp3rOz 729 LFXbMB8B_e9sFwI4GuTykXObVrGpGBJ-Hy93EuacXI2Mh00vbRTJkbT8ClgZhsBq 730 ERawxBaucm_Lemig4GUgjA"}}} 732 A personal profile would typically contain at least one application 733 when first created. For the sake of demonstration, we will do this 734 later. 736 The personal profile thus consists of the master profile and the 737 device profile: 739 { 740 "PersonalProfile": { 741 "Identifier": "MDJVA-GWBES-2YXPA-7FHWU-GNTHE-D2ELD", 742 "SignedMasterProfile": { 743 "Identifier": "MDJVA-GWBES-2YXPA-7FHWU-GNTHE-D2ELD", 744 "SignedData": { 745 "header": " 746 ewogICJhbGciOiAiUlM1MTIiLAogICJraWQiOiAiTURKVkEtR1dCRVMtMllYUEEt 747 N0ZIV1UtR05USEUtRDJFTEQifQ", 748 "payload": " 749 ewogICJNYXN0ZXJQcm9maWxlIjogewogICAgIklkZW50aWZpZXIiOiAiTURKVkEt 750 R1dCRVMtMllYUEEtN0ZIV1UtR05USEUtRDJFTEQiLAogICAgIk1hc3RlclNpZ25h 751 ... 752 QVFBQiJ9fX1dfX0", 753 "signature": " 754 BrTIIVhIuK4g0bzSjAmbIcoaYLtBoJhveJfS9R-QrsSwcBEpITxyfDbdKK8GjRey 755 hmZQSOogxnSaj4VJul6G-EnHFCMfq7DFlxI6BSim-dThjFIKq3XHPSVS1kwVX5IF 756 YoQBzWKjeGIPYfEFTliDjjpFg_Kx7vXRDaArk108PNb7_IVmo1aWEIMh86Izs776 757 -hX_1TktNCMTGORG5Z5O48YcwsJX-cMwB_6R_PcVlUja-saD42-vQc_ztU-_iMxx 758 p6maDB0vWCxSYvGDF3uxICRi2atcsc8P8arEv4dbyoRa9PArssUu2uYif8czXVEH 759 V9Ip6IEd6FWFFyNqab0cxA"}}, 760 "Devices": [{ 761 "Identifier": "MBKMG-6QV5K-5PSXF-6TLUP-XXLRB-FEMVT", 762 "SignedData": { 763 "header": " 764 ewogICJhbGciOiAiUlM1MTIiLAogICJraWQiOiAiTUJLTUctNlFWNUstNVBTWEYt 765 NlRMVVAtWFhMUkItRkVNVlQifQ", 766 "payload": " 767 ewogICJEZXZpY2VQcm9maWxlIjogewogICAgIklkZW50aWZpZXIiOiAiTUJLTUct 768 NlFWNUstNVBTWEYtNlRMVVAtWFhMUkItRkVNVlQiLAogICAgIk5hbWVzIjogWyJB 769 ... 770 ICAgICAiZSI6ICIKQVFBQiJ9fX19fQ", 771 "signature": " 772 vOMCqvNhnMIYnQWldv_2fiGEsYwTHdDJSrmGSnaeG5QrdcmaPqgXHQX-w8rcBy15 773 _7i8_9x9jhqytLfsU7dCzNePvyX87D3dPEmdL0-A7RsGp0goKrP3w8O6WMyGTk92 774 GrpqSgeNWcpejqxzoB2Mln21J_vRsmkWkHZznRvh5mDSVc5OAZ5-XI8Vg2v4IpV- 775 NJKkuAeChUGiOWUBwXsoCIXbU5tjtFYVLYii2F_a3vrVBXGY_hNfDl8DsLJp3rOz 776 LFXbMB8B_e9sFwI4GuTykXObVrGpGBJ-Hy93EuacXI2Mh00vbRTJkbT8ClgZhsBq 777 ERawxBaucm_Lemig4GUgjA"}}], 778 "Applications": []}} 780 The personal profile is then signed using the Online Signing Key: 782 { 783 "SignedPersonalProfile": { 784 "Identifier": "MDJVA-GWBES-2YXPA-7FHWU-GNTHE-D2ELD", 785 "SignedData": { 786 "header": " 787 ewogICJhbGciOiAiUlM1MTIiLAogICJraWQiOiAiTUJLTUctNlFWNUstNVBTWEYt 788 NlRMVVAtWFhMUkItRkVNVlQifQ", 789 "payload": " 790 ewogICJQZXJzb25hbFByb2ZpbGUiOiB7CiAgICAiSWRlbnRpZmllciI6ICJNREpW 791 QS1HV0JFUy0yWVhQQS03RkhXVS1HTlRIRS1EMkVMRCIsCiAgICAiU2lnbmVkTWFz 792 ... 793 X0xlbWlnNEdVZ2pBIn19XSwKICAgICJBcHBsaWNhdGlvbnMiOiBbXX19", 794 "signature": " 795 Tpqh8sl8K9apRYJWuZ46ApGZMNTM-lgUSr_ASLlLQkXzUILltzxKQi9RNpPdiHwz 796 -RjcKTmBIrWXTqu94rz7Zn6VjHOMc2WkmKZumiwD0toDznLreFzN5RY7Lf9NXeiD 797 czoE_DGIcVK-hxlJ7QPSZ4Tv0rmX2c-uwBdNqSr2_TfgE9sgWvIftTfS6rEzcJp8 798 pxnYMyjRknqg-Y4V5Bwz9iklcPy-K5MbnFFm_cCJikTbmUAG0-oA3HsreyqnfBQH 799 ckfX-nwYRO0ChV4K86ud4RB0KYORDIEcxVjQS59J_iGG00NrL3KVaQ05zXPt1_UG 800 KNrppHhqpoon0xnTRIUgAQ"}}} 802 8.2.1. Publishing a new user profile 804 Once the signed personal profile is created, the client can finaly 805 make the request for the service to create the account. The request 806 object contains the requested account identifier and profile: 808 { 809 "CreateRequest": { 810 "Account": "alice", 811 "Profile": { 812 "SignedPersonalProfile": { 813 "Identifier": "MDJVA-GWBES-2YXPA-7FHWU-GNTHE-D2ELD", 814 "SignedData": { 815 "header": " 816 ewogICJhbGciOiAiUlM1MTIiLAogICJraWQiOiAiTUJLTUctNlFWNUstNVBTWEYt 817 NlRMVVAtWFhMUkItRkVNVlQifQ", 818 "payload": " 819 ewogICJQZXJzb25hbFByb2ZpbGUiOiB7CiAgICAiSWRlbnRpZmllciI6ICJNREpW 820 QS1HV0JFUy0yWVhQQS03RkhXVS1HTlRIRS1EMkVMRCIsCiAgICAiU2lnbmVkTWFz 821 ... 822 X0xlbWlnNEdVZ2pBIn19XSwKICAgICJBcHBsaWNhdGlvbnMiOiBbXX19", 823 "signature": " 824 Tpqh8sl8K9apRYJWuZ46ApGZMNTM-lgUSr_ASLlLQkXzUILltzxKQi9RNpPdiHwz 825 -RjcKTmBIrWXTqu94rz7Zn6VjHOMc2WkmKZumiwD0toDznLreFzN5RY7Lf9NXeiD 826 czoE_DGIcVK-hxlJ7QPSZ4Tv0rmX2c-uwBdNqSr2_TfgE9sgWvIftTfS6rEzcJp8 827 pxnYMyjRknqg-Y4V5Bwz9iklcPy-K5MbnFFm_cCJikTbmUAG0-oA3HsreyqnfBQH 828 ckfX-nwYRO0ChV4K86ud4RB0KYORDIEcxVjQS59J_iGG00NrL3KVaQ05zXPt1_UG 829 KNrppHhqpoon0xnTRIUgAQ"}}}}} 830 The service reports the success (or failure) of the account creation 831 request: 833 { 834 "CreateResponse": { 835 "Status": 201, 836 "StatusDescription": "Operation completed successfully"}} 838 8.3. Connecting a device profile to a user profile 840 Connecting a device to a profile requires the client on the new 841 device to interact with a client on a device that has administration 842 capabilities, i.e. it has access to an Online Signing Key. Since 843 clients cannot interact directly with other clients, a service is 844 required to mediate the connection. This service is provided by a 845 Mesh portal provider. 847 All service transactions are initiated by the clients. First the 848 connecting device posts ConnectStart, after which it may poll for the 849 outcome of the connection request using ConnectStatus. 851 Periodically, the Administration Device polls for a list of pending 852 connection requests using ConnectPending. After posting a request, 853 the administration device posts the result using ConnectComplete: 855 Connecting Mesh Administration 856 Device Service Device 858 | | | 859 | ConnectStart | | 860 | ----------------------> | | 861 | | ConnectPending | 862 | | <---------------------- | 863 | | | 864 | | ConnectComplete | 865 | | <---------------------- | 866 | ConnectStatus | | 867 | ----------------------> | | 869 The first step in the process is for the client to generate a device 870 profile. Ideally the device profile is bound to the device in a 871 read-only fashion such that applications running on the device can 872 make use of the deencryption and authentication keys but these 873 private keys cannot be extracted from the device: 875 { 876 "DeviceProfile": { 877 "Identifier": "MCBEY-2RVCZ-VNEOZ-I47J6-OAEDL-AUUWM", 878 "Names": ["Alice Ring"], 879 "Description": "A wearable ring computer bought.", 880 "DeviceSignatureKey": { 881 "UDF": "MCBEY-2RVCZ-VNEOZ-I47J6-OAEDL-AUUWM", 882 "PublicParameters": { 883 "PublicKeyRSA": { 884 "kid": "MCBEY-2RVCZ-VNEOZ-I47J6-OAEDL-AUUWM", 885 "n": " 886 oQ11i4hTaUpOmH6RSx6yvRgCO9ZC_eDbUYDZGzJn4nnS-5o8532smX7xGhnH8VNM 887 rd9xp3VhOMI8emuHTbFDvEM3IvAPi4KsfTMZ__Nsl_6tLYhw9ehgN-i5oRcOc7tT 888 Fbcrs89raMKDhwruRPYScO8SlvVRg31QHtBuC_Z5M5l4g25n311shbeWm1TeDQW3 889 ISZNYdxZMuzpDG2fojqQXyF5M1oJmvB5HWk5toUUFrv4399NIStYGiRlmjADEjRY 890 MarkYq-AcMXq3j0vCRTww4b4ZDIOKERMCtpHTeNB2gNk6zV_SxoL6rSsDRTfEFE9 891 eTxX0Dw7wnklM1ub7ebl6w", 892 "e": " 893 AQAB"}}}, 894 "DeviceAuthenticationKey": { 895 "UDF": "MDNSC-VYX44-3L2DW-CIR3M-TUPLW-I6VP6", 896 "PublicParameters": { 897 "PublicKeyRSA": { 898 "kid": "MDNSC-VYX44-3L2DW-CIR3M-TUPLW-I6VP6", 899 "n": " 900 2mFfT9Dg0_ROdaFlFyWlpkwajZWF0lOTgQvFJ6Evx9GwhajzqJS6FUUFwkxNQ4TL 901 rWd4gHF5AcPtJbCnFqIupgy341LsLOPXBzf4tFbn9JD8Ls2DmpxOvXMed4j51yw8 902 HN-J0slG5MPxQSB4YDUoCQuoSLDirpblQXgqTs_sY-oh_eavBYoyqt-08D8zHfQy 903 n01tOwZ2EsBz3aWF6D910Tq11lvB_VNF58g9ipPXI1J0ljBQ8Tlv6HT8hfn31g-B 904 SGT4EfMRUtSo149TthZynve1DfrbNq_tQgTMJBF0I38fr41QYgAi6mJjo8So_BvX 905 xCoLUMKkG1zTfRuUQ3GS3w", 906 "e": " 907 AQAB"}}}, 908 "DeviceEncryptiontionKey": { 909 "UDF": "MCAOX-46YPX-GAW5J-75V6G-B6OUP-2RG3X", 910 "PublicParameters": { 911 "PublicKeyRSA": { 912 "kid": "MCAOX-46YPX-GAW5J-75V6G-B6OUP-2RG3X", 913 "n": " 914 yNvvw3ddU5xc5yGZtN3XYm40aGDmntKHbqgP8csM6p6INfZK5jn9kKggE6vZBXRC 915 xi0Ko8HrRtK2yfqFRQXItIbbAwEW0DrwsWjBsks3OU2Vxksku81TEQelYJ5uXpI2 916 _0W0apqqeqG_8njvPvtu1S8Fhpt7uc_bu_h4EabiTK-EaXOKmd7owPtOt5PuL8VR 917 3JATRj1ytyPy9zJTbHv9iahE7moRHqRtggDbJ4yI0lInT_yawrKxld2qNl9c9JtH 918 AmtSzhU_XLztuXoA_o-Dlr6mv0p0bKi33SYOjcg08i2VYDabzY_5HJK1UfMqagIp 919 rxOIkT7k6b5bqgLuEFqt3w", 920 "e": " 921 AQAB"}}}}} 922 The device profile is then signed: 924 { 925 "SignedDeviceProfile": { 926 "Identifier": "MCBEY-2RVCZ-VNEOZ-I47J6-OAEDL-AUUWM", 927 "SignedData": { 928 "header": " 929 ewogICJhbGciOiAiUlM1MTIiLAogICJraWQiOiAiTUNCRVktMlJWQ1otVk5FT1ot 930 STQ3SjYtT0FFREwtQVVVV00ifQ", 931 "payload": " 932 ewogICJEZXZpY2VQcm9maWxlIjogewogICAgIklkZW50aWZpZXIiOiAiTUNCRVkt 933 MlJWQ1otVk5FT1otSTQ3SjYtT0FFREwtQVVVV00iLAogICAgIk5hbWVzIjogWyJB 934 ... 935 In19fX19", 936 "signature": " 937 OKsswShxjiC010nuOa14J4oBhsZ2CIuEingj2NzXh1ZUvKspPhedict88bye3BN_ 938 x_bzJifoUAytSICUmuMsCs4iPmnrc4UhiITRg4ZskBQfHa4YTKpywj7h6QVHuIz6 939 FNVWrpYjlg5hskQHm3uMXswMxrr-8xvOiz8XYOfs7DT-qIIsy9wfrADZZXP1ai9X 940 Eg16pxvbxvC12lxNqwnZy7G06SnqQJU-VcUCAdcz6zXHFmAc6jFD4ij1FnccwoMJ 941 VJv7v-9ID0f6YGoyM8iyW6_NKfAo6cYCc021MqGdDJdrfrT7Cm-8vSl3VMlQGkqn 942 PcyR-G2ySzDX3x4Qd-xqNQ"}}} 944 8.3.1. Profile Authentication 946 One of the main architecutral principles of the Mesh is bilateral 947 authentication. Every device that is connected to a Mesh profile 948 MUST authenticate the profile it is connecting to and every Mesh 949 profile administrator MUST authenticate devices that are connected. 951 Having created the necessary profile, the device MUST verify that it 952 is connecting to the correct Mesh profile. The best mechanism for 953 achieving this purpose depends on the capabilities of the device 954 being connected. The administration device obviously requires some 955 means of communicating with the user to serve its function. But the 956 device being connected may have a limited display capability or no 957 user interaction capability at all. 959 8.3.1.1. Interactive Devices 961 If the device has user input and display capabilities, it can verify 962 that it is connecting to the correct display by first requesting the 963 user enter the portal account of the profile they wish to connect to, 964 retreiving the profile associated with the device and displaying the 965 profile fingerprint. 967 The client requests the profile for the requested account name: 969 { 970 "GetRequest": { 971 "Account": "alice", 972 "Multiple": false}} 974 The response contains the requested profile information. 976 { 977 "GetResponse": { 978 "Status": 201, 979 "StatusDescription": "Operation completed successfully", 980 "Entries": [{ 981 "SignedPersonalProfile": { 982 "Identifier": "MDJVA-GWBES-2YXPA-7FHWU-GNTHE-D2ELD", 983 "SignedData": { 984 "header": " 985 ewogICJhbGciOiAiUlM1MTIiLAogICJraWQiOiAiTUJLTUctNlFWNUstNVBTWEYt 986 NlRMVVAtWFhMUkItRkVNVlQifQ", 987 "payload": " 988 ewogICJQZXJzb25hbFByb2ZpbGUiOiB7CiAgICAiSWRlbnRpZmllciI6ICJNREpW 989 QS1HV0JFUy0yWVhQQS03RkhXVS1HTlRIRS1EMkVMRCIsCiAgICAiU2lnbmVkTWFz 990 ... 991 X0xlbWlnNEdVZ2pBIn19XSwKICAgICJBcHBsaWNhdGlvbnMiOiBbXX19", 992 "signature": " 993 Tpqh8sl8K9apRYJWuZ46ApGZMNTM-lgUSr_ASLlLQkXzUILltzxKQi9RNpPdiHwz 994 -RjcKTmBIrWXTqu94rz7Zn6VjHOMc2WkmKZumiwD0toDznLreFzN5RY7Lf9NXeiD 995 czoE_DGIcVK-hxlJ7QPSZ4Tv0rmX2c-uwBdNqSr2_TfgE9sgWvIftTfS6rEzcJp8 996 pxnYMyjRknqg-Y4V5Bwz9iklcPy-K5MbnFFm_cCJikTbmUAG0-oA3HsreyqnfBQH 997 ckfX-nwYRO0ChV4K86ud4RB0KYORDIEcxVjQS59J_iGG00NrL3KVaQ05zXPt1_UG 998 KNrppHhqpoon0xnTRIUgAQ"}}}]}} 1000 Having received the profile data, the user can then verify that the 1001 device is attempting to connect to the correct profile by verifying 1002 that the fingerprint shown by the device attempting to connect is 1003 correct. 1005 8.3.1.2. Constrained Interaction Devices 1007 Connection of an Internet of Things 'IoT' device that does not have 1008 the ability to accept user input requires a mechanism by which the 1009 user can identify the device they wish to connect to their profile 1010 and a mechanism to authenticate the profile to the device. 1012 If the connecting device has a wired communication capability such as 1013 a USB port, this MAY be used to effect the device connection using a 1014 standardized interaction profile. But an increasing number of 1015 constrained IoT devices are only capable of wireless communication. 1017 Configuration of such devices for the purpose of the Mesh requires 1018 that we also consider configuration of the wireless networking 1019 capabilities at the same time. The precise mechanism by which this 1020 is achieved is therefore outside the scope of this particular 1021 document. However prototypes have been built and are being 1022 considered that make use of some or all of the following 1023 communication techniques: 1025 o 1027 * Wired serial connection (RS232, RS485). 1029 * DHCP signalling. 1031 * Machine readable device identifiers (barcodes, QRCodes). 1033 * Default device profile installed during manufacture. 1035 * Optical communication path using camera on administrative 1036 device and status light on connecting device to communicate the 1037 device identifier, challenge nonce and confirm profile 1038 fingerprint. 1040 * Speech output on audio capable connecting device. 1042 8.3.2. Connection request 1044 After the user verifies the device fingerprint as correct, the client 1045 posts a device connection request to the portal: 1047 { 1048 "ConnectStartRequest": { 1049 "SignedRequest": { 1050 "Identifier": "MCBEY-2RVCZ-VNEOZ-I47J6-OAEDL-AUUWM", 1051 "SignedData": { 1052 "header": " 1053 ewogICJhbGciOiAiUlM1MTIiLAogICJraWQiOiAiTUNCRVktMlJWQ1otVk5FT1ot 1054 STQ3SjYtT0FFREwtQVVVV00ifQ", 1055 "payload": " 1056 ewogICJDb25uZWN0aW9uUmVxdWVzdCI6IHsKICAgICJQYXJlbnRVREYiOiAiYWxp 1057 Y2UiLAogICAgIkRldmljZSI6IHsKICAgICAgIklkZW50aWZpZXIiOiAiTUNCRVkt 1058 ... 1059 TlEifX19fQ", 1060 "signature": " 1061 CixG1xk8bFADyNCAJP0lqrjuFlMtoIz5hTCiGhKb_4mjgUqW4Fpsj3HydumNRktU 1062 c_7B9AlBO0TD7Z6IS-LbmfhmhQtFElvs9WhB42hqoe-cK_N_fL1T9H1B0QgyesWO 1063 nvZaE5dS3MmIsOCA_VTG_LUDmdqi908wWLHCsDpMkHwC_QD8SW1L0-NlmrJgRXSC 1064 xv2VAJAMAf1LysYyEJ_32Z2XsH7AjI9gWsVnCzbZTaNqJSdjx0mgsCRvj4GBqYGl 1065 txRC9Qr_2R_ye6PxOhBxE7Sl3pSKZqjQKVlTeKizKI6O8L-U2nwgdmwyN8eLMYMD 1066 GNWrP6SrEpPHSMUoCa6Avw"}}, 1067 "AccountID": "alice"}} 1069 The portal verifies that the request is accepable and returns the 1070 transaction result: 1072 { 1073 "ConnectStartResponse": {}} 1075 8.3.3. Administrator Polls Pending Connections 1077 The client can poll the portal for the status of pending requests at 1078 any time (modulo any service throttling restrictions at the service 1079 side). But the request status will only change when an update is 1080 posted by an administration device. 1082 Since the user is typically connecting a device to their profile, the 1083 next step in connecting the device is to start the administration 1084 client. When started, the client polls for pending connection 1085 requests using ConnectPendingRequest. 1087 { 1088 "ConnectPendingRequest": { 1089 "AccountID": "alice"}} 1091 The service responds with a list of pending requests: 1093 { 1094 "ConnectPendingResponse": { 1095 "Pending": [{ 1096 "Identifier": "MCBEY-2RVCZ-VNEOZ-I47J6-OAEDL-AUUWM", 1097 "SignedData": { 1098 "header": " 1099 ewogICJhbGciOiAiUlM1MTIiLAogICJraWQiOiAiTUNCRVktMlJWQ1otVk5FT1ot 1100 STQ3SjYtT0FFREwtQVVVV00ifQ", 1101 "payload": " 1102 ewogICJDb25uZWN0aW9uUmVxdWVzdCI6IHsKICAgICJQYXJlbnRVREYiOiAiYWxp 1103 Y2UiLAogICAgIkRldmljZSI6IHsKICAgICAgIklkZW50aWZpZXIiOiAiTUNCRVkt 1104 ... 1105 TlEifX19fQ", 1106 "signature": " 1107 CixG1xk8bFADyNCAJP0lqrjuFlMtoIz5hTCiGhKb_4mjgUqW4Fpsj3HydumNRktU 1108 c_7B9AlBO0TD7Z6IS-LbmfhmhQtFElvs9WhB42hqoe-cK_N_fL1T9H1B0QgyesWO 1109 nvZaE5dS3MmIsOCA_VTG_LUDmdqi908wWLHCsDpMkHwC_QD8SW1L0-NlmrJgRXSC 1110 xv2VAJAMAf1LysYyEJ_32Z2XsH7AjI9gWsVnCzbZTaNqJSdjx0mgsCRvj4GBqYGl 1111 txRC9Qr_2R_ye6PxOhBxE7Sl3pSKZqjQKVlTeKizKI6O8L-U2nwgdmwyN8eLMYMD 1112 GNWrP6SrEpPHSMUoCa6Avw"}}]}} 1114 8.3.4. Administrator updates and publishes the personal profile. 1116 The device profile is added to the Personal profile which is then 1117 signed by the online signing key. The administration client 1118 publishes the updated profile to the Mesh through the portal: 1120 { 1121 "PublishRequest": { 1122 "Entry": { 1123 "SignedPersonalProfile": { 1124 "Identifier": "MDJVA-GWBES-2YXPA-7FHWU-GNTHE-D2ELD", 1125 "SignedData": { 1126 "header": " 1127 ewogICJhbGciOiAiUlM1MTIiLAogICJraWQiOiAiTUJLTUctNlFWNUstNVBTWEYt 1128 NlRMVVAtWFhMUkItRkVNVlQifQ", 1129 "payload": " 1130 ewogICJQZXJzb25hbFByb2ZpbGUiOiB7CiAgICAiSWRlbnRpZmllciI6ICJNREpW 1131 QS1HV0JFUy0yWVhQQS03RkhXVS1HTlRIRS1EMkVMRCIsCiAgICAiU2lnbmVkTWFz 1132 ... 1133 MnlTekRYM3g0UWQteHFOUSJ9fV0sCiAgICAiQXBwbGljYXRpb25zIjogW119fQ", 1134 "signature": " 1135 QK3qK17qqKjrzJpheNMSP8l-Mfids1U8LteXgXtNslyKsN1fsf3Wc3orZRvxkmq3 1136 SiwwkRSY3k1bWGkMQ2-IVGuAVBvDq-ndgrc9zlqx4OGOZHIsUEpMmEMxYCGPWCek 1137 DRmeCg08o-viOXuBGNukjdmoV47AdWjEwp3bim-1RsA4NP5QfdAifesjI37iScUH 1138 HwvraQsPCDmYpoWfzqLiFu-d5OIzf2A6-V73DLw63sxy6POq9XN3uvBVbpeRXD3Z 1139 5zvFp58fprVjpqUqpdiDAecwd47xisxjtN7QNoE1mTuUsjcrz6uWRhe9zkCiAEd1 1140 i02PON8adi7XJD39Fr7TZQ"}}}}} 1141 As usual, the service returns the response code: 1143 { 1144 "PublishResponse": { 1145 "Status": 201, 1146 "StatusDescription": "Operation completed successfully"}} 1148 8.3.5. Administrator posts completion request. 1150 Having accepted the device and connected it to the profile, the 1151 administration client creates and signs a connection completion 1152 result which is posted to the portal using ConnectCompleteRequest: 1154 { 1155 "ConnectCompleteRequest": { 1156 "Result": { 1157 "Identifier": "MCBEY-2RVCZ-VNEOZ-I47J6-OAEDL-AUUWM", 1158 "SignedData": { 1159 "header": " 1160 ewogICJhbGciOiAiUlM1MTIiLAogICJraWQiOiAiTUJLTUctNlFWNUstNVBTWEYt 1161 NlRMVVAtWFhMUkItRkVNVlQifQ", 1162 "payload": " 1163 ewogICJDb25uZWN0aW9uUmVzdWx0IjogewogICAgIkRldmljZSI6IHsKICAgICAg 1164 IklkZW50aWZpZXIiOiAiTUNCRVktMlJWQ1otVk5FT1otSTQ3SjYtT0FFREwtQVVV 1165 ... 1166 dGVkIn19", 1167 "signature": " 1168 KP_5t5TeJEXXkw19wCpGcim8tIkElcpsIAUId7f8WabrQUNDGNEYox-1QrBaCCuC 1169 X8hud2kRZimhG-f8rWnOcXe4tDU8y1eoNeiGC_TijV_Bb189XDKpZobDtVSXLvhB 1170 YZp10T3RlzUEhMAPVUXJqf5yMIgJHnTTKzlT_cwNvnRSGMAnY2NLEg-lQ3FHkiiX 1171 copSUGQ9SzXuMSKu5b29Rdgqz-9C_-v5N7x9gNuU-YliEZACFfMMylUlfIWN4aYw 1172 TU8m-XckHkuKN75TNdH_gRAe6RqgbdYa_gQS5IhwZ5bbv2TGQe6T6ap7_92SFvNT 1173 Ew6pGGbAdBJ6RAwrZFbo2A"}}, 1174 "AccountID": "alice"}} 1176 Again, the service returns the response code: 1178 { 1179 "ConnectCompleteResponse": {}} 1181 8.3.6. Connecting device polls for status update. 1183 As stated previously, the connecting device polls the portal 1184 periodically to determine the status of the pending request using 1185 ConnectStatusRequest: 1187 { 1188 "ConnectStatusRequest": { 1189 "AccountID": "alice", 1190 "DeviceID": "MCBEY-2RVCZ-VNEOZ-I47J6-OAEDL-AUUWM"}} 1192 If the response is that the connection status has not changed, the 1193 service MAY return a response that specifies a minimum retry 1194 interval. In this case however there is a connection result: 1196 { 1197 "ConnectStatusResponse": { 1198 "Result": { 1199 "Identifier": "MCBEY-2RVCZ-VNEOZ-I47J6-OAEDL-AUUWM", 1200 "SignedData": { 1201 "header": " 1202 ewogICJhbGciOiAiUlM1MTIiLAogICJraWQiOiAiTUJLTUctNlFWNUstNVBTWEYt 1203 NlRMVVAtWFhMUkItRkVNVlQifQ", 1204 "payload": " 1205 ewogICJDb25uZWN0aW9uUmVzdWx0IjogewogICAgIkRldmljZSI6IHsKICAgICAg 1206 IklkZW50aWZpZXIiOiAiTUNCRVktMlJWQ1otVk5FT1otSTQ3SjYtT0FFREwtQVVV 1207 ... 1208 dGVkIn19", 1209 "signature": " 1210 KP_5t5TeJEXXkw19wCpGcim8tIkElcpsIAUId7f8WabrQUNDGNEYox-1QrBaCCuC 1211 X8hud2kRZimhG-f8rWnOcXe4tDU8y1eoNeiGC_TijV_Bb189XDKpZobDtVSXLvhB 1212 YZp10T3RlzUEhMAPVUXJqf5yMIgJHnTTKzlT_cwNvnRSGMAnY2NLEg-lQ3FHkiiX 1213 copSUGQ9SzXuMSKu5b29Rdgqz-9C_-v5N7x9gNuU-YliEZACFfMMylUlfIWN4aYw 1214 TU8m-XckHkuKN75TNdH_gRAe6RqgbdYa_gQS5IhwZ5bbv2TGQe6T6ap7_92SFvNT 1215 Ew6pGGbAdBJ6RAwrZFbo2A"}}}} 1217 [Should probably unpack further.] 1219 8.4. Adding an application profile to a user profile 1221 Application profiles are published separately from the personal 1222 profile to which they are linked. This allows a device to be given 1223 administration capability for a particular application without 1224 granting administration capability for the profile itself and the 1225 ability to connect additional profiles and devices. 1227 Another advantage of this separation is that an application profile 1228 might be managed by a separate party. In an enterprise, the 1229 application profile for a user's corporate email account could be 1230 managed by the corporate IT department. 1232 A user MAY have multiple application profiles for the same 1233 application. If a user has three email accounts, they would have 1234 three email application profiles, one for each account. 1236 In this example, the user has requested a PaswordProfile to be 1237 created. When populated, this records the usernames and passwords 1238 for the various Web sites that the user has created accounts at and 1239 has requested the Web browser store in the Mesh. 1241 Unlike a traditional password management service, the data stored the 1242 Password Profile is encrypted end to end and can only be decrypted by 1243 the devices that hold a decryption key. 1245 { 1246 "PasswordProfile": { 1247 "Identifier": "MCSJQ-ENQ6L-IJZH5-MCLCC-SE2NG-3T5F2-A", 1248 "EncryptedData": { 1249 "protected": " 1250 ewogICJhbGciOiAiQUUxMjgifQ", 1251 "iv": " 1252 G3CweSUBT8omE_VT9SCuZw", 1253 "ciphertext": " 1254 _JR9uX63-CkvvvJS0axnJxCChcBqe0mYv4M2xjHDaZqE6oUkQS7ZnHOTTmKO748r", 1255 "recipients": [{ 1256 "Header": { 1257 "kid": "MBLYV-KC666-JGASF-7RCNB-DAHQ2-JMTA2"}, 1258 "encrypted_key": " 1259 ZATx6Rivrr_qGmHbbKGV7tcnm_9UgRspFXu4oti6O9kRjglHS7wnvu5IpmDk5szv 1260 Eq_Zh7X7m3vxsxfvsKrAPKVnpVMx10847apFrAmvwbHNmX1a_rxtxxdzHAgDtJT0 1261 xJ4sch-CAEyudB_k2UNw1cpRtVm02x6sWyVtfTStFSADYw86bFvf4jHQBcv9FxHO 1262 r_EVvE5D-XuQC4ROB8ozbZnadQgQxrZYBfxyNfZfnMigeotzlD_q_lsHua3ffXGA 1263 7ZYi02TPPqwKwcoTBy2DdjE1IR0EFcycInNwb87nyxmOVqezOIZNt_2sOJm0I4Ui 1264 kYQCDogUcrwqqcuycXQsdw"}, 1265 { 1266 "Header": { 1267 "kid": "MCAOX-46YPX-GAW5J-75V6G-B6OUP-2RG3X"}, 1268 "encrypted_key": " 1269 KRZ9IfGlNADsgNdIs0L_H-Drs_1FhtRARGP3NdZxF9JfiuN6YDF5tPaJFQ0wfrFV 1270 JKOc5PTe5UWiDPSXy_FFQb6-Cg00uJ5TcQceZoePZqmGYbxYoqQPL2MBCP5g1yvW 1271 xLoGTdqk7pJC8GkGUejMbsv5c2nNR4GT1mpj-E7FXyXD914pwmxwroubdbvTAUYy 1272 QLXAiZ20vXxFzWmdf13QZ31nRNBBorCS1EBcapxfih9H_QCiutukN4Yxoj-Cjy5O 1273 1ogSP0GKJlchiKkypNJ6TgvuR743x7YybDvcPMUk1hMR1GteknI2dGSAADRQupF_ 1274 7huHRXxYODuSgfq0jRf14Q"}]}}} 1276 The application profile is published to the Mesh in the same way as 1277 any other profile update, via a a Publish transaction: 1279 { 1280 "PublishRequest": { 1281 "Entry": { 1282 "SignedApplicationProfile": { 1283 "Identifier": "MCSJQ-ENQ6L-IJZH5-MCLCC-SE2NG-3T5F2-A", 1284 "SignedData": { 1285 "header": " 1286 ewogICJhbGciOiAiUlM1MTIiLAogICJraWQiOiAiTUJLTUctNlFWNUstNVBTWEYt 1287 NlRMVVAtWFhMUkItRkVNVlQifQ", 1288 "payload": " 1289 ewogICJQYXNzd29yZFByb2ZpbGUiOiB7CiAgICAiSWRlbnRpZmllciI6ICJNQ1NK 1290 US1FTlE2TC1JSlpINS1NQ0xDQy1TRTJORy0zVDVGMi1BIiwKICAgICJFbmNyeXB0 1291 ... 1292 MmRHU0FBRFJRdXBGXwo3aHVIUlh4WU9EdVNnZnEwalJmMTRRIn1dfX19", 1293 "signature": " 1294 i4s0nRQj3nA5sWrAzmTrBBqgRJxP7npPYUAjK4ChVBy8GKq64aldCSbeO7fzDO20 1295 4zcgyGnOUKi8AQmSTj8qHdLnGLq9zAXtFoYnHa7N5PevYLATxDNTnauHgewOufyM 1296 XxF4ImepbFZRHcoHhHOWxp-qG7RkptMwqP-3g9-4pAxRUqJWzfWjoxzhy0z0_Tal 1297 21b6I37E-UwwJd271UNkY1b24lHILuMvvgfB1hvzu-O6bDdExIt4iN88jkw7rvQi 1298 7veQA9D-aiAyQmwtasD9uIyKo8GdhLUOrThjQkap8xf3Dfmhd-mt-AmCQjQ_gpvS 1299 iOW-sGdz8x4VjUXDLlwSqQ"}}}}} 1301 The service returns a status response. 1303 { 1304 "PublishResponse": { 1305 "Status": 201, 1306 "StatusDescription": "Operation completed successfully"}} 1308 Note that the degree of verification to be performed by the service 1309 when an application profile is published is an open question. 1311 Having created the application profile, the administration client 1312 adds it to the personal profile and publishes it: 1314 { 1315 "PublishRequest": { 1316 "Entry": { 1317 "SignedPersonalProfile": { 1318 "Identifier": "MDJVA-GWBES-2YXPA-7FHWU-GNTHE-D2ELD", 1319 "SignedData": { 1320 "header": " 1321 ewogICJhbGciOiAiUlM1MTIiLAogICJraWQiOiAiTUJLTUctNlFWNUstNVBTWEYt 1322 NlRMVVAtWFhMUkItRkVNVlQifQ", 1323 "payload": " 1324 ewogICJQZXJzb25hbFByb2ZpbGUiOiB7CiAgICAiSWRlbnRpZmllciI6ICJNREpW 1325 QS1HV0JFUy0yWVhQQS03RkhXVS1HTlRIRS1EMkVMRCIsCiAgICAiU2lnbmVkTWFz 1326 ... 1327 MnlTekRYM3g0UWQteHFOUSJ9fV0sCiAgICAiQXBwbGljYXRpb25zIjogW119fQ", 1328 "signature": " 1329 QK3qK17qqKjrzJpheNMSP8l-Mfids1U8LteXgXtNslyKsN1fsf3Wc3orZRvxkmq3 1330 SiwwkRSY3k1bWGkMQ2-IVGuAVBvDq-ndgrc9zlqx4OGOZHIsUEpMmEMxYCGPWCek 1331 DRmeCg08o-viOXuBGNukjdmoV47AdWjEwp3bim-1RsA4NP5QfdAifesjI37iScUH 1332 HwvraQsPCDmYpoWfzqLiFu-d5OIzf2A6-V73DLw63sxy6POq9XN3uvBVbpeRXD3Z 1333 5zvFp58fprVjpqUqpdiDAecwd47xisxjtN7QNoE1mTuUsjcrz6uWRhe9zkCiAEd1 1334 i02PON8adi7XJD39Fr7TZQ"}}}}} 1336 Note that if the publication was to happen in the reverse order, with 1337 the personal profile being published before the application profile, 1338 the personal profile might be rejected by the portal for 1339 inconsistency as it links to a non existent application profile. 1340 Though the value of such a check is debatable. It might well be 1341 preferable to not make such checks as it permits an application 1342 profile to have a degree of anonymity. 1344 { 1345 "PublishResponse": { 1346 "Status": 201, 1347 "StatusDescription": "Operation completed successfully"}} 1349 8.5. Creating a recovery profile 1351 The Mesh invites users to put all their data eggs in one 1352 cryptographic basket. If the private keys in their master profile 1353 are lost, they could lose all their digital assets. 1355 The debate over the desirability of key escrow is a complex one. Not 1356 least because voluntary key escrow by the user to protect the user's 1357 digital assets is frequently conflated with mechanisms to support 1358 'Lawful Access' through government managed backdoors. 1360 Accidents happen and so do disasters. For most users and most 1361 applications, data loss is a much more important concern than data 1362 disclosure. The option of using a robust key recovery mechanism is 1363 therefore essential for use of strong cryptography is to become 1364 ubiquitous. 1366 There are of course circumstances in which some users may prefer to 1367 risk losing some of their data rather than risk disclosure. Since 1368 any key recovery infrastructure necessarily introduces the risk of 1369 coercion, the choice of whether to use key recovery or not is left to 1370 the user to decide. 1372 The Mesh permits users to escrow their private keys in the Mesh 1373 itself in an OfflineEscrowEntry. Such entries are encrypted using 1374 the strongest degree of encryption available under a symmetric key. 1375 The symmetric key is then in turn split using Shamir secret sharing 1376 using an n of m threshold scheme. 1378 The OfflineEscrowEntry identifier is a UDF fingerprint of the 1379 symmetric key used to encrypt the data. This guarantees that a party 1380 that has the decryption key has the ability to locate the 1381 corresponding Escrow entry. 1383 The OfflineEscrowEntry is published using the usual Publish 1384 transaction: 1386 { 1387 "PublishRequest": { 1388 "Entry": { 1389 "OfflineEscrowEntry": { 1390 "Identifier": "MA2J2-OQI55-PSIGB-LZRY2-KMBCI-HNNNR", 1391 "EncryptedData": { 1392 "protected": " 1393 ewogICJhbGciOiAiQUUxMjgifQ", 1394 "iv": " 1395 gkV_n1ibVtSfrfXAAgha7A", 1396 "ciphertext": " 1397 X7tqES5Qw4mUvpjHayZf-sVKf9WPCyOTWkAG2ZXue2vbMWauYtEBVokXGJv1oQVD 1398 1YqNzMOhcPA619L3k9qiVecNk2Q5lLw2fsYPulml3CMfUw1VOg29NH4uIZbjlCnq 1399 ... 1400 bj3d_6tV34PbzN5s8xinXqrz3_8a1Rr8dEE2tcxZdPoBZdakVphjGmH-Py8kXjgS"}}}}} 1402 The response indicates success or failure: 1404 { 1405 "PublishResponse": { 1406 "Status": 201, 1407 "StatusDescription": "Operation completed successfully"}} 1409 8.6. Recovering a profile 1411 To recover a profile, the user MUST supply the necessary number of 1412 secret shares. These are then used to calculate the UDF fingerprint 1413 to use as the locator in a Get transaction: 1415 { 1416 "GetRequest": { 1417 "Identifier": "MA2J2-OQI55-PSIGB-LZRY2-KMBCI-HNNNR", 1418 "Multiple": false}} 1420 If the transaction succeeds, GetResponse is returned with the 1421 requested data. 1423 { 1424 "GetResponse": { 1425 "Status": 201, 1426 "StatusDescription": "Operation completed successfully", 1427 "Entries": [{ 1428 "OfflineEscrowEntry": { 1429 "Identifier": "MA2J2-OQI55-PSIGB-LZRY2-KMBCI-HNNNR", 1430 "EncryptedData": { 1431 "protected": " 1432 ewogICJhbGciOiAiQUUxMjgifQ", 1433 "iv": " 1434 gkV_n1ibVtSfrfXAAgha7A", 1435 "ciphertext": " 1436 X7tqES5Qw4mUvpjHayZf-sVKf9WPCyOTWkAG2ZXue2vbMWauYtEBVokXGJv1oQVD 1437 1YqNzMOhcPA619L3k9qiVecNk2Q5lLw2fsYPulml3CMfUw1VOg29NH4uIZbjlCnq 1438 ... 1439 bj3d_6tV34PbzN5s8xinXqrz3_8a1Rr8dEE2tcxZdPoBZdakVphjGmH-Py8kXjgS"}}}]}} 1441 The client can now decrypt the OfflineEscrowEntry to recover the 1442 private key(s). 1444 9. Transparent Audit 1446 Can be performed by any party that is a participant in the InterMesh 1447 protocol or subsequently in an offline transaction. 1449 10. Security Considerations 1451 Security Considerations are addressed in the companion document 1452 [draft-hallambaker-mesh-reference] 1454 11. IANA Considerations 1456 IANA Considerations are addressed in the companion document [draft- 1457 hallambaker-mesh-reference] 1459 12. Acknowledgements 1461 Comodo Group: Egemen Tas, Melhi Abdulhayo?lu, Rob Stradling, Robin 1462 Alden. 1464 13. References 1466 13.1. Normative References 1468 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1469 Requirement Levels", BCP 14, RFC 2119, 1470 DOI 10.17487/RFC2119, March 1997. 1472 [RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)", 1473 RFC 3977, DOI 10.17487/RFC3977, October 2006. 1475 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 1476 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1477 2014. 1479 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 1480 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013. 1482 [RFC5822] "[Reference Not Found!]". 1484 [draft-hallambaker-udf] 1485 "[Reference Not Found!]". 1487 [draft-hallambaker-mesh-reference] 1488 "[Reference Not Found!]". 1490 13.2. Informative References 1492 [RFC4644] Vinocur, J. and K. Murchison, "Network News Transfer 1493 Protocol (NNTP) Extension for Streaming Feeds", RFC 4644, 1494 DOI 10.17487/RFC4644, October 2006. 1496 [RFC822] "[Reference Not Found!]". 1498 Author's Address 1500 Phillip Hallam-Baker 1501 Comodo Group Inc. 1503 Email: philliph@comodo.com