idnits 2.17.1 draft-hallambaker-mesh-schema-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 13, 2019) is 1719 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 2197 -- Looks like a reference, but probably isn't: '2' on line 2199 -- Looks like a reference, but probably isn't: '3' on line 2201 -- Looks like a reference, but probably isn't: '4' on line 2203 -- Looks like a reference, but probably isn't: '5' on line 2205 -- Looks like a reference, but probably isn't: '6' on line 2207 == Missing Reference: 'TBS' is mentioned on line 975, but not defined -- Looks like a reference, but probably isn't: '7' on line 2209 -- Looks like a reference, but probably isn't: '8' on line 2211 -- Looks like a reference, but probably isn't: '9' on line 2213 -- Looks like a reference, but probably isn't: '10' on line 2215 == Missing Reference: 'NYI' is mentioned on line 1376, but not defined -- Obsolete informational reference (is this intentional?): RFC 2426 (Obsoleted by RFC 6350) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hallam-Baker 3 Internet-Draft August 13, 2019 4 Intended status: Informational 5 Expires: February 14, 2020 7 Mathematical Mesh 3.0 Part IV: Schema Reference 8 draft-hallambaker-mesh-schema-03 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 This document is also available online at 19 http://mathmesh.com/Documents/draft-hallambaker-mesh-schema.html [1] 20 . 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on February 14, 2020. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 59 2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 5 60 2.3. Related Specifications . . . . . . . . . . . . . . . . . 5 61 2.4. Implementation Status . . . . . . . . . . . . . . . . . . 5 62 3. Mesh Assertions . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 6 64 3.2. Mesh Profiles . . . . . . . . . . . . . . . . . . . . . . 6 65 3.3. Mesh Connections . . . . . . . . . . . . . . . . . . . . 7 66 3.4. Mesh Private Declarations . . . . . . . . . . . . . . . . 7 67 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 7 68 4.1. Device Management . . . . . . . . . . . . . . . . . . . . 8 69 4.1.1. Master Profile . . . . . . . . . . . . . . . . . . . 9 70 4.1.2. Mesh Devices . . . . . . . . . . . . . . . . . . . . 11 71 4.2. Mesh Accounts . . . . . . . . . . . . . . . . . . . . . . 17 72 4.2.1. Creating a ProfileAccount . . . . . . . . . . . . . . 19 73 4.2.2. Connecting a Device to an Account . . . . . . . . . . 19 74 4.2.3. Binding and Account to a Service . . . . . . . . . . 20 75 4.3. Mesh Services . . . . . . . . . . . . . . . . . . . . . . 20 76 4.3.1. Creating a ProfileService . . . . . . . . . . . . . . 21 77 4.3.2. Creating a ProfileHost . . . . . . . . . . . . . . . 22 78 4.3.3. Creating a ConnectionHost . . . . . . . . . . . . . . 22 79 4.4. Mesh Messaging . . . . . . . . . . . . . . . . . . . . . 22 80 4.4.1. Traffic Analysis . . . . . . . . . . . . . . . . . . 23 81 5. Mesh Catalogs . . . . . . . . . . . . . . . . . . . . . . . . 24 82 5.1. Application . . . . . . . . . . . . . . . . . . . . . . . 25 83 5.1.1. Mesh Account . . . . . . . . . . . . . . . . . . . . 25 84 5.1.2. SSH . . . . . . . . . . . . . . . . . . . . . . . . . 25 85 5.1.3. Mail . . . . . . . . . . . . . . . . . . . . . . . . 26 86 5.2. Device . . . . . . . . . . . . . . . . . . . . . . . . . 26 87 5.3. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 26 88 5.4. Credential . . . . . . . . . . . . . . . . . . . . . . . 27 89 5.5. Bookmark . . . . . . . . . . . . . . . . . . . . . . . . 27 90 5.6. Task . . . . . . . . . . . . . . . . . . . . . . . . . . 27 91 5.7. Network . . . . . . . . . . . . . . . . . . . . . . . . . 28 92 6. Mesh Messages . . . . . . . . . . . . . . . . . . . . . . . . 28 93 6.1. Completion . . . . . . . . . . . . . . . . . . . . . . . 28 94 6.2. Connection . . . . . . . . . . . . . . . . . . . . . . . 28 95 6.3. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 29 96 6.4. Confirmation . . . . . . . . . . . . . . . . . . . . . . 30 98 7. Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 99 7.1. Shared Classes . . . . . . . . . . . . . . . . . . . . . 31 100 7.1.1. Classes describing keys . . . . . . . . . . . . . . . 31 101 7.1.2. Structure: PublicKey . . . . . . . . . . . . . . . . 31 102 7.1.3. Structure: KeyComposite . . . . . . . . . . . . . . . 31 103 7.1.4. Structure: KeyOverlay . . . . . . . . . . . . . . . . 31 104 7.1.5. Structure: EscrowedKeySet . . . . . . . . . . . . . . 31 105 7.1.6. Structure: DeviceRecryptionKey . . . . . . . . . . . 32 106 7.2. Assertion classes . . . . . . . . . . . . . . . . . . . . 32 107 7.2.1. Structure: Assertion . . . . . . . . . . . . . . . . 32 108 7.2.2. Structure: Condition . . . . . . . . . . . . . . . . 32 109 7.2.3. Profile Classes . . . . . . . . . . . . . . . . . . . 32 110 7.2.4. Structure: Profile . . . . . . . . . . . . . . . . . 32 111 7.2.5. Structure: ProfilePersonal . . . . . . . . . . . . . 33 112 7.2.6. Structure: ProfileDevice . . . . . . . . . . . . . . 33 113 7.2.7. Structure: ProfileService . . . . . . . . . . . . . . 33 114 7.2.8. Structure: ProfileAccount . . . . . . . . . . . . . . 34 115 7.2.9. Structure: ProfileGroup . . . . . . . . . . . . . . . 34 116 7.2.10. Structure: ProfileHost . . . . . . . . . . . . . . . 34 117 7.2.11. Connection Classes . . . . . . . . . . . . . . . . . 34 118 7.2.12. Structure: Connection . . . . . . . . . . . . . . . . 34 119 7.2.13. Structure: Permission . . . . . . . . . . . . . . . . 35 120 7.2.14. Structure: ConnectionDevice . . . . . . . . . . . . . 35 121 7.2.15. Structure: ConnectionAccount . . . . . . . . . . . . 35 122 7.2.16. Structure: ConnectionService . . . . . . . . . . . . 36 123 7.2.17. Structure: ConnectionHost . . . . . . . . . . . . . . 36 124 7.2.18. Structure: ConnectionApplication . . . . . . . . . . 36 125 7.2.19. Activation Classes . . . . . . . . . . . . . . . . . 36 126 7.2.20. Structure: Activation . . . . . . . . . . . . . . . . 36 127 7.2.21. Structure: ActivationDevice . . . . . . . . . . . . . 36 128 7.2.22. Structure: ActivationAccount . . . . . . . . . . . . 37 129 7.3. Cataloged items . . . . . . . . . . . . . . . . . . . . . 37 130 7.3.1. Data Structures . . . . . . . . . . . . . . . . . . . 37 131 7.3.2. Structure: Contact . . . . . . . . . . . . . . . . . 37 132 7.3.3. Structure: Role . . . . . . . . . . . . . . . . . . . 38 133 7.3.4. Structure: Address . . . . . . . . . . . . . . . . . 39 134 7.3.5. Structure: Location . . . . . . . . . . . . . . . . . 39 135 7.3.6. Structure: Reference . . . . . . . . . . . . . . . . 39 136 7.3.7. Structure: Task . . . . . . . . . . . . . . . . . . . 40 137 7.4. Catalog Entries . . . . . . . . . . . . . . . . . . . . . 41 138 7.4.1. Structure: CatalogedEntry . . . . . . . . . . . . . . 41 139 7.4.2. Structure: CatalogedDevice . . . . . . . . . . . . . 41 140 7.4.3. Structure: CatalogedCredential . . . . . . . . . . . 41 141 7.4.4. Structure: CatalogedNetwork . . . . . . . . . . . . . 42 142 7.4.5. Structure: CatalogedContact . . . . . . . . . . . . . 42 143 7.4.6. Structure: CatalogedContactRecryption . . . . . . . . 42 144 7.4.7. Structure: CatalogedBookmark . . . . . . . . . . . . 43 145 7.4.8. Structure: CatalogedTask . . . . . . . . . . . . . . 43 146 7.4.9. Structure: CatalogedApplication . . . . . . . . . . . 43 147 7.4.10. Structure: CatalogedApplicationAccount . . . . . . . 43 148 7.4.11. Structure: CatalogedMember . . . . . . . . . . . . . 44 149 7.4.12. Structure: CatalogedGroup . . . . . . . . . . . . . . 44 150 7.4.13. Structure: CatalogedApplicationSSH . . . . . . . . . 44 151 7.4.14. Structure: CatalogedApplicationMail . . . . . . . . . 44 152 7.4.15. Structure: CatalogedApplicationNetwork . . . . . . . 44 153 7.5. Messages . . . . . . . . . . . . . . . . . . . . . . . . 44 154 7.5.1. Structure: Message . . . . . . . . . . . . . . . . . 44 155 7.5.2. Structure: MessageComplete . . . . . . . . . . . . . 45 156 7.5.3. Structure: MessagePIN . . . . . . . . . . . . . . . . 45 157 7.5.4. Structure: RequestConnection . . . . . . . . . . . . 45 158 7.5.5. Structure: AcknowledgeConnection . . . . . . . . . . 46 159 7.5.6. Structure: RequestContact . . . . . . . . . . . . . . 46 160 7.5.7. Structure: RequestConfirmation . . . . . . . . . . . 46 161 7.5.8. Structure: ResponseConfirmation . . . . . . . . . . . 46 162 7.5.9. Structure: RequestTask . . . . . . . . . . . . . . . 47 163 8. Security Considerations . . . . . . . . . . . . . . . . . . . 47 164 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 165 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 47 166 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 167 11.1. Normative References . . . . . . . . . . . . . . . . . . 47 168 11.2. Informative References . . . . . . . . . . . . . . . . . 48 169 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 48 170 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 49 172 1. Introduction 174 This document describes the data structures of the Mathematical Mesh 175 with illustrative examples. For an overview of the Mesh objectives 176 and architecture, consult the accompanying Architecture Guide 177 [draft-hallambaker-mesh-architecture] . For information on the 178 implementation of the Mesh Service protocol, consult the accompanying 179 Protocol Reference [draft-hallambaker-mesh-protocol] 181 This document has two main sections. The first section presents 182 examples of the Mesh assertions, catalog entry and messages in use. 183 The second section contains the schema reference. All the material 184 in both sections is generated from the Mesh reference implementation 185 [draft-hallambaker-mesh-developer] . 187 Although some of the services described in this document could be 188 used to replace existing Internet protocols including FTP and SMTP, 189 the principal value of any communication protocol lies in the size of 190 the audience it allows them to communicate with. Thus, while the 191 Mesh Messaging service is designed to support efficient and reliable 192 transfer of messages ranging in size from a few bytes to multiple 193 terabytes, the near-term applications of these services will be to 194 applications that are not adequately supported by existing protocols 195 if at all. 197 2. Definitions 199 This section presents the related specifications and standard, the 200 terms that are used as terms of art within the documents and the 201 terms used as requirements language. 203 2.1. Requirements Language 205 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 206 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 207 document are to be interpreted as described in [RFC2119] . 209 2.2. Defined Terms 211 The terms of art used in this document are described in the Mesh 212 Architecture Guide [draft-hallambaker-mesh-architecture] . 214 2.3. Related Specifications 216 The architecture of the Mathematical Mesh is described in the Mesh 217 Architecture Guide [draft-hallambaker-mesh-architecture] . The Mesh 218 documentation set and related specifications are described in this 219 document. 221 2.4. Implementation Status 223 The implementation status of the reference code base is described in 224 the companion document [draft-hallambaker-mesh-developer] . 226 3. Mesh Assertions 228 Mesh Assertions are signed DARE Envelopes that contain one of more 229 claims. Mesh Assertions provide the basis for trust in the 230 Mathematical Mesh. 232 Mesh Assertions are divided into two classes. Mesh Profiles are 233 self-signed assertions. Assertions that are not self-signed are 234 called declarations. The only type of declaration currently defined 235 is a Connection Declaration describing the connection of one profile 236 to another. Currently, five profile and four connection types are 237 defined: 239 [[This figure is not viewable in this format. The figure is 240 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 241 schema.html [2].]] 243 Profiles And Connections 245 3.1. Encoding 247 The payload of a Mesh Assertion is a JSON encoded object that is a 248 subclass of the Assertion class which defines the following fields: 250 Identifier An identifier for the assertion. 252 Updated The date and time at which the assertion was issued or last 253 updated 255 NotaryToken An assertion may optionally contain one or more notary 256 tokens issued by a Mesh Notary service. These establish a proof 257 that the assertion was signed after the date the notary token was 258 created. 260 Conditions A list of conditions that MAY be used to verify the 261 status of the assertion if the relying party requires. 263 The implementation of the NotaryToken and Conditions mechanisms is to 264 be specified in [draft-hallambaker-mesh-notary] at a future date. 266 Note that the implementation of Conditions differs significantly from 267 that of SAML. Relying parties are required to process condition 268 clauses in a SAML assertion to determine validity. Mesh Relying 269 parties MAY verify the conditions clauses or rely on the 270 trustworthiness of the provider. 272 The reason for weakening the processing of conditions clauses in the 273 Mesh is that it is only ever possible to validate a conditions clause 274 of any type relative to a ground truth. In SAML applications, the 275 relying party almost invariably has access to an independent source 276 of ground truth. A Mesh device connected to a Mesh Service does not. 277 Thus the types of verification that can be achieved in practice are 278 limited to verifying the consistency of current and previous 279 statements from the Mesh Service. 281 3.2. Mesh Profiles 283 Mesh Profiles perform a similar role to X.509v3 certificates but with 284 important differences: 286 o Profiles describe credentials, they do not make identity 287 statements 289 o Profiles do not expire, there is therefore no need to support 290 renewal processing. 292 o Profiles may be modified over time, the current and past status of 293 a profile being recorded in an append only log. 295 Profiles provide the axioms of trust for the Mesh PKI. Unlike in the 296 PKIX model in which all trust flows from axioms of trust held by a 297 small number of Certificate Authorities, every part in the Mesh 298 contributes their own axiom of trust. 300 It should be noted however that the role of Certificate Authorities 301 is redefined rather than eliminated. Rather than making assertions 302 whose subject is represented by identities which are inherently 303 mutable and subjective, Certificate Authorities can now make 304 assertions about immutable cryptographic keys. 306 Every Profile MUST contain a SignatureKey field and MUST be signed by 307 the key specified in that field. 309 A Profile is valid if and only if: 311 o There is a SignatureKey field. 313 o The profile is signed under the key specified in the SignatureKey 314 field. 316 A profile has the status current if and only if: 318 o The Profile is valid 320 o Every Conditions clause in the profile is understood by the 321 relying party and evaluates to true. 323 3.3. Mesh Connections 325 3.4. Mesh Private Declarations 327 4. Architecture 329 The Mesh architecture has four principal components: 331 Mesh Device Management Binds a collection of devices that the owner 332 of the Mesh uses together to function as a single personal Mesh. 334 Mesh Account Contains all the information (contacts, calendar 335 entries, inbound and outbound messages, etc.) related to a 336 particular persona used by the owner. 338 Mesh Service Provides a service identifier (e.g. alice@example.com) 339 through which devices and other Mesh users may interact with a 340 Mesh Account. 342 Mesh Messaging 344 Allows short messages (less than 32KB) to be exchanged between Mesh 345 devices connected to an account and between Mesh Accounts. 347 Device management and Accounts components are defined by a data 348 schema alone. The Service and Messaging components are defined by a 349 data schema and a service protocol. 351 The separation of accounts and services as separate components is a 352 key distinction between the Mesh and earlier Internet applications. 353 A Mesh account belongs to the owner of the Mesh and not the account 354 service provider which the user may change at any time of their 355 choosing. A Mesh account may be connected to multiple service 356 providers to provide backup capability or to none. 358 For example, Alice's personal Mesh has one Master Profile, multiple 359 device profiles (two of which are shown here) and two Account 360 Profiles. Her Personal account is connected to two Mesh services 361 while her Business account is not currently connected to any service: 363 [[This figure is not viewable in this format. The figure is 364 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 365 schema.html [3].]] 367 Alice's Personal Mesh 369 In normal circumstances, a user will create a personal Mesh and add 370 their first device, account and service at once. These are shown 371 here as separate operations to illustrate the separation of the Mesh 372 components. 374 4.1. Device Management 376 Device Management provides the foundation for all Mesh functions 377 allowing a collection of devices belonging to a user to function as a 378 single personal Mesh. 380 The device management layer of a personal Mesh consists of exactly 381 one Master Profile and a catalog containing the entries describing 382 the connected devices. 384 4.1.1. Master Profile 386 A Mesh master profile provides the axiom of trust for a mesh user. 387 It contains a Master Signature Key and one or more Administration 388 Signature Keys. The unique identifier of the master profile is the 389 UDF of the Master Signature Key. 391 A Master Profile MAY contain one or more MasterEscrowKeys. These MAY 392 be used to escrow private keys used for encryption. They SHOULD NOT 393 be used to escrow authentication keys and MUST NOT be used to escrow 394 signature keys. 396 [[This figure is not viewable in this format. The figure is 397 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 398 schema.html [4].]] 400 Master Profile and Associated Device and Account Connection 401 Assertions. 403 A user should not need to replace their master profile unless they 404 intend to establish a separate identity. To minimize the risk of 405 disclosure, the Master Signature Key is only ever used to sign 406 updates to the master profile itself. This allows the user to secure 407 their Master Signature Key by either keeping it on hardware token or 408 device dedicated to that purpose or by using the escrow mechanism and 409 paper recovery keys as described in this document. 411 Alice creates a ProfileMaster with one administration key and one 412 master escrow key: 414 { 415 "ProfilePersonal":{ 416 "KeyOfflineSignature":{ 417 "UDF":"MAOZ-3MVE-G5EN-64BI-I3RM-ODFJ-H5W4", 418 "PublicParameters":{ 419 "PublicKeyECDH":{ 420 "crv":"Ed448", 421 "Public":"0Vxq105QJ4y0IJu_pE2iBm6y7NTruQQkZhUIJGYu-6mBhNJ 422 CTKjnSIkkb6SK6aLRlzpwv-UWCzMA"}}}, 423 "KeysOnlineSignature":[{ 424 "UDF":"MBE7-UCJF-ZAZ2-MLGP-LB55-HZBT-XMHV", 425 "PublicParameters":{ 426 "PublicKeyECDH":{ 427 "crv":"Ed448", 428 "Public":"Rd3snDZ-iOOYA1BSphd7H9J1C5xfSR2ojBEGK1SljRUD0 429 8MR4tFsWo0Y2cGCOYLbHIi6aT6HffAA"}}} 430 ], 431 "KeyEncryption":{ 432 "UDF":"MBGA-C2UQ-QFVG-5HNA-2WTZ-IKNK-EWHT", 433 "PublicParameters":{ 434 "PublicKeyECDH":{ 435 "crv":"Ed448", 436 "Public":"42IyVJWg4W1J9-F0itPADd00yAYQwB8kWP0UkYWLqJuR6g0 437 wnkYQCF8Zr4zTe2lNhDPUf8BR8VSA"}}}}} 439 4.1.1.1. Creating a ProfileMaster 441 Creating a ProfileMaster comprises the steps of: 443 1. Creating a Master Signature key. 445 2. Creating an Online Signing Key 447 3. Signing the ProfileMaster using the Master Signature Key 449 4. Persisting the ProfileMaster on the administration device to the 450 CatalogHost. 452 5. (Optional) Connecting at least one Administration Device and 453 granting it the ActivationAdministration activation. 455 4.1.1.2. Updating a ProfileMaster 457 Updating a ProfileMaster comprises the steps of: 459 1. Making the necessary changes. 461 2. Signing the ProfileMaster using the Master Signature Key 462 3. Persisting the ProfileMaster on the administration device to the 463 CatalogHost. 465 4.1.1.3. The Device Catalog 467 Each personal Mesh has a Device Catalog CatalogDevice associated with 468 it. The Device Catalog is used to manage the connection of devices 469 to the Personal Mesh and has a CatalogEntryDevice for each device 470 currently connected to the catalog. 472 Each Administration Device MUST have access to an up to date copy of 473 the Device Catalog in order to manage the devices connected to the 474 Mesh. The Mesh Service protocol MAY be used to synchronize the 475 Device Catalog between administration devices in the case that there 476 is more than one administration device. 478 The CatalogEntryDevice contains fields for the device profile, device 479 private and device connection. 481 4.1.2. Mesh Devices 483 The principle of radical distrust requires us to consider the 484 possibility that a device might be compromised during manufacture. 485 Once consequence of this possibility is that when an administration 486 device connects a new device to a user's personal Mesh, we cannot put 487 our full trust in either the device being connected or the 488 administration device connecting it. 490 This concern is resolved by (at minimum) combining keying material 491 generated from both sources to create the keys to be used in the 492 context of the user's personal Mesh with the process being fully 493 verified by both parties. 495 Additional keying material sources could be added if protection 496 against the possibility of compromise at both devices was required 497 but this is not supported by the current specifications. 499 A device profile provides the axiom of trust and the key 500 contributions of the device: 502 [[This figure is not viewable in this format. The figure is 503 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 504 schema.html [5].]] 506 Mapping of Device Profile and Device Private to Device Connection 507 Keys. 509 Unless exceptional circumstances require, a device should not require 510 more than one Device profile even if the device supports use by 511 multiple users under different accounts. But a device MAY have 512 multiple profiles if this approach is more convenient for 513 implementation. 515 Alice's Device Profile specifies keys for encryption, signature and 516 exchange: 518 { 519 "ProfileDevice":{ 520 "KeyOfflineSignature":{ 521 "UDF":"MABG-6ZLL-I2FM-KUKX-TM7E-OVAJ-M5QP", 522 "PublicParameters":{ 523 "PublicKeyECDH":{ 524 "crv":"Ed448", 525 "Public":"9Fot0c6ztURHkCY0pLew5-9cjGvP72EztCSx0xwh0IstC-I 526 kb7fdzwv_vcEA6f6eyJF4HD-mGSeA"}}}, 527 "KeyEncryption":{ 528 "UDF":"MB3L-TNWX-HNZI-FFHN-IJRZ-HSOF-NKZL", 529 "PublicParameters":{ 530 "PublicKeyECDH":{ 531 "crv":"Ed448", 532 "Public":"CUG3q5c8uFglVWyGeMnxybLprQAKHvqb-V9UbRQ5OS3LB9J 533 j1H7k8i9HQpiyhNvCZ5mcb5Rti_6A"}}}, 534 "KeyAuthentication":{ 535 "UDF":"MD6N-VQ4H-6EQO-DT3S-IUMN-C5OJ-CDXR", 536 "PublicParameters":{ 537 "PublicKeyECDH":{ 538 "crv":"Ed448", 539 "Public":"IodXkMxsyg6kUsKFSlS8mDvxe5ZKSuSU0r-lXoY2Tvp0CMo 540 F34NAloV1RpAjTaPhVPJLdgaLspYA"}}}}} 542 Since the Device Profile keys are ultimately under the control of the 543 device and/or software provider, these are considered insufficiently 544 trustworthy and the administration device creates key contributions 545 to be added to the device keys to establish the key set to be used in 546 the context of the user's personal Mesh: 548 { 549 "ActivationDevice":{ 550 "KeySignature":{ 551 "UDF":"MDAA-75W5-HOD4-LSSU-JNYG-WHML-34DU", 552 "BaseUDF":"MABG-6ZLL-I2FM-KUKX-TM7E-OVAJ-M5QP", 553 "Overlay":{ 554 "PrivateKeyECDH":{ 555 "crv":"Ed448", 556 "Private":"hchEs5Is89D_B89_04Y24dau12P7hVvGlIY5JJVRevREwG 557 LZsuRaDnsJTDaW7yEbKwQMTdhky5k"}}}, 558 "KeyEncryption":{ 559 "UDF":"MDBS-VUEM-T4LN-V6SG-OLAZ-DBXD-BEKR", 560 "BaseUDF":"MB3L-TNWX-HNZI-FFHN-IJRZ-HSOF-NKZL", 561 "Overlay":{ 562 "PrivateKeyECDH":{ 563 "crv":"Ed448", 564 "Private":"idvk3TtbV_tE1P0jEFyMZAnrOWrODow6TnvsuNpGUIrqte 565 QaRHLM35tA53Nca7Fyl2_8NpA85Ps"}}}, 566 "KeyAuthentication":{ 567 "UDF":"MC2O-YPA4-NZYJ-4XYX-LV7S-TVCV-ODIH", 568 "BaseUDF":"MD6N-VQ4H-6EQO-DT3S-IUMN-C5OJ-CDXR", 569 "Overlay":{ 570 "PrivateKeyECDH":{ 571 "crv":"Ed448", 572 "Private":"Sq5L14DMmsCG0WC4gBzc3RGMq4QSrl1DBautaEDSNQFLQP 573 RFD4CR2h1Iq057HKuNk5IDViidsyA"}}}}} 575 The resulting key set is specified in the device connection: 577 { 578 "ConnectionDevice":{ 579 "KeySignature":{ 580 "UDF":"MDAA-75W5-HOD4-LSSU-JNYG-WHML-34DU", 581 "PublicParameters":{ 582 "PublicKeyECDH":{ 583 "crv":"Ed448", 584 "Public":"CHU3vyEJRMDuHnzZev5GqO-0iK-lOBxowBEUsOUaWN-KUe0 585 RZHa5d-a3xBEQtG-0o0rq5LwKvJwA"}}}, 586 "KeyEncryption":{ 587 "UDF":"MDBS-VUEM-T4LN-V6SG-OLAZ-DBXD-BEKR", 588 "PublicParameters":{ 589 "PublicKeyECDH":{ 590 "crv":"Ed448", 591 "Public":"VW2pEXUUgHkvV7e4DhsX8qjLr4Z5-qGkyBsfCRUdmtyGqdq 592 RGYXA8qeGvP4GcrMlhlmtJ_tEQBcA"}}}, 593 "KeyAuthentication":{ 594 "UDF":"MC2O-YPA4-NZYJ-4XYX-LV7S-TVCV-ODIH", 595 "PublicParameters":{ 596 "PublicKeyECDH":{ 597 "crv":"Ed448", 598 "Public":"Yz1ljn0ykFMNussK778qoua202kBugeeCRj35OL7VqBxYOw 599 8nG4BcmHTH3cIKdJohQB4H3T1ikOA"}}}}} 601 All the above are combined to form the CatalogedDevice entry: 603 { 604 "CatalogedDevice":{ 605 "UDF":"MDAA-75W5-HOD4-LSSU-JNYG-WHML-34DU", 606 "DeviceUDF":"MABG-6ZLL-I2FM-KUKX-TM7E-OVAJ-M5QP", 607 "EnvelopedProfileDevice":[{ 608 "dig":"S512", 609 "cty":"application/mmm"}, 610 "ewogICJQcm9maWxlRGV2aWNlIjogewogICAgIktleU9mZmxpbmVTaWduYXR1 611 cmUiOiB7CiAgICAgICJVREYiOiAiTUFCRy02WkxMLUkyRk0tS1VLWC1UTTdFLU9WQ 612 UotTTVRUCIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdW 613 JsaWNLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6ICJFZDQ0OCIsCiAgICAgICA 614 gICAiUHVibGljIjogIjlGb3QwYzZ6dFVSSGtDWTBwTGV3NS05Y2pHdlA3MkV6dENT 615 eDB4d2gwSXN0Qy1Ja2I3ZmQKICB6d3ZfdmNFQTZmNmV5SkY0SEQtbUdTZUEifX19L 616 AogICAgIktleUVuY3J5cHRpb24iOiB7CiAgICAgICJVREYiOiAiTUIzTC1UTldYLU 617 hOWkktRkZITi1JSlJaLUhTT0YtTktaTCIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJ 618 zIjogewogICAgICAgICJQdWJsaWNLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6 619 ICJFZDQ0OCIsCiAgICAgICAgICAiUHVibGljIjogIkNVRzNxNWM4dUZnbFZXeUdlT 620 W54eWJMcHJRQUtIdnFiLVY5VWJSUTVPUzNMQjlKajFIN2sKICA4aTlIUXBpeWhOdk 621 NaNW1jYjVSdGlfNkEifX19LAogICAgIktleUF1dGhlbnRpY2F0aW9uIjogewogICA 622 gICAiVURGIjogIk1ENk4tVlE0SC02RVFPLURUM1MtSVVNTi1DNU9KLUNEWFIiLAog 623 ICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgICAiUHVibGljS2V5RUNES 624 CI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICAgICAgIlB1YmxpYy 625 I6ICJJb2RYa014c3lnNmtVc0tGU2xTOG1EdnhlNVpLU3VTVTByLWxYb1kyVHZwMEN 626 Nb0YzNE5BCiAgbG9WMVJwQWpUYVBoVlBKTGRnYUxzcFlBIn19fX19", 627 { 628 "signatures":[{ 629 "signature":"zTXCLitDmFOuBcza1RqH_DgGOhyP7WpVk3ndttT7OA 630 Nlxf7RQc7n6fcmfKLqeyuINT04YfPwC94Ac5Fv0Mi_jzOPdJBcipuAu-_nH6ArIcD 631 uxfiat7kbAfSJmv4dMJV_gzIdynf6yX6WH6SA7VVSpxAA"} 632 ], 633 "PayloadDigest":"qFInJ114BiGrkbKq-TvoQ3b0ztUyVu_1qmIwUed3nj 634 mYeguyZov8nIQKNdnuFmGYfYKxOW2n-Usz-4PHvHAyDg"} 635 ], 636 "EnvelopedConnectionDevice":[{ 637 "dig":"S512"}, 638 "ewogICJDb25uZWN0aW9uRGV2aWNlIjogewogICAgIktleVNpZ25hdHVyZSI6 639 IHsKICAgICAgIlVERiI6ICJNREFBLTc1VzUtSE9ENC1MU1NVLUpOWUctV0hNTC0zN 640 ERVIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0 641 tleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIkVkNDQ4IiwKICAgICAgICAgICJ 642 QdWJsaWMiOiAiQ0hVM3Z5RUpSTUR1SG56WmV2NUdxTy0waUstbE9CeG93QkVVc09V 643 YVdOLUtVZTBSWkhhNQogIGQtYTN4QkVRdEctMG8wcnE1THdLdkp3QSJ9fX0sCiAgI 644 CAiS2V5RW5jcnlwdGlvbiI6IHsKICAgICAgIlVERiI6ICJNREJTLVZVRU0tVDRMTi 645 1WNlNHLU9MQVotREJYRC1CRUtSIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB 646 7CiAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIkVk 647 NDQ4IiwKICAgICAgICAgICJQdWJsaWMiOiAiVlcycEVYVVVnSGt2VjdlNERoc1g4c 648 WpMcjRaNS1xR2t5QnNmQ1JVZG10eUdxZHFSR1lYQQogIDhxZUd2UDRHY3JNbGhsbX 649 RKX3RFUUJjQSJ9fX0sCiAgICAiS2V5QXV0aGVudGljYXRpb24iOiB7CiAgICAgICJ 650 VREYiOiAiTUMyTy1ZUEE0LU5aWUotNFhZWC1MVjdTLVRWQ1YtT0RJSCIsCiAgICAg 651 ICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdWJsaWNLZXlFQ0RIIjoge 652 wogICAgICAgICAgImNydiI6ICJFZDQ0OCIsCiAgICAgICAgICAiUHVibGljIjogIl 653 l6MWxqbjB5a0ZNTnVzc0s3Nzhxb3VhMjAya0J1Z2VlQ1JqMzVPTDdWcUJ4WU93OG5 654 HNEIKICBjbUhUSDNjSUtkSm9oUUI0SDNUMWlrT0EifX19fX0", 655 { 656 "signatures":[{ 657 "signature":"LakNIBxHRHIWfUdZuKKt_UzGpwJPxLXSDHvS43pzFO 658 G8Q4FJzacaO1MsS3piW6Mjwcq8kvGZr7QArwewDVCGXsF-fO43zlk8iEeJBA8csWz 659 ika412bjVSvT--oNjKYtaeRLBYcM656e7ITOdjft_sR8A"} 660 ], 661 "PayloadDigest":"sUSwjnOWHrs5n7CUZCr72SHFGJYYiNgxtg8fIcUEeQ 662 u1Mhjwz3iI-UAjJ1yRQQnmsZ_YEf_aBzSWRK077LwX2w"} 663 ], 664 "EnvelopedActivationDevice":[{ 665 "enc":"none", 666 "Salt":"cJK1bnGuELszHVogMXTj3Q", 667 "cty":"application/mmm", 668 "recipients":[{ 669 "kid":"MB3L-TNWX-HNZI-FFHN-IJRZ-HSOF-NKZL", 670 "epk":{ 671 "PublicKeyECDH":{ 672 "crv":"Ed448", 673 "Public":"8bUnsSVeSoF5wzTXjEw4uNfXb0gTgP0_qV_utnBl3 674 SuIIub6LKfeLcArA8pEwnzk7-GrtJkBCCsA"}}, 675 "wmk":"pqampqampqY"}, 676 { 677 "kid":"MBGA-C2UQ-QFVG-5HNA-2WTZ-IKNK-EWHT", 678 "epk":{ 679 "PublicKeyECDH":{ 680 "crv":"Ed448", 681 "Public":"JqQ0Xz152usfWTlj7dITf6AUpC-IglIEXq7babkUB 682 WZ57lRRHegc0CIo3McqAHqp6kAR7d34alOA"}}, 683 "wmk":"pqampqampqY"} 684 ]}, 685 "ewogICJBY3RpdmF0aW9uRGV2aWNlIjogewogICAgIktleVNpZ25hdHVyZSI6 686 IHsKICAgICAgIlVERiI6ICJNREFBLTc1VzUtSE9ENC1MU1NVLUpOWUctV0hNTC0zN 687 ERVIiwKICAgICAgIkJhc2VVREYiOiAiTUFCRy02WkxMLUkyRk0tS1VLWC1UTTdFLU 688 9WQUotTTVRUCIsCiAgICAgICJPdmVybGF5IjogewogICAgICAgICJQcml2YXRlS2V 689 5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICAgICAgIlBy 690 aXZhdGUiOiAiaGNoRXM1SXM4OURfQjg5XzA0WTI0ZGF1MTJQN2hWdkdsSVk1SkpWU 691 mV2UkV3R0xac3VSCiAgYURuc0pURGFXN3lFYkt3UU1UZGhreTVrIn19fSwKICAgIC 692 JLZXlFbmNyeXB0aW9uIjogewogICAgICAiVURGIjogIk1EQlMtVlVFTS1UNExOLVY 693 2U0ctT0xBWi1EQlhELUJFS1IiLAogICAgICAiQmFzZVVERiI6ICJNQjNMLVROV1gt 694 SE5aSS1GRkhOLUlKUlotSFNPRi1OS1pMIiwKICAgICAgIk92ZXJsYXkiOiB7CiAgI 695 CAgICAgIlByaXZhdGVLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6ICJFZDQ0OC 696 IsCiAgICAgICAgICAiUHJpdmF0ZSI6ICJpZHZrM1R0YlZfdEUxUDBqRUZ5TVpBbnJ 697 PV3JPRG93NlRudnN1TnBHVUlycXRlUWFSSEwKICBNMzV0QTUzTmNhN0Z5bDJfOE5w 698 QTg1UHMifX19LAogICAgIktleUF1dGhlbnRpY2F0aW9uIjogewogICAgICAiVURGI 699 jogIk1DMk8tWVBBNC1OWllKLTRYWVgtTFY3Uy1UVkNWLU9ESUgiLAogICAgICAiQm 700 FzZVVERiI6ICJNRDZOLVZRNEgtNkVRTy1EVDNTLUlVTU4tQzVPSi1DRFhSIiwKICA 701 gICAgIk92ZXJsYXkiOiB7CiAgICAgICAgIlByaXZhdGVLZXlFQ0RIIjogewogICAg 702 ICAgICAgImNydiI6ICJFZDQ0OCIsCiAgICAgICAgICAiUHJpdmF0ZSI6ICJTcTVMM 703 TRETW1zQ0cwV0M0Z0J6YzNSR01xNFFTcmwxREJhdXRhRURTTlFGTFFQUkZENEMKIC 704 BSMmgxSXEwNTdIS3VOazVJRFZpaWRzeUEifX19fX0" 705 ]}} 707 The derivation of the Connection encryption and signature keys from 708 the Profile and Private contributions in this example is shown in 709 [draft-hallambaker-mesh-cryptography] . 711 4.1.2.1. Creating a ProfileDevice 713 Creating a ProfileDevice comprises the steps of: 715 1. Creating the necessary key 717 2. Signing the ProfileDevice using the Master Signature Key 718 3. Once created, a ProfileDevice is never changed. In the unlikely 719 event that any modification is required, a completely new 720 ProfileDevice MUST be created. 722 4.1.2.2. Connection to a Personal Mesh 724 Devices are only connected to a personal Mesh by administration 725 device. This comprises the steps of: 727 1. Generating the PrivateDevice keys. 729 2. Creating the ConnectionDevice data from the public components of 730 the ProfileDevice and PrivateDevice keys and signing it using the 731 administration key. 733 3. Creating the Activations for the device and signing them using 734 the administration key. 736 4. Creating the CatalogEntryDevice for the device and adding it to 737 the CatalogDevice of the Personal Mesh. 739 5. If the Personal Mesh has accounts that are connected to a Mesh 740 Service, synchronizing the CatalogEntryDevice to those services. 742 4.2. Mesh Accounts 744 Mesh Accounts contains all the stateful information (contacts, 745 calendar entries, inbound and outbound messages, etc.) related to a 746 particular persona used by the owner. 748 A Mesh Profile MAY be connected to multiple accounts at the same time 749 allowing the user to maintain separate personas for separate 750 purposes. 752 Unlike traditional Internet application accounts, Mesh accounts are 753 created by and belong to the user, not the Mesh Service provider. A 754 user MAY change their Mesh Service provider at any time and 755 disconnect the profile from all Mesh Services (e.g. to archive the 756 account). 758 Alice's personal account is connected to two Mesh services: 760 [[This figure is not viewable in this format. The figure is 761 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 762 schema.html [6].]] 764 Account Profile Connected to Devices and Services. 766 The account profile specifies the online and offline signature keys 767 used to maintain the profile and the encryption key to be used by the 768 account. 770 { 771 "ProfileAccount":{ 772 "MeshProfileUDF":"MAOZ-3MVE-G5EN-64BI-I3RM-ODFJ-H5W4", 773 "KeyEncryption":{ 774 "UDF":"MAFZ-VUMP-7PU3-4TP7-7MRZ-BKBQ-VMNN", 775 "PublicParameters":{ 776 "PublicKeyECDH":{ 777 "crv":"Ed448", 778 "Public":"1lcZUNjHGJWkPWmS9MHeGYNfDSZGUO4lGk5Xpq7XgH--SGL 779 QE4E_s-0b0PI8m0fjtzIMUEYDI_IA"}}}}} 781 Each device using the account requires an activation record: 783 { 784 "ActivationAccount":{ 785 "AccountUDF":"MAFZ-VUMP-7PU3-4TP7-7MRZ-BKBQ-VMNN", 786 "EnvelopedAssertionAccountConnection":[{ 787 "dig":"S512"}, 788 "ewogICJDb25uZWN0aW9uQWNjb3VudCI6IHsKICAgICJLZXlTaWduYXR1cmUi 789 OiB7CiAgICAgICJVREYiOiAiTURZTC02RzJBLVkzRUctVTNGRy1IQVkzLVNOTE4tT 790 llQMiIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdWJsaW 791 NLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6ICJFZDQ0OCIsCiAgICAgICAgICA 792 iUHVibGljIjogIkkzcDFocE50YnN3dWhEaU5kdGxNVnBTMVF0amxjbkh0bmZxdE5I 793 WHFYVVBxT1pZbTF0WGIKICAxUDRNRWZjQXZvVHlNZ1lZdUZWdXlBV0EifX19LAogI 794 CAgIktleUVuY3J5cHRpb24iOiB7CiAgICAgICJVREYiOiAiTUFGWi1WVU1QLTdQVT 795 MtNFRQNy03TVJaLUJLQlEtVk1OTiIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjo 796 gewogICAgICAgICJQdWJsaWNLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6ICJF 797 ZDQ0OCIsCiAgICAgICAgICAiUHVibGljIjogIjFsY1pVTmpIR0pXa1BXbVM5TUhlR 798 1lOZkRTWkdVTzRsR2s1WHBxN1hnSC0tU0dMUUU0RV8KICBzLTBiMFBJOG0wZmp0ek 799 lNVUVZRElfSUEifX19LAogICAgIktleUF1dGhlbnRpY2F0aW9uIjogewogICAgICA 800 iVURGIjogIk1DTlctUVVSTi1XNzVFLVRIRTYtUDJSQS1RN1BOLUlNVFkiLAogICAg 801 ICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgICAiUHVibGljS2V5RUNESCI6I 802 HsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICAgICAgIlB1YmxpYyI6IC 803 JjRW5xYWkyWmU0NTFNVHBQSWNPNDFlcHZPTlNaOFk2d2dQMFZ1N2o4ckcwbTZHMUd 804 LWUplCiAgSlJEUTROMEhTUVFkUUVGMjNDaHkxWFNBIn19fX19", 805 { 806 "signatures":[{ 807 "signature":"jm8gei5o49kwvBEbFGB9E9SpxdmIpoTzF7QXqL2IGF 808 e8dCsPfbDQKkO0x7v95Aw7SsOZ7p_KLysAJJg5ly8W02jwhQhLa4DCf2sthWA82yv 809 yHnMFysD4rAzyxi3J9b2BEXpS8e_OXKcy_Y5syjq-_gAA"} 810 ], 811 "PayloadDigest":"oKJFUfV-FrLaHCbGvk_GTyUVxRPGSgUM5AuwnuHgLK 812 ANfb_cz0GIHDiYCpIYIbWnajerZZDNARd8R_4M5va4Ow"} 813 ], 815 "KeyEncryption":{ 816 "Public":{ 817 "PublicKeyECDH":{ 818 "crv":"Ed448", 819 "Public":"1lcZUNjHGJWkPWmS9MHeGYNfDSZGUO4lGk5Xpq7XgH--SGL 820 QE4E_s-0b0PI8m0fjtzIMUEYDI_IA"}}, 821 "Part":{ 822 "PrivateKeyECDH":{ 823 "crv":"Ed448", 824 "Private":"0wzAsNH-Ft8i3GcK585BXuECOXwQCS1V_bPJxhjHURA7we 825 SPHfLh-ThoRkAF6Em0jtST4mG0FBI"}}}, 826 "KeyAuthentication":{ 827 "UDF":"MCNW-QURN-W75E-THE6-P2RA-Q7PN-IMTY", 828 "BaseUDF":"MD6N-VQ4H-6EQO-DT3S-IUMN-C5OJ-CDXR", 829 "Overlay":{ 830 "PrivateKeyECDH":{ 831 "crv":"Ed448", 832 "Private":"8E50eTfRcL9ghQUyOnSvI3wagGsYGQaKSXj09KxNRMzq5T 833 DaKD-E-HroSc8wJapds-bHDSoShgM"}}}, 834 "KeySignature":{ 835 "UDF":"MDYL-6G2A-Y3EG-U3FG-HAY3-SNLN-NYP2", 836 "BaseUDF":"MABG-6ZLL-I2FM-KUKX-TM7E-OVAJ-M5QP", 837 "Overlay":{ 838 "PrivateKeyECDH":{ 839 "crv":"Ed448", 840 "Private":"Ye28IFBvRvxKCc5r5c-cAPYjGhLFw_dCt5ScuFzAx7bAlt 841 WviYPsk_bD5ndt3oKReFUT30EpFOg"}}}}} 843 4.2.1. Creating a ProfileAccount 845 Creating a ProfileAccount comprises the steps of: 847 1. [TBS] 849 2. . 851 3. Signing the ProfileMaster using the Master Signature Key 853 4.2.2. Connecting a Device to an Account 855 Adding a device to an account comprises the steps of: 857 1. Creating a PrivateAccount instance for the device. 859 2. Creating a ConnectionAccountDevice for the device using the 860 public keys from the PrivateAccount instance and the 861 ProfileDevice. 863 3. Creating an ActivationAccount for the device containing the 864 PrivateAccount and ConnectionAccountDevice instances. 866 4. Adding the ActivationAccount to the CatalogEntryDevice of the 867 device. 869 5. If the Personal Mesh has accounts that are connected to a Mesh 870 Service, synchronizing the CatalogEntryDevice to those services. 872 4.2.3. Binding and Account to a Service 874 Binding a ProfileAccount to a Mesh Service the steps of: 876 1. [TBS] 878 2. . 880 3. Signing the ProfileMaster using the Master Signature Key 882 4.3. Mesh Services 884 A service profile provides the axiom of trust and cryptographic keys 885 for a Mesh Service. A Mesh Service Host SHOULD return a copy of its 886 ProfileHost and the parent ProfileService in response to a Hello 887 transaction request. 889 [[This figure is not viewable in this format. The figure is 890 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 891 schema.html [7].]] 893 Service Profile and Delegated Host Assertion. 895 The credentials provided by the ProfileService and ProfileHost are 896 distinct from those provided by the WebPKI that typically services 897 TLS requests. WebPKI credentials provide service introduction and 898 authentication while a Mesh ProfileHost only provides authentication. 900 Unless exceptional circumstances require, a service should not need 901 to revise its Service Profile unless it is intended to change its 902 identity. Service Profiles MAY be countersigned by Trusted Third 903 Parties to establish accountability. 905 The service profile 906 { 907 "ProfileService":{ 908 "KeyOfflineSignature":{ 909 "UDF":"MBCP-OGFY-KFAQ-6EO3-VX6S-6V4G-ENNU", 910 "PublicParameters":{ 911 "PublicKeyECDH":{ 912 "crv":"Ed448", 913 "Public":"mHlROSazpUTzwFNZ0qI1MbXjpthOUxple0W8NUaq8M71VT5 914 eNwXjcfQ-tMlLgwq_Uff1FGmmlH-A"}}}}} 916 The host also has a profile 918 { 919 "ProfileHost":{ 920 "KeyOfflineSignature":{ 921 "UDF":"MDKQ-VTTD-HQKB-YH6O-H57C-4KDH-6KWI", 922 "PublicParameters":{ 923 "PublicKeyECDH":{ 924 "crv":"Ed448", 925 "Public":"ouDlKyIUksS_CWUhqoWaPFP93Ka9Zg53dQCC44guaGOBB9S 926 12eHlz2KoX9-PctQH31567TcmMDCA"}}}, 927 "KeyAuthentication":{ 928 "UDF":"MC3D-ID62-L5VZ-IWLC-WRLX-7FTT-F7ST", 929 "PublicParameters":{ 930 "PublicKeyECDH":{ 931 "crv":"Ed448", 932 "Public":"4BfeW0WQB5O3EOrjW4LvAdkLz71BtJsls3wzw0acuH5Edup 933 WWT8vE3MObkkfmD_4tPZ7B6VanteA"}}}}} 935 And there should be a connection of the host to the service but this 936 isn't implemented yet: 938 $$$$ Empty $$$$ 940 4.3.1. Creating a ProfileService 942 [TBS] 944 Creating a ProfileService comprises the steps of: 946 1. [TBS] 948 2. . 950 3. [TBS] 952 4. 954 5. Signing the ProfileMaster using the Master Signature Key 956 4.3.2. Creating a ProfileHost 958 Creating a ProfileHost comprises the steps of: 960 1. [TBS] 962 2. . 964 3. [TBS] 966 4. 968 5. Signing the ConnectionHost using the Master Signature Key of the 969 ProfileService. 971 4.3.3. Creating a ConnectionHost 973 Creating a ConnectionHost comprises the steps of: 975 1. [TBS] 977 2. . 979 3. Signing the ConnectionHost using the Master Signature Key of the 980 ProfileService. 982 4.4. Mesh Messaging 984 Mesh Messaging is an end-to-end secure messaging system used to 985 exchange short (32KB) messages between Mesh devices and services. In 986 cases where exchange of longer messages is required, Mesh Messaging 987 MAY be used to provide a control plane to advise the intended message 988 recipient(s) of the type of data being offered and the means of 989 retrieval (e.g an EARL). 991 A four-corner messaging model is enforced. Mesh Services only accept 992 outbound messages from devices connected to accounts that it 993 services. Inbound messages are only accepted from other Mesh 994 Services. This model enables access control at both the outbound and 995 inbound services 997 [[This figure is not viewable in this format. The figure is 998 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 999 schema.html [8].]] 1001 Performing Access Control on Outbound Messages 1003 The outbound Mesh Service checks to see that the message request does 1004 not violate its acceptable use policy. Accounts that make a large 1005 number of message requests that result in complaints SHOULD be 1006 subject to consequences ranging from restriction of the number and 1007 type of messages sent to suspending or terminating messaging 1008 privileges. 1010 [[This figure is not viewable in this format. The figure is 1011 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 1012 schema.html [9].]] 1014 Performing Access Control on Outbound Messages 1016 The inbound Mesh Service also checks to see that messages received 1017 are consistent with the service Acceptable Use Policy and the user's 1018 personal access control settings. 1020 Mesh Services that fail to police abuse by their account holders 1021 SHOULD be subject to consequences in the same fashion as account 1022 holders. 1024 [[This figure is not viewable in this format. The figure is 1025 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 1026 schema.html [10].]] 1028 Performing Access Control on Inbound Messages 1030 4.4.1. Traffic Analysis 1032 The Mesh Messaging protocol as currently specified provides only 1033 limited protection against traffic analysis attacks. The use of TLS 1034 to encrypt communication between Mesh Services limits the 1035 effectiveness of na?ve traffic analysis mechanisms but does not 1036 prevent timing attacks unless dummy traffic is introduced to 1037 obfuscate traffic flows. 1039 The limitation of the message size is in part intended to facilitate 1040 use of mechanisms capable of providing high levels of traffic 1041 analysis such as mixmaster and onion routing but the current Mesh 1042 Service Protocol does not provide support for such approaches and 1043 there are no immediate plans to do so. 1045 5. Mesh Catalogs 1047 Catalogs track sets of persistent objects associated with a Mesh 1048 Service Account. The Mesh Service has no access to the entries in 1049 any Mesh catalog except for the Device and Contacts catalog which are 1050 used in device authentication and authorization of inbound messages. 1052 Each Mesh Catalog managed by a Mesh Account has a name of the form: 1054 <_ 1056 Where < is the IANA assigned service name. The assigned 1057 service name for the Mathematical Mesh is mmm. Thus, all catalogs 1058 specified by the Mesh schema have names prefixed with the sequence 1059 mmm_. 1061 The following catalogs are currently specified within the 1062 Mathematical Mesh. 1064 Application: mmm_CatalogApplication Contains configuration 1065 information for applications including mail (SMTP, IMAP, OpenPGP, 1066 S/MIME, etc) and SSH and for the MeshAccount application itself. 1068 Device: mmm_CatalogDevice Contains descriptions of devices connected 1069 to the account and the permissions assigned to them 1071 Contact: mmm_CatalogContact Contains logical and physical contact 1072 information for people and organizations. 1074 Credential: mmm_CatalogCredential Contains credentials used to 1075 access network resources. 1077 Bookmark: mmm_CatalogBookmark Contains Web bookmarks and other 1078 citations allowing them to be shared between devices connected to 1079 the profile. 1081 Task: mmm_CatalogTask Contains tasks assigned to the user including 1082 calendar entries and to do lists. 1084 Network: mmm_CatalogNetwork Contains network settings such as WiFi 1085 access points, IPSEC and TLS VPN configurations, etc. 1087 In many cases, the Mesh Catalog offers capabilities that represent a 1088 superset of the capabilities of an existing application. For 1089 example, the task catalog supports the appointment tracking functions 1090 of a traditional calendar application and the task tracking function 1091 of the traditional 'to do list' application. Combining these 1092 functions allows tasks to be triggered by other events other than the 1093 passage of time such as completion of other tasks, geographical 1094 presence, etc. 1096 In such cases, the Mesh Catalog entries are designed to provide a 1097 superset of the data representation capabilities of the legacy 1098 formats and (where available) recent extensions. Where a catalog 1099 entry is derived from input presented in a legacy format, the 1100 original data representation MAY be attached verbatim to facilitate 1101 interoperability. 1103 5.1. Application 1105 The application catalog mmm_CatalogApplication contains 1106 CatalogEntryApplication entries which describe the use of specific 1107 applications under the Mesh Service Account. Multiple application 1108 accounts for a single application MAY be connected to a single Mesh 1109 Service Account. Each account being specified in a separate entry. 1111 The CatalogEntryApplication entries only contain configuration 1112 information for the application as it applies to the account as a 1113 whole. If the application requires separate configuration for 1114 individual devices, this is specified in separate activation records 1115 specified in the corresponding ConnectionDevice. 1117 5.1.1. Mesh Account 1119 Mesh Accounts are described by CatalogEntryAccount entries. The 1120 corresponding activation records for the connected devices contain 1121 the contributions used to derive the private keys for use of the 1122 account. 1124 The CatalogEntryAccount entry is described in the section describing 1125 Mesh accounts above. 1127 5.1.2. SSH 1129 SSH configuration profiles are described by 1130 CatalogEntryApplicationSSH entries. The corresponding activation 1131 records for the connected devices contain the contributions used to 1132 derive the private keys. 1134 A user may have separate SSH configurations for separate purposes 1135 within a single Mesh Account. This allows a system administrator 1136 servicing multiple clients to maintain separate SSH profiles for each 1137 of her customers allowing credentials to be easily (and verifiably) 1138 revoked at contract termination. 1140 The SSH profile contains the information that is stored in the 1141 known_hosts and authorized_keys files of SSH clients and servers. 1143 $$$$ Empty $$$$ 1145 5.1.3. Mail 1147 Mail configuration profiles are described by one or more 1148 CatalogEntryApplicationMail entries, one for each email account 1149 connected to the Mesh profile. The corresponding activation records 1150 for the connected devices contain information used to provide the 1151 device with the necessary decryption information. 1153 Entries specify the email account address(es), the inbound and 1154 outbound server configuration and the cryptographic keys to be used 1155 for S/MIME and OpenPGP encryption. 1157 $$$$ Empty $$$$ 1159 5.2. Device 1161 The device catalog mmm_CatalogDevice contains CatalogEntryDevice 1162 entries which describe the devices connected to the account and the 1163 permissions assigned to them. 1165 The management of the device catalog is described in the section 1166 describing Mesh Device Management. 1168 5.3. Contact 1170 The contacts catalog contains CatalogEntryContact entries which 1171 describe 1173 $$$$ Empty $$$$ 1175 The fields of the contact catalog provide a superset of the 1176 capabilities of vCard [RFC2426] . 1178 The Contact catalog is typically used by the MeshService as a source 1179 of authorization information to perform access control on inbound and 1180 outbound message requests. For this reason, Mesh Service SHOULD be 1181 granted read access to the contacts catalog by providing a decryption 1182 entry for the service. 1184 5.4. Credential 1186 The credential catalog contains CatalogEntryCredential entries which 1187 describe credentials used to access network resources. 1189 Only username/password credentials are stored in the credential 1190 catalog. If public key credentials are to be used, these SHOULD 1191 be managed as an application profile allowing separate credentials 1192 to be created for each device. 1194 { 1195 "CatalogedCredential":{ 1196 "Service":"ftp.example.com", 1197 "Username":"alice1", 1198 "Password":"newpassword"}} 1200 5.5. Bookmark 1202 The bookmark catalog contains CatalogEntryBookmark entries which 1203 describe Web bookmarks and other citations allowing them to be shared 1204 between devices connected to the profile. 1206 The fields currently supported by the Bookmarks catalog are currently 1207 limited to the fields required for tracking Web bookmarks. 1208 Specification of additional fields to track full academic citations 1209 is a work in progress. 1211 { 1212 "CatalogedBookmark":{ 1213 "Uri":"http://example.net/Bananas", 1214 "Title":"\"Banana", 1215 "Path":"Folder1/2"}} 1217 5.6. Task 1219 The Task catalog contains CatalogEntryTask entries which describe 1220 tasks assigned to the user including calendar entries and to do 1221 lists. 1223 The fields of the task catalog currently reflect those offered by the 1224 iCalendar specification [RFC5545] . Specification of additional 1225 fields to allow task triggering on geographic location and/or 1226 completion of other tasks is a work in progress. 1228 { 1229 "CatalogedTask":{ 1230 "Key":"CalID1"}} 1232 5.7. Network 1234 The network catalog contains CatalogEntryNetwork entries which 1235 describe network settings, IPSEC and TLS VPN configurations, etc. 1237 $$$$ Empty $$$$ 1239 6. Mesh Messages 1241 All communications between Mesh accounts takes the form of a Mesh 1242 Message carried in a Dare Envelope. Mesh Messages are stored in two 1243 spools associated with the account, the SpoolOutbound and the 1244 SpoolInbound containing the messages sent and received respectively. 1246 This document only describes the representation of the messages 1247 within the message spool. The Mesh Service protocol by which the 1248 messages are exchanged between devices and services and between 1249 services is described in [draft-hallambaker-mesh-protocol] . 1251 6.1. Completion 1253 Completion messages are dummy messages that are added to a Mesh Spool 1254 to change the status of messages previously posted. Any message that 1255 is in the inbound spool and has not been erased or redacted MAY be 1256 marked as read, unread or deleted. Any message in the outbound spool 1257 MAY be marked as sent, received or deleted. 1259 Services MAY erase or redact messages in accordance with local site 1260 policy. Since messages are not removed from the spool on being 1261 marked deleted, they may be undeleted by marking them as read or 1262 unread. Marking a message deleted MAY make it more likely that the 1263 Service will purge the message however. 1265 Having processed a message, a completion message is added to the 1266 spool so that other devices can see that it has been read: 1268 [NYI] 1270 6.2. Connection 1272 Connection requests are sent by a device requesting connection to a 1273 Mesh Service Account. 1275 The MessageConnectionRequest is originally sent by the device 1276 requesting connection to the Mesh Service associated with the 1277 account. 1279 If the connection request is accepted by the Mesh Service, it creates 1280 a MessageConnectionResponse containing the ServerNonce and Witness 1281 values used in the authentication of the response together with a 1282 verbatim copy of the original request. The MessageConnectionResponse 1283 is then returned to the device that made the original request and 1284 placed on the SpoolInbound of the account to which the request was 1285 directed. 1287 Further details of this mechanism are described in 1288 [draft-hallambaker-mesh-protocol] . 1290 The connection process begins with the assignment of a time-limited 1291 PIN value. This is described in a Message sent by the administration 1292 device to allow other admin devices to accept the request made. 1294 [NYI] 1296 The initial request is sent to the service 1298 [NYI] 1300 The service returns an acknowledgement giving the Witness value. 1301 Note that this is not a 'reply' since it comes from the service, not 1302 the user. 1304 [NYI] 1306 [Note, this mechanism should be revised to ensure that there is 1307 perfect forward secrecy. The device should provide a nonce key as a 1308 mixin] 1310 6.3. Contact 1312 A contact request presents a proposed contact entry and requests that 1313 it be added to the Contacts catalog of the specified Mesh Service 1314 Account. A contact request is usually sent by the party requesting 1315 that their contact be added but this is not necessarily the case. 1317 The MessageContact contains a DARE Envelope containing the Contact 1318 information of the requester. If the request is accepted, this 1319 information will be added to the contact catalog of the relevant 1320 account. If the Reply field has the value 'true', this indicates 1321 that the sender is asking for the recipient to return their own 1322 credentials in reply. 1324 Since the sender requires the user's contact information before the 1325 request can be made, the MessageContact message MAY be encrypted 1326 under either the user's account encryption key (if known) or the Mesh 1327 Service encryption key (which may be obtained from the service on 1328 request. 1330 Bob asks Alice to send her contact details and sends his. 1332 [NYI] 1334 Alice responds with her details: 1336 [NYI] 1338 [Note that this exchange could be performed automatically on Alice's 1339 behalf by the service if she delegates this action to it.] 1341 The current protocol assumes that all contact management will be 1342 performed end-to-end through the Mesh Services themselves. If the 1343 number of Mesh users were to become very large, additional 1344 infrastructure to facilitate contact management will be required. 1345 These topics are discussed at a high level in 1346 [draft-hallambaker-mesh-trust] . 1348 In situations where a user is well known and has a very large number 1349 of contacts, they are likely to make use of a tiered approach to 1350 contact management in which they keep separate accounts for their 1351 'public' and 'restricted' personas and delegate management of their 1352 public account to a subordinate or to their Mesh Service provider. 1354 6.4. Confirmation 1356 Confirmation messages are used to provide an improved form of second 1357 factor authentication capability. 1359 Two confirmation messages are specified, a request and response. 1361 A confirmation request is initiated by sending a 1362 MessageConfirmationRequest to the Mesh Service hosting the recipient 1363 Mesh Service Account. The request specifies the question that is to 1364 be put to the user. 1366 To respond to a confirmation request, a user generates a 1367 MessageConfirmationResponse. This MUST be signed by a device 1368 authorized to respond to confirmation requests by a Device Connection 1369 Assertion with the Confirmation privilege. 1371 The confirmation request 1373 [NYI] 1374 The confirmation response 1376 [NYI] 1378 7. Schema 1380 7.1. Shared Classes 1382 The following classes are used as common elements in Mesh profile 1383 specifications. 1385 7.1.1. Classes describing keys 1387 7.1.2. Structure: PublicKey 1389 The PublicKey class is used to describe public key pairs and trust 1390 assertions associated with a public key. 1392 UDF: String (Optional) UDF fingerprint of the public key parameters/ 1394 X509Certificate: Binary (Optional) List of X.509 Certificates 1396 X509Chain: Binary [0..Many] X.509 Certificate chain. 1398 X509CSR: Binary (Optional) X.509 Certificate Signing Request. 1400 7.1.3. Structure: KeyComposite 1402 Service: String (Optional) Service holding the additional 1403 contribution 1405 7.1.4. Structure: KeyOverlay 1407 UDF: String (Optional) Fingerprint of the resulting composite key 1408 (to allow verification) 1410 BaseUDF: String (Optional) Fingerprint specifying the base key 1412 7.1.5. Structure: EscrowedKeySet 1414 A set of escrowed keys. 1416 [No fields] 1418 7.1.6. Structure: DeviceRecryptionKey 1420 UDF: String (Optional) The fingerprint of the encryption key 1422 RecryptionKey: PublicKey (Optional) The recryption key 1424 EnvelopedRecryptionKeyDevice: DareEnvelope (Optional) The decryption 1425 key encrypted under the user's device key. 1427 7.2. Assertion classes 1429 Classes that are derived from an assertion. 1431 7.2.1. Structure: Assertion 1433 Parent class from which all assertion classes are derived 1435 Names: String [0..Many] Fingerprints of index terms for profile 1436 retrieval. The use of the fingerprint of the name rather than the 1437 name itself is a precaution against enumeration attacks and other 1438 forms of abuse. 1440 Updated: DateTime (Optional) The time instant the profile was last 1441 modified. 1443 NotaryToken: String (Optional) A Uniform Notary Token providing 1444 evidence that a signature was performed after the notary token was 1445 created. 1447 7.2.2. Structure: Condition 1449 Parent class from which all condition classes are derived. 1451 [No fields] 1453 7.2.3. Profile Classes 1455 Profiles are self signed assertions. 1457 7.2.4. Structure: Profile 1459 Inherits: Assertion 1461 Parent class from which all profile classes are derived 1463 KeyOfflineSignature: PublicKey (Optional) The permanent signature 1464 key used to sign the profile itself. The UDF of the key is used 1465 as the permanent object identifier of the profile. Thus, by 1466 definition, the KeySignature value of a Profile does not change 1467 under any circumstance. The only case in which a 1469 KeysOnlineSignature: PublicKey [0..Many] A Personal profile contains 1470 at least one OSK which is used to sign device administration 1471 application profiles. 1473 7.2.5. Structure: ProfilePersonal 1475 Inherits: Profile 1477 Describes the long term parameters associated with a personal 1478 profile. 1480 KeysMasterEscrow: PublicKey [0..Many] A Personal Profile MAY contain 1481 one or more PMEK keys to enable escrow of private keys used for 1482 stored data. 1484 KeyEncryption: PublicKey (Optional) Key used to pass encrypted data 1485 to the device such as a DeviceUseEntry 1487 7.2.6. Structure: ProfileDevice 1489 Inherits: Profile 1491 Describes a mesh device. 1493 Description: String (Optional) Description of the device 1495 KeyEncryption: PublicKey (Optional) Key used to pass encrypted data 1496 to the device such as a DeviceUseEntry 1498 KeyAuthentication: PublicKey (Optional) Key used to authenticate 1499 requests made by the device. 1501 7.2.7. Structure: ProfileService 1503 Inherits: Profile 1505 Profile of a Mesh Service 1507 KeyAuthentication: PublicKey (Optional) Key used to authenticate 1508 service connections. 1510 7.2.8. Structure: ProfileAccount 1512 Inherits: Profile 1514 Account assertion. This is signed by the service hosting the 1515 account. 1517 ServiceIDs: String [0..Many] Service address(es). 1519 MeshProfileUDF: String (Optional) Master profile of the account 1520 being registered. 1522 KeyEncryption: PublicKey (Optional) Key used to encrypt data under 1523 this profile 1525 7.2.9. Structure: ProfileGroup 1527 Inherits: Profile 1529 Describes a group. Note that while a group is created by one person 1530 who becomes its first administrator, control of the group may pass to 1531 other administrators over time. 1533 [No fields] 1535 7.2.10. Structure: ProfileHost 1537 Inherits: Profile 1539 Inherits: Profile 1541 KeyAuthentication: PublicKey (Optional) Key used to authenticate 1542 service connections. 1544 7.2.11. Connection Classes 1546 7.2.12. Structure: Connection 1548 Inherits: Assertion 1550 Inherits: Assertion 1552 SubjectUDF: String (Optional) UDF of the connection target. 1554 AuthorityUDF: String (Optional) UDF of the connection source. 1556 7.2.13. Structure: Permission 1558 Name: String (Optional) 1560 Name: String (Optional) 1562 Role: String (Optional) 1564 Role: String (Optional) 1566 Capabilities: DareEnvelope (Optional) Keys or key contributions 1567 enabling the operation to be performed 1569 7.2.14. Structure: ConnectionDevice 1571 Inherits: Connection 1573 Inherits: Connection 1575 Permissions: Permission [0..Many] List of the permissions that the 1576 device has been granted. 1578 KeySignature: PublicKey (Optional) The signature key for use of the 1579 device under the profile 1581 KeyEncryption: PublicKey (Optional) The encryption key for use of 1582 the device under the profile 1584 KeyAuthentication: PublicKey (Optional) The authentication key for 1585 use of the device under the profile 1587 7.2.15. Structure: ConnectionAccount 1589 Inherits: Connection 1591 Inherits: Connection 1593 Permissions: Permission [0..Many] List of the permissions that the 1594 device has been granted. 1596 KeySignature: PublicKey (Optional) The signature key for use of the 1597 device under the profile 1599 KeyEncryption: PublicKey (Optional) The encryption key for use of 1600 the device under the profile 1602 KeyAuthentication: PublicKey (Optional) The authentication key for 1603 use of the device under the profile 1605 7.2.16. Structure: ConnectionService 1607 Inherits: Connection 1609 [No fields] 1611 7.2.17. Structure: ConnectionHost 1613 Inherits: Connection 1615 [No fields] 1617 7.2.18. Structure: ConnectionApplication 1619 Inherits: Connection 1621 [No fields] 1623 7.2.19. Activation Classes 1625 7.2.20. Structure: Activation 1627 Inherits: Assertion 1629 Contains the private activation information for a Mesh application 1630 running on a specific device 1632 [No fields] 1634 7.2.21. Structure: ActivationDevice 1636 Inherits: Assertion 1638 Inherits: Assertion 1640 EnvelopedAssertionDeviceConnection: DareEnvelope (Optional) The 1641 signed AssertionDeviceConnection. 1643 KeySignature: KeyOverlay (Optional) The key overlay used to generate 1644 the account signature key from the device signature key 1646 KeyEncryption: KeyOverlay (Optional) The key overlay used to 1647 generate the account encryption key from the device encryption key 1649 KeyAuthentication: KeyOverlay (Optional) The key overlay used to 1650 generate the account authentication key from the device 1651 authentication key 1653 7.2.22. Structure: ActivationAccount 1655 Inherits: Activation 1657 Inherits: Activation 1659 AccountUDF: String (Optional) The UDF of the account 1661 EnvelopedAssertionAccountConnection: DareEnvelope (Optional) The 1662 account connection assertion 1664 KeyEncryption: KeyComposite (Optional) The key contribution for the 1665 decryption key for the device. NB this is NOT an overlay on the 1666 device signature key, it is an overlay on the corresponding 1667 recryption key. 1669 KeyAuthentication: KeyOverlay (Optional) The key overlay used to 1670 generate the account authentication key from the device 1671 authentication key 1673 KeySignature: KeyOverlay (Optional) The key overlay used to generate 1674 the account signature key from the device signature key 1676 7.3. Cataloged items 1678 7.3.1. Data Structures 1680 Classes describing data used in cataloged data. 1682 7.3.2. Structure: Contact 1684 Inherits: Assertion 1686 Inherits: Assertion 1688 Identifier: String (Optional) 1690 Identifier: String (Optional) 1692 FullName: String (Optional) 1694 FullName: String (Optional) 1696 Title: String (Optional) 1698 Title: String (Optional) 1700 First: String (Optional) 1701 First: String (Optional) 1703 Middle: String (Optional) 1705 Middle: String (Optional) 1707 Last: String (Optional) 1709 Last: String (Optional) 1711 Suffix: String (Optional) 1713 Suffix: String (Optional) 1715 Labels: String [0..Many] 1717 Labels: String [0..Many] 1719 AssertionAccounts: ProfileAccount [0..Many] 1721 AssertionAccounts: ProfileAccount [0..Many] 1723 Addresses: Address [0..Many] 1725 Addresses: Address [0..Many] 1727 Locations: Location [0..Many] 1729 Locations: Location [0..Many] 1731 Roles: Role [0..Many] 1733 7.3.3. Structure: Role 1735 CompanyName: String (Optional) 1737 CompanyName: String (Optional) 1739 Addresses: Address [0..Many] 1741 Addresses: Address [0..Many] 1743 Locations: Location [0..Many] 1745 7.3.4. Structure: Address 1747 URI: String (Optional) 1749 URI: String (Optional) 1751 Labels: String [0..Many] 1753 7.3.5. Structure: Location 1755 Appartment: String (Optional) 1757 Appartment: String (Optional) 1759 Street: String (Optional) 1761 Street: String (Optional) 1763 District: String (Optional) 1765 District: String (Optional) 1767 Locality: String (Optional) 1769 Locality: String (Optional) 1771 County: String (Optional) 1773 County: String (Optional) 1775 Postcode: String (Optional) 1777 Postcode: String (Optional) 1779 Country: String (Optional) 1781 7.3.6. Structure: Reference 1783 MessageID: String (Optional) The received message to which this is a 1784 response 1786 ResponseID: String (Optional) Message that was generated in response 1787 to the original (optional). 1789 Relationship: String (Optional) The relationship type. This can be 1790 Read, Unread, Accept, Reject. 1792 7.3.7. Structure: Task 1794 Key: String (Optional) Unique key. 1796 Start: DateTime (Optional) 1798 Start: DateTime (Optional) 1800 Finish: DateTime (Optional) 1802 Finish: DateTime (Optional) 1804 StartTravel: String (Optional) 1806 StartTravel: String (Optional) 1808 FinishTravel: String (Optional) 1810 FinishTravel: String (Optional) 1812 TimeZone: String (Optional) 1814 TimeZone: String (Optional) 1816 Title: String (Optional) 1818 Title: String (Optional) 1820 Description: String (Optional) 1822 Description: String (Optional) 1824 Location: String (Optional) 1826 Location: String (Optional) 1828 Trigger: String [0..Many] 1830 Trigger: String [0..Many] 1832 Conference: String [0..Many] 1834 Conference: String [0..Many] 1836 Repeat: String (Optional) 1838 Repeat: String (Optional) 1839 Busy: Boolean (Optional) 1841 7.4. Catalog Entries 1843 7.4.1. Structure: CatalogedEntry 1845 Base class for cataloged Mesh data. 1847 [No fields] 1849 7.4.2. Structure: CatalogedDevice 1851 Inherits: CatalogedEntry 1853 Public device entry, indexed under the device ID 1855 AccountUDFs: String [0..Many] The accounts to which this device is 1856 bound. 1858 UDF: String (Optional) UDF of the signature key of the device in the 1859 Mesh 1861 DeviceUDF: String (Optional) UDF of the signature key of the device 1863 EnvelopedProfileDevice: DareEnvelope (Optional) The device profile 1865 EnvelopedConnectionDevice: DareEnvelope (Optional) The public 1866 assertion demonstrating connection of the Device to the Mesh 1868 EnvelopedActivationDevice: DareEnvelope (Optional) The device 1869 profile 1871 7.4.3. Structure: CatalogedCredential 1873 Inherits: CatalogedEntry 1875 Inherits: CatalogedEntry 1877 Protocol: String (Optional) 1879 Protocol: String (Optional) 1881 Service: String (Optional) 1883 Service: String (Optional) 1885 Username: String (Optional) 1886 Username: String (Optional) 1888 Password: String (Optional) 1890 7.4.4. Structure: CatalogedNetwork 1892 Inherits: CatalogedEntry 1894 Inherits: CatalogedEntry 1896 Protocol: String (Optional) 1898 Protocol: String (Optional) 1900 Service: String (Optional) 1902 Service: String (Optional) 1904 Username: String (Optional) 1906 Username: String (Optional) 1908 Password: String (Optional) 1910 7.4.5. Structure: CatalogedContact 1912 Inherits: CatalogedEntry 1914 Inherits: CatalogedEntry 1916 Self: Boolean (Optional) If true, this catalog entry is for the user 1917 who created the catalog. To be valid, such an entry MUST be 1918 signed by an administration key for the Mesh profile containing 1919 the account to which the catalog belongs. 1921 Key: String (Optional) Unique key. 1923 Permissions: Permission [0..Many] List of the permissions that the 1924 contact has been granted. 1926 EnvelopedContact: DareEnvelope (Optional) The (signed) contact data. 1928 7.4.6. Structure: CatalogedContactRecryption 1930 Inherits: CatalogedContact 1932 [No fields] 1934 7.4.7. Structure: CatalogedBookmark 1936 Inherits: CatalogedEntry 1938 Inherits: CatalogedEntry 1940 Uri: String (Optional) 1942 Uri: String (Optional) 1944 Title: String (Optional) 1946 Title: String (Optional) 1948 Path: String (Optional) 1950 7.4.8. Structure: CatalogedTask 1952 Inherits: CatalogedEntry 1954 Inherits: CatalogedEntry 1956 EnvelopedTask: DareEnvelope (Optional) 1958 EnvelopedTask: DareEnvelope (Optional) 1960 Key: String (Optional) Unique key. 1962 7.4.9. Structure: CatalogedApplication 1964 Inherits: CatalogedEntry 1966 Inherits: CatalogedEntry 1968 Key: String (Optional) 1970 7.4.10. Structure: CatalogedApplicationAccount 1972 Wrapper for a signed AccountAssertion 1974 Inherits: CatalogedApplication 1976 Inherits: CatalogedApplication 1978 EnvelopedProfileAccount: DareEnvelope (Optional) The account 1979 assertion 1981 7.4.11. Structure: CatalogedMember 1983 UDF: String (Optional) 1985 UDF: String (Optional) 1987 Inherits: CatalogedEntry 1989 7.4.12. Structure: CatalogedGroup 1991 Inherits: CatalogedApplication 1993 [No fields] 1995 7.4.13. Structure: CatalogedApplicationSSH 1997 Inherits: CatalogedApplication 1999 [No fields] 2001 7.4.14. Structure: CatalogedApplicationMail 2003 Inherits: CatalogedApplication 2005 [No fields] 2007 7.4.15. Structure: CatalogedApplicationNetwork 2009 Inherits: CatalogedApplication 2011 [No fields] 2013 7.5. Messages 2015 7.5.1. Structure: Message 2017 MessageID: String (Optional) 2019 MessageID: String (Optional) 2021 Sender: String (Optional) 2023 Sender: String (Optional) 2025 Recipient: String (Optional) 2027 Recipient: String (Optional) 2028 References: Reference [0..Many] 2030 7.5.2. Structure: MessageComplete 2032 Inherits: Message 2034 [No fields] 2036 7.5.3. Structure: MessagePIN 2038 Account: String (Optional) 2040 Account: String (Optional) 2042 Inherits: Message 2044 Inherits: Message 2046 Expires: DateTime (Optional) 2048 Expires: DateTime (Optional) 2050 PIN: String (Optional) 2052 7.5.4. Structure: RequestConnection 2054 Connection request message. This message contains the information 2056 Inherits: Message 2058 Inherits: Message 2060 ServiceID: String (Optional) 2062 ServiceID: String (Optional) 2064 EnvelopedProfileDevice: DareEnvelope (Optional) Device profile of 2065 the device making the request. 2067 ClientNonce: Binary (Optional) 2069 ClientNonce: Binary (Optional) 2071 PinUDF: String (Optional) Fingerprint of the PIN value used to 2072 authenticate the request. 2074 7.5.5. Structure: AcknowledgeConnection 2076 Connection request message generated by a service on receipt of a 2077 valid MessageConnectionRequestClient 2079 Inherits: Message 2081 Inherits: Message 2083 EnvelopedRequestConnection: DareEnvelope (Optional) The client 2084 connection request. 2086 ServerNonce: Binary (Optional) 2088 ServerNonce: Binary (Optional) 2090 Witness: String (Optional) 2092 7.5.6. Structure: RequestContact 2094 Inherits: Message 2096 Inherits: Message 2098 Reply: Boolean (Optional) 2100 Reply: Boolean (Optional) 2102 Self: DareEnvelope (Optional) The contact data. 2104 7.5.7. Structure: RequestConfirmation 2106 Inherits: Message 2108 Inherits: Message 2110 Text: String (Optional) 2112 7.5.8. Structure: ResponseConfirmation 2114 Inherits: Message 2116 Inherits: Message 2118 ResponseID: String (Optional) 2120 ResponseID: String (Optional) 2121 Accept: Boolean (Optional) 2123 7.5.9. Structure: RequestTask 2125 Inherits: Message 2127 [No fields] 2129 8. Security Considerations 2131 The security considerations for use and implementation of Mesh 2132 services and applications are described in the Mesh Security 2133 Considerations guide [draft-hallambaker-mesh-security] . 2135 9. IANA Considerations 2137 All the IANA considerations for the Mesh documents are specified in 2138 this document 2140 10. Acknowledgements 2142 A list of people who have contributed to the design of the Mesh is 2143 presented in [draft-hallambaker-mesh-architecture] . 2145 11. References 2147 11.1. Normative References 2149 [draft-hallambaker-mesh-architecture] 2150 Hallam-Baker, P., "Mathematical Mesh 3.0 Part I: 2151 Architecture Guide", draft-hallambaker-mesh- 2152 architecture-09 (work in progress), July 2019. 2154 [draft-hallambaker-mesh-cryptography] 2155 Hallam-Baker, P., "Mathematical Mesh 3.0 Part VIII: 2156 Cryptographic Algorithms", draft-hallambaker-mesh- 2157 cryptography-02 (work in progress), July 2019. 2159 [draft-hallambaker-mesh-notary] 2160 "[Reference Not Found!]". 2162 [draft-hallambaker-mesh-protocol] 2163 Hallam-Baker, P., "Mathematical Mesh Part V: Protocol 2164 Reference", draft-hallambaker-mesh-protocol-01 (work in 2165 progress), July 2019. 2167 [draft-hallambaker-mesh-security] 2168 Hallam-Baker, P., "Mathematical Mesh Part VII: Security 2169 Considerations", draft-hallambaker-mesh-security-01 (work 2170 in progress), July 2019. 2172 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2173 Requirement Levels", BCP 14, RFC 2119, 2174 DOI 10.17487/RFC2119, March 1997. 2176 11.2. Informative References 2178 [draft-hallambaker-mesh-developer] 2179 Hallam-Baker, P., "Mathematical Mesh: Reference 2180 Implementation", draft-hallambaker-mesh-developer-08 (work 2181 in progress), April 2019. 2183 [draft-hallambaker-mesh-trust] 2184 Hallam-Baker, P., "Mathematical Mesh Part VI: The Trust 2185 Mesh", draft-hallambaker-mesh-trust-02 (work in progress), 2186 July 2019. 2188 [RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile", 2189 RFC 2426, DOI 10.17487/RFC2426, September 1998. 2191 [RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling 2192 Core Object Specification (iCalendar)", RFC 5545, 2193 DOI 10.17487/RFC5545, September 2009. 2195 11.3. URIs 2197 [1] http://mathmesh.com/Documents/draft-hallambaker-mesh-schema.html 2199 [2] http://mathmesh.com/Documents/draft-hallambaker-mesh-schema.html 2201 [3] http://mathmesh.com/Documents/draft-hallambaker-mesh-schema.html 2203 [4] http://mathmesh.com/Documents/draft-hallambaker-mesh-schema.html 2205 [5] http://mathmesh.com/Documents/draft-hallambaker-mesh-schema.html 2207 [6] http://mathmesh.com/Documents/draft-hallambaker-mesh-schema.html 2209 [7] http://mathmesh.com/Documents/draft-hallambaker-mesh-schema.html 2211 [8] http://mathmesh.com/Documents/draft-hallambaker-mesh-schema.html 2213 [9] http://mathmesh.com/Documents/draft-hallambaker-mesh-schema.html 2215 [10] http://mathmesh.com/Documents/draft-hallambaker-mesh-schema.html 2217 Author's Address 2219 Phillip Hallam-Baker 2221 Email: phill@hallambaker.com