idnits 2.17.1 draft-hallambaker-mesh-schema-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (16 January 2020) is 1562 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TBS' is mentioned on line 1039, but not defined == Missing Reference: 'NYI' is mentioned on line 1436, but not defined == Missing Reference: 'UDF-Mesh' is mentioned on line 2133, but not defined -- Obsolete informational reference (is this intentional?): RFC 2426 (Obsoleted by RFC 6350) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. M. Hallam-Baker 3 Internet-Draft 16 January 2020 4 Intended status: Informational 5 Expires: 19 July 2020 7 Mathematical Mesh 3.0 Part IV: Schema Reference 8 draft-hallambaker-mesh-schema-05 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 core protocols of 15 the Mesh are described with examples of common use cases and 16 reference data. 18 [Note to Readers] 20 Discussion of this draft takes place on the MATHMESH mailing list 21 (mathmesh@ietf.org), which is archived at 22 https://mailarchive.ietf.org/arch/search/?email_list=mathmesh. 24 This document is also available online at 25 http://mathmesh.com/Documents/draft-hallambaker-mesh-schema.html. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on 19 July 2020. 44 Copyright Notice 46 Copyright (c) 2020 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 58 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 60 2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 5 61 2.3. Related Specifications . . . . . . . . . . . . . . . . . 5 62 2.4. Implementation Status . . . . . . . . . . . . . . . . . . 6 63 3. Mesh Assertions . . . . . . . . . . . . . . . . . . . . . . . 6 64 3.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 6 65 3.2. Mesh Profiles . . . . . . . . . . . . . . . . . . . . . . 7 66 3.3. Mesh Connections . . . . . . . . . . . . . . . . . . . . 8 67 3.4. Mesh Private Declarations . . . . . . . . . . . . . . . . 8 68 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 8 69 4.1. Device Management . . . . . . . . . . . . . . . . . . . . 9 70 4.1.1. Master Profile . . . . . . . . . . . . . . . . . . . 9 71 4.1.2. Mesh Devices . . . . . . . . . . . . . . . . . . . . 11 72 4.2. Mesh Accounts . . . . . . . . . . . . . . . . . . . . . . 18 73 4.2.1. Creating a ProfileAccount . . . . . . . . . . . . . . 20 74 4.2.2. Connecting a Device to an Account . . . . . . . . . . 20 75 4.2.3. Binding and Account to a Service . . . . . . . . . . 21 76 4.3. Mesh Services . . . . . . . . . . . . . . . . . . . . . . 21 77 4.3.1. Creating a ProfileService . . . . . . . . . . . . . . 22 78 4.3.2. Creating a ProfileHost . . . . . . . . . . . . . . . 23 79 4.3.3. Creating a ConnectionHost . . . . . . . . . . . . . . 23 80 4.4. Mesh Messaging . . . . . . . . . . . . . . . . . . . . . 23 81 4.4.1. Traffic Analysis . . . . . . . . . . . . . . . . . . 24 82 5. Mesh Catalogs . . . . . . . . . . . . . . . . . . . . . . . . 24 83 5.1. Application . . . . . . . . . . . . . . . . . . . . . . . 26 84 5.1.1. Mesh Account . . . . . . . . . . . . . . . . . . . . 26 85 5.1.2. SSH . . . . . . . . . . . . . . . . . . . . . . . . . 26 86 5.1.3. Mail . . . . . . . . . . . . . . . . . . . . . . . . 27 87 5.2. Device . . . . . . . . . . . . . . . . . . . . . . . . . 27 88 5.3. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 27 89 5.4. Credential . . . . . . . . . . . . . . . . . . . . . . . 27 90 5.5. Bookmark . . . . . . . . . . . . . . . . . . . . . . . . 28 91 5.6. Task . . . . . . . . . . . . . . . . . . . . . . . . . . 28 92 5.7. Network . . . . . . . . . . . . . . . . . . . . . . . . . 28 93 6. Mesh Messages . . . . . . . . . . . . . . . . . . . . . . . . 29 94 6.1. Completion . . . . . . . . . . . . . . . . . . . . . . . 29 95 6.2. Connection . . . . . . . . . . . . . . . . . . . . . . . 29 96 6.3. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 30 97 6.4. Confirmation . . . . . . . . . . . . . . . . . . . . . . 31 98 7. Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 99 7.1. Shared Classes . . . . . . . . . . . . . . . . . . . . . 32 100 7.1.1. Classes describing keys . . . . . . . . . . . . . . . 32 101 7.1.2. Structure: PublicKey . . . . . . . . . . . . . . . . 32 102 7.1.3. Structure: KeyComposite . . . . . . . . . . . . . . . 32 103 7.1.4. Structure: DeviceRecryptionKey . . . . . . . . . . . 32 104 7.1.5. Structure: KeyOverlay . . . . . . . . . . . . . . . . 32 105 7.1.6. Structure: EscrowedKeySet . . . . . . . . . . . . . . 32 106 7.2. Assertion classes . . . . . . . . . . . . . . . . . . . . 33 107 7.2.1. Structure: Assertion . . . . . . . . . . . . . . . . 33 108 7.2.2. Structure: Condition . . . . . . . . . . . . . . . . 33 109 7.2.3. Profile Classes . . . . . . . . . . . . . . . . . . . 33 110 7.2.4. Structure: Profile . . . . . . . . . . . . . . . . . 33 111 7.2.5. Structure: ProfileMesh . . . . . . . . . . . . . . . 33 112 7.2.6. Structure: ProfileDevice . . . . . . . . . . . . . . 34 113 7.2.7. Structure: ProfileService . . . . . . . . . . . . . . 34 114 7.2.8. Structure: ProfileAccount . . . . . . . . . . . . . . 34 115 7.2.9. Structure: ProfileGroup . . . . . . . . . . . . . . . 35 116 7.2.10. Structure: ProfileHost . . . . . . . . . . . . . . . 35 117 7.2.11. Connection Classes . . . . . . . . . . . . . . . . . 35 118 7.2.12. Structure: Connection . . . . . . . . . . . . . . . . 35 119 7.2.13. Structure: Permission . . . . . . . . . . . . . . . . 35 120 7.2.14. Structure: ConnectionDevice . . . . . . . . . . . . . 35 121 7.2.15. Structure: ConnectionAccount . . . . . . . . . . . . 36 122 7.2.16. Structure: ConnectionGroup . . . . . . . . . . . . . 36 123 7.2.17. Structure: ConnectionService . . . . . . . . . . . . 36 124 7.2.18. Structure: ConnectionHost . . . . . . . . . . . . . . 36 125 7.2.19. Structure: ConnectionApplication . . . . . . . . . . 37 126 7.2.20. Activation Classes . . . . . . . . . . . . . . . . . 37 127 7.2.21. Structure: Activation . . . . . . . . . . . . . . . . 37 128 7.2.22. Structure: ActivationDevice . . . . . . . . . . . . . 37 129 7.2.23. Structure: ActivationAccount . . . . . . . . . . . . 37 130 7.2.24. Structure: ActivationGroup . . . . . . . . . . . . . 38 131 7.3. Cataloged items . . . . . . . . . . . . . . . . . . . . . 38 132 7.3.1. Data Structures . . . . . . . . . . . . . . . . . . . 38 133 7.3.2. Structure: ContactMesh . . . . . . . . . . . . . . . 38 134 7.3.3. Structure: Contact . . . . . . . . . . . . . . . . . 38 135 7.3.4. Structure: Role . . . . . . . . . . . . . . . . . . . 39 136 7.3.5. Structure: Address . . . . . . . . . . . . . . . . . 39 137 7.3.6. Structure: Location . . . . . . . . . . . . . . . . . 39 138 7.3.7. Structure: Reference . . . . . . . . . . . . . . . . 39 139 7.3.8. Structure: Task . . . . . . . . . . . . . . . . . . . 40 140 7.4. Catalog Entries . . . . . . . . . . . . . . . . . . . . . 40 141 7.4.1. Structure: CatalogedEntry . . . . . . . . . . . . . . 40 142 7.4.2. Structure: CatalogedDevice . . . . . . . . . . . . . 40 143 7.4.3. Structure: AccountEntry . . . . . . . . . . . . . . . 41 144 7.4.4. Structure: CatalogedCredential . . . . . . . . . . . 41 145 7.4.5. Structure: CatalogedNetwork . . . . . . . . . . . . . 41 146 7.4.6. Structure: CatalogedContact . . . . . . . . . . . . . 42 147 7.4.7. Structure: CatalogedContactRecryption . . . . . . . . 42 148 7.4.8. Structure: CatalogedBookmark . . . . . . . . . . . . 42 149 7.4.9. Structure: CatalogedTask . . . . . . . . . . . . . . 42 150 7.4.10. Structure: CatalogedApplication . . . . . . . . . . . 42 151 7.4.11. Structure: CatalogedMember . . . . . . . . . . . . . 43 152 7.4.12. Structure: CatalogedGroup . . . . . . . . . . . . . . 43 153 7.4.13. Structure: CatalogedApplicationSSH . . . . . . . . . 43 154 7.4.14. Structure: CatalogedApplicationMail . . . . . . . . . 43 155 7.4.15. Structure: CatalogedApplicationNetwork . . . . . . . 43 156 7.5. Messages . . . . . . . . . . . . . . . . . . . . . . . . 43 157 7.5.1. Structure: Message . . . . . . . . . . . . . . . . . 43 158 7.5.2. Structure: MessageComplete . . . . . . . . . . . . . 43 159 7.5.3. Structure: MessagePIN . . . . . . . . . . . . . . . . 44 160 7.5.4. Structure: RequestConnection . . . . . . . . . . . . 44 161 7.5.5. Structure: AcknowledgeConnection . . . . . . . . . . 44 162 7.5.6. Structure: OfferGroup . . . . . . . . . . . . . . . . 44 163 7.5.7. Structure: RequestContact . . . . . . . . . . . . . . 45 164 7.5.8. Structure: ReplyContact . . . . . . . . . . . . . . . 45 165 7.5.9. Structure: GroupInvitation . . . . . . . . . . . . . 45 166 7.5.10. Structure: RequestConfirmation . . . . . . . . . . . 45 167 7.5.11. Structure: ResponseConfirmation . . . . . . . . . . . 45 168 7.5.12. Structure: RequestTask . . . . . . . . . . . . . . . 45 169 8. Security Considerations . . . . . . . . . . . . . . . . . . . 46 170 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 171 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 46 172 11. Appendix A: Example Container Organization (not normative) . 46 173 11.1. Device . . . . . . . . . . . . . . . . . . . . . . . . . 46 174 11.1.1. Creating a new Mesh . . . . . . . . . . . . . . . . 46 175 11.1.2. Adding an Account . . . . . . . . . . . . . . . . . 46 176 11.1.3. Adding a Device . . . . . . . . . . . . . . . . . . 47 177 11.2. Service . . . . . . . . . . . . . . . . . . . . . . . . 47 178 11.2.1. Creating a Service . . . . . . . . . . . . . . . . . 47 179 11.2.2. Adding an Account . . . . . . . . . . . . . . . . . 47 180 12. Appendix B: Collected Authentication and Encryption 181 Requirements . . . . . . . . . . . . . . . . . . . . . . . . 47 182 12.1. Mesh Messaging . . . . . . . . . . . . . . . . . . . . . 47 183 13. Normative References . . . . . . . . . . . . . . . . . . . . 48 184 14. Informative References . . . . . . . . . . . . . . . . . . . 49 186 1. Introduction 188 This document describes the data structures of the Mathematical Mesh 189 with illustrative examples. For an overview of the Mesh objectives 190 and architecture, consult the accompanying _Architecture Guide_ 191 [draft-hallambaker-mesh-architecture]. For information on the 192 implementation of the Mesh Service protocol, consult the accompanying 193 _Protocol Reference_ [draft-hallambaker-mesh-protocol] 195 This document has two main sections. The first section presents 196 examples of the Mesh assertions, catalog entry and messages in use. 197 The second section contains the schema reference. All the material 198 in both sections is generated from the Mesh reference implementation 199 [draft-hallambaker-mesh-developer]. 201 Although some of the services described in this document could be 202 used to replace existing Internet protocols including FTP and SMTP, 203 the principal value of any communication protocol lies in the size of 204 the audience it allows them to communicate with. Thus, while the 205 Mesh Messaging service is designed to support efficient and reliable 206 transfer of messages ranging in size from a few bytes to multiple 207 terabytes, the near-term applications of these services will be to 208 applications that are not adequately supported by existing protocols 209 if at all. 211 2. Definitions 213 This section presents the related specifications and standard, the 214 terms that are used as terms of art within the documents and the 215 terms used as requirements language. 217 2.1. Requirements Language 219 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 220 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 221 document are to be interpreted as described in [RFC2119]. 223 2.2. Defined Terms 225 The terms of art used in this document are described in the _Mesh 226 Architecture Guide_ [draft-hallambaker-mesh-architecture]. 228 2.3. Related Specifications 230 The architecture of the Mathematical Mesh is described in the _Mesh 231 Architecture Guide_ [draft-hallambaker-mesh-architecture]. The Mesh 232 documentation set and related specifications are described in this 233 document. 235 2.4. Implementation Status 237 The implementation status of the reference code base is described in 238 the companion document [draft-hallambaker-mesh-developer]. 240 3. Mesh Assertions 242 Mesh Assertions are signed DARE Envelopes that contain one of more 243 claims. Mesh Assertions provide the basis for trust in the 244 Mathematical Mesh. 246 Mesh Assertions are divided into two classes. Mesh Profiles are 247 self-signed assertions. Assertions that are not self-signed are 248 called declarations. The only type of declaration currently defined 249 is a Connection Declaration describing the connection of one profile 250 to another. Currently, five profile and four connection types are 251 defined: 253 (Artwork only available as svg: No external link available, see 254 draft-hallambaker-mesh-schema-05.html for artwork.) 256 Figure 1 258 3.1. Encoding 260 The payload of a Mesh Assertion is a JSON encoded object that is a 261 subclass of the Assertion class which defines the following fields: 263 Identifier An identifier for the assertion. 265 Updated The date and time at which the assertion was issued or last 266 updated 268 NotaryToken An assertion may optionally contain one or more notary 269 tokens issued by a Mesh Notary service. These establish a proof 270 that the assertion was signed after the date the notary token was 271 created. 273 Conditions A list of conditions that MAY be used to verify the 274 status of the assertion if the relying party requires. 276 The implementation of the NotaryToken and Conditions mechanisms is to 277 be specified in [draft-hallambaker-mesh-notary] at a future date. 279 Note that the implementation of Conditions differs significantly from 280 that of SAML. Relying parties are required to process condition 281 clauses in a SAML assertion to determine validity. Mesh Relying 282 parties MAY verify the conditions clauses or rely on the 283 trustworthiness of the provider. 285 The reason for weakening the processing of conditions clauses in the 286 Mesh is that it is only ever possible to validate a conditions clause 287 of any type relative to a ground truth. In SAML applications, the 288 relying party almost invariably has access to an independent source 289 of ground truth. A Mesh device connected to a Mesh Service does not. 290 Thus the types of verification that can be achieved in practice are 291 limited to verifying the consistency of current and previous 292 statements from the Mesh Service. 294 3.2. Mesh Profiles 296 Mesh Profiles perform a similar role to X.509v3 certificates but with 297 important differences: 299 * Profiles describe credentials, they do not make identity 300 statements 302 * Profiles do not expire, there is therefore no need to support 303 renewal processing. 305 * Profiles may be modified over time, the current and past status of 306 a profile being recorded in an append only log. 308 Profiles provide the axioms of trust for the Mesh PKI. Unlike in the 309 PKIX model in which all trust flows from axioms of trust held by a 310 small number of Certificate Authorities, every part in the Mesh 311 contributes their own axiom of trust. 313 It should be noted however that the role of Certificate Authorities 314 is redefined rather than eliminated. Rather than making assertions 315 whose subject is represented by identities which are inherently 316 mutable and subjective, Certificate Authorities can now make 317 assertions about immutable cryptographic keys. 319 Every Profile MUST contain a "SignatureKey" field and MUST be signed 320 by the key specified in that field. 322 A Profile is valid if and only if: 324 * There is a "SignatureKey" field. 326 * The profile is signed under the key specified in the 327 "SignatureKey" field. 329 A profile has the status "current" if and only if: 331 * The Profile is valid 333 * Every Conditions clause in the profile is understood by the 334 relying party and evaluates to "true". 336 3.3. Mesh Connections 338 3.4. Mesh Private Declarations 340 4. Architecture 342 The Mesh architecture has four principal components: 344 Mesh Device Management Binds a collection of devices that the owner 345 of the Mesh uses together to function as a single personal Mesh. 347 Mesh Account Contains all the information (contacts, calendar 348 entries, inbound and outbound messages, etc.) related to a 349 particular persona used by the owner. 351 Mesh Service Provides a service identifier (e.g. 352 "alice@example.com") through which devices and other Mesh users 353 may interact with a Mesh Account. 355 Mesh Messaging 357 Allows short messages (less than 32KB) to be exchanged between Mesh 358 devices connected to an account and between Mesh Accounts. 360 Device management and Accounts components are defined by a data 361 schema alone. The Service and Messaging components are defined by a 362 data schema and a service protocol. 364 The separation of accounts and services as separate components is a 365 key distinction between the Mesh and earlier Internet applications. 366 A Mesh account belongs to the owner of the Mesh and not the account 367 service provider which the user may change at any time of their 368 choosing. A Mesh account may be connected to multiple service 369 providers to provide backup capability or to none. 371 For example, Alice's personal Mesh has one Master Profile, multiple 372 device profiles (two of which are shown here) and two Account 373 Profiles. Her Personal account is connected to two Mesh services 374 while her Business account is not currently connected to any service: 376 (Artwork only available as svg: No external link available, see 377 draft-hallambaker-mesh-schema-05.html for artwork.) 378 Figure 2 380 In normal circumstances, a user will create a personal Mesh and add 381 their first device, account and service at once. These are shown 382 here as separate operations to illustrate the separation of the Mesh 383 components. 385 4.1. Device Management 387 Device Management provides the foundation for all Mesh functions 388 allowing a collection of devices belonging to a user to function as a 389 single personal Mesh. 391 The device management layer of a personal Mesh consists of exactly 392 one Master Profile and a catalog containing the entries describing 393 the connected devices. 395 4.1.1. Master Profile 397 A Mesh master profile provides the axiom of trust for a mesh user. 398 It contains a Master Signature Key and one or more Administration 399 Signature Keys. The unique identifier of the master profile is the 400 UDF of the Master Signature Key. 402 A Master Profile MAY contain one or more "MasterEscrowKeys". These 403 MAY be used to escrow private keys used for encryption. They SHOULD 404 NOT be used to escrow authentication keys and MUST NOT be used to 405 escrow signature keys. 407 (Artwork only available as svg: No external link available, see 408 draft-hallambaker-mesh-schema-05.html for artwork.) 410 Figure 3 412 A user should not need to replace their master profile unless they 413 intend to establish a separate identity. To minimize the risk of 414 disclosure, the Master Signature Key is only ever used to sign 415 updates to the master profile itself. This allows the user to secure 416 their Master Signature Key by either keeping it on hardware token or 417 device dedicated to that purpose or by using the escrow mechanism and 418 paper recovery keys as described in this document. 420 Alice creates a ProfileMaster with one administration key and one 421 master escrow key: 423 { 424 "ProfileMesh":{ 425 "KeyOfflineSignature":{ 426 "UDF":"MCSC-2POG-PH7T-ODJX-HOCA-B4XY-AFSK", 427 "PublicParameters":{ 428 "PublicKeyECDH":{ 429 "crv":"Ed448", 430 "Public":"AqOm-eLsUPySPkemMvVIJctXUSTa6EC5c_w0kLHZCh4xLlF 431 ow4SJzsDj2xSX5ofUl1XcuCBj9qaA"}}}, 432 "KeysOnlineSignature":[{ 433 "UDF":"MDI7-LMMT-LTJE-6C5Z-AFZN-6OXW-YLW3", 434 "PublicParameters":{ 435 "PublicKeyECDH":{ 436 "crv":"Ed448", 437 "Public":"tQhM2lUiBnKgk9PASigebdZH18nDC4qFSZIJgmwTPYrpd 438 AKsSnuZPH7UPu3AtYjFF8aGMyyF8UuA"}}} 439 ], 440 "KeyEncryption":{ 441 "UDF":"MATS-37J5-26DG-MYUR-7BMU-PPJJ-UUO4", 442 "PublicParameters":{ 443 "PublicKeyECDH":{ 444 "crv":"Ed448", 445 "Public":"SUJNzpDLHT9dxOyYdzfuhPL0mkR1tw-JTjuIVgU7X-bFqi2 446 z66efQv1cwSeVL-oZn2COpIHN-lKA"}}}}} 448 4.1.1.1. Creating a ProfileMaster 450 Creating a "ProfileMaster" comprises the steps of: 452 0. Creating a Master Signature key. 454 1. Creating an Online Signing Key 456 2. Signing the "ProfileMaster" using the Master Signature Key 458 3. Persisting the "ProfileMaster" on the administration device to 459 the "CatalogHost". 461 4. (Optional) Connecting at least one Administration Device and 462 granting it the "ActivationAdministration" activation. 464 4.1.1.2. Updating a ProfileMaster 466 Updating a "ProfileMaster" comprises the steps of: 468 0. Making the necessary changes. 470 1. Signing the ProfileMaster using the Master Signature Key 471 2. Persisting the ProfileMaster on the administration device to the 472 CatalogHost. 474 4.1.1.3. The Device Catalog 476 Each personal Mesh has a Device Catalog "CatalogDevice" associated 477 with it. The Device Catalog is used to manage the connection of 478 devices to the Personal Mesh and has a "CatalogEntryDevice" for each 479 device currently connected to the catalog. 481 Each Administration Device MUST have access to an up to date copy of 482 the Device Catalog in order to manage the devices connected to the 483 Mesh. The Mesh Service protocol MAY be used to synchronize the 484 Device Catalog between administration devices in the case that there 485 is more than one administration device. 487 The "CatalogEntryDevice" contains fields for the device profile, 488 device private and device connection. 490 4.1.2. Mesh Devices 492 The principle of radical distrust requires us to consider the 493 possibility that a device might be compromised during manufacture. 494 Once consequence of this possibility is that when an administration 495 device connects a new device to a user's personal Mesh, we cannot put 496 our full trust in either the device being connected or the 497 administration device connecting it. 499 This concern is resolved by (at minimum) combining keying material 500 generated from both sources to create the keys to be used in the 501 context of the user's personal Mesh with the process being fully 502 verified by both parties. 504 Additional keying material sources could be added if protection 505 against the possibility of compromise at both devices was required 506 but this is not supported by the current specifications. 508 A device profile provides the axiom of trust and the key 509 contributions of the device: 511 (Artwork only available as svg: No external link available, see 512 draft-hallambaker-mesh-schema-05.html for artwork.) 514 Figure 4 516 Unless exceptional circumstances require, a device should not require 517 more than one Device profile even if the device supports use by 518 multiple users under different accounts. But a device MAY have 519 multiple profiles if this approach is more convenient for 520 implementation. 522 Alice's Device Profile specifies keys for encryption, signature and 523 exchange: 525 { 526 "ProfileDevice":{ 527 "KeyOfflineSignature":{ 528 "UDF":"MCYS-TOQJ-CDAX-EDU7-6EZ3-OLPG-KMLG", 529 "PublicParameters":{ 530 "PublicKeyECDH":{ 531 "crv":"Ed448", 532 "Public":"m54L_jENmDdwE9vFeDZgBuJHbV3HTZxWr6Ep-tVdQhudcpw 533 25rOBvp6l5OhKbNUfoKRWFKTS93qA"}}}, 534 "KeyEncryption":{ 535 "UDF":"MCZP-AMNO-JHWY-ZQ22-N3ZP-V2KW-52JE", 536 "PublicParameters":{ 537 "PublicKeyECDH":{ 538 "crv":"Ed448", 539 "Public":"W-E1XmOgjze4ozrhkkft5nV_Zcr90En9vT6WswBe3VBCrxW 540 RKGI48Ud9EWSDlJfEqQWRbhMyZp0A"}}}, 541 "KeyAuthentication":{ 542 "UDF":"MDYO-XAHJ-RXT6-YO4J-X7WV-L3IW-5NEP", 543 "PublicParameters":{ 544 "PublicKeyECDH":{ 545 "crv":"Ed448", 546 "Public":"OlJMs9_Dcm7XuFzvbypI5WC3xLLgPOjohsg5dkqA61gCfsF 547 9J4syqcZnOFrAsk-pFWFDm0DESoAA"}}}}} 549 Since the Device Profile keys are ultimately under the control of the 550 device and/or software provider, these are considered insufficiently 551 trustworthy and the administration device creates key contributions 552 to be added to the device keys to establish the key set to be used in 553 the context of the user's personal Mesh: 555 $$$$ Empty $$$$ 557 The resulting key set is specified in the device connection: 559 { 560 "ConnectionDevice":{ 561 "KeySignature":{ 562 "UDF":"MBPL-MIIT-KOHN-FC6P-6V5Y-ZQ4R-3NKY", 563 "PublicParameters":{ 564 "PublicKeyECDH":{ 565 "crv":"Ed448", 566 "Public":"D-g5vilsBjZ_6BKRG9O3cl30IrN3hCGNzVO_C6YT5OkOkVC 567 IO47FRho9xdoJ8zCcH938WlTDBLeA"}}}, 568 "KeyEncryption":{ 569 "UDF":"MBLY-KNQG-YT6V-ENLJ-KMIT-MRYT-YOHQ", 570 "PublicParameters":{ 571 "PublicKeyECDH":{ 572 "crv":"Ed448", 573 "Public":"aEe3u24gwMh-ygY0HqjVbBxzFEYJyPVhB_h1-Ma3F_nz6Ae 574 vA0fSMaJKprA-qv-JpHSsMCbA74iA"}}}, 575 "KeyAuthentication":{ 576 "UDF":"MDVV-QJE7-UYR4-24TQ-JK54-QDTU-BZF3", 577 "PublicParameters":{ 578 "PublicKeyECDH":{ 579 "crv":"Ed448", 580 "Public":"kV_ODrLu4jWdT0hJibnEcujjxu-E4ofRlI7o2eyy3eSbGaA 581 EES0KYv5N8BaawmWP67athBZZDjeA"}}}}} 583 All the above are combined to form the CatalogedDevice entry: 585 { 586 "CatalogedDevice":{ 587 "UDF":"MBPL-MIIT-KOHN-FC6P-6V5Y-ZQ4R-3NKY", 588 "DeviceUDF":"MCYS-TOQJ-CDAX-EDU7-6EZ3-OLPG-KMLG", 589 "EnvelopedProfileDevice":[{ 590 "dig":"SHA2"}, 591 "ewogICJQcm9maWxlRGV2aWNlIjogewogICAgIktleU9mZmxpbmVTaWduYXR1 592 cmUiOiB7CiAgICAgICJVREYiOiAiTUNZUy1UT1FKLUNEQVgtRURVNy02RVozLU9MU 593 EctS01MRyIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdW 594 JsaWNLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6ICJFZDQ0OCIsCiAgICAgICA 595 gICAiUHVibGljIjogIm01NExfakVObURkd0U5dkZlRFpnQnVKSGJWM0hUWnhXcjZF 596 cC10VmRRaHVkY3B3MjVyT0IKICB2cDZsNU9oS2JOVWZvS1JXRktUUzkzcUEifX19L 597 AogICAgIktleUVuY3J5cHRpb24iOiB7CiAgICAgICJVREYiOiAiTUNaUC1BTU5PLU 598 pIV1ktWlEyMi1OM1pQLVYyS1ctNTJKRSIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJ 599 zIjogewogICAgICAgICJQdWJsaWNLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6 600 ICJFZDQ0OCIsCiAgICAgICAgICAiUHVibGljIjogIlctRTFYbU9nanplNG96cmhra 601 2Z0NW5WX1pjcjkwRW45dlQ2V3N3QmUzVkJDcnhXUktHSTQKICA4VWQ5RVdTRGxKZk 602 VxUVdSYmhNeVpwMEEifX19LAogICAgIktleUF1dGhlbnRpY2F0aW9uIjogewogICA 603 gICAiVURGIjogIk1EWU8tWEFISi1SWFQ2LVlPNEotWDdXVi1MM0lXLTVORVAiLAog 604 ICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgICAiUHVibGljS2V5RUNES 605 CI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICAgICAgIlB1YmxpYy 606 I6ICJPbEpNczlfRGNtN1h1Rnp2YnlwSTVXQzN4TExnUE9qb2hzZzVka3FBNjFnQ2Z 607 zRjlKNHN5CiAgcWNabk9GckFzay1wRldGRG0wREVTb0FBIn19fX19", 608 { 609 "signatures":[{ 610 "alg":"SHA2", 611 "kid":"MCYS-TOQJ-CDAX-EDU7-6EZ3-OLPG-KMLG", 612 "signature":"9uexE_-IFBMWisUSR9xLXgJskkYDoYnbXVONBUR0NV 613 P5vC5_N2-m4uXUkpN1ClBKcDPhQmX0tk0AjY-xZhrTpdB9GjQmiBSyCGsl5I0VBAh 614 y9ogTegiNXyYznYw6cukAHrcRH7_h2dFsv2_WFT8OWTEA"} 615 ], 616 "PayloadDigest":"Eo6k0vBBU9dfLJA0MTEt87qdGpzCMJi4PEFOxE9w5a 617 2AaC3izRZYoobWz0fJ5vjwLEfte-_ggv9wKc8GcITekw"} 618 ], 619 "EnvelopedConnectionDevice":[{ 620 "dig":"SHA2"}, 621 "ewogICJDb25uZWN0aW9uRGV2aWNlIjogewogICAgIktleVNpZ25hdHVyZSI6 622 IHsKICAgICAgIlVERiI6ICJNQlBMLU1JSVQtS09ITi1GQzZQLTZWNVktWlE0Ui0zT 623 ktZIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0 624 tleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIkVkNDQ4IiwKICAgICAgICAgICJ 625 QdWJsaWMiOiAiRC1nNXZpbHNCalpfNkJLUkc5TzNjbDMwSXJOM2hDR056Vk9fQzZZ 626 VDVPa09rVkNJTzQ3RgogIFJobzl4ZG9KOHpDY0g5MzhXbFREQkxlQSJ9fX0sCiAgI 627 CAiS2V5RW5jcnlwdGlvbiI6IHsKICAgICAgIlVERiI6ICJNQkxZLUtOUUctWVQ2Vi 628 1FTkxKLUtNSVQtTVJZVC1ZT0hRIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB 629 7CiAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIkVk 630 NDQ4IiwKICAgICAgICAgICJQdWJsaWMiOiAiYUVlM3UyNGd3TWgteWdZMEhxalZiQ 631 nh6RkVZSnlQVmhCX2gxLU1hM0Zfbno2QWV2QTBmUwogIE1hSktwckEtcXYtSnBIU3 632 NNQ2JBNzRpQSJ9fX0sCiAgICAiS2V5QXV0aGVudGljYXRpb24iOiB7CiAgICAgICJ 633 VREYiOiAiTURWVi1RSkU3LVVZUjQtMjRUUS1KSzU0LVFEVFUtQlpGMyIsCiAgICAg 634 ICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdWJsaWNLZXlFQ0RIIjoge 635 wogICAgICAgICAgImNydiI6ICJFZDQ0OCIsCiAgICAgICAgICAiUHVibGljIjogIm 636 tWX09Eckx1NGpXZFQwaEppYm5FY3Vqanh1LUU0b2ZSbEk3bzJleXkzZVNiR2FBRUV 637 TMEsKICBZdjVOOEJhYXdtV1A2N2F0aEJaWkRqZUEifX19fX0", 638 { 639 "signatures":[{ 640 "alg":"SHA2", 641 "kid":"MDI7-LMMT-LTJE-6C5Z-AFZN-6OXW-YLW3", 642 "signature":"R51-7cQTb4f2nK69t77YamP7ny0i9TOw0CdXl0X3dp 643 vgSiZ2I1OWbxncJqqkOpj7AW5e7uiOBumAc0j3tiWXSwKIQZAtoUsGvcYFY2Yq11K 644 OHC9kMS4ea2Hcu0IMd8tpoIglnJC38ajl_pFBCbrJVAAA"} 645 ], 646 "PayloadDigest":"Td9sSenLRJHoZ0YtbwztmpadlzOv2AVb9JtOCgnuiX 647 X1xwkuJ5KYAAlOoSusI6pyT1iM6TtYYh0hpCSEooizgg"} 648 ], 649 "EnvelopedActivationDevice":[{ 650 "enc":"A256CBC", 651 "Salt":"Wv42VzJRlBdLKIqwODqHYg", 652 "recipients":[{ 653 "kid":"MCZP-AMNO-JHWY-ZQ22-N3ZP-V2KW-52JE", 654 "epk":{ 655 "PublicKeyECDH":{ 656 "crv":"Ed448", 657 "Public":"80ofnf812P3naGy_KG6a1IUAdQKcZ9fF5TKZ8q8yR 658 ZsWn870qm1QKgXYxOz82RpWKEqGHGdWEYcA"}}, 659 "wmk":"_-0e3rNNbEIvH8zjSe1tBz84FEg71dzdhHJnfQvbteecigqM 660 sZaFZA"}, 661 { 662 "kid":"MATS-37J5-26DG-MYUR-7BMU-PPJJ-UUO4", 663 "epk":{ 664 "PublicKeyECDH":{ 665 "crv":"Ed448", 666 "Public":"Y64tNqhJuEREoAm3pFqXSQqBdbmN7qPhmnKKmwOWh 667 VnVxVvBuRFjAwM6HuVpgLa53kK3Ucl7uCsA"}}, 668 "wmk":"G3nEbaXRHIgdaXcx-DyKXuOA1QXKG-coa4q3urbu6L4bti4c 669 uI5_og"} 670 ], 671 "ContentMetaData":"ewogICJjdHkiOiAiYXBwbGljYXRpb24vbW1tIn0"}, 672 "xq7fBwbgcYBrqZgcleQhT92CfS5uLMEO2xAbhr2c4clU0i6tX67Z-sx5opqd 673 MrSDHGuaDUShWce9JhSwBomvs_8un_0V9vhqwV5gSP_fTsvSU2nnCBT0ziEk19B5z 674 57AsGwAWL9lTa9kX3M6AfF92UIog4vZGTHrJ_m1yLJc_etVBAeL4GF_M9_LSZ4zjf 675 eZZGSwOBwQKGSWGqCfEdWRec0OZ_q4WUg3Fh6NyrdG8kaUwkF3EYgfBhN2OyLQ7oH 676 ybuQs-J2w_m_ev79C-o0eUYz8TJQTLeYpQb3cFmXkD71BLqBn0nWBp4BeR73UMWoo 677 Nv1OkyHw9HXmreaDeCOeWWqZsfNqE47xvNX1DWbwlxBYMJLqoz3y_XUSTaQFJqa1s 678 uX_c7ZhtbXDVEWyDFBOayf64r68LDbAI-1yVEpcBF8h9XwBvZnGXyC5iUzFGCL0WY 679 MlH1oC8JU8rG3kp12pDhaGR0V8OHJ6C_AL1mk2Wm39XqZFOTjIy7KJM69EN-U4MNx 680 -ph8Pil78inOTcfUCNffepP5XGbeNO0pse1Og35eiGnZFLf9yRB_iZtQwJmMsEZ0p 681 sW8qXp7vnYd2Qk5vwAmizYqRZ7oViTVotGHHgvNRTliuJgmTGHRlYYUxlsH3lUxDv 682 5UHJzSBKiXK5g4a3Vf5I10qaFLi2V0Gh3P-MkEXyvrcRGZVkix8K6mLYIVzZueskl 683 hJ28M-WlattxnV4Kdjd_0Q85HZLoKlsJryf7VUDBzfrtpoCKH19r2BWBLCC-HlsTx 684 NN0CArNk_Lt7FXxuAuKnB0jAPOmZhjbP2W13gP6B3IsTZQon9EGgEEWLwThyGZmh3 685 DwTQscUUc0tz5Gu5KywANKqXpjbhrPS-vRPogByOLAa2u_gzeCuSq6RqTva0-dCgb 686 gFMkqZic25BqO9BpmTmnLKTOumhGhKA2r2aNfhMeQp12wpH3zLfNsYHwTUwQj--KJ 687 CRgRlYt6lVBs-9U8BEgcWI_bThDod3d-CNuU7A0IveifojNeUScA9UniJPjympL1P 688 Q953B46-nb8Y7LodudjuEbbmJxcTzlg6Rao66oMo0rGDeEyxb0RaYPQ41gKqAi1MM 689 bBc80flGgxdlN4nGPYXtyQBCZQJ0Rlk-1nWujdf6LoCBg_-dpteR54N9o_Mc-aNsP 690 i_FpdSVrGweQp6HpoQuwpXOncHyMG257iCxZN0Fev-nviLkXn8JA_iJ72vvJzHZMH 691 J33XOhFlbvwDIN5g4Drn448i0t9u_G5n--3kN9nt916fUFM6tq" 692 ], 693 "Accounts":[{ 694 "AccountUDF":"MC23-X3CT-EUNB-DR3M-QIBI-W2IJ-ATEP", 695 "EnvelopedProfileAccount":[{ 696 "dig":"SHA2"}, 697 "ewogICJQcm9maWxlQWNjb3VudCI6IHsKICAgICJLZXlPZmZsaW5lU2ln 698 bmF0dXJlIjogewogICAgICAiVURGIjogIk1DMjMtWDNDVC1FVU5CLURSM00tUUlCS 699 S1XMklKLUFURVAiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgIC 700 AiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICA 701 gICAgICAgIlB1YmxpYyI6ICI5dXBQMWlhazMwX0pyRzFwZVl3aGtUMDBEcHc4SjBq 702 d0dRQTBuZWhuQlZQdU9hRzloNlNzCiAgRmUwRGV6MmIzYVFwbGRBR1VLb1VCZENBI 703 n19fSwKICAgICJLZXlzT25saW5lU2lnbmF0dXJlIjogW3sKICAgICAgICAiVURGIj 704 ogIk1DUlItSkZMWi1UMkpILUlOR0QtU0JZRi1OTzZYLTU1Uk4iLAogICAgICAgICJ 705 QdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7 706 CiAgICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICAgICAgICAiUHVibGljI 707 jogIkZfTUpmMHc4ZFVIaVBZeTk3WEtRbXBmRlZMbk5uZHNqUUg1cDFjM3ozSGxucV 708 RhMmE3YkUKICBVQ09veGE0SEFpc2Y5QnFueEpFZE9tZ0EifX19XSwKICAgICJNZXN 709 oUHJvZmlsZVVERiI6ICJNQ1NDLTJQT0ctUEg3VC1PREpYLUhPQ0EtQjRYWS1BRlNL 710 IiwKICAgICJLZXlFbmNyeXB0aW9uIjogewogICAgICAiVURGIjogIk1CV1ktSUlLW 711 S1WT0I1LUJYSVAtRElYWC1SNFRILVpJRjIiLAogICAgICAiUHVibGljUGFyYW1ldG 712 VycyI6IHsKICAgICAgICAiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnY 713 iOiAiRWQ0NDgiLAogICAgICAgICAgIlB1YmxpYyI6ICJzd3BlNkg1eWlVNHZKb3Ri 714 b1hiRnd3SUVwX2xYTy1rYm05emo5UE9GTEx3ZnFlNkJVTXN1CiAgOUZCQ0w2R0hwO 715 TN3Y21MTTI3dEdSbjRBIn19fX19", 716 { 717 "signatures":[{ 718 "alg":"SHA2", 719 "kid":"MC23-X3CT-EUNB-DR3M-QIBI-W2IJ-ATEP", 720 "signature":"xBUh419PqcBn2XAGToSaPRxDiUJSEABsZubx-z 721 OaEqZsotZceYNIj6h2axaL0ZsJAwO3vPNCgCOAbX6LLqeJk4qheJ5FLmZ53_T66gD 722 PqaTIE0NhFp8ulQuDE0aAvU0eH7vPV1HhqUMaQMc-lZGPQCUA"} 723 ], 724 "PayloadDigest":"aXMNPb2KrzIznCZVP28IrDLCOsVirh1Oy_VRZc 725 sqX0Y3JMuCTXOJ8BpIMc_bjer2T8a4m0e5SzYoRe4S-gXP6w"} 726 ], 727 "EnvelopedConnectionAccount":[{ 728 "dig":"SHA2"}, 729 "ewogICJDb25uZWN0aW9uQWNjb3VudCI6IHsKICAgICJTdWJqZWN0VURG 730 IjogIk1DWkwtTVFPQS1YTFlVLVJMUFctVlJSSC02VUZELUtESUUiLAogICAgIkF1d 731 Ghvcml0eVVERiI6ICJNQzIzLVgzQ1QtRVVOQi1EUjNNLVFJQkktVzJJSi1BVEVQIi 732 wKICAgICJLZXlTaWduYXR1cmUiOiB7CiAgICAgICJVREYiOiAiTUNaTC1NUU9BLVh 733 MWVUtUkxQVy1WUlJILTZVRkQtS0RJRSIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJz 734 IjogewogICAgICAgICJQdWJsaWNLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6I 735 CJFZDQ0OCIsCiAgICAgICAgICAiUHVibGljIjogImFDdnlmT2d1YVlBRm5XeTlfNX 736 JYdy1rY0U0NWtNWGsyWGRtMkt0VWVWSjhnVkpTakQwZHIKICBMUzZpQ3J4SFBWdUl 737 hb0lGNW84UWhnVUEifX19LAogICAgIktleUF1dGhlbnRpY2F0aW9uIjogewogICAg 738 ICAiVURGIjogIk1DTDQtS1JCNC1QTVROLTNDTEktVVBGWi1NVjJaLTZUVUciLAogI 739 CAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgICAiUHVibGljS2V5RUNESC 740 I6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICAgICAgIlB1YmxpYyI 741 6ICJpR0Y0X19vRk9PWVotVm5QZHFoQlZ4bEVpTEF4UllQRnNRLVlxclVJdTVlbXlF 742 cjRXUlBMCiAgLTl6M2VMMmQ5SXgwSm9raUI3RUYyRm9BIn19fX19", 743 { 744 "signatures":[{ 745 "alg":"SHA2", 746 "kid":"MCRR-JFLZ-T2JH-INGD-SBYF-NO6X-55RN", 747 "signature":"DXZyUQa06ki6HuDtd7ooofkLlX6_d341Gq0YD8 748 3sLOVFcKwP-C12JWOBRcp_iVdd_tlx94nkrqWAH9ZI6__XrfavdqFWbrkl9kLCQi5 749 mpisnx9zxOTZ_0a_kE7KAnjl7SoSV5G7Z9MqlWhZ1OVCmyR0A"} 750 ], 752 "PayloadDigest":"eKZx9Y5JQGXuaXE1o1BfwSqeDRX0h4VYUWZZIT 753 _wFfh391cZxAp3x5GSiex1vMw4oy_I1oKLC7QdKxthACTz2Q"} 754 ], 755 "EnvelopedActivationAccount":[{ 756 "dig":"SHA2"}, 757 "ewogICJBY3RpdmF0aW9uQWNjb3VudCI6IHsKICAgICJBY2NvdW50VURG 758 IjogIk1DMjMtWDNDVC1FVU5CLURSM00tUUlCSS1XMklKLUFURVAiLAogICAgIktle 759 UVuY3J5cHRpb24iOiB7CiAgICAgICJVREYiOiAiTUNDQS00WTM3LU5SR0wtQkVKUy 760 1ENDdaLTRQSVotVlNDTiIsCiAgICAgICJCYXNlVURGIjogIk1DWlAtQU1OTy1KSFd 761 ZLVpRMjItTjNaUC1WMktXLTUySkUiLAogICAgICAiT3ZlcmxheSI6IHsKICAgICAg 762 ICAiUHJpdmF0ZUtleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIkVkNDQ4IiwKI 763 CAgICAgICAgICJQcml2YXRlIjogIkozX0cyYkxmcjhkRkRaSDRnYjNQc0dwVTE0T0 764 VjMmJib3YtdDFJOTR4WDJaQmVOWGN6TQogIFFDdGVYWDNsNnNrQm1TejA0S2VKd2p 765 hVSJ9fX0sCiAgICAiS2V5QXV0aGVudGljYXRpb24iOiB7CiAgICAgICJVREYiOiAi 766 TUNMNC1LUkI0LVBNVE4tM0NMSS1VUEZaLU1WMlotNlRVRyIsCiAgICAgICJCYXNlV 767 URGIjogIk1EWU8tWEFISi1SWFQ2LVlPNEotWDdXVi1MM0lXLTVORVAiLAogICAgIC 768 AiT3ZlcmxheSI6IHsKICAgICAgICAiUHJpdmF0ZUtleUVDREgiOiB7CiAgICAgICA 769 gICAiY3J2IjogIkVkNDQ4IiwKICAgICAgICAgICJQcml2YXRlIjogIk9OUE5BMlVu 770 SXNEYnljcGl4YXkzZ3JGenh5T241dmk4bTNnV1lxUGFsVG9YRHljUlQ2UwogIFRNN 771 XZETjZXR0M3VC1ncDNhbnZWT3VGayJ9fX0sCiAgICAiS2V5U2lnbmF0dXJlIjogew 772 ogICAgICAiVURGIjogIk1DWkwtTVFPQS1YTFlVLVJMUFctVlJSSC02VUZELUtESUU 773 iLAogICAgICAiQmFzZVVERiI6ICJNQ1lTLVRPUUotQ0RBWC1FRFU3LTZFWjMtT0xQ 774 Ry1LTUxHIiwKICAgICAgIk92ZXJsYXkiOiB7CiAgICAgICAgIlByaXZhdGVLZXlFQ 775 0RIIjogewogICAgICAgICAgImNydiI6ICJFZDQ0OCIsCiAgICAgICAgICAiUHJpdm 776 F0ZSI6ICJPZ0pSOEJZWXpKTGNqRVJrVzVYY2x0OUsyWUhhaHVVZzROQkRKWHNjVWt 777 LQTRIWVYzN0wKICByWE1nbDVpNmVHZTh5SG9TWVcwRlRWcFkifX19fX0", 778 { 779 "signatures":[{ 780 "alg":"SHA2", 781 "kid":"MCRR-JFLZ-T2JH-INGD-SBYF-NO6X-55RN", 782 "signature":"DG3O45F_0CUD9TEOKgkLtRK1BZDqWey5JO3Kt6 783 foye8lvR13l6P6UnieF9jDNO0WQY-yPI4LjyuAVNSZWi97IF4M--zrduv7ZpjCthk 784 sLnlQvH-oYIfGb-dZfAOza6B7zvgU6IbxPWWWCo4zQOj6qBkA"} 785 ], 786 "PayloadDigest":"4pwNPnQPWuciKHFFtXv7zXN7MN4bEsRJ78KmRG 787 8F3cR5pK32CcQ-aI5-qF2yL_gL8hJuU6S04mPpZEpE_acOWg"} 788 ]} 789 ]}} 791 The derivation of the Connection encryption and signature keys from 792 the Profile and Private contributions in this example is shown in 793 [draft-hallambaker-mesh-cryptography]. 795 4.1.2.1. Creating a ProfileDevice 797 Creating a "ProfileDevice" comprises the steps of: 799 0. Creating the necessary key 800 1. Signing the "ProfileDevice" using the Master Signature Key 802 2. Once created, a "ProfileDevice" is never changed. In the 803 unlikely event that any modification is required, a completely 804 new "ProfileDevice" MUST be created. 806 4.1.2.2. Connection to a Personal Mesh 808 Devices are only connected to a personal Mesh by administration 809 device. This comprises the steps of: 811 0. Generating the PrivateDevice keys. 813 1. Creating the ConnectionDevice data from the public components of 814 the ProfileDevice and PrivateDevice keys and signing it using the 815 administration key. 817 2. Creating the Activations for the device and signing them using 818 the administration key. 820 3. Creating the "CatalogEntryDevice" for the device and adding it to 821 the "CatalogDevice" of the Personal Mesh. 823 4. If the Personal Mesh has accounts that are connected to a Mesh 824 Service, synchronizing the "CatalogEntryDevice" to those 825 services. 827 4.2. Mesh Accounts 829 Mesh Accounts contains all the stateful information (contacts, 830 calendar entries, inbound and outbound messages, etc.) related to a 831 particular persona used by the owner. 833 A Mesh Profile MAY be connected to multiple accounts at the same time 834 allowing the user to maintain separate personas for separate 835 purposes. 837 Unlike traditional Internet application accounts, Mesh accounts are 838 created by and belong to the user, not the Mesh Service provider. A 839 user MAY change their Mesh Service provider at any time and 840 disconnect the profile from all Mesh Services (e.g. to archive the 841 account). 843 Alice's personal account is connected to two Mesh services: 845 (Artwork only available as svg: No external link available, see 846 draft-hallambaker-mesh-schema-05.html for artwork.) 847 Figure 5 849 The account profile specifies the online and offline signature keys 850 used to maintain the profile and the encryption key to be used by the 851 account. 853 { 854 "ProfileAccount":{ 855 "KeyOfflineSignature":{ 856 "UDF":"MC23-X3CT-EUNB-DR3M-QIBI-W2IJ-ATEP", 857 "PublicParameters":{ 858 "PublicKeyECDH":{ 859 "crv":"Ed448", 860 "Public":"9upP1iak30_JrG1peYwhkT00Dpw8J0jwGQA0nehnBVPuOaG 861 9h6SsFe0Dez2b3aQpldAGUKoUBdCA"}}}, 862 "KeysOnlineSignature":[{ 863 "UDF":"MCRR-JFLZ-T2JH-INGD-SBYF-NO6X-55RN", 864 "PublicParameters":{ 865 "PublicKeyECDH":{ 866 "crv":"Ed448", 867 "Public":"F_MJf0w8dUHiPYy97XKQmpfFVLnNndsjQH5p1c3z3Hlnq 868 Ta2a7bEUCOoxa4HAisf9BqnxJEdOmgA"}}} 869 ], 870 "ServiceIDs":["alice@example.com" 871 ], 872 "MeshProfileUDF":"MCSC-2POG-PH7T-ODJX-HOCA-B4XY-AFSK", 873 "KeyEncryption":{ 874 "UDF":"MBWY-IIKY-VOB5-BXIP-DIXX-R4TH-ZIF2", 875 "PublicParameters":{ 876 "PublicKeyECDH":{ 877 "crv":"Ed448", 878 "Public":"swpe6H5yiU4vJotboXbFwwIEp_lXO-kbm9zj9POFLLwfqe6 879 BUMsu9FBCL6GHp93wcmLM27tGRn4A"}}}}} 881 Each device using the account requires an activation record: 883 { 884 "ActivationAccount":{ 885 "AccountUDF":"MC23-X3CT-EUNB-DR3M-QIBI-W2IJ-ATEP", 886 "KeyEncryption":{ 887 "UDF":"MCCA-4Y37-NRGL-BEJS-D47Z-4PIZ-VSCN", 888 "BaseUDF":"MCZP-AMNO-JHWY-ZQ22-N3ZP-V2KW-52JE", 889 "Overlay":{ 890 "PrivateKeyECDH":{ 891 "crv":"Ed448", 892 "Private":"J3_G2bLfr8dFDZH4gb3PsGpU14OEc2bbov-t1I94xX2ZBe 893 NXczMQCteXX3l6skBmSz04KeJwjaU"}}}, 894 "KeyAuthentication":{ 895 "UDF":"MCL4-KRB4-PMTN-3CLI-UPFZ-MV2Z-6TUG", 896 "BaseUDF":"MDYO-XAHJ-RXT6-YO4J-X7WV-L3IW-5NEP", 897 "Overlay":{ 898 "PrivateKeyECDH":{ 899 "crv":"Ed448", 900 "Private":"ONPNA2UnIsDbycpixay3grFzxyOn5vi8m3gWYqPalToXDy 901 cRT6STM5vDN6WGC7T-gp3anvVOuFk"}}}, 902 "KeySignature":{ 903 "UDF":"MCZL-MQOA-XLYU-RLPW-VRRH-6UFD-KDIE", 904 "BaseUDF":"MCYS-TOQJ-CDAX-EDU7-6EZ3-OLPG-KMLG", 905 "Overlay":{ 906 "PrivateKeyECDH":{ 907 "crv":"Ed448", 908 "Private":"OgJR8BYYzJLcjERkW5Xclt9K2YHahuUg4NBDJXscUkKA4H 909 YV37LrXMgl5i6eGe8yHoSYW0FTVpY"}}}}} 911 4.2.1. Creating a ProfileAccount 913 Creating a "ProfileAccount" comprises the steps of: 915 0. [TBS] 917 1. . 919 2. Signing the ProfileMaster using the Master Signature Key 921 4.2.2. Connecting a Device to an Account 923 Adding a device to an account comprises the steps of: 925 0. Creating a PrivateAccount instance for the device. 927 1. Creating a ConnectionAccountDevice for the device using the 928 public keys from the PrivateAccount instance and the 929 ProfileDevice. 931 2. Creating an ActivationAccount for the device containing the 932 PrivateAccount and ConnectionAccountDevice instances. 934 3. Adding the ActivationAccount to the "CatalogEntryDevice" of the 935 device. 937 4. If the Personal Mesh has accounts that are connected to a Mesh 938 Service, synchronizing the "CatalogEntryDevice" to those 939 services. 941 4.2.3. Binding and Account to a Service 943 Binding a "ProfileAccount" to a Mesh Service the steps of: 945 0. [TBS] 947 1. . 949 2. Signing the ProfileMaster using the Master Signature Key 951 4.3. Mesh Services 953 A service profile provides the axiom of trust and cryptographic keys 954 for a Mesh Service. A Mesh Service Host SHOULD return a copy of its 955 ProfileHost and the parent ProfileService in response to a Hello 956 transaction request. 958 (Artwork only available as svg: No external link available, see 959 draft-hallambaker-mesh-schema-05.html for artwork.) 961 Figure 6 963 The credentials provided by the ProfileService and ProfileHost are 964 distinct from those provided by the WebPKI that typically services 965 TLS requests. WebPKI credentials provide service introduction and 966 authentication while a Mesh ProfileHost only provides authentication. 968 Unless exceptional circumstances require, a service should not need 969 to revise its Service Profile unless it is intended to change its 970 identity. Service Profiles MAY be countersigned by Trusted Third 971 Parties to establish accountability. 973 The service profile 974 { 975 "ProfileService":{ 976 "KeyOfflineSignature":{ 977 "UDF":"MAZN-ABCG-4UH7-NN3H-5G7D-KP7X-HRGO", 978 "PublicParameters":{ 979 "PublicKeyECDH":{ 980 "crv":"Ed448", 981 "Public":"4_-7mv9dECSF5ihqS7wRP-KZbo4ExJc5JjoH4iudjymQ9Qb 982 HPUYWHD1YSpVypaHgyg-XkfhaqkSA"}}}}} 984 The host also has a profile 986 { 987 "ProfileHost":{ 988 "KeyOfflineSignature":{ 989 "UDF":"MDNG-3RJS-N6BJ-MU63-U7TZ-RKVB-SYZT", 990 "PublicParameters":{ 991 "PublicKeyECDH":{ 992 "crv":"Ed448", 993 "Public":"Bn3Yo-Hh_donsmk1AQxSd1nzR-SEzRcJudwoC174DEV-Vm4 994 t6Sl2jVFAq3GBG7lOUEF5HfeVqQiA"}}}, 995 "KeyAuthentication":{ 996 "UDF":"MDSO-WOVL-R4YG-7OUT-PB6O-2DBW-KUND", 997 "PublicParameters":{ 998 "PublicKeyECDH":{ 999 "crv":"Ed448", 1000 "Public":"hFtmh1ErT93IUy-FJbPHt7QFIAP-ohQNLSzUwtXc2E0IH7r 1001 XE6u92gnCUQpJVECuTNrHuwALJB4A"}}}}} 1003 And there should be a connection of the host to the service but this 1004 isn't implemented yet: 1006 $$$$ Empty $$$$ 1008 4.3.1. Creating a ProfileService 1010 [TBS] 1012 Creating a "ProfileService" comprises the steps of: 1014 0. [TBS] 1016 1. . 1018 2. [TBS] 1020 4. Signing the ProfileMaster using the Master Signature Key 1022 4.3.2. Creating a ProfileHost 1024 Creating a "ProfileHost" comprises the steps of: 1026 0. [TBS] 1028 1. . 1030 2. [TBS] 1032 4. Signing the "ConnectionHost" using the Master Signature Key of 1033 the "ProfileService". 1035 4.3.3. Creating a ConnectionHost 1037 Creating a "ConnectionHost" comprises the steps of: 1039 0. [TBS] 1041 1. . 1043 2. Signing the "ConnectionHost" using the Master Signature Key of 1044 the "ProfileService". 1046 4.4. Mesh Messaging 1048 Mesh Messaging is an end-to-end secure messaging system used to 1049 exchange short (32KB) messages between Mesh devices and services. In 1050 cases where exchange of longer messages is required, Mesh Messaging 1051 MAY be used to provide a control plane to advise the intended message 1052 recipient(s) of the type of data being offered and the means of 1053 retrieval (e.g an EARL). 1055 A four-corner messaging model is enforced. Mesh Services only accept 1056 outbound messages from devices connected to accounts that it 1057 services. Inbound messages are only accepted from other Mesh 1058 Services. This model enables access control at both the outbound and 1059 inbound services 1061 (Artwork only available as svg: No external link available, see 1062 draft-hallambaker-mesh-schema-05.html for artwork.) 1064 Figure 7 1066 The outbound Mesh Service checks to see that the message request does 1067 not violate its acceptable use policy. Accounts that make a large 1068 number of message requests that result in complaints SHOULD be 1069 subject to consequences ranging from restriction of the number and 1070 type of messages sent to suspending or terminating messaging 1071 privileges. 1073 (Artwork only available as svg: No external link available, see 1074 draft-hallambaker-mesh-schema-05.html for artwork.) 1076 Figure 8 1078 The inbound Mesh Service also checks to see that messages received 1079 are consistent with the service Acceptable Use Policy and the user's 1080 personal access control settings. 1082 Mesh Services that fail to police abuse by their account holders 1083 SHOULD be subject to consequences in the same fashion as account 1084 holders. 1086 (Artwork only available as svg: No external link available, see 1087 draft-hallambaker-mesh-schema-05.html for artwork.) 1089 Figure 9 1091 4.4.1. Traffic Analysis 1093 The Mesh Messaging protocol as currently specified provides only 1094 limited protection against traffic analysis attacks. The use of TLS 1095 to encrypt communication between Mesh Services limits the 1096 effectiveness of na?ve traffic analysis mechanisms but does not 1097 prevent timing attacks unless dummy traffic is introduced to 1098 obfuscate traffic flows. 1100 The limitation of the message size is in part intended to facilitate 1101 use of mechanisms capable of providing high levels of traffic 1102 analysis such as mixmaster and onion routing but the current Mesh 1103 Service Protocol does not provide support for such approaches and 1104 there are no immediate plans to do so. 1106 5. Mesh Catalogs 1108 Catalogs track sets of persistent objects associated with a Mesh 1109 Service Account. The Mesh Service has no access to the entries in 1110 any Mesh catalog except for the Device and Contacts catalog which are 1111 used in device authentication and authorization of inbound messages. 1113 Each Mesh Catalog managed by a Mesh Account has a name of the form: 1115 "<_" 1116 Where "<" is the IANA assigned service name. The assigned 1117 service name for the Mathematical Mesh is mmm. Thus, all catalogs 1118 specified by the Mesh schema have names prefixed with the sequence 1119 "mmm_". 1121 The following catalogs are currently specified within the 1122 Mathematical Mesh. 1124 Application: "mmm_CatalogApplication" Contains configuration 1125 information for applications including mail (SMTP, IMAP, OpenPGP, 1126 S/MIME, etc) and SSH and for the MeshAccount application itself. 1128 Device: "mmm_CatalogDevice" Contains descriptions of devices 1129 connected to the account and the permissions assigned to them 1131 Contact: "mmm_CatalogContact" Contains logical and physical contact 1132 information for people and organizations. 1134 Credential: "mmm_CatalogCredential" Contains credentials used to 1135 access network resources. 1137 Bookmark: "mmm_CatalogBookmark" Contains Web bookmarks and other 1138 citations allowing them to be shared between devices connected to 1139 the profile. 1141 Task: "mmm_CatalogTask" Contains tasks assigned to the user 1142 including calendar entries and to do lists. 1144 Network: "mmm_CatalogNetwork" Contains network settings such as WiFi 1145 access points, IPSEC and TLS VPN configurations, etc. 1147 In many cases, the Mesh Catalog offers capabilities that represent a 1148 superset of the capabilities of an existing application. For 1149 example, the task catalog supports the appointment tracking functions 1150 of a traditional calendar application and the task tracking function 1151 of the traditional 'to do list' application. Combining these 1152 functions allows tasks to be triggered by other events other than the 1153 passage of time such as completion of other tasks, geographical 1154 presence, etc. 1156 In such cases, the Mesh Catalog entries are designed to provide a 1157 superset of the data representation capabilities of the legacy 1158 formats and (where available) recent extensions. Where a catalog 1159 entry is derived from input presented in a legacy format, the 1160 original data representation MAY be attached verbatim to facilitate 1161 interoperability. 1163 5.1. Application 1165 The application catalog "mmm"_"CatalogApplication" contains 1166 "CatalogEntryApplication" entries which describe the use of specific 1167 applications under the Mesh Service Account. Multiple application 1168 accounts for a single application MAY be connected to a single Mesh 1169 Service Account. Each account being specified in a separate entry. 1171 The "CatalogEntryApplication" entries only contain configuration 1172 information for the application as it applies to the account as a 1173 whole. If the application requires separate configuration for 1174 individual devices, this is specified in separate activation records 1175 specified in the corresponding "ConnectionDevice". 1177 5.1.1. Mesh Account 1179 Mesh Accounts are described by "CatalogEntryAccount" entries. The 1180 corresponding activation records for the connected devices contain 1181 the contributions used to derive the private keys for use of the 1182 account. 1184 The "CatalogEntryAccount" entry is described in the section 1185 describing Mesh accounts above. 1187 5.1.2. SSH 1189 SSH configuration profiles are described by 1190 "CatalogEntryApplicationSSH" entries. The corresponding activation 1191 records for the connected devices contain the contributions used to 1192 derive the private keys. 1194 A user may have separate SSH configurations for separate purposes 1195 within a single Mesh Account. This allows a system administrator 1196 servicing multiple clients to maintain separate SSH profiles for each 1197 of her customers allowing credentials to be easily (and verifiably) 1198 revoked at contract termination. 1200 The SSH profile contains the information that is stored in the 1201 "known_hosts" and "authorized_keys" files of SSH clients and servers. 1203 $$$$ Empty $$$$ 1205 5.1.3. Mail 1207 Mail configuration profiles are described by one or more 1208 "CatalogEntryApplicationMail" entries, one for each email account 1209 connected to the Mesh profile. The corresponding activation records 1210 for the connected devices contain information used to provide the 1211 device with the necessary decryption information. 1213 Entries specify the email account address(es), the inbound and 1214 outbound server configuration and the cryptographic keys to be used 1215 for S/MIME and OpenPGP encryption. 1217 $$$$ Empty $$$$ 1219 5.2. Device 1221 The device catalog "mmm_CatalogDevice" contains "CatalogEntryDevice" 1222 entries which describe the devices connected to the account and the 1223 permissions assigned to them. 1225 The management of the device catalog is described in the section 1226 describing Mesh Device Management. 1228 5.3. Contact 1230 The contacts catalog contains "CatalogEntryContact" entries which 1231 describe 1233 $$$$ Empty $$$$ 1235 The fields of the contact catalog provide a superset of the 1236 capabilities of vCard [RFC2426]. 1238 The Contact catalog is typically used by the MeshService as a source 1239 of authorization information to perform access control on inbound and 1240 outbound message requests. For this reason, Mesh Service SHOULD be 1241 granted read access to the contacts catalog by providing a decryption 1242 entry for the service. 1244 5.4. Credential 1246 The credential catalog contains "CatalogEntryCredential" entries 1247 which describe credentials used to access network resources. 1249 Only username/password credentials are stored in the credential 1250 catalog. If public key credentials are to be used, these SHOULD 1251 be managed as an application profile allowing separate credentials 1252 to be created for each device. 1254 { 1255 "CatalogedCredential":{ 1256 "Service":"ftp.example.com", 1257 "Username":"alice1", 1258 "Password":"newpassword"}} 1260 5.5. Bookmark 1262 The bookmark catalog contains "CatalogEntryBookmark" entries which 1263 describe Web bookmarks and other citations allowing them to be shared 1264 between devices connected to the profile. 1266 The fields currently supported by the Bookmarks catalog are currently 1267 limited to the fields required for tracking Web bookmarks. 1268 Specification of additional fields to track full academic citations 1269 is a work in progress. 1271 { 1272 "CatalogedBookmark":{ 1273 "Uri":"http://example.net/Bananas", 1274 "Title":"\"Banana", 1275 "Path":"Folder1/2"}} 1277 5.6. Task 1279 The Task catalog contains "CatalogEntryTask" entries which describe 1280 tasks assigned to the user including calendar entries and to do 1281 lists. 1283 The fields of the task catalog currently reflect those offered by the 1284 iCalendar specification [RFC5545]. Specification of additional 1285 fields to allow task triggering on geographic location and/or 1286 completion of other tasks is a work in progress. 1288 $$$$ Empty $$$$ 1290 5.7. Network 1292 The network catalog contains "CatalogEntryNetwork" entries which 1293 describe network settings, IPSEC and TLS VPN configurations, etc. 1295 $$$$ Empty $$$$ 1297 6. Mesh Messages 1299 All communications between Mesh accounts takes the form of a Mesh 1300 Message carried in a Dare Envelope. Mesh Messages are stored in two 1301 spools associated with the account, the "SpoolOutbound" and the 1302 "SpoolInbound" containing the messages sent and received 1303 respectively. 1305 This document only describes the representation of the messages 1306 within the message spool. The Mesh Service protocol by which the 1307 messages are exchanged between devices and services and between 1308 services is described in [draft-hallambaker-mesh-protocol]. 1310 6.1. Completion 1312 Completion messages are dummy messages that are added to a Mesh Spool 1313 to change the status of messages previously posted. Any message that 1314 is in the inbound spool and has not been erased or redacted MAY be 1315 marked as "read", "unread" or "deleted". Any message in the outbound 1316 spool MAY be marked as "sent", "received" or "deleted". 1318 Services MAY erase or redact messages in accordance with local site 1319 policy. Since messages are not removed from the spool on being 1320 marked deleted, they may be undeleted by marking them as read or 1321 unread. Marking a message deleted MAY make it more likely that the 1322 Service will purge the message however. 1324 Having processed a message, a completion message is added to the 1325 spool so that other devices can see that it has been read: 1327 [NYI] 1329 6.2. Connection 1331 Connection requests are sent by a device requesting connection to a 1332 Mesh Service Account. 1334 The "MessageConnectionRequest" is originally sent by the device 1335 requesting connection to the Mesh Service associated with the 1336 account. 1338 If the connection request is accepted by the Mesh Service, it creates 1339 a "MessageConnectionResponse" containing the ServerNonce and Witness 1340 values used in the authentication of the response together with a 1341 verbatim copy of the original request. The 1342 "MessageConnectionResponse" is then returned to the device that made 1343 the original request and placed on the SpoolInbound of the account to 1344 which the request was directed. 1346 Further details of this mechanism are described in 1347 [draft-hallambaker-mesh-protocol]. 1349 The connection process begins with the assignment of a time-limited 1350 PIN value. This is described in a Message sent by the administration 1351 device to allow other admin devices to accept the request made. 1353 [NYI] 1355 The initial request is sent to the service 1357 [NYI] 1359 The service returns an acknowledgement giving the Witness value. 1360 Note that this is not a 'reply' since it comes from the service, not 1361 the user. 1363 [NYI] 1365 [Note, this mechanism should be revised to ensure that there is 1366 perfect forward secrecy. The device should provide a nonce key as a 1367 mixin] 1369 6.3. Contact 1371 A contact request presents a proposed contact entry and requests that 1372 it be added to the Contacts catalog of the specified Mesh Service 1373 Account. A contact request is usually sent by the party requesting 1374 that their contact be added but this is not necessarily the case. 1376 The MessageContact contains a DARE Envelope containing the Contact 1377 information of the requester. If the request is accepted, this 1378 information will be added to the contact catalog of the relevant 1379 account. If the Reply field has the value 'true', this indicates 1380 that the sender is asking for the recipient to return their own 1381 credentials in reply. 1383 Since the sender requires the user's contact information before the 1384 request can be made, the MessageContact message MAY be encrypted 1385 under either the user's account encryption key (if known) or the Mesh 1386 Service encryption key (which may be obtained from the service on 1387 request. 1389 Bob asks Alice to send her contact details and sends his. 1391 [NYI] 1393 Alice responds with her details: 1395 [NYI] 1397 [Note that this exchange could be performed automatically on Alice's 1398 behalf by the service if she delegates this action to it.] 1400 The current protocol assumes that all contact management will be 1401 performed end-to-end through the Mesh Services themselves. If the 1402 number of Mesh users were to become very large, additional 1403 infrastructure to facilitate contact management will be required. 1404 These topics are discussed at a high level in 1405 [draft-hallambaker-mesh-trust]. 1407 In situations where a user is well known and has a very large number 1408 of contacts, they are likely to make use of a tiered approach to 1409 contact management in which they keep separate accounts for their 1410 'public' and 'restricted' personas and delegate management of their 1411 public account to a subordinate or to their Mesh Service provider. 1413 6.4. Confirmation 1415 Confirmation messages are used to provide an improved form of second 1416 factor authentication capability. 1418 Two confirmation messages are specified, a request and response. 1420 A confirmation request is initiated by sending a 1421 "MessageConfirmationRequest" to the Mesh Service hosting the 1422 recipient Mesh Service Account. The request specifies the question 1423 that is to be put to the user. 1425 To respond to a confirmation request, a user generates a 1426 "MessageConfirmationResponse". This MUST be signed by a device 1427 authorized to respond to confirmation requests by a Device Connection 1428 Assertion with the "Confirmation" privilege. 1430 The confirmation request 1432 [NYI] 1434 The confirmation response 1436 [NYI] 1438 7. Schema 1439 7.1. Shared Classes 1441 The following classes are used as common elements in Mesh profile 1442 specifications. 1444 7.1.1. Classes describing keys 1446 7.1.2. Structure: PublicKey 1448 The PublicKey class is used to describe public key pairs and trust 1449 assertions associated with a public key. 1451 UDF: String (Optional) UDF fingerprint of the public key parameters/ 1453 X509Certificate: Binary (Optional) List of X.509 Certificates 1455 X509Chain: Binary [0..Many] X.509 Certificate chain. 1457 X509CSR: Binary (Optional) X.509 Certificate Signing Request. 1459 7.1.3. Structure: KeyComposite 1461 Service: String (Optional) Service holding the additional 1462 contribution 1464 7.1.4. Structure: DeviceRecryptionKey 1466 UDF: String (Optional) The fingerprint of the encryption key 1468 Contact: Contact (Optional) The User's Mesh contact information 1470 RecryptionKey: PublicKey (Optional) The recryption key 1472 EnvelopedRecryptionKeyDevice: DareEnvelope (Optional) The decryption 1473 key encrypted under the user's device key. 1475 7.1.5. Structure: KeyOverlay 1477 UDF: String (Optional) Fingerprint of the resulting composite key 1478 (to allow verification) 1480 BaseUDF: String (Optional) Fingerprint specifying the base key 1482 7.1.6. Structure: EscrowedKeySet 1484 A set of escrowed keys. 1486 [No fields] 1488 7.2. Assertion classes 1490 Classes that are derived from an assertion. 1492 7.2.1. Structure: Assertion 1494 Parent class from which all assertion classes are derived 1496 Names: String [0..Many] Fingerprints of index terms for profile 1497 retrieval. The use of the fingerprint of the name rather than the 1498 name itself is a precaution against enumeration attacks and other 1499 forms of abuse. 1501 Updated: DateTime (Optional) The time instant the profile was last 1502 modified. 1504 NotaryToken: String (Optional) A Uniform Notary Token providing 1505 evidence that a signature was performed after the notary token was 1506 created. 1508 7.2.2. Structure: Condition 1510 Parent class from which all condition classes are derived. 1512 [No fields] 1514 7.2.3. Profile Classes 1516 Profiles are self signed assertions. 1518 7.2.4. Structure: Profile 1520 Inherits: Assertion 1522 Parent class from which all profile classes are derived 1524 KeyOfflineSignature: PublicKey (Optional) The permanent signature 1525 key used to sign the profile itself. The UDF of the key is used 1526 as the permanent object identifier of the profile. Thus, by 1527 definition, the KeySignature value of a Profile does not change 1528 under any circumstance. The only case in which a 1530 KeysOnlineSignature: PublicKey [0..Many] A Personal profile contains 1531 at least one OSK which is used to sign device administration 1532 application profiles. 1534 7.2.5. Structure: ProfileMesh 1535 Inherits: Profile 1537 Describes the long term parameters associated with a personal 1538 profile. 1540 KeysMasterEscrow: PublicKey [0..Many] A Personal Profile MAY contain 1541 one or more PMEK keys to enable escrow of private keys used for 1542 stored data. 1544 KeyEncryption: PublicKey (Optional) Key used to pass encrypted data 1545 to the device such as a DeviceUseEntry 1547 7.2.6. Structure: ProfileDevice 1549 Inherits: Profile 1551 Describes a mesh device. 1553 Description: String (Optional) Description of the device 1555 KeyEncryption: PublicKey (Optional) Key used to pass encrypted data 1556 to the device such as a DeviceUseEntry 1558 KeyAuthentication: PublicKey (Optional) Key used to authenticate 1559 requests made by the device. 1561 7.2.7. Structure: ProfileService 1563 Inherits: Profile 1565 Profile of a Mesh Service 1567 KeyAuthentication: PublicKey (Optional) Key used to authenticate 1568 service connections. 1570 7.2.8. Structure: ProfileAccount 1572 Inherits: Profile 1574 Account assertion. This is signed by the service hosting the 1575 account. 1577 ServiceIDs: String [0..Many] Service address(es). 1579 MeshProfileUDF: String (Optional) Master profile of the account 1580 being registered. 1582 KeyEncryption: PublicKey (Optional) Key used to encrypt data under 1583 this profile 1585 7.2.9. Structure: ProfileGroup 1587 Inherits: Profile 1589 Describes a group. Note that while a group is created by one person 1590 who becomes its first administrator, control of the group may pass to 1591 other administrators over time. 1593 ServiceIDs: String [0..Many] Service address(es). 1595 KeyEncryption: PublicKey (Optional) Key currently used to encrypt 1596 data under this profile 1598 7.2.10. Structure: ProfileHost 1600 Inherits: Profile 1602 KeyAuthentication: PublicKey (Optional) Key used to authenticate 1603 service connections. 1605 7.2.11. Connection Classes 1607 7.2.12. Structure: Connection 1609 Inherits: Assertion 1611 SubjectUDF: String (Optional) UDF of the connection target. 1613 AuthorityUDF: String (Optional) UDF of the connection source. 1615 7.2.13. Structure: Permission 1617 Name: String (Optional) 1619 Role: String (Optional) 1621 Capabilities: DareEnvelope (Optional) Keys or key contributions 1622 enabling the operation to be performed 1624 7.2.14. Structure: ConnectionDevice 1626 Inherits: Connection 1628 Permissions: Permission [0..Many] List of the permissions that the 1629 device has been granted. 1631 KeySignature: PublicKey (Optional) The signature key for use of the 1632 device under the profile 1634 KeyEncryption: PublicKey (Optional) The encryption key for use of 1635 the device under the profile 1637 KeyAuthentication: PublicKey (Optional) The authentication key for 1638 use of the device under the profile 1640 7.2.15. Structure: ConnectionAccount 1642 Inherits: Connection 1644 ServiceID: String [0..Many] The list of service identifiers. 1646 Permissions: Permission [0..Many] List of the permissions that the 1647 device has been granted. 1649 KeySignature: PublicKey (Optional) The signature key for use of the 1650 device under the profile 1652 KeyEncryption: PublicKey (Optional) The encryption key for use of 1653 the device under the profile 1655 KeyAuthentication: PublicKey (Optional) The authentication key for 1656 use of the device under the profile 1658 7.2.16. Structure: ConnectionGroup 1660 Describes the connection of a member to a group. 1662 Inherits: Connection 1664 KeyEncryption: KeyComposite (Optional) The decryption key for the 1665 user within the group 1667 7.2.17. Structure: ConnectionService 1669 Inherits: Connection 1671 [No fields] 1673 7.2.18. Structure: ConnectionHost 1675 Inherits: Connection 1677 [No fields] 1679 7.2.19. Structure: ConnectionApplication 1681 Inherits: Connection 1683 [No fields] 1685 7.2.20. Activation Classes 1687 7.2.21. Structure: Activation 1689 Inherits: Assertion 1691 Contains the private activation information for a Mesh application 1692 running on a specific device 1694 [No fields] 1696 7.2.22. Structure: ActivationDevice 1698 Inherits: Assertion 1700 EnvelopedAssertionDeviceConnection: DareEnvelope (Optional) The 1701 signed AssertionDeviceConnection. 1703 KeySignature: KeyOverlay (Optional) The key overlay used to generate 1704 the account signature key from the device signature key 1706 KeyEncryption: KeyOverlay (Optional) The key overlay used to 1707 generate the account encryption key from the device encryption key 1709 KeyAuthentication: KeyOverlay (Optional) The key overlay used to 1710 generate the account authentication key from the device 1711 authentication key 1713 7.2.23. Structure: ActivationAccount 1715 Inherits: Activation 1717 AccountUDF: String (Optional) The UDF of the account 1719 KeyGroup: KeyComposite (Optional) The key contribution for the 1720 decryption key for the device. NB this is NOT an overlay on the 1721 device signature key, it is an overlay on the corresponding 1722 recryption key. 1724 KeyEncryption: KeyOverlay (Optional) The key overlay used to 1725 generate the account encryption key from the device encryption key 1727 KeyAuthentication: KeyOverlay (Optional) The key overlay used to 1728 generate the account authentication key from the device 1729 authentication key 1731 KeySignature: KeyOverlay (Optional) The key overlay used to generate 1732 the account signature key from the device signature key 1734 7.2.24. Structure: ActivationGroup 1736 Inherits: Activation 1738 GroupUDF: String (Optional) The UDF of the group 1740 KeyEncryption: KeyOverlay (Optional) The key overlay that 1741 compliments the member's group decryption key. 1743 7.3. Cataloged items 1745 7.3.1. Data Structures 1747 Classes describing data used in cataloged data. 1749 7.3.2. Structure: ContactMesh 1751 UDF: String (Optional) 1753 ServiceID: String [0..Many] 1755 7.3.3. Structure: Contact 1757 Inherits: Assertion 1759 MeshAccounts: DareEnvelope [0..Many] The Mesh Account Connection - 1760 the main event really 1762 Email: String (Optional) 1764 Identifier: String (Optional) 1766 FullName: String (Optional) 1768 Title: String (Optional) 1770 First: String (Optional) 1772 Middle: String (Optional) 1774 Last: String (Optional) 1775 Suffix: String (Optional) 1777 Labels: String [0..Many] 1779 AssertionAccounts: ProfileAccount [0..Many] 1781 Addresses: Address [0..Many] 1783 Locations: Location [0..Many] 1785 Roles: Role [0..Many] 1787 7.3.4. Structure: Role 1789 CompanyName: String (Optional) 1791 Addresses: Address [0..Many] 1793 Locations: Location [0..Many] 1795 7.3.5. Structure: Address 1797 URI: String (Optional) 1799 Labels: String [0..Many] 1801 7.3.6. Structure: Location 1803 Appartment: String (Optional) 1805 Street: String (Optional) 1807 District: String (Optional) 1809 Locality: String (Optional) 1811 County: String (Optional) 1813 Postcode: String (Optional) 1815 Country: String (Optional) 1817 7.3.7. Structure: Reference 1819 MessageID: String (Optional) The received message to which this is a 1820 response 1822 ResponseID: String (Optional) Message that was generated in response 1823 to the original (optional). 1825 Relationship: String (Optional) The relationship type. This can be 1826 Read, Unread, Accept, Reject. 1828 7.3.8. Structure: Task 1830 Key: String (Optional) Unique key. 1832 Start: DateTime (Optional) 1834 Finish: DateTime (Optional) 1836 StartTravel: String (Optional) 1838 FinishTravel: String (Optional) 1840 TimeZone: String (Optional) 1842 Title: String (Optional) 1844 Description: String (Optional) 1846 Location: String (Optional) 1848 Trigger: String [0..Many] 1850 Conference: String [0..Many] 1852 Repeat: String (Optional) 1854 Busy: Boolean (Optional) 1856 7.4. Catalog Entries 1858 7.4.1. Structure: CatalogedEntry 1860 Base class for cataloged Mesh data. 1862 [No fields] 1864 7.4.2. Structure: CatalogedDevice 1866 Inherits: CatalogedEntry 1868 Public device entry, indexed under the device ID 1869 UDF: String (Optional) UDF of the signature key of the device in the 1870 Mesh 1872 DeviceUDF: String (Optional) UDF of the signature key of the device 1874 EnvelopedProfileDevice: DareEnvelope (Optional) The device profile 1876 EnvelopedConnectionDevice: DareEnvelope (Optional) The public 1877 assertion demonstrating connection of the Device to the Mesh 1879 EnvelopedActivationDevice: DareEnvelope (Optional) The activations 1880 of the device within the Mesh 1882 Accounts: AccountEntry [0..Many] The accounts that this device is 1883 connected to 1885 7.4.3. Structure: AccountEntry 1887 AccountUDF: String (Optional) UDF of the account profile 1889 EnvelopedProfileAccount: DareEnvelope (Optional) The account profile 1891 EnvelopedConnectionAccount: DareEnvelope (Optional) The connection 1892 of this device to the account 1894 EnvelopedActivationAccount: DareEnvelope (Optional) The activation 1895 data for this device to the account 1897 7.4.4. Structure: CatalogedCredential 1899 Inherits: CatalogedEntry 1901 Protocol: String (Optional) 1903 Service: String (Optional) 1905 Username: String (Optional) 1907 Password: String (Optional) 1909 7.4.5. Structure: CatalogedNetwork 1911 Inherits: CatalogedEntry 1913 Protocol: String (Optional) 1915 Service: String (Optional) 1916 Username: String (Optional) 1918 Password: String (Optional) 1920 7.4.6. Structure: CatalogedContact 1922 Inherits: CatalogedEntry 1924 Self: Boolean (Optional) If true, this catalog entry is for the user 1925 who created the catalog. To be valid, such an entry MUST be 1926 signed by an administration key for the Mesh profile containing 1927 the account to which the catalog belongs. 1929 Key: String (Optional) Unique key. 1931 Permissions: Permission [0..Many] List of the permissions that the 1932 contact has been granted. 1934 EnvelopedContact: DareEnvelope (Optional) The (signed) contact data. 1936 7.4.7. Structure: CatalogedContactRecryption 1938 Inherits: CatalogedContact 1940 [No fields] 1942 7.4.8. Structure: CatalogedBookmark 1944 Inherits: CatalogedEntry 1946 Uri: String (Optional) 1948 Title: String (Optional) 1950 Path: String (Optional) 1952 7.4.9. Structure: CatalogedTask 1954 Inherits: CatalogedEntry 1956 EnvelopedTask: DareEnvelope (Optional) 1958 Title: String (Optional) 1960 Key: String (Optional) Unique key. 1962 7.4.10. Structure: CatalogedApplication 1963 Inherits: CatalogedEntry 1965 Key: String (Optional) 1967 7.4.11. Structure: CatalogedMember 1969 UDF: String (Optional) 1971 Inherits: CatalogedEntry 1973 7.4.12. Structure: CatalogedGroup 1975 Inherits: CatalogedApplication 1977 Profile: ProfileGroup (Optional) 1979 7.4.13. Structure: CatalogedApplicationSSH 1981 Inherits: CatalogedApplication 1983 [No fields] 1985 7.4.14. Structure: CatalogedApplicationMail 1987 Inherits: CatalogedApplication 1989 [No fields] 1991 7.4.15. Structure: CatalogedApplicationNetwork 1993 Inherits: CatalogedApplication 1995 [No fields] 1997 7.5. Messages 1999 7.5.1. Structure: Message 2001 MessageID: String (Optional) 2003 Sender: String (Optional) 2005 Recipient: String (Optional) 2007 References: Reference [0..Many] 2009 7.5.2. Structure: MessageComplete 2010 Inherits: Message 2012 [No fields] 2014 7.5.3. Structure: MessagePIN 2016 Account: String (Optional) 2018 Inherits: Message 2020 Expires: DateTime (Optional) 2022 PIN: String (Optional) 2024 7.5.4. Structure: RequestConnection 2026 Connection request message. This message contains the information 2028 Inherits: Message 2030 ServiceID: String (Optional) 2032 EnvelopedProfileDevice: DareEnvelope (Optional) Device profile of 2033 the device making the request. 2035 ClientNonce: Binary (Optional) 2037 PinUDF: String (Optional) Fingerprint of the PIN value used to 2038 authenticate the request. 2040 7.5.5. Structure: AcknowledgeConnection 2042 Connection request message generated by a service on receipt of a 2043 valid MessageConnectionRequestClient 2045 Inherits: Message 2047 EnvelopedRequestConnection: DareEnvelope (Optional) The client 2048 connection request. 2050 ServerNonce: Binary (Optional) 2052 Witness: String (Optional) 2054 7.5.6. Structure: OfferGroup 2056 Inherits: Message 2058 [No fields] 2060 7.5.7. Structure: RequestContact 2062 Inherits: Message 2064 Reply: Boolean (Optional) 2066 Subject: String (Optional) 2068 Self: DareEnvelope (Optional) The contact data. 2070 7.5.8. Structure: ReplyContact 2072 Inherits: RequestContact 2074 [No fields] 2076 7.5.9. Structure: GroupInvitation 2078 Inherits: Message 2080 Text: String (Optional) 2082 EncryptedPartDecrypt: DareEnvelope (Optional) 2084 7.5.10. Structure: RequestConfirmation 2086 Inherits: Message 2088 Text: String (Optional) 2090 7.5.11. Structure: ResponseConfirmation 2092 Inherits: Message 2094 Request: RequestConfirmation (Optional) 2096 Accept: Boolean (Optional) 2098 7.5.12. Structure: RequestTask 2100 Inherits: Message 2102 [No fields] 2104 8. Security Considerations 2106 The security considerations for use and implementation of Mesh 2107 services and applications are described in the Mesh Security 2108 Considerations guide [draft-hallambaker-mesh-security]. 2110 9. IANA Considerations 2112 All the IANA considerations for the Mesh documents are specified in 2113 this document 2115 10. Acknowledgements 2117 A list of people who have contributed to the design of the Mesh is 2118 presented in [draft-hallambaker-mesh-architecture]. 2120 11. Appendix A: Example Container Organization (not normative) 2122 The means by which profiles are stored on devices is outside the 2123 scope of the specification. Only catalogs that are required to be 2124 shared between machines by means of accounts need to be standardized. 2126 11.1. Device 2128 Host Catalog: Host.dare Catalog of all the Mesh Profiles that the 2129 user has registered with the device and the latest version of the 2130 device profile for this device. 2132 MeshCatalog: [UDF-Mesh].dcat Catalog containing the Account Entries 2133 for the Mesh [UDF-Mesh]. 2135 Account Catalogs: [UDF-Account]/mmm_Device.dcat The device catalog 2136 associated with the specified account 2138 Account Catalogs: [UDF-Account]/[Catalog name].dcat The set of 2139 account catalogs that are shared verbatim between the devices 2140 connected to the account. 2142 11.1.1. Creating a new Mesh 2144 Create new Mesh Profile, Device Profile, Add to Host Catalog 2146 Create MeshCatalog 2148 11.1.2. Adding an Account 2150 Create new Account Profile, Add to MeshCatalog 2151 Create new Account Device Catalog 2153 For each device to be added to the account: Create Account Connection 2154 Assertion, add to Account Device Catalog. 2156 11.1.3. Adding a Device 2158 Create a Device Connection Assertion. 2160 For each account the device is to be added to: Create Account 2161 Connection Assertion, add to Account Device Catalog. 2163 11.2. Service 2165 Master Catalog Catalog of all services on machine 2167 Service Catalog Catalog of accounts in the service. 2169 11.2.1. Creating a Service 2171 Create a Service Description, add to Master Catalog 2173 11.2.2. Adding an Account 2175 Create the account entry, add to Service Catalog 2177 Create the Account Directory 2179 12. Appendix B: Collected Authentication and Encryption Requirements 2181 12.1. Mesh Messaging 2183 +-----------------------+---------+------------------+ 2184 | Message | Signer | Recipients | 2185 +=======================+=========+==================+ 2186 | RequestConnection | Device | Service | 2187 +-----------------------+---------+------------------+ 2188 | AcknowledgeConnection | Service | Device, Receiver | 2189 +-----------------------+---------+------------------+ 2190 | OfferGroup | Sender | Receiver | 2191 +-----------------------+---------+------------------+ 2192 | RequestContact | Sender | Receiver | 2193 +-----------------------+---------+------------------+ 2194 | ReplyContact | Sender | Receiver | 2195 +-----------------------+---------+------------------+ 2196 | RequestConfirmation | Sender | Receiver | 2197 +-----------------------+---------+------------------+ 2198 | ResponseConfirmation | Sender | Receiver | 2199 +-----------------------+---------+------------------+ 2200 | RequestTask | Sender | Receiver | 2201 +-----------------------+---------+------------------+ 2202 | ResponseTask | Sender | Receiver | 2203 +-----------------------+---------+------------------+ 2205 Table 1 2207 13. Normative References 2209 [draft-hallambaker-mesh-architecture] 2210 Hallam-Baker, P., "Mathematical Mesh 3.0 Part I: 2211 Architecture Guide", Work in Progress, Internet-Draft, 2212 draft-hallambaker-mesh-architecture-12, 16 January 2020, 2213 . 2216 [draft-hallambaker-mesh-cryptography] 2217 Hallam-Baker, P., "Mathematical Mesh 3.0 Part VIII: 2218 Cryptographic Algorithms", Work in Progress, Internet- 2219 Draft, draft-hallambaker-mesh-cryptography-04, 1 November 2220 2019, . 2223 [draft-hallambaker-mesh-notary] 2224 "[Reference Not Found!]". 2226 [draft-hallambaker-mesh-protocol] 2227 Hallam-Baker, P., "Mathematical Mesh 3.0 Part V: Protocol 2228 Reference", Work in Progress, Internet-Draft, draft- 2229 hallambaker-mesh-protocol-03, 23 October 2019, 2230 . 2233 [draft-hallambaker-mesh-security] 2234 Hallam-Baker, P., "Mathematical Mesh 3.0 Part VII: 2235 Security Considerations", Work in Progress, Internet- 2236 Draft, draft-hallambaker-mesh-security-02, 23 October 2237 2019, . 2240 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2241 Requirement Levels", BCP 14, RFC 2119, 2242 DOI 10.17487/RFC2119, March 1997, 2243 . 2245 14. Informative References 2247 [draft-hallambaker-mesh-developer] 2248 Hallam-Baker, P., "Mathematical Mesh: Reference 2249 Implementation", Work in Progress, Internet-Draft, draft- 2250 hallambaker-mesh-developer-09, 23 October 2019, 2251 . 2254 [draft-hallambaker-mesh-trust] 2255 Hallam-Baker, P., "Mathematical Mesh 3.0 Part VI: The 2256 Trust Mesh", Work in Progress, Internet-Draft, draft- 2257 hallambaker-mesh-trust-03, 23 October 2019, 2258 . 2261 [RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile", 2262 RFC 2426, DOI 10.17487/RFC2426, September 1998, 2263 . 2265 [RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling 2266 Core Object Specification (iCalendar)", RFC 5545, 2267 DOI 10.17487/RFC5545, September 2009, 2268 .