idnits 2.17.1 draft-hallambaker-mesh-schema-07.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 exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: A Mesh account is an abstract construct that (when active) is instantiated across one or more physical machines called a device. Each device that is connected to an account has a separate set of cryptographic keys that are used to interact with other devices connected to the account and MAY be provisioned with access to the account private keys which MAY or MAY NOT be mediated by the current Mesh Service. -- The document date (13 January 2021) is 1196 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'UDF-Mesh' is mentioned on line 2821, but not defined -- Obsolete informational reference (is this intentional?): RFC 2426 (Obsoleted by RFC 6350) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 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 ThresholdSecrets.com 4 Intended status: Informational 13 January 2021 5 Expires: 17 July 2021 7 Mathematical Mesh 3.0 Part IV: Schema Reference 8 draft-hallambaker-mesh-schema-07 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 17 July 2021. 44 Copyright Notice 46 Copyright (c) 2021 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 . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 6 60 2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 6 61 2.3. Related Specifications . . . . . . . . . . . . . . . . . 6 62 2.4. Implementation Status . . . . . . . . . . . . . . . . . . 6 63 3. Actors . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 3.1. Accounts . . . . . . . . . . . . . . . . . . . . . . . . 7 65 3.2. Device . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 3.2.1. Activation . . . . . . . . . . . . . . . . . . . . . 10 67 3.3. Service . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 4. Catalogs . . . . . . . . . . . . . . . . . . . . . . . . . . 13 69 4.1. Access . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 4.2. Application . . . . . . . . . . . . . . . . . . . . . . . 15 71 4.2.1. Mesh Account . . . . . . . . . . . . . . . . . . . . 15 72 4.2.2. SSH . . . . . . . . . . . . . . . . . . . . . . . . . 15 73 4.2.3. Mail . . . . . . . . . . . . . . . . . . . . . . . . 16 74 4.3. Bookmark . . . . . . . . . . . . . . . . . . . . . . . . 16 75 4.4. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 16 76 4.5. Credential . . . . . . . . . . . . . . . . . . . . . . . 20 77 4.6. Device . . . . . . . . . . . . . . . . . . . . . . . . . 20 78 4.7. Network . . . . . . . . . . . . . . . . . . . . . . . . . 20 79 4.8. Publication . . . . . . . . . . . . . . . . . . . . . . . 20 80 4.9. Task . . . . . . . . . . . . . . . . . . . . . . . . . . 21 81 5. Spools . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 82 5.1. Outbound . . . . . . . . . . . . . . . . . . . . . . . . 22 83 5.2. Inbound . . . . . . . . . . . . . . . . . . . . . . . . . 22 84 5.3. Local . . . . . . . . . . . . . . . . . . . . . . . . . . 22 85 6. Cryptographic Operations . . . . . . . . . . . . . . . . . . 23 86 6.1. Key Derivation from Seed . . . . . . . . . . . . . . . . 23 87 6.2. Message Envelope and Response Identifiers. . . . . . . . 23 88 6.3. Proof of Knowledge of PIN . . . . . . . . . . . . . . . . 24 89 6.4. EARL . . . . . . . . . . . . . . . . . . . . . . . . . . 26 90 6.5. Key Agreement . . . . . . . . . . . . . . . . . . . . . . 27 91 6.6. Service Cryptographic Operations . . . . . . . . . . . . 27 92 7. Mesh Assertions . . . . . . . . . . . . . . . . . . . . . . . 28 93 7.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 28 94 7.2. Mesh Profiles . . . . . . . . . . . . . . . . . . . . . . 29 95 7.3. Mesh Connections . . . . . . . . . . . . . . . . . . . . 30 96 8. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 31 97 8.1. Mesh Account . . . . . . . . . . . . . . . . . . . . . . 32 98 8.1.1. Account Profile . . . . . . . . . . . . . . . . . . . 32 99 8.2. Device Management . . . . . . . . . . . . . . . . . . . . 33 100 8.2.1. The Device Catalog . . . . . . . . . . . . . . . . . 34 101 8.2.2. Mesh Devices . . . . . . . . . . . . . . . . . . . . 34 102 8.3. Mesh Services . . . . . . . . . . . . . . . . . . . . . . 36 103 8.4. Mesh Messaging . . . . . . . . . . . . . . . . . . . . . 37 104 8.4.1. Message Status . . . . . . . . . . . . . . . . . . . 37 105 8.4.2. Four Corner Model . . . . . . . . . . . . . . . . . . 38 106 8.4.3. Traffic Analysis . . . . . . . . . . . . . . . . . . 38 107 9. Publications . . . . . . . . . . . . . . . . . . . . . . . . 39 108 9.1. Contact Exchange . . . . . . . . . . . . . . . . . . . . 39 109 9.2. Device Preconfiguration . . . . . . . . . . . . . . . . . 39 110 9.3. Device Description . . . . . . . . . . . . . . . . . . . 41 111 10. Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 112 10.1. Shared Classes . . . . . . . . . . . . . . . . . . . . . 42 113 10.1.1. Classes describing keys . . . . . . . . . . . . . . 42 114 10.1.2. Structure: KeyData . . . . . . . . . . . . . . . . . 42 115 10.1.3. Structure: CompositePrivate . . . . . . . . . . . . 42 116 10.2. Assertion classes . . . . . . . . . . . . . . . . . . . 42 117 10.2.1. Structure: Assertion . . . . . . . . . . . . . . . . 42 118 10.2.2. Structure: Condition . . . . . . . . . . . . . . . . 43 119 10.2.3. Base Classes . . . . . . . . . . . . . . . . . . . . 43 120 10.2.4. Structure: Connection . . . . . . . . . . . . . . . 43 121 10.2.5. Structure: Activation . . . . . . . . . . . . . . . 43 122 10.2.6. Structure: ActivationEntry . . . . . . . . . . . . . 43 123 10.2.7. Mesh Profile Classes . . . . . . . . . . . . . . . . 43 124 10.2.8. Structure: Profile . . . . . . . . . . . . . . . . . 44 125 10.2.9. Structure: ProfileDevice . . . . . . . . . . . . . . 44 126 10.2.10. Structure: ProfileAccount . . . . . . . . . . . . . 44 127 10.2.11. Structure: ProfileUser . . . . . . . . . . . . . . . 45 128 10.2.12. Structure: ProfileGroup . . . . . . . . . . . . . . 45 129 10.2.13. Structure: ProfileService . . . . . . . . . . . . . 45 130 10.2.14. Structure: ProfileHost . . . . . . . . . . . . . . . 45 131 10.2.15. Connection Assertions . . . . . . . . . . . . . . . 46 132 10.2.16. Structure: ConnectionDevice . . . . . . . . . . . . 46 133 10.2.17. Structure: ConnectionApplication . . . . . . . . . . 46 134 10.2.18. Structure: ConnectionGroup . . . . . . . . . . . . . 46 135 10.2.19. Structure: ConnectionService . . . . . . . . . . . . 47 136 10.2.20. Structure: ConnectionHost . . . . . . . . . . . . . 47 137 10.2.21. Activation Assertions . . . . . . . . . . . . . . . 47 138 10.2.22. Structure: ActivationDevice . . . . . . . . . . . . 47 139 10.2.23. Structure: ActivationAccount . . . . . . . . . . . . 47 140 10.2.24. Structure: ActivationApplication . . . . . . . . . . 47 141 10.3. Data Structures . . . . . . . . . . . . . . . . . . . . 48 142 10.3.1. Structure: Contact . . . . . . . . . . . . . . . . . 48 143 10.3.2. Structure: Anchor . . . . . . . . . . . . . . . . . 48 144 10.3.3. Structure: TaggedSource . . . . . . . . . . . . . . 48 145 10.3.4. Structure: ContactGroup . . . . . . . . . . . . . . 49 146 10.3.5. Structure: ContactPerson . . . . . . . . . . . . . . 49 147 10.3.6. Structure: ContactOrganization . . . . . . . . . . . 49 148 10.3.7. Structure: OrganizationName . . . . . . . . . . . . 49 149 10.3.8. Structure: PersonName . . . . . . . . . . . . . . . 49 150 10.3.9. Structure: NetworkAddress . . . . . . . . . . . . . 50 151 10.3.10. Structure: NetworkProtocol . . . . . . . . . . . . . 50 152 10.3.11. Structure: Role . . . . . . . . . . . . . . . . . . 50 153 10.3.12. Structure: Location . . . . . . . . . . . . . . . . 50 154 10.3.13. Structure: Bookmark . . . . . . . . . . . . . . . . 51 155 10.3.14. Structure: Reference . . . . . . . . . . . . . . . . 51 156 10.3.15. Structure: Task . . . . . . . . . . . . . . . . . . 51 157 10.4. Catalog Entries . . . . . . . . . . . . . . . . . . . . 52 158 10.4.1. Structure: CatalogedEntry . . . . . . . . . . . . . 52 159 10.4.2. Structure: CatalogedDevice . . . . . . . . . . . . . 52 160 10.4.3. Structure: CatalogedPublication . . . . . . . . . . 53 161 10.4.4. Structure: CatalogedCredential . . . . . . . . . . . 53 162 10.4.5. Structure: CatalogedNetwork . . . . . . . . . . . . 53 163 10.4.6. Structure: CatalogedContact . . . . . . . . . . . . 53 164 10.4.7. Structure: CatalogedAccess . . . . . . . . . . . . . 54 165 10.4.8. Structure: CryptographicCapability . . . . . . . . . 54 166 10.4.9. Structure: CapabilityDecrypt . . . . . . . . . . . . 54 167 10.4.10. Structure: CapabilityDecryptPartial . . . . . . . . 54 168 10.4.11. Structure: CapabilityDecryptServiced . . . . . . . . 55 169 10.4.12. Structure: CapabilitySign . . . . . . . . . . . . . 55 170 10.4.13. Structure: CapabilityKeyGenerate . . . . . . . . . . 55 171 10.4.14. Structure: CapabilityFairExchange . . . . . . . . . 55 172 10.4.15. Structure: CatalogedBookmark . . . . . . . . . . . . 55 173 10.4.16. Structure: CatalogedTask . . . . . . . . . . . . . . 56 174 10.4.17. Structure: CatalogedApplication . . . . . . . . . . 56 175 10.4.18. Structure: CatalogedMember . . . . . . . . . . . . . 56 176 10.4.19. Structure: CatalogedGroup . . . . . . . . . . . . . 56 177 10.4.20. Structure: CatalogedApplicationSSH . . . . . . . . . 56 178 10.4.21. Structure: CatalogedApplicationMail . . . . . . . . 56 179 10.4.22. Structure: CatalogedApplicationNetwork . . . . . . . 57 180 10.5. Publications . . . . . . . . . . . . . . . . . . . . . . 57 181 10.5.1. Structure: DevicePreconfiguration . . . . . . . . . 57 182 10.6. Messages . . . . . . . . . . . . . . . . . . . . . . . . 57 183 10.6.1. Structure: Message . . . . . . . . . . . . . . . . . 57 184 10.6.2. Structure: MessageError . . . . . . . . . . . . . . 57 185 10.6.3. Structure: MessageComplete . . . . . . . . . . . . . 57 186 10.6.4. Structure: MessagePinValidated . . . . . . . . . . . 58 187 10.6.5. Structure: MessagePin . . . . . . . . . . . . . . . 58 188 10.6.6. Structure: RequestConnection . . . . . . . . . . . . 58 189 10.6.7. Structure: AcknowledgeConnection . . . . . . . . . . 58 190 10.6.8. Structure: RespondConnection . . . . . . . . . . . . 59 191 10.6.9. Structure: MessageContact . . . . . . . . . . . . . 59 192 10.6.10. Structure: GroupInvitation . . . . . . . . . . . . . 59 193 10.6.11. Structure: RequestConfirmation . . . . . . . . . . . 59 194 10.6.12. Structure: ResponseConfirmation . . . . . . . . . . 60 195 10.6.13. Structure: RequestTask . . . . . . . . . . . . . . . 60 196 10.6.14. Structure: MessageClaim . . . . . . . . . . . . . . 60 197 10.6.15. Structure: ProcessResult . . . . . . . . . . . . . . 60 198 11. Security Considerations . . . . . . . . . . . . . . . . . . . 60 199 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60 200 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 61 201 14. Appendix A: Example Container Organization (not normative) . 61 202 14.1. Device . . . . . . . . . . . . . . . . . . . . . . . . . 61 203 14.1.1. Creating a new Mesh . . . . . . . . . . . . . . . . 61 204 14.1.2. Adding an Account . . . . . . . . . . . . . . . . . 61 205 14.1.3. Adding a Device . . . . . . . . . . . . . . . . . . 61 206 14.2. Service . . . . . . . . . . . . . . . . . . . . . . . . 62 207 14.2.1. Creating a Service . . . . . . . . . . . . . . . . . 62 208 14.2.2. Adding an Account . . . . . . . . . . . . . . . . . 62 209 15. Appendix B: Collected Authentication and Encryption 210 Requirements . . . . . . . . . . . . . . . . . . . . . . . . 62 211 15.1. Mesh Messaging . . . . . . . . . . . . . . . . . . . . . 62 212 16. Normative References . . . . . . . . . . . . . . . . . . . . 63 213 17. Informative References . . . . . . . . . . . . . . . . . . . 64 215 1. Introduction 217 This document describes the data structures of the Mathematical Mesh 218 with illustrative examples. For an overview of the Mesh objectives 219 and architecture, consult the accompanying _Architecture Guide_ 220 [draft-hallambaker-mesh-architecture]. For information on the 221 implementation of the Mesh Service protocol, consult the accompanying 222 _Protocol Reference_ [draft-hallambaker-mesh-protocol] 224 This document has two main sections. The first section presents 225 examples of the Mesh assertions, catalog entry and messages in use. 226 The second section contains the schema reference. All the material 227 in both sections is generated from the Mesh reference implementation 228 [draft-hallambaker-mesh-developer]. 230 Although some of the services described in this document could be 231 used to replace existing Internet protocols including FTP and SMTP, 232 the principal value of any communication protocol lies in the size of 233 the audience it allows them to communicate with. Thus, while the 234 Mesh Messaging service is designed to support efficient and reliable 235 transfer of messages ranging in size from a few bytes to multiple 236 terabytes, the near-term applications of these services will be to 237 applications that are not adequately supported by existing protocols 238 if at all. 240 2. Definitions 242 This section presents the related specifications and standard, the 243 terms that are used as terms of art within the documents and the 244 terms used as requirements language. 246 2.1. Requirements Language 248 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 249 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 250 document are to be interpreted as described in [RFC2119]. 252 2.2. Defined Terms 254 The terms of art used in this document are described in the _Mesh 255 Architecture Guide_ [draft-hallambaker-mesh-architecture]. 257 2.3. Related Specifications 259 The architecture of the Mathematical Mesh is described in the _Mesh 260 Architecture Guide_ [draft-hallambaker-mesh-architecture]. The Mesh 261 documentation set and related specifications are described in this 262 document. 264 2.4. Implementation Status 266 The implementation status of the reference code base is described in 267 the companion document [draft-hallambaker-mesh-developer]. 269 3. Actors 271 The Mesh mediates interactions between three principal actors: 272 *Accounts*, *Devices*, and *Services*. 274 Currently two account types are specified, *user accounts* which 275 belong to an individual user and *group accounts* that are used to 276 share access to confidential information between a group of users. 277 It may prove useful to define new types of account over time or to 278 eliminate the distinction entirely. When active a Mesh account is 279 bound to a Mesh Service. The service to which an account is bound 280 MAY be changed over time but an account can only be bound to a single 281 service at a time. 283 A Mesh account is an abstract construct that (when active) is 284 instantiated across one or more physical machines called a device. 285 Each device that is connected to an account has a separate set of 286 cryptographic keys that are used to interact with other devices 287 connected to the account and MAY be provisioned with access to the 288 account private keys which MAY or MAY NOT be mediated by the current 289 Mesh Service. 291 A Mesh Service is an abstract construct that is provided by one or 292 more physical machines called Hosts. A Mesh Host is a device that is 293 attached to a service rather than an account. 295 3.1. Accounts 297 A Mesh Account is described by a Profile descended from Profile 298 Account and contains a set of Mesh stores. Currently two account 299 profiles are defined: 301 ProfileUser Describes a user account. 303 ProfileGroup Describes a group account used to share confidential 304 information between a group of users. 306 Both types of profile specify the following fields: 308 ProfileSignature The public signature key used to authenticate the 309 profile itself 311 AccountAddress The account name to which the account is currently 312 bound. (e.g. "alice@example.com", "@alice"). 314 ServiceUdf If the account is active, specifies the fingerprint of 315 the service profile to which the account is currently bound. 317 AdministratorSignature The public signature key used to verify 318 administrative actions on the account. In particular addition of 319 devices to a user account or members to a group account. 321 AccountEncryption The public encryption key for the account. All 322 messages sent to the account MUST be encrypted under this key. By 323 definition, all data encrypted under this account is encrypted 324 under this key. 326 User accounts specify two additional public keys, "AccountSignature" 327 and "AccountAuthentication" which allow signature and authentication 328 operations under the account context. 330 Every account contains a set of catalogs and spools that are managed 331 by the service as directed by the contents of the associated "Access" 332 catalog. 334 For example, the personal account profile Alice created is: 336 { 337 "ProfileUser":{ 338 "ProfileSignature":{ 339 "Udf":"MAMU-5QXP-TWCD-7PKI-S4FC-IB76-XASH", 340 "PublicParameters":{ 341 "PublicKeyECDH":{ 342 "crv":"Ed448", 343 "Public":"c3l96hFNVbXzQa7dohgp_X9YIIzaR4U0dPCfyocquFWnZ 344 uiFdu9vl9UIgtYv-tjFVpmk6qRDj7mA"}}}, 345 "AccountAddress":"alice@example.com", 346 "ServiceUdf":"MA36-TUJL-QRZJ-3M3L-SRBQ-BRYQ-W2YM", 347 "AccountEncryption":{ 348 "Udf":"MDLO-JJ4B-RBY5-VYD7-LJZY-S3RK-DBM2", 349 "PublicParameters":{ 350 "PublicKeyECDH":{ 351 "crv":"X448", 352 "Public":"4Mi9X8mXI9mGh_7sjGZP0aFPRXJNSFexPBnIAK1BN__SX 353 RxtWQTsXsgz1fl5Jc38ZYx7MVe2X9wA"}}}, 354 "AdministratorSignature":{ 355 "Udf":"MCCK-F2WZ-QAAC-C3NA-EVAW-SBL7-IHEQ", 356 "PublicParameters":{ 357 "PublicKeyECDH":{ 358 "crv":"Ed448", 359 "Public":"8TSZ7DNTM7FugJqAFft4FJD4WdjA9omHUDa7tntnJBkQ4 360 kNW_tyS6QMGMYly4wHR1WFnUZvI5QmA"}}}, 361 "AccountAuthentication":{ 362 "Udf":"MBB3-723K-DJKQ-G4HH-7PTN-5JXK-ZV6A", 363 "PublicParameters":{ 364 "PublicKeyECDH":{ 365 "crv":"X448", 366 "Public":"l674_n9ihg91rjgPisb3XuA78E_8hWzsHtYfoFQvGB2kZ 367 3O1xSBFE2ppFjhS4hslA45yz7WpBzgA"}}}, 368 "AccountSignature":{ 369 "Udf":"MDA6-ELE2-T2AM-52RT-AN3R-LUDS-GJGX", 370 "PublicParameters":{ 371 "PublicKeyECDH":{ 372 "crv":"Ed448", 373 "Public":"AHStW8KGpbroZt5ez-wvbC_FMr9AjqI8gLigC5p3whHcE 374 Q4jP9dW1xDwZ34j77qXNIfFEvOEWJMA"}}}}} 376 3.2. Device 378 Every Mesh device has a set of private keys that are unique to that 379 device. These keys MAY be installed during manufacture, installed 380 from an external source after manufacture or generated on the device. 381 If the platform capabilities allow, device private keys SHOULD be 382 bound to the device so that they cannot be extracted or exported 383 without substantial effort. 385 The public keys corresponding to the device private keys are 386 specified in a ProfileDevice. This MUST contain at least the 387 following fields: 389 ProfileSignature The public signature key used to authenticate the 390 profile itself. 392 BaseEncryption Public encryption key used as a share contribution to 393 generation of device encryption keys to be used in the context of 394 an account and to decrypt data during the process of connecting to 395 an account. 397 BaseAuthentication Public authentication key used as a share 398 contribution to generation of device authentication keys to be 399 used in the context of an account and to authenticate the device 400 to a service during the process of connecting to an account. 402 BaseSignature Public signature key used as a share contribution to 403 generation of device authentication keys to be used in the context 404 of an account. 406 For example, the device profile corresponding to Alice's coffee pot 407 device is: 409 { 410 "ProfileDevice":{ 411 "ProfileSignature":{ 412 "Udf":"MAQO-2SJC-PGX4-KVHC-TEQ3-I2NP-GYBA", 413 "PublicParameters":{ 414 "PublicKeyECDH":{ 415 "crv":"Ed448", 416 "Public":"s9IdDH2a_dArdBA8thg41Ctwc0qVo6w67bRrEI1LZgSlG 417 pUSlXWZN8W-VY7hm40Xoq7TU5KEsQSA"}}}, 418 "BaseEncryption":{ 419 "Udf":"MD5F-Q3O6-KRGL-IS4V-IWVC-5SIN-S63R", 420 "PublicParameters":{ 421 "PublicKeyECDH":{ 422 "crv":"X448", 423 "Public":"aJSPUdraCO0yv2YXVKkQ4i1XUKVau-Apb7-OxXNb06Y-w 424 9I420kkRzXhSfsifKPegX7kJMHDKZkA"}}}, 425 "BaseAuthentication":{ 426 "Udf":"MDQC-JYXP-KZ3I-ETIO-KMWA-XIAP-3JRD", 427 "PublicParameters":{ 428 "PublicKeyECDH":{ 429 "crv":"X448", 430 "Public":"KABXGv_VuvLPRhfVpHd5qykjJDUNRiwhh5u3CJpwuAZXf 431 vmeM0KXit5b6wNvYYsSoLeNfKy337IA"}}}, 432 "BaseSignature":{ 433 "Udf":"MDL3-Q7RU-USJR-QF3O-CJEF-6TPW-EVAN", 434 "PublicParameters":{ 435 "PublicKeyECDH":{ 436 "crv":"Ed448", 437 "Public":"2wXyHGACnTq5ee8mgXM_jADlpeRV7gcN3jTQc9LP3LP1Y 438 zii2iSkUMgUTP8yF_KmibXs5pXvv0oA"}}}}} 440 3.2.1. Activation 442 The device private keys are only used to perform cryptographic 443 operations during the process of connecting a device to an account. 444 During that connection process, a threshold key generation scheme is 445 used to generate a second set of device keys bound to the account by 446 combining the base key held by the device with a second device 447 private key provided by the administration device approving the 448 connection of the device to the account. The resulting key is 449 referred to as the device key. The process of combining the base 450 keys with the contributions to form the device keys is called 451 Activation. 453 The activation record for Alice's coffee pot device is: 455 { 456 "ActivationDevice":{ 457 "ActivationKey":"ZAAQ-HHIF-DKIU-F5UI-VEFB-G4XO-SZY6-JF4J-7QLL-2 458 RFQ-QGUO-AJI7-I2FQ-CXO6", 459 "AccountUdf":"MAQO-2SJC-PGX4-KVHC-TEQ3-I2NP-GYBA"}} 461 The Mesh protocols are designed so that there is never a need to 462 export or escrow private keys of any type associated with a device, 463 neither the base key, nor the device key nor the contribution from 464 the administration device. 466 This approach to device configuration ensures that the keys that are 467 used by the device when operating within the context of the account 468 are entirely separate from those originally provided by the device 469 manufacturer or generated on the device, provided only that the key 470 contributions from the administration device are sufficiently random 471 and unguessable. 473 The public keys corresponding to the composite keys generated during 474 the connection process are described in a "ConnectionUser" assertion 475 signed by the administration key of the corresponding account. 477 The connection record for Alice's coffee pot device is: 479 { 480 "ConnectionDevice":{ 481 "DeviceSignature":{ 482 "Udf":"MCEL-HWST-PNFX-ENF4-ROL5-INQF-P2TK", 483 "PublicParameters":{ 484 "PublicKeyECDH":{ 485 "crv":"Ed448", 486 "Public":"4DHBHjQ8X2CadyazPhOx_kSM1IFwgkZEWwW6BK18UBsrr 487 wURQg5QVOGbZl4hvQqu7dULB4tDjAIA"}}}, 488 "DeviceEncryption":{ 489 "Udf":"MDPR-ZBW2-AERR-PQIZ-2J3Z-5DLN-ALBM", 490 "PublicParameters":{ 491 "PublicKeyECDH":{ 492 "crv":"X448", 493 "Public":"Q7UKXQoRCr4eqDLi1WgyyO9JNtDmZ4AaFl6iaGB5IRGrF 494 eMpv7LanAKnTNZUQP0fbnmpdoGvjG-A"}}}, 495 "DeviceAuthentication":{ 496 "Udf":"MDS4-XJNU-HVTT-VR27-I4W3-DYDC-AFEK", 497 "PublicParameters":{ 498 "PublicKeyECDH":{ 499 "crv":"X448", 500 "Public":"F2Bv14NA0Qw_f2B1ktqMGUzAMKbiUNF8etfElLVN-FGYw 501 V0PN9PMdE55ELOt0Y0YkKxP3CR0Kp4A"}}}}} 503 The "ConnectionUser" assertion MAY be used in the same fashion as an 504 X.509v3/PKIX certificate to mediate interactions between devices 505 connected to the same account without the need for interaction with 506 the Mesh service. Thus, a coffee pot device connected to the account 507 can receive and authenticate instructions issued by a voice 508 recognition device connected to that account. 510 While the "ConnectionUser" assertion MAY be used to mediate external 511 interactions, this approach is typically undesirable as it provides 512 the external parties with visibility to the internal configuration of 513 the account, in particular which connected devices are being used on 514 which occasions. Furthermore, the lack of the need to interact with 515 the service means that the service is necessarily unable to mediate 516 the exchange and enforce authorization policy on the interactions. 518 Device keys are intended to be used to secure communications between 519 devices connected to the same account. All communication between 520 Mesh accounts SHOULD be mediated by a Mesh service. This enables 521 abuse mitigation by applying access control to every outbound and 522 every inbound message. 524 Since Alice's coffee pot does not require the external communication 525 right, the activation record for the coffee pot does not provide 526 access to the account keys required to perform external 527 communications. Alice's watch device does require access to the 528 account keys so it can receive messages and task updates. But since 529 it is a device that Alice has to carry on her person to use, it is a 530 device that might easily be lost or stolen. Accordingly, the 531 activation record for Alice's watch provides access to the account 532 decryption and signature keys but in the form of threshold key shares 533 mediated by the Mesh service. Thus, Alice's watch can sign and read 534 message sent to the account but only under the control of the Mesh 535 service. 537 3.3. Service 539 Mesh services are described by a "ProfileService". This specifies 540 the encryption, and signature authentication keys used to interact 541 with the abstract service. 543 Since Mesh accounts and services are both abstract constructs, they 544 cannot interact directly. A device connected to an account can only 545 interact with a service by interacted with a device authorized to 546 provide services on behalf of one or more accounts connected to the 547 service. Such a device is called a Mesh Host. 549 Mesh hosts MAY be managed using the same ProfileDevice and device 550 connection mechanism provided for management of user devices or by 551 whatever other management protocols prove convenient. The only part 552 of the Service/Host interaction that is visible to devices connected 553 to a profile and to hosts connected to other services is the 554 ConnectionHost structure that describes the set of device keys to use 555 in interactions with that specific host. 557 4. Catalogs 559 Catalogs track sets of persistent objects associated with a Mesh 560 Service Account. The Mesh Service has no access to the entries in 561 any Mesh catalog except for the Device and Contacts catalog which are 562 used in device authentication and authorization of inbound messages. 564 Each Mesh Catalog managed by a Mesh Account has a name of the form: 566 "_" 568 Where "" is the IANA assigned service name. The assigned 569 service name for the Mathematical Mesh is mmm. Thus, all catalogs 570 specified by the Mesh schema have names prefixed with the sequence 571 "mmm_". 573 The following catalogs are currently specified within the 574 Mathematical Mesh. 576 Access: mmm_Access Describes access control policy for performing 577 operations on the account. The Access catalog is the only Mesh 578 catalog whose contents are readable by the Mesh Service under 579 normal circumstances. 581 Application: "mmm_Application" Describes configuration information 582 for applications including mail (SMTP, IMAP, OpenPGP, S/MIME, etc) 583 and SSH and for the MeshAccount application itself. 585 Bookmark: "mmm_Bookmark" Describes Web bookmarks and other citations 586 allowing them to be shared between devices connected to the 587 profile. 589 Contact: "mmm_Contact" Describes logical and physical contact 590 information for people and organizations. 592 Credential: "mmm_Credential" Describes credentials used to access 593 network resources. 595 Device: "mmm_Device" Describes the set of devices connected to the 596 account and the permissions assigned to them 598 Network: "mmm_Network" Describes network settings such as WiFi 599 access points, IPSEC and TLS VPN configurations, etc. 601 Member: mmm_Member Describes the set of members connected to a group 602 account. 604 Publication: mmm_Publication Describes data published under the 605 account context. The data MAY be stored in the publication 606 catalog itself or on a separate service (e.g. a Web server). 608 Task: "mmm_CatalogTask" Describes tasks assigned to the user 609 including calendar entries and to do lists. 611 The Access, Publication, Device and Member catalogs are involved in 612 Mesh Service Protocol interactions. These interactions are further 613 described in the Protocol Reference 614 [draft-hallambaker-mesh-protocol]. 616 In many cases, the Mesh Catalog offers capabilities that represent a 617 superset of the capabilities of an existing application. For 618 example, the task catalog supports the appointment tracking functions 619 of a traditional calendar application and the task tracking function 620 of the traditional 'to do list' application. Combining these 621 functions allows tasks to be triggered by other events other than the 622 passage of time such as completion of other tasks, geographical 623 presence, etc. 625 In such cases, the Mesh Catalog entries are designed to provide a 626 superset of the data representation capabilities of the legacy 627 formats and (where available) recent extensions. Where a catalog 628 entry is derived from input presented in a legacy format, the 629 original data representation MAY be attached verbatim to facilitate 630 interoperability. 632 4.1. Access 634 The access catalog "mmm_Access" contains a list of access control 635 entries granting a party authenticated using a particular 636 cryptographic credential a specific privilege such as: 638 * Accept Mesh Messages of particular types 640 * Perform an operation on a private key known to the service. 642 As with the publication catalog, the access catalog provides 643 information that is necessary for the Mesh Service to act on behalf 644 of the user. It is therefore necessary to grant a decryption 645 capability for this catalog during the process of binding the account 646 to a service. 648 4.2. Application 650 The application catalog "mmm"_"Application" contains 651 "CatalogEntryApplication" entries which describe the use of specific 652 applications under the Mesh Service Account. Multiple application 653 accounts for a single application MAY be connected to a single Mesh 654 Service Account. Each account being specified in a separate entry. 656 The "CatalogEntryApplication" entries only contain configuration 657 information for the application as it applies to the account as a 658 whole. If the application requires separate configuration for 659 individual devices, this is specified in separate activation records 660 specified in the corresponding "ConnectionDevice". 662 4.2.1. Mesh Account 664 Mesh Accounts are described by "CatalogEntryAccount" entries. The 665 corresponding activation records for the connected devices contain 666 the contributions used to derive the private keys for use of the 667 account. 669 The "CatalogEntryAccount" entry is described in the section 670 describing Mesh accounts above. 672 4.2.2. SSH 674 SSH configuration profiles are described by 675 "CatalogEntryApplicationSSH" entries. The corresponding activation 676 records for the connected devices contain the contributions used to 677 derive the private keys. 679 A user may have separate SSH configurations for separate purposes 680 within a single Mesh Account. This allows a system administrator 681 servicing multiple clients to maintain separate SSH profiles for each 682 of her customers allowing credentials to be easily (and verifiably) 683 revoked at contract termination. 685 The SSH profile contains the information that is stored in the 686 "known_hosts" and "authorized_keys" files of SSH clients and servers. 688 4.2.3. Mail 690 Mail configuration profiles are described by one or more 691 "CatalogEntryApplicationMail" entries, one for each email account 692 connected to the Mesh profile. The corresponding activation records 693 for the connected devices contain information used to provide the 694 device with the necessary decryption information. 696 Entries specify the email account address(es), the inbound and 697 outbound server configuration and the cryptographic keys to be used 698 for S/MIME and OpenPGP encryption. 700 4.3. Bookmark 702 The bookmark catalog "mmm_bookmark" contains "CatalogEntryBookmark" 703 entries which describe Web bookmarks and other citations allowing 704 them to be shared between devices connected to the profile. 706 The fields currently supported by the Bookmarks catalog are currently 707 limited to the fields required for tracking Web bookmarks. 708 Specification of additional fields to track full academic citations 709 is a work in progress. 711 { 712 "CatalogedBookmark":{ 713 "Uri":"http://www.site1.com", 714 "Title":"site1", 715 "Path":"Sites.1"}} 717 4.4. Contact 719 The contact catalog "mmm_contact" contains "CatalogEntryContact" 720 entries which describe 722 { 723 "CatalogedContact":{ 724 "Key":"MAMU-5QXP-TWCD-7PKI-S4FC-IB76-XASH", 725 "Self":true, 726 "Contact":{ 727 "ContactPerson":{ 728 "Id":"MAMU-5QXP-TWCD-7PKI-S4FC-IB76-XASH", 729 "Anchors":[{ 730 "Udf":"MAMU-5QXP-TWCD-7PKI-S4FC-IB76-XASH", 731 "Validation":"Self"} 732 ], 733 "NetworkAddresses":[{ 734 "Address":"alice@example.com", 735 "EnvelopedProfileAccount":[{ 736 "EnvelopeId":"MAMU-5QXP-TWCD-7PKI-S4FC-IB76-XASH", 737 "dig":"S512", 738 "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJNQU1VLT 739 VRWFAtVFdDRC03UEtJLVM0RkMtSUI3Ni1YQVNIIiwKICAiTWVzc2FnZVR5cGUiOiA 740 iUHJvZmlsZVVzZXIiLAogICJjdHkiOiAiYXBwbGljYXRpb24vbW1tL29iamVjdCIs 741 CiAgIkNyZWF0ZWQiOiAiMjAyMS0wMS0xM1QxNjozODoxOVoifQ"}, 742 "ewogICJQcm9maWxlVXNlciI6IHsKICAgICJQcm9maWxlU2lnbm 743 F0dXJlIjogewogICAgICAiVWRmIjogIk1BTVUtNVFYUC1UV0NELTdQS0ktUzRGQy1 744 JQjc2LVhBU0giLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgICAi 745 UHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgI 746 CAgICAgIlB1YmxpYyI6ICJjM2w5NmhGTlZiWHpRYTdkb2hncF9YOVlJSXphUjRVMG 747 RQQ2Z5b2NxdUZXblp1aUZkdTl2CiAgbDlVSWd0WXYtdGpGVnBtazZxUkRqN21BIn1 748 9fSwKICAgICJBY2NvdW50QWRkcmVzcyI6ICJhbGljZUBleGFtcGxlLmNvbSIsCiAg 749 ICAiU2VydmljZVVkZiI6ICJNQTM2LVRVSkwtUVJaSi0zTTNMLVNSQlEtQlJZUS1XM 750 llNIiwKICAgICJBY2NvdW50RW5jcnlwdGlvbiI6IHsKICAgICAgIlVkZiI6ICJNRE 751 xPLUpKNEItUkJZNS1WWUQ3LUxKWlktUzNSSy1EQk0yIiwKICAgICAgIlB1YmxpY1B 752 hcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICAg 753 ICAiY3J2IjogIlg0NDgiLAogICAgICAgICAgIlB1YmxpYyI6ICI0TWk5WDhtWEk5b 754 UdoXzdzakdaUDBhRlBSWEpOU0ZleFBCbklBSzFCTl9fU1hSeHRXUVRzCiAgWHNnej 755 FmbDVKYzM4Wll4N01WZTJYOXdBIn19fSwKICAgICJBZG1pbmlzdHJhdG9yU2lnbmF 756 0dXJlIjogewogICAgICAiVWRmIjogIk1DQ0stRjJXWi1RQUFDLUMzTkEtRVZBVy1T 757 Qkw3LUlIRVEiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgICAiU 758 HVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgIC 759 AgICAgIlB1YmxpYyI6ICI4VFNaN0ROVE03RnVnSnFBRmZ0NEZKRDRXZGpBOW9tSFV 760 EYTd0bnRuSkJrUTRrTldfdHlTCiAgNlFNR01ZbHk0d0hSMVdGblVadkk1UW1BIn19 761 fSwKICAgICJBY2NvdW50QXV0aGVudGljYXRpb24iOiB7CiAgICAgICJVZGYiOiAiT 762 UJCMy03MjNLLURKS1EtRzRISC03UFROLTVKWEstWlY2QSIsCiAgICAgICJQdWJsaW 763 NQYXJhbWV0ZXJzIjogewogICAgICAgICJQdWJsaWNLZXlFQ0RIIjogewogICAgICA 764 gICAgImNydiI6ICJYNDQ4IiwKICAgICAgICAgICJQdWJsaWMiOiAibDY3NF9uOWlo 765 ZzkxcmpnUGlzYjNYdUE3OEVfOGhXenNIdFlmb0ZRdkdCMmtaM08xeFNCRgogIEUyc 766 HBGamhTNGhzbEE0NXl6N1dwQnpnQSJ9fX0sCiAgICAiQWNjb3VudFNpZ25hdHVyZS 767 I6IHsKICAgICAgIlVkZiI6ICJNREE2LUVMRTItVDJBTS01MlJULUFOM1ItTFVEUy1 768 HSkdYIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1Ymxp 769 Y0tleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIkVkNDQ4IiwKICAgICAgICAgI 770 CJQdWJsaWMiOiAiQUhTdFc4S0dwYnJvWnQ1ZXotd3ZiQ19GTXI5QWpxSThnTGlnQz 771 VwM3doSGNFUTRqUDlkVwogIDF4RHdaMzRqNzdxWE5JZkZFdk9FV0pNQSJ9fX19fQ", 772 { 773 "signatures":[{ 774 "alg":"S512", 775 "kid":"MAMU-5QXP-TWCD-7PKI-S4FC-IB76-XASH", 776 "signature":"_9tIDk5KvjeIuasHaXDawBB1VTw2YIzx 777 BUxpLn78a0qfO9CjuWh7auyUMHrCGvpuQRjjQrDR_OeATnhDzrIG5xcQbFwvfge_r 778 fqvUjqQc-CZqvT8lLDQ2clW6THP1Z0GcIZmxNEpYVkyyR-9AACDQAcA"} 779 ], 780 "PayloadDigest":"fb_iksIe0dM4IWIWZjmKlYQSF-XttjIA 781 g8Bww4tJjpOE0P9bxX42pkNorLfHQ8XyD8x9IHT-FKh-_lhLJNAUzA"} 782 ], 783 "Protocols":[{ 784 "Protocol":"mmm"} 785 ]} 786 ], 787 "Sources":[{ 788 "Validation":"Self", 789 "EnvelopedSource":[{ 790 "dig":"S512", 791 "ContentMetaData":"ewogICJNZXNzYWdlVHlwZSI6ICJDb2 792 50YWN0UGVyc29uIiwKICAiY3R5IjogImFwcGxpY2F0aW9uL21tbS9vYmplY3QiLAo 793 gICJDcmVhdGVkIjogIjIwMjEtMDEtMTNUMTY6Mzg6MTlaIn0"}, 794 "ewogICJDb250YWN0UGVyc29uIjogewogICAgIkFuY2hvcnMiOi 795 BbewogICAgICAgICJVZGYiOiAiTUFNVS01UVhQLVRXQ0QtN1BLSS1TNEZDLUlCNzY 796 tWEFTSCIsCiAgICAgICAgIlZhbGlkYXRpb24iOiAiU2VsZiJ9XSwKICAgICJOZXR3 797 b3JrQWRkcmVzc2VzIjogW3sKICAgICAgICAiQWRkcmVzcyI6ICJhbGljZUBleGFtc 798 GxlLmNvbSIsCiAgICAgICAgIkVudmVsb3BlZFByb2ZpbGVBY2NvdW50IjogW3sKIC 799 AgICAgICAgICAgIkVudmVsb3BlSWQiOiAiTUFNVS01UVhQLVRXQ0QtN1BLSS1TNEZ 800 DLUlCNzYtWEFTSCIsCiAgICAgICAgICAgICJkaWciOiAiUzUxMiIsCiAgICAgICAg 801 ICAgICJDb250ZW50TWV0YURhdGEiOiAiZXdvZ0lDSlZibWx4ZFdWSlpDSTZJQ0pOU 802 VUxVkxUVlJXRkF0VkZkRFJDMAogIDNVRXRKTFZNMFJrTXRTVUkzTmkxWVFWTklJaX 803 dLSUNBaVRXVnpjMkZuWlZSNWNHVWlPaUFpVUhKdlptbHNaCiAgVlZ6WlhJaUxBb2d 804 JQ0pqZEhraU9pQWlZWEJ3YkdsallYUnBiMjR2YlcxdEwyOWlhbVZqZENJc0NpQWdJ 805 a04KICB5WldGMFpXUWlPaUFpTWpBeU1TMHdNUzB4TTFReE5qb3pPRG94T1ZvaWZRI 806 n0sCiAgICAgICAgICAiZXdvZ0lDSlFjbTltYVd4bFZYTmxjaUk2SUhzS0lDQWdJQ0 807 pRY205bWFXeAogIGxVMmxuYm1GMGRYSmxJam9nZXdvZ0lDQWdJQ0FpVldSbUlqb2d 808 JazFCVFZVdE5WRllVQzFVVjBORUxUZFFTCiAgMGt0VXpSR1F5MUpRamMyTFZoQlUw 809 Z2lMQW9nSUNBZ0lDQWlVSFZpYkdsalVHRnlZVzFsZEdWeWN5STZJSHMKICBLSUNBZ 810 0lDQWdJQ0FpVUhWaWJHbGpTMlY1UlVORVNDSTZJSHNLSUNBZ0lDQWdJQ0FnSUNKam 811 NuWWlPaUFpUgogIFdRME5EZ2lMQW9nSUNBZ0lDQWdJQ0FnSWxCMVlteHBZeUk2SUN 812 Kak0ydzVObWhHVGxaaVdIcFJZVGRrYjJoCiAgbmNGOVlPVmxKU1hwaFVqUlZNR1JR 813 UTJaNWIyTnhkVVpYYmxwMWFVWmtkVGwyQ2lBZ2JEbFZTV2QwV1hZdGQKICBHcEdWb 814 kJ0YXpaeFVrUnFOMjFCSW4xOWZTd0tJQ0FnSUNKQlkyTnZkVzUwUVdSa2NtVnpjeU 815 k2SUNKaGJHbAogIGpaVUJsZUdGdGNHeGxMbU52YlNJc0NpQWdJQ0FpVTJWeWRtbGp 816 aVlZrWmlJNklDSk5RVE0yTFZSVlNrd3RVCiAgVkphU2kwelRUTk1MVk5TUWxFdFFs 817 SlpVUzFYTWxsTklpd0tJQ0FnSUNKQlkyTnZkVzUwUlc1amNubHdkR2wKICB2YmlJN 818 klIc0tJQ0FnSUNBZ0lsVmtaaUk2SUNKTlJFeFBMVXBLTkVJdFVrSlpOUzFXV1VRM0 819 xVeEtXbGt0VQogIHpOU1N5MUVRazB5SWl3S0lDQWdJQ0FnSWxCMVlteHBZMUJoY21 820 GdFpYUmxjbk1pT2lCN0NpQWdJQ0FnSUNBCiAgZ0lsQjFZbXhwWTB0bGVVVkRSRWdp 821 T2lCN0NpQWdJQ0FnSUNBZ0lDQWlZM0oySWpvZ0lsZzBORGdpTEFvZ0kKICBDQWdJQ 822 0FnSUNBZ0lsQjFZbXhwWXlJNklDSTBUV2s1V0RodFdFazViVWRvWHpkemFrZGFVRE 823 JoUmxCU1dFcAogIE9VMFpsZUZCQ2JrbEJTekZDVGw5ZlUxaFNlSFJYVVZSekNpQWd 824 XSE5uZWpGbWJEVktZek00V2xsNE4wMVdaCiAgVEpZT1hkQkluMTlmU3dLSUNBZ0lD 825 SkJaRzFwYm1semRISmhkRzl5VTJsbmJtRjBkWEpsSWpvZ2V3b2dJQ0EKICBnSUNBa 826 VZXUm1Jam9nSWsxRFEwc3RSakpYV2kxUlFVRkRMVU16VGtFdFJWWkJWeTFUUWt3M0 827 xVbElSVkVpTAogIEFvZ0lDQWdJQ0FpVUhWaWJHbGpVR0Z5WVcxbGRHVnljeUk2SUh 828 zS0lDQWdJQ0FnSUNBaVVIVmliR2xqUzJWCiAgNVJVTkVTQ0k2SUhzS0lDQWdJQ0Fn 829 SUNBZ0lDSmpjbllpT2lBaVJXUTBORGdpTEFvZ0lDQWdJQ0FnSUNBZ0kKICBsQjFZb 830 XhwWXlJNklDSTRWRk5hTjBST1ZFMDNSblZuU25GQlJtWjBORVpLUkRSWFpHcEJPVz 831 l0U0ZWRVlUZAogIDBiblJ1U2tKclVUUnJUbGRmZEhsVENpQWdObEZOUjAxWmJIazB 832 kMGhTTVZkR2JsVmFka2sxVVcxQkluMTlmCiAgU3dLSUNBZ0lDSkJZMk52ZFc1MFFY 833 VjBhR1Z1ZEdsallYUnBiMjRpT2lCN0NpQWdJQ0FnSUNKVlpHWWlPaUEKICBpVFVKQ 834 015MDNNak5MTFVSS1MxRXRSelJJU0MwM1VGUk9MVFZLV0VzdFdsWTJRU0lzQ2lBZ0 835 lDQWdJQ0pRZAogIFdKc2FXTlFZWEpoYldWMFpYSnpJam9nZXdvZ0lDQWdJQ0FnSUN 836 KUWRXSnNhV05MWlhsRlEwUklJam9nZXdvCiAgZ0lDQWdJQ0FnSUNBZ0ltTnlkaUk2 837 SUNKWU5EUTRJaXdLSUNBZ0lDQWdJQ0FnSUNKUWRXSnNhV01pT2lBaWIKICBEWTNOR 838 jl1T1dsb1p6a3hjbXBuVUdsellqTllkVUUzT0VWZk9HaFhlbk5JZEZsbWIwWlJka2 839 RDTW10YU0wOAogIHhlRk5DUmdvZ0lFVXljSEJHYW1oVE5HaHpiRUUwTlhsNk4xZHd 840 RbnBuUVNKOWZYMHNDaUFnSUNBaVFXTmpiCiAgM1Z1ZEZOcFoyNWhkSFZ5WlNJNklI 841 c0tJQ0FnSUNBZ0lsVmtaaUk2SUNKTlJFRTJMVVZNUlRJdFZESkJUUzAKICAxTWxKV 842 UxVRk9NMUl0VEZWRVV5MUhTa2RZSWl3S0lDQWdJQ0FnSWxCMVlteHBZMUJoY21GdF 843 pYUmxjbk1pTwogIGlCN0NpQWdJQ0FnSUNBZ0lsQjFZbXhwWTB0bGVVVkRSRWdpT2l 844 CN0NpQWdJQ0FnSUNBZ0lDQWlZM0oySWpvCiAgZ0lrVmtORFE0SWl3S0lDQWdJQ0Fn 845 SUNBZ0lDSlFkV0pzYVdNaU9pQWlRVWhUZEZjNFMwZHdZbkp2V25RMVoKICBYb3RkM 846 1ppUTE5R1RYSTVRV3B4U1RoblRHbG5RelZ3TTNkb1NHTkZVVFJxVURsa1Z3b2dJRE 847 Y0UkhkYU16UgogIHFOemR4V0U1SlprWkZkazlGVjBwTlFTSjlmWDE5ZlEiLAogICA 848 gICAgICAgewogICAgICAgICAgICAic2lnbmF0dXJlcyI6IFt7CiAgICAgICAgICAg 849 ICAgICAiYWxnIjogIlM1MTIiLAogICAgICAgICAgICAgICAgImtpZCI6ICJNQU1VL 850 TVRWFAtVFdDRC03UEtJLVM0RkMtSUI3Ni1YQVNIIiwKICAgICAgICAgICAgICAgIC 851 JzaWduYXR1cmUiOiAiXzl0SURrNUt2amVJdWFzSGFYRGF3QkIxVlR3MllJenhCVXh 852 wTG43OGEwcWZPOUNqdQogIFdoN2F1eVVNSHJDR3ZwdVFSampRckRSX09lQVRuaER6 853 cklHNXhjUWJGd3ZmZ2VfcmZxdlVqcVFjLUNacXZUCiAgOGxMRFEyY2xXNlRIUDFaM 854 EdjSVpteE5FcFlWa3l5Ui05QUFDRFFBY0EifV0sCiAgICAgICAgICAgICJQYXlsb2 855 FkRGlnZXN0IjogImZiX2lrc0llMGRNNElXSVdaam1LbFlRU0YtWHR0aklBZzhCd3c 856 0dEpqcE9FMAogIFA5YnhYNDJwa05vckxmSFE4WHlEOHg5SUhULUZLaC1fbGhMSk5B 857 VXpBIn1dLAogICAgICAgICJQcm90b2NvbHMiOiBbewogICAgICAgICAgICAiUHJvd 858 G9jb2wiOiAibW1tIn1dfV19fQ", 859 { 860 "signatures":[{ 861 "alg":"S512", 862 "kid":"MDA6-ELE2-T2AM-52RT-AN3R-LUDS-GJGX", 863 "signature":"TNxwW6yniJfw_8hNE_6bssF6HiT_Ian7 864 y755E1N-X9t88aU2FzbsOHvILoehWLnSUYd8FSWnRw4AwOkXeNnSOC0vP_ORtgCVF 865 tNjqyjvTSVqlH2qUa5u_ad8cTe9iEEc8Kw34jIjJ3vGG5T-zoEhpCcA"} 866 ], 867 "PayloadDigest":"unXsJJuUAUZ6Sd8nfRYOnUvFQjsevfU9 868 8Dj6NJn3ul30f6mwwaHcsWojEr2F1lfeHbkA4vksAX2seekIjNH7Ww"} 869 ]} 870 ]}}}} 872 The fields of the contact catalog provide a superset of the 873 capabilities of vCard [RFC2426]. 875 The Contact catalog is typically used by the MeshService as a source 876 of authorization information to perform access control on inbound and 877 outbound message requests. For this reason, Mesh Service SHOULD be 878 granted read access to the contacts catalog by providing a decryption 879 entry for the service. 881 4.5. Credential 883 The credential catalog "mmm_credential" contains 884 "CatalogEntryCredential" entries which describe credentials used to 885 access network resources. 887 { 888 "CatalogedCredential":{ 889 "Service":"ftp.example.com", 890 "Username":"alice1", 891 "Password":"password"}} 893 Only username/password credentials are stored in the credential 894 catalog. If public key credentials are to be used, these SHOULD be 895 managed as an application profile allowing separate credentials to be 896 created for each device. 898 4.6. Device 900 The device catalog "mmm_Device" contains "CatalogEntryDevice" entries 901 which describe the devices connected to the account and the 902 permissions assigned to them. 904 Each device connected to a Mesh Account has an associated 905 CatalogEntryDevice entry that includes the activation and connection 906 records for the account. These records are described in further 907 detail in section REF _Ref54628559 \r \h 0. 909 4.7. Network 911 The network catalog contains "CatalogEntryNetwork" entries which 912 describe network settings, IPSEC and TLS VPN configurations, etc. 914 { 915 "CatalogedNetwork":{ 916 "Service":"myWiFi", 917 "Password":"securePassword"}} 919 4.8. Publication 921 The publication catalog "mmm_Publication" contains 922 "CatalogEntryPublication" entries which describe content published 923 through the account. 925 4.9. Task 927 The Task catalog "mmm_Task" contains "CatalogEntryTask" entries which 928 describe tasks assigned to the user including calendar entries and to 929 do lists. 931 The fields of the task catalog currently reflect those offered by the 932 iCalendar specification [RFC5545]. Specification of additional 933 fields to allow task triggering on geographic location and/or 934 completion of other tasks is a work in progress. 936 { 937 "CatalogedTask":{ 938 "Title":"SomeItem", 939 "Key":"NC44-73RX-SL65-EFN4-E6ZD-JL47-CZ3A"}} 941 5. Spools 943 Spools are DARE Containers containing an append only list of messages 944 sent or received by an account. Three spools are currently defined: 946 Inbound Messages sent to the account. These are encrypted under the 947 account encryption keys of the sender and receiver that were 948 current at the time the message was sent. 950 Outbound Messages sent from the account. These are encrypted under 951 the account encryption keys of the sender and receiver that were 952 current at the time the message was sent. 954 Local Messages sent from the account for internal use. These are 955 encrypted under the encryption key of the intended recipient 956 alone. This is either the account administration encryption key 957 or a device encryption key. 959 Every Mesh Message has a unique message identifier. Messages created 960 at the beginning of a new messaging protocol interaction are assigned 961 a random message identifier. Responses to previous messages are 962 assigned message identifiers formed from the message identifier to 963 which they respond by means of a message digest function. 965 Every Mesh Message stored in a spool is encapsulated in an envelope 966 which bears a unique identifier that is formed by applying a message 967 digest function to the message identifier. Each stored message has 968 an associated state which is initially set to the state "Initial" and 969 MAY be subsequently altered by one or more "MessageComplete" messages 970 subsequently appended to the spool. The allowable message states 971 depending upon the spool in question. 973 5.1. Outbound 975 The outbound spool stores messages that are to be or have been sent 976 and "MessageComplete" messages reporting changes to the status of the 977 messages stored on the spool. 979 Messages posted to the outbound spool have the state Initial, Sent, 980 Received or Refused: 982 Initial The initial state of a message posted to the spool. 984 Sent The Mesh Service of the sender has delivered the message to the 985 Mesh Service of the recipient which accepted it. 987 Received The Mesh Service of the sender has delivered the message to 988 the Mesh Service of the recipient and the recipient has 989 acknowledged receipt. 991 Refused The Mesh Service of the sender has delivered the message to 992 the Mesh Service of the recipient which refused to accept it. 994 "MessageComplete" messages are only valid when posted to the spool by 995 the service. 997 5.2. Inbound 999 The inbound spool stores messages that have been received by the Mesh 1000 service servicing the account and MessageComplete messages reporting 1001 changes to the status of the messages stored on the spool. 1003 Messages posted to the outbound spool have the state Initial, Read: 1005 Initial The initial state of a message posted to the spool. 1007 Read The message has been read. 1009 A message previously marked as read MAY be returned to the unread 1010 state by marking it as being in the Initial state. 1012 5.3. Local 1014 The local spool stores messages that are used for administrative 1015 functions. In normal circumstances, only administrator devices and 1016 the Mesh Service require access to the local spool. 1018 The local spool is used to store MessagePin messages used to notify 1019 administration devices that a PIN code has been registered for some 1020 purpose and RespondConnection messages used to inform a device of the 1021 result of a connection request. 1023 The local spool is used in a device connection operation to provide a 1024 device with the activation and connection records required to access 1025 the service as an authorized client. Servicing these requests 1026 requires that the service be able to access messages stored in the 1027 spool by envelope id. 1029 Messages posted to the outbound spool have the states Initial, 1030 Closed: 1032 Initial The initial state of a message posted to the spool. 1034 Closed The action associated with the message has been completed. 1036 6. Cryptographic Operations 1038 The Mesh makes use of various cryptographic operations including 1039 threshold operations. For convenience, these are gathered here and 1040 specified as functions that are referenced by other parts of the 1041 specification. 1043 6.1. Key Derivation from Seed 1045 Mesh Keys that derived from a seed value use the mechanism described 1046 in [draft-hallambaker-mesh-udf]. Use of the "keyname" parameter 1047 allows multiple keys for different uses to be derived from a single 1048 key. Thus escrow of a single seed value permits recovery of all the 1049 private keys associated with the profile. 1051 The keyname parameter is a string formed by concatenating identifiers 1052 specifying the key type, the actor that will use the key and the key 1053 operation: 1055 6.2. Message Envelope and Response Identifiers. 1057 Every Mesh message has a unique Message Identifier "MessageId". The 1058 "MakeID()" function is used to calculate the value of Envelope 1059 Identifier and Response identifier from the message identifier as 1060 follows: 1062 static string MakeID(string udf, string content) { 1063 var (code, bds) = UDF.Parse(udf); 1064 return code switch 1065 { 1066 UdfTypeIdentifier.Digest_SHA_3_512 => 1067 UDF.ContentDigestOfDataString( 1068 bds, content, cryptoAlgorithmId: 1069 CryptoAlgorithmId.SHA_3_512), 1070 _ => UDF.ContentDigestOfDataString( 1071 bds, content, cryptoAlgorithmId: 1072 CryptoAlgorithmId.SHA_2_512), 1073 }; 1075 Where the values of content are given as follows: 1077 String String 1079 For example: 1081 MessageID 1082 = NBPS-TE2K-5BQZ-3HWA-PJNU-WYOX-DAMW 1084 EnvelopeID 1085 = MAD4-DQE5-PU4Y-QCTJ-D5U2-ZZVS-WBYC 1087 ResponseID 1088 = MDDB-CUZ4-QYCA-BEZB-3BPQ-PYOM-GPUM 1090 6.3. Proof of Knowledge of PIN 1092 Mesh Message classes that are subclasses of "MessagePinValidated" MAY 1093 be authenticated by means of a PIN. Currently two such messages are 1094 defined: "MessageContact" used in contact exchange and 1095 "RequestConnection" message used in device connection. 1097 The PIN codes used to authenticate "MessagePinValidated" messages are 1098 UDF Authenticator strings. The type code of the identifier specifies 1099 the algorithm to be used to authenticate the PIN code and the Binary 1100 Data Sequence value specifies the key. 1102 The inputs to the PIN proof of knowledge functions are: 1104 PIN: string A UDF Authenticator. The type code of the identifier 1105 specifies the algorithm to be used to authenticate the PIN code 1106 and the Binary Data Sequence value specifies the key. 1108 Action: string A code determining the specific action that the PIN 1109 code MAY be used to authenticate. By convention this is the name 1110 of the Mesh message type used to perform the action. 1112 Account: string The account for which the PIN code is issued. 1114 ClientNonce: binary Nonce value generated by the client using the 1115 PIN code to authenticate its message. 1117 PayloadDigest: binary The PayloadDigest of a DARE Envelope that 1118 contains the message to be authenticated. Note that if the 1119 envelope is encrypted, this value is calculated over the 1120 ciphertext and does not provide proof of knowledge of the 1121 plaintext. 1123 The following values of Action are currently defined: 1125 String String 1127 These inputs are used to derive values as follows: 1129 alg = UdfAlg (PIN) 1130 pinData = UdfBDS (PIN) 1131 saltedPINData = MAC (Action, pinData) 1132 saltedPIN = UDFPresent (HMAC_SHA_2_512 + saltedPINData) 1133 PinId = UDFPresent (MAC (Account, saltedPINData)) 1135 The issuer of the PIN code stores the value saltedPIN for retrieval 1136 using the key PinId. 1138 The witness value for a Dare Envelope with payload digest 1139 PayloadDigest authenticated by a PIN code whose salted value is 1140 saltedPINData, issued by account Account is given by PinWitness() as 1141 follows: 1143 witnessData = Account.ToUTF8() + ClientNonce + PayloadDigest 1144 witnessValue = MAC (witnessData , saltedPINData) 1146 For example, to generate saltedPIN for the pin AB23-ZBOI-CEIZ-MTD4-VQ 1147 used to authenticate a an action of type Device: 1149 pin = AB23-ZBOI-CEIZ-MTD4-VQ 1150 action = message. 1152 alg = UdfAlg (PIN) 1153 = Authenticator_HMAC_SHA_2_512 1155 hashalg = default (alg, HMAC_SHA_2_512) 1157 pinData = UdfBDS (PIN) 1158 = System.Byte[] 1160 saltedPINData 1161 = hashalg(pinData, hashalg); 1162 = System.Byte[] 1164 saltedPIN = UDFPresent (hashalg + saltedPINData) 1165 = AANT-HAQW-KDUY-GUMW-YFY2-YWB5-23YC 1167 The PinId binding the pin to the account alice@example.com is 1169 Account = alice@example.com 1171 PinId = UDFPresent (MAC (Account, saltedPINData)) 1172 = ABVQ-HJHJ-UUIJ-SLQE-KMK4-XUVP-DTVG 1174 Where "MAC(data, key)" is the message authentication code algorithm 1175 specified by the value of "alg". 1177 When an administrative device issues a PIN code, a Message PIN is 1178 appended to the local spool. This has the MessageId PinId and 1179 specifies the value "saltedPIN" in the field of that name. 1181 When PIN code authentication is used, a message of type 1182 "MessagePinValidated" specifies the values "ClientNonce", 1183 "PinWitness" and "PinId" in the fields of those names. These values 1184 are used to authenticate the inner message data specified by the 1185 "AuthenticatedData" field. 1187 6.4. EARL 1189 The UDF Encrypted Authenticated Resource Locator mechanism is used to 1190 publish data and provide means of authentication and access through a 1191 static identifier such as a QR code. 1193 This mechanism is used to allow contact exchange by means of a QR 1194 code printed on a business card and to connect a device to an account 1195 using a static identifier printed on the device in the form of a QR 1196 code. 1198 In both cases, the information is passed using the EARL format 1199 described in [draft-hallambaker-mesh-udf]. 1201 6.5. Key Agreement 1203 All Mesh Protocol requests except for the HelloRequest and every 1204 response MUST be authenticated under the device key of the host or 1205 device making the request. 1207 Initial authentication is achieved by performing a Key agreement 1208 under the "DeviceAuthentication" key of each of the hosts and 1209 combining the result with nonce values provided by the requestor and 1210 respondent using a KDF function as follows: 1212 Two bindings are currently planned. 1214 DARE Envelope over HTTPS The request or response is encapsulated in 1215 a DARE Envelope that is exchanged by means of a HTTP POST method 1216 over a TLS transport. The shared secret is used as the key on 1217 Message Authentication Code that authenticates the request 1218 payload. 1220 UDP Transport Presents the same information as for the DARE Envelope 1221 over HTTPS case but in a compact encoding using the shared secret 1222 and an authenticated encryption scheme to pass the required 1223 information. 1225 Once authentication has been performed, the same pair of devices MAY 1226 re-authenticate using the previously agreed key. To facilitate 1227 stateless implementation, a host specifies an opaque identifier to be 1228 used to identify the shared secret on subsequent uses which MAY be 1229 used to recover the shared secret from the opaque identifier. 1231 [To be specified] 1233 6.6. Service Cryptographic Operations 1235 A Mesh Service acts as the counterparty for threshold operations 1236 allowing mitigation of the risk of compromise of an individual device 1237 connected to a user account or an insider threat from an individual 1238 member of a group account. 1240 When acting in this role, the Mesh service controls the use of the 1241 cryptographic function but does not have the ability to perform the 1242 action either by itself or by collaborating with other services to 1243 which the account has been bound in the past. 1245 Note that this approach limits rather than eliminates trust in the 1246 service. As with services presenting themselves as 'zero trust', a 1247 Mesh service becomes a trusted service after a sufficient number of 1248 breaches in other parts of the system have occurred. And the user 1249 trusts the service to provide availability of the service. 1251 Three service cryptographic operations are currently specified: 1253 Threshold Key Share A private key share _s_, held by the service is 1254 split into key shares _x_, _y_ such that _a_ = _x_ + _y_. One key 1255 share is encrypted under a decryption key held by the service. 1256 The other is encrypted under a public key specified by the party 1257 making the request. 1259 Threshold Key Agreement A private key share s, held by the service 1260 is used to calculate the value (_sl_+ _c_)._P_ where _l_, _c_ are 1261 integers specified by the requestor and _P_ is a point on the 1262 curve. 1264 Threshold Signature A private key share s, held by the service is 1265 used to calculate a contribution to a threshold signature scheme. 1267 The implementation of the cryptographic operations described above is 1268 described in [draft-hallambaker-threshold] and 1269 [draft-hallambaker-threshold-sigs]. 1271 7. Mesh Assertions 1273 Mesh Assertions are signed DARE Envelopes that contain one of more 1274 claims. Mesh Assertions provide the basis for trust in the 1275 Mathematical Mesh. 1277 Mesh Assertions are divided into two classes. Mesh Profiles are 1278 self-signed assertions. Assertions that are not self-signed are 1279 called declarations. The only type of declaration currently defined 1280 is a Connection Declaration describing the connection of a device to 1281 an account. 1283 (Artwork only available as svg: No external link available, see 1284 draft-hallambaker-mesh-schema-07.html for artwork.) 1286 Figure 1: Profiles And Connections 1288 7.1. Encoding 1290 The payload of a Mesh Assertion is a JSON encoded object that is a 1291 subclass of the Assertion class which defines the following fields: 1293 Identifier An identifier for the assertion. 1295 Updated The date and time at which the assertion was issued or last 1296 updated 1298 NotaryToken An assertion may optionally contain one or more notary 1299 tokens issued by a Mesh Notary service. These establish a proof 1300 that the assertion was signed after the date the notary token was 1301 created. 1303 Conditions A list of conditions that MAY be used to verify the 1304 status of the assertion if the relying party requires. 1306 The implementation of the NotaryToken and Conditions mechanisms is to 1307 be specified in [draft-hallambaker-mesh-notary] at a future date. 1309 Note that the implementation of Conditions differs significantly from 1310 that of SAML. Relying parties are required to process condition 1311 clauses in a SAML assertion to determine validity. Mesh Relying 1312 parties MAY verify the conditions clauses or rely on the 1313 trustworthiness of the provider. 1315 The reason for weakening the processing of conditions clauses in the 1316 Mesh is that it is only ever possible to validate a conditions clause 1317 of any type relative to a ground truth. In SAML applications, the 1318 relying party almost invariably has access to an independent source 1319 of ground truth. A Mesh device connected to a Mesh Service does not. 1320 Thus the types of verification that can be achieved in practice are 1321 limited to verifying the consistency of current and previous 1322 statements from the Mesh Service. 1324 7.2. Mesh Profiles 1326 Mesh Profiles perform a similar role to X.509v3 certificates but with 1327 important differences: 1329 * Profiles describe credentials, they do not make identity 1330 statements 1332 * Profiles do not expire, there is therefore no need to support 1333 renewal processing. 1335 * Profiles may be modified over time, the current and past status of 1336 a profile being recorded in an append only log. 1338 Profiles provide the axioms of trust for the Mesh PKI. Unlike in the 1339 PKIX model in which all trust flows from axioms of trust held by a 1340 small number of Certificate Authorities, every part in the Mesh 1341 contributes their own axiom of trust. 1343 It should be noted however that the role of Certificate Authorities 1344 is redefined rather than eliminated. Rather than making assertions 1345 whose subject is represented by identities which are inherently 1346 mutable and subjective, Certificate Authorities can now make 1347 assertions about immutable cryptographic keys. 1349 Every Profile MUST contain a "SignatureKey" field and MUST be signed 1350 by the key specified in that field. 1352 A Profile is valid if and only if: 1354 * There is a "SignatureKey" field. 1356 * The profile is signed under the key specified in the 1357 "SignatureKey" field. 1359 A profile has the status "current" if and only if: 1361 * The Profile is valid 1363 * Every Conditions clause in the profile is understood by the 1364 relying party and evaluates to "true". 1366 7.3. Mesh Connections 1368 A Mesh connection is an assertion describing the connection of a 1369 device or a member to an account. 1371 Mesh connections provide similar functionality to 'end-entity' 1372 certificates in PKIX but with the important proviso that they are 1373 only used to provide trust between a device connected to an account 1374 and the service to which that account is bound and between the 1375 devices connected to an account. 1377 A connection is valid with respect to an account with profile _P_ if 1378 and only if: 1380 * The profile _P_ is valid 1382 * The "AuthorityUdf" field of the connection is consistent with the 1383 UDF of _P_ 1385 * The profile is signed under the key specified in the 1386 "AdministrationKey" field of _P_. 1388 * Any conditions specified in the profile are met 1390 A connection has the status current with respect to an account with 1391 profile if and only if: 1393 * The connection is valid with respect to the account with profile 1394 _P_. 1396 * The profile "P" is current. 1398 A device is authenticated with respect to an account with profile P 1399 if and only if: 1401 * The connection is valid with respect to the account with profile 1402 _P_. 1404 * The device has presented an appropriate proof of knowledge of the 1405 "DeviceAuthentication" key specified in the connection. 1407 8. Architecture 1409 The Mesh architecture has four principal components: 1411 Mesh Account A collection of information (contacts, calendar 1412 entries, inbound and outbound messages, etc.) belonging to a user 1413 who uses the Mesh to management. 1415 Mesh Device Management The various functions that manage binding of 1416 devices to a Mesh to grant access to information and services 1417 bound to that account. 1419 Mesh Service Provides network services through which devices and 1420 other Mesh users may interact with a Mesh Account. 1422 Mesh Messaging An end to end secure messaging service that allows 1423 short messages (less than 32KB) to be exchanged between Mesh 1424 Accounts and between the Mesh devices connected to a particular 1425 account. 1427 The separation of accounts and services as separate components is a 1428 key distinction between the Mesh and earlier Internet applications. 1429 A Mesh account belongs to the owner of the Mesh and not the Mesh 1430 Service Provider which the user may change at any time of their 1431 choosing. 1433 A Mesh Account May be active or inactive. By definition, an active 1434 Mesh account is serviced by exactly one Mesh Service, an inactive 1435 Mesh account is not serviced by a Mesh Service. A Mesh Service 1436 Provider MAY offer a backup service for accounts hosted by other 1437 providers. In this case the backup provider is connected to the 1438 account as a Mesh device, thus allowing the backup provider to 1439 maintain a copy of the stores contained in the account and 1440 facilitating a rapid transfer of responsibility for servicing the 1441 account should that be desired. The use of backup providers is 1442 described further in [draft-hallambaker-mesh-discovery]. 1444 8.1. Mesh Account 1446 Mesh Accounts contains all the stateful information (contacts, 1447 calendar entries, inbound and outbound messages, etc.) related to a 1448 particular persona used by the owner. 1450 By definition a Mesh Account is active if it is serviced by a Mesh 1451 Service and inactive otherwise. A Mesh user MAY change their service 1452 provider at any time. An active Mesh Account is serviced by exactly 1453 one Mesh Service at once but a user MAY register a 'backup' service 1454 provider to their account in the same manner as adding an advice. 1455 This ensures that the backup service is pre-populated with all the 1456 information required to allow the user to switch to the new provider 1457 without interruption of service. 1459 Each Mesh account is described by an Account Profile. Currently 1460 separate profile Account Profile are defined for user accounts and 1461 group accounts. It is not clear if this distinction is a useful one. 1463 8.1.1. Account Profile 1465 A Mesh account profile provides the axiom of trust for a mesh user. 1466 It contains a Master Signature Key and one or more Administration 1467 Signature Keys. The unique identifier of the master profile is the 1468 UDF of the Master Signature Key. 1470 An Account Profile MUST specify an "EscrowEncryption" key. This key 1471 MAY be used to escrow private keys used for encryption of stored 1472 data. They SHOULD NOT be used to escrow authentication keys and MUST 1473 NOT be used to escrow signature keys. 1475 A user should not need to replace their account profile unless they 1476 intend to establish a separate identity. To minimize the risk of 1477 disclosure, the Profile Signature Key is only ever used to sign 1478 updates to the account profile itself. This allows the user to 1479 secure their Profile Signature Key by either keeping it on hardware 1480 token or device dedicated to that purpose or by using the escrow 1481 mechanism and paper recovery keys as described in this document. 1483 8.1.1.1. Creating a ProfileMaster 1485 Creating a "ProfileMaster" comprises the steps of: 1487 0. Creating a Master Signature key. 1489 1. Creating an Online Signing Key 1491 2. Signing the "ProfileMaster" using the Master Signature Key 1493 3. Persisting the "ProfileMaster" on the administration device to 1494 the "CatalogHost". 1496 4. (Optional) Connecting at least one Administration Device and 1497 granting it the "ActivationAdministration" activation. 1499 8.1.1.2. Updating a ProfileMaster 1501 Updating a "ProfileMaster" comprises the steps of: 1503 0. Making the necessary changes. 1505 1. Signing the ProfileMaster using the Master Signature Key 1507 2. Persisting the ProfileMaster on the administration device to the 1508 CatalogHost. 1510 8.2. Device Management 1512 Device management allows a collection of devices belonging to a user 1513 to function as a single personal Mesh. 1515 The device management functions are principally concerned with the 1516 catalog containing the entries describing the connected devices. 1518 8.2.1. The Device Catalog 1520 Each Mesh Account has a Device Catalog "CatalogDevice" associated 1521 with it. The Device Catalog is used to manage the connection of 1522 devices to the Personal Mesh and has a "CatalogEntryDevice" for each 1523 device currently connected to the catalog. 1525 Each Administration Device MUST have access to an up-to-date copy of 1526 the Device Catalog in order to manage the devices connected to the 1527 Mesh. The Mesh Service protocol MAY be used to synchronize the 1528 Device Catalog between administration devices in the case that there 1529 is more than one administration device. 1531 The "CatalogEntryDevice" contains fields for the device profile, 1532 device private and device connection. 1534 8.2.2. Mesh Devices 1536 The principle of radical distrust requires us to consider the 1537 possibility that a device might be compromised during manufacture. 1538 Once consequence of this possibility is that when an administration 1539 device connects a new device to a user's personal Mesh, we cannot put 1540 our full trust in either the device being connected or the 1541 administration device connecting it. 1543 This concern is resolved by (at minimum) combining keying material 1544 generated from both sources to create the keys to be used in the 1545 context of the user's personal Mesh with the process being fully 1546 verified by both parties. 1548 Additional keying material sources could be added if protection 1549 against the possibility of compromise at both devices was required 1550 but this is not supported by the current specifications. 1552 A device profile provides the axiom of trust and the key 1553 contributions of the device. When bound to an account, the base keys 1554 specified in the Device Profile are combined with the key data 1555 provided in the Activation device to construct the keys the device 1556 will use in the context of the account. 1558 (Artwork only available as svg: No external link available, see 1559 draft-hallambaker-mesh-schema-07.html for artwork.) 1561 Figure 2: Mapping of Device Profile and Device Private to Device 1562 Connection Keys. 1564 Unless exceptional circumstances require, a device should not require 1565 more than one Device profile even if the device supports use by 1566 multiple users under different accounts. But a device MAY have 1567 multiple profiles if this approach is more convenient for 1568 implementation. 1570 { 1571 "ProfileDevice":{ 1572 "ProfileSignature":{ 1573 "Udf":"MAQO-2SJC-PGX4-KVHC-TEQ3-I2NP-GYBA", 1574 "PublicParameters":{ 1575 "PublicKeyECDH":{ 1576 "crv":"Ed448", 1577 "Public":"s9IdDH2a_dArdBA8thg41Ctwc0qVo6w67bRrEI1LZgSlG 1578 pUSlXWZN8W-VY7hm40Xoq7TU5KEsQSA"}}}, 1579 "BaseEncryption":{ 1580 "Udf":"MD5F-Q3O6-KRGL-IS4V-IWVC-5SIN-S63R", 1581 "PublicParameters":{ 1582 "PublicKeyECDH":{ 1583 "crv":"X448", 1584 "Public":"aJSPUdraCO0yv2YXVKkQ4i1XUKVau-Apb7-OxXNb06Y-w 1585 9I420kkRzXhSfsifKPegX7kJMHDKZkA"}}}, 1586 "BaseAuthentication":{ 1587 "Udf":"MDQC-JYXP-KZ3I-ETIO-KMWA-XIAP-3JRD", 1588 "PublicParameters":{ 1589 "PublicKeyECDH":{ 1590 "crv":"X448", 1591 "Public":"KABXGv_VuvLPRhfVpHd5qykjJDUNRiwhh5u3CJpwuAZXf 1592 vmeM0KXit5b6wNvYYsSoLeNfKy337IA"}}}, 1593 "BaseSignature":{ 1594 "Udf":"MDL3-Q7RU-USJR-QF3O-CJEF-6TPW-EVAN", 1595 "PublicParameters":{ 1596 "PublicKeyECDH":{ 1597 "crv":"Ed448", 1598 "Public":"2wXyHGACnTq5ee8mgXM_jADlpeRV7gcN3jTQc9LP3LP1Y 1599 zii2iSkUMgUTP8yF_KmibXs5pXvv0oA"}}}}} 1601 The derivation of the Connection encryption and signature keys from 1602 the Profile and Private contributions in this example is shown in 1603 [draft-hallambaker-mesh-cryptography]. 1605 8.2.2.1. Creating a ProfileDevice 1607 Creating a "ProfileDevice" comprises the steps of: 1609 0. Creating the necessary key 1611 1. Signing the "ProfileDevice" using the Master Signature Key 1612 2. Once created, a "ProfileDevice" is never changed. In the 1613 unlikely event that any modification is required, a completely 1614 new "ProfileDevice" MUST be created. 1616 8.2.2.2. Connection to a Personal Mesh 1618 Devices are only connected to a personal Mesh by an administration 1619 device. This comprises the steps of: 1621 0. Generating the PrivateDevice keys. 1623 1. Creating the ConnectionDevice data from the public components of 1624 the ProfileDevice and PrivateDevice keys and signing it using the 1625 administration key. 1627 2. Creating the Activations for the device and signing them using 1628 the administration key. 1630 3. Creating the "CatalogEntryDevice" for the device and adding it to 1631 the "CatalogDevice" of the Personal Mesh. 1633 4. If the Personal Mesh has accounts that are connected to a Mesh 1634 Service, synchronizing the "CatalogEntryDevice" to those 1635 services. 1637 These steps are usually performed through use of the Mesh Protocol 1638 Connection mechanism. However, Mesh clients MAY support additional 1639 mechanisms as circumstances require provided that the appropriate 1640 authentication and private key protection controls are provided. 1642 8.3. Mesh Services 1644 A Mesh Service provides one or more Mesh Hosts that support Mesh 1645 Accounts through the Mesh Web Service Protocol. 1647 Mesh Services and Hosts are described by Service Profiles and Host 1648 Profiles. The means by which services manage the hosts through which 1649 they provide service is outside the scope of this document. 1651 As with a Device connected to a Mesh Account, a the binding of a Host 1652 to the service it supports is described by a connection record: 1654 (Artwork only available as svg: No external link available, see 1655 draft-hallambaker-mesh-schema-07.html for artwork.) 1657 Figure 3: Service Profile and Delegated Host Assertion. 1659 The credentials provided by the ProfileService and ProfileHost are 1660 distinct from those provided by the WebPKI that typically services 1661 TLS requests. WebPKI credentials provide service introduction and 1662 authentication while a Mesh ProfileHost only provides authentication. 1664 Unless exceptional circumstances require, a service should not need 1665 to revise its Service Profile unless it is intended to change its 1666 identity. Service Profiles MAY be countersigned by Trusted Third 1667 Parties to establish accountability. 1669 8.4. Mesh Messaging 1671 Mesh Messaging is an end-to-end secure messaging system used to 1672 exchange short (32KB) messages between Mesh devices and services. In 1673 cases where exchange of longer messages is required, Mesh Messaging 1674 MAY be used to provide a control plane to advise the intended message 1675 recipient(s) of the type of data being offered and the means of 1676 retrieval (e.g an EARL). 1678 All communications between Mesh accounts takes the form of a Mesh 1679 Message carried in a Dare Envelope. Mesh Messages are stored in two 1680 spools associated with the account, the SpoolOutbound and the 1681 SpoolInbound containing the messages sent and received respectively. 1683 This document only describes the representation of the messages 1684 within the message spool. The Mesh Service protocol by which the 1685 messages are exchanged between devices and services and between 1686 services is described in [draft-hallambaker-mesh-protocol]. 1688 8.4.1. Message Status 1690 As previously described in section ###, every message stored in a 1691 spool has a specified state. The range of allowable states is 1692 defined by the message type. New message states MAY be defined for 1693 new message types as they are defined. 1695 By default, messages are appended to a spool in the "Initial" state, 1696 but a spool entry MAY specify any state that is valid for that 1697 message type. 1699 The state of a message is changed by appending a completion message 1700 to the spool as described in [draft-hallambaker-mesh-protocol]. 1702 Services MAY erase or redact messages in accordance with local site 1703 policy. Since messages are not removed from the spool on being 1704 marked deleted, they may be undeleted by marking them as read or 1705 unread. Marking a message deleted MAY make it more likely that the 1706 message will be removed if the sequence is subsequently purged. 1708 8.4.2. Four Corner Model 1710 A four-corner messaging model is enforced. Mesh Services only accept 1711 outbound messages from devices connected to accounts that it 1712 services. Inbound messages are only accepted from other Mesh 1713 Services. This model enables access control at both the outbound and 1714 inbound services 1716 (Artwork only available as svg: No external link available, see 1717 draft-hallambaker-mesh-schema-07.html for artwork.) 1719 Figure 4: Four Corner Messaging Model 1721 The outbound Mesh Service checks to see that the request to send a 1722 message does not violate its acceptable use policy. Accounts that 1723 make a large number of message requests that result in complaints 1724 SHOULD be subject to consequences ranging from restriction of the 1725 number and type of messages sent to suspending or terminating 1726 messaging privileges. Services that fail to implement appropriate 1727 controls are likely to be subject to sanctions from either their 1728 users or from other services. 1730 (Artwork only available as svg: No external link available, see 1731 draft-hallambaker-mesh-schema-07.html for artwork.) 1733 Figure 5: Performing Access Control on Outbound Messages 1735 The inbound Mesh Service also checks to see that messages received 1736 are consistent with the service Acceptable Use Policy and the user's 1737 personal access control settings. 1739 Mesh Services that fail to police abuse by their account holders 1740 SHOULD be subject to consequences in the same fashion as account 1741 holders. 1743 (Artwork only available as svg: No external link available, see 1744 draft-hallambaker-mesh-schema-07.html for artwork.) 1746 Figure 6: Performing Access Control on Inbound Messages 1748 8.4.3. Traffic Analysis 1750 The Mesh Messaging protocol as currently specified provides only 1751 limited protection against traffic analysis attacks. The use of TLS 1752 to encrypt communication between Mesh Services limits the 1753 effectiveness of na?ve traffic analysis mechanisms but does not 1754 prevent timing attacks unless dummy traffic is introduced to 1755 obfuscate traffic flows. 1757 The limitation of the message size is in part intended to facilitate 1758 use of mechanisms capable of providing high levels of traffic 1759 analysis such as mixmaster and onion routing but the current Mesh 1760 Service Protocol does not provide support for such approaches and 1761 there are no immediate plans to do so. 1763 9. Publications 1765 Static QR codes MAY be used to allow contact exchange or device 1766 connection. In either case, the QR code contains an EARL providing 1767 the means of locating, decrypting and authenticating the published 1768 data. 1770 The use of EARLs as a means of publishing encrypted data and the use 1771 of EARLs for location, decryption and authentication is discussed in 1772 [draft-hallambaker-mesh-dare] . 1774 9.1. Contact Exchange 1776 When used for contact exchange, the envelope payload is a 1777 CatalogedContact record. 1779 Besides allowing for exchange of contact information on a business 1780 card, a user might have their contact information printed on personal 1781 property to facilitate return of lost property. 1783 9.2. Device Preconfiguration 1785 The static QR code device connection interaction allows a device with 1786 no keyboard, display or other user affordances to be connected to a 1787 Mesh account. 1789 The information necessary to establish communication with the device 1790 and to complete a device connection workflow is provided by means of 1791 a DevicePreconfiguration record accessed by means of an EARL. 1793 For example, Alice's coffee pot was preconfigured for connection to a 1794 Mesh account at the factory and the following DevicePreconfiguration 1795 record created: 1797 { 1798 "DevicePreconfiguration":{ 1799 "EnvelopedProfileDevice":[{ 1800 "EnvelopeId":"MAQO-2SJC-PGX4-KVHC-TEQ3-I2NP-GYBA", 1801 "dig":"S512", 1802 "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJNQVFPLTJTSkMtUE 1803 dYNC1LVkhDLVRFUTMtSTJOUC1HWUJBIiwKICAiTWVzc2FnZVR5cGUiOiAiUHJvZml 1804 sZURldmljZSIsCiAgImN0eSI6ICJhcHBsaWNhdGlvbi9tbW0vb2JqZWN0IiwKICAi 1805 Q3JlYXRlZCI6ICIyMDIxLTAxLTEzVDE2OjM4OjM5WiJ9"}, 1806 "ewogICJQcm9maWxlRGV2aWNlIjogewogICAgIlByb2ZpbGVTaWduYXR1cm 1807 UiOiB7CiAgICAgICJVZGYiOiAiTUFRTy0yU0pDLVBHWDQtS1ZIQy1URVEzLUkyTlA 1808 tR1lCQSIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdWJs 1809 aWNLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6ICJFZDQ0OCIsCiAgICAgICAgI 1810 CAiUHVibGljIjogInM5SWRESDJhX2RBcmRCQTh0aGc0MUN0d2MwcVZvNnc2N2JSck 1811 VJMUxaZ1NsR3BVU2xYV1oKICBOOFctVlk3aG00MFhvcTdUVTVLRXNRU0EifX19LAo 1812 gICAgIkJhc2VFbmNyeXB0aW9uIjogewogICAgICAiVWRmIjogIk1ENUYtUTNPNi1L 1813 UkdMLUlTNFYtSVdWQy01U0lOLVM2M1IiLAogICAgICAiUHVibGljUGFyYW1ldGVyc 1814 yI6IHsKICAgICAgICAiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOi 1815 AiWDQ0OCIsCiAgICAgICAgICAiUHVibGljIjogImFKU1BVZHJhQ08weXYyWVhWS2t 1816 RNGkxWFVLVmF1LUFwYjctT3hYTmIwNlktdzlJNDIwa2sKICBSelhoU2ZzaWZLUGVn 1817 WDdrSk1IREtaa0EifX19LAogICAgIkJhc2VBdXRoZW50aWNhdGlvbiI6IHsKICAgI 1818 CAgIlVkZiI6ICJNRFFDLUpZWFAtS1ozSS1FVElPLUtNV0EtWElBUC0zSlJEIiwKIC 1819 AgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUVDREg 1820 iOiB7CiAgICAgICAgICAiY3J2IjogIlg0NDgiLAogICAgICAgICAgIlB1YmxpYyI6 1821 ICJLQUJYR3ZfVnV2TFBSaGZWcEhkNXF5a2pKRFVOUml3aGg1dTNDSnB3dUFaWGZ2b 1822 WVNMEtYCiAgaXQ1YjZ3TnZZWXNTb0xlTmZLeTMzN0lBIn19fSwKICAgICJCYXNlU2 1823 lnbmF0dXJlIjogewogICAgICAiVWRmIjogIk1ETDMtUTdSVS1VU0pSLVFGM08tQ0p 1824 FRi02VFBXLUVWQU4iLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAg 1825 ICAiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogI 1826 CAgICAgICAgIlB1YmxpYyI6ICIyd1h5SEdBQ25UcTVlZThtZ1hNX2pBRGxwZVJWN2 1827 djTjNqVFFjOUxQM0xQMVl6aWkyaVNrCiAgVU1nVVRQOHlGX0ttaWJYczVwWHZ2MG9 1828 BIn19fX19", 1829 { 1830 "signatures":[{ 1831 "alg":"S512", 1832 "kid":"MAQO-2SJC-PGX4-KVHC-TEQ3-I2NP-GYBA", 1833 "signature":"Rk-jBj3zvSUIYSTkVcq1BL134IBOKSFw0exQnv1Y 1834 26U42dKutmhV5HahY40oJ3qlnaj6ZNuW0OSAKeoNbCJH--_3IggojgroQT_YHR3xe 1835 G2nr5QcKNdrM9MenLukm4vj9Kk-CiQIsr4LE8rXnx-ICAIA"} 1836 ], 1837 "PayloadDigest":"cdJ8Gs61LhDMaKD_H4s-4BLas3GVu5ktraeMhbgZ 1838 AcKpYK-WOslevSZZ1B73P_gwHsMoltGo8hIL6CBQydwyuw"} 1839 ], 1840 "EnvelopedConnectionDevice":[{ 1841 "dig":"S512", 1842 "ContentMetaData":"ewogICJNZXNzYWdlVHlwZSI6ICJDb25uZWN0aW 1843 9uRGV2aWNlIiwKICAiY3R5IjogImFwcGxpY2F0aW9uL21tbS9vYmplY3QiLAogICJ 1844 DcmVhdGVkIjogIjIwMjEtMDEtMTNUMTY6Mzg6NDBaIn0"}, 1845 "ewogICJDb25uZWN0aW9uRGV2aWNlIjogewogICAgIkRldmljZVNpZ25hdH 1846 VyZSI6IHsKICAgICAgIlVkZiI6ICJNREwzLVE3UlUtVVNKUi1RRjNPLUNKRUYtNlR 1847 QVy1FVkFOIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1 1848 YmxpY0tleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIkVkNDQ4IiwKICAgICAgI 1849 CAgICJQdWJsaWMiOiAiMndYeUhHQUNuVHE1ZWU4bWdYTV9qQURscGVSVjdnY04zal 1850 RRYzlMUDNMUDFZemlpMmlTawogIFVNZ1VUUDh5Rl9LbWliWHM1cFh2djBvQSJ9fX0 1851 sCiAgICAiRGV2aWNlRW5jcnlwdGlvbiI6IHsKICAgICAgIlVkZiI6ICJNRDVGLVEz 1852 TzYtS1JHTC1JUzRWLUlXVkMtNVNJTi1TNjNSIiwKICAgICAgIlB1YmxpY1BhcmFtZ 1853 XRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICAgICAiY3 1854 J2IjogIlg0NDgiLAogICAgICAgICAgIlB1YmxpYyI6ICJhSlNQVWRyYUNPMHl2Mll 1855 YVktrUTRpMVhVS1ZhdS1BcGI3LU94WE5iMDZZLXc5STQyMGtrCiAgUnpYaFNmc2lm 1856 S1BlZ1g3a0pNSERLWmtBIn19fSwKICAgICJEZXZpY2VBdXRoZW50aWNhdGlvbiI6I 1857 HsKICAgICAgIlVkZiI6ICJNRDVGLVEzTzYtS1JHTC1JUzRWLUlXVkMtNVNJTi1TNj 1858 NSIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0t 1859 leUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIlg0NDgiLAogICAgICAgICAgIlB1 1860 YmxpYyI6ICJhSlNQVWRyYUNPMHl2MllYVktrUTRpMVhVS1ZhdS1BcGI3LU94WE5iM 1861 DZZLXc5STQyMGtrCiAgUnpYaFNmc2lmS1BlZ1g3a0pNSERLWmtBIn19fX19", 1862 { 1863 "signatures":[{ 1864 "alg":"S512", 1865 "kid":"MC3W-C4WT-J4SR-F6W7-HOZN-ATJT-DNJZ", 1866 "signature":"7PK0VTzj2A-WQsV2rJB13o4GERF2RsAS0lvE_dEo 1867 gSU9ntXlphGKq2_HG1mRl_ST384i_850aeMASEBUeNmpAC7Int1Dhd6SIWIlPV0ro 1868 xGnfqWQz-0Q44yxoyb10peN8sXApzotLOIcub3tN4q5vS8A"} 1869 ], 1870 "PayloadDigest":"kDW0uaxyl9h89xhwA62Yj0SNOCfdpScINyvRrehg 1871 -kFMn6NCEA69AFtawZ2gwKPRZfV30dAi-cQ47ACH0b3V-g"} 1872 ], 1873 "PrivateKey":{ 1874 "PrivateKeyUDF":{ 1875 "PrivateValue":"ZAAQ-AQWW-7FV6-RK7V-XWUH-5LCF-DMRU-GHAT-5FD 1876 P-PABH-3SD5-3UNJ-I6NO-BYFB", 1877 "KeyType":"MeshProfileDevice"}}, 1878 "ConnectUri":"mcu://maker@example.com/EAQN-I5LT-6YG6-RR5F-57CG- 1879 B755-RFUR-JVQQ-IW5N-X5FR-57BA-SJS6-X2PF-A"}} 1881 To connect to the coffee pot, Alice first scans the QR code with her 1882 administrative device which uses the PIN code and service to 1883 retrieve, decrypt and authenticate the DevicePreconfiguration record. 1884 Future versions of the specification will allow this record to 1885 specify means by which the administration device can establish direct 1886 peer-to-peer communication to complete the connection process by any 1887 communication modality supported by both devices (e.g. IR, 1888 Bluetooth, WiFi-Direct, etc.) 1890 The use of the publication mechanism in device connection is 1891 discussed further in [draft-hallambaker-mesh-protocol]. 1893 9.3. Device Description 1895 The device description publication is a JSON Record that describes a 1896 device that is available for connection. 1898 [Not yet implemented.] 1900 10. Schema 1902 10.1. Shared Classes 1904 The following classes are used as common elements in Mesh profile 1905 specifications. 1907 10.1.1. Classes describing keys 1909 10.1.2. Structure: KeyData 1911 The KeyData class is used to describe public key pairs and trust 1912 assertions associated with a public key. 1914 Udf: String (Optional) UDF fingerprint of the public key parameters 1916 X509Certificate: Binary (Optional) List of X.509 Certificates 1918 X509Chain: Binary [0..Many] X.509 Certificate chain. 1920 X509CSR: Binary (Optional) X.509 Certificate Signing Request. 1922 NotBefore: DateTime (Optional) If present specifies a time instant 1923 that use of the private key is not valid before. 1925 NotOnOrAfter: DateTime (Optional) If present specifies a time 1926 instant that use of the private key is not valid on or after. 1928 10.1.3. Structure: CompositePrivate 1930 Inherits: Key 1932 DeviceKeyUdf: String (Optional) UDF fingerprint of the bound device 1933 key (if used). 1935 10.2. Assertion classes 1937 Classes that are derived from an assertion. 1939 10.2.1. Structure: Assertion 1941 Parent class from which all assertion classes are derived 1943 Names: String [0..Many] Fingerprints of index terms for profile 1944 retrieval. The use of the fingerprint of the name rather than the 1945 name itself is a precaution against enumeration attacks and other 1946 forms of abuse. 1948 Updated: DateTime (Optional) The time instant the profile was last 1949 modified. 1951 NotaryToken: String (Optional) A Uniform Notary Token providing 1952 evidence that a signature was performed after the notary token was 1953 created. 1955 10.2.2. Structure: Condition 1957 Parent class from which all condition classes are derived. 1959 [No fields] 1961 10.2.3. Base Classes 1963 Abstract classes from which the Profile, Activation and Connection 1964 classes are derrived. 1966 10.2.4. Structure: Connection 1968 Inherits: Assertion 1970 SubjectUdf: String (Optional) UDF of the connection target. 1972 AuthorityUdf: String (Optional) UDF of the connection source. 1974 10.2.5. Structure: Activation 1976 Inherits: Assertion 1978 Contains the private activation information for a Mesh application 1979 running on a specific device 1981 ActivationKey: String (Optional) Secret seed used to derive keys 1982 that are not explicitly specified. 1984 Entries: ActivationEntry [0..Many] Activation of named resources. 1986 10.2.6. Structure: ActivationEntry 1988 Resource: String (Optional) Name of the activated resource 1990 Key: KeyData (Optional) The activation key or key share 1992 10.2.7. Mesh Profile Classes 1994 Classes describing Mesh Profiles. All Profiles are Assertions 1995 derrived from Assertion. 1997 10.2.8. Structure: Profile 1999 Inherits: Assertion 2001 Parent class from which all profile classes are derived 2003 ProfileSignature: KeyData (Optional) The permanent signature key 2004 used to sign the profile itself. The UDF of the key is used as 2005 the permanent object identifier of the profile. Thus, by 2006 definition, the KeySignature value of a Profile does not change 2007 under any circumstance. 2009 10.2.9. Structure: ProfileDevice 2011 Inherits: Profile 2013 Describes a mesh device. 2015 Description: String (Optional) Description of the device 2017 BaseEncryption: KeyData (Optional) Base key contribution for 2018 encryption keys. Also used to decrypt activation data sent to the 2019 device during connection to an account. 2021 BaseAuthentication: KeyData (Optional) Base key contribution for 2022 authentication keys. Also used to authenticate the device during 2023 connection to an account. 2025 BaseSignature: KeyData (Optional) Base key contribution for 2026 signature keys. 2028 10.2.10. Structure: ProfileAccount 2030 Base class for the account profiles ProfileUser and ProfileGroup. 2031 These subclasses may be merged at some future date. 2033 Inherits: Profile 2035 AccountAddress: String (Optional) The account address. This is 2036 either a DNS service address (e.g. alice@example.com) or a Mesh 2037 Name (@alice). 2039 ServiceUdf: String (Optional) The fingerprint of the service profile 2040 to which the account is currently bound. 2042 EscrowEncryption: KeyData (Optional) Escrow key associated with the 2043 account. 2045 AccountEncryption: KeyData (Optional) Key currently used to encrypt 2046 data under this profile 2048 AdministratorSignature: KeyData (Optional) Key used to sign 2049 connection assertions to the account. 2051 10.2.11. Structure: ProfileUser 2053 Inherits: ProfileAccount 2055 Account assertion. This is signed by the service hosting the 2056 account. 2058 AccountAuthentication: KeyData (Optional) Key used to authenticate 2059 requests made under this user account. 2061 AccountSignature: KeyData (Optional) Key used to sign data under the 2062 account. 2064 10.2.12. Structure: ProfileGroup 2066 Inherits: ProfileAccount 2068 Describes a group. Note that while a group is created by one person 2069 who becomes its first administrator, control of the group may pass to 2070 other administrators over time. 2072 [No fields] 2074 10.2.13. Structure: ProfileService 2076 Inherits: Profile 2078 Profile of a Mesh Service 2080 ServiceAuthentication: KeyData (Optional) Key used to authenticate 2081 service connections. 2083 ServiceEncryption: KeyData (Optional) Key used to encrypt data under 2084 this profile 2086 ServiceSignature: KeyData (Optional) Key used to sign data under the 2087 account. 2089 10.2.14. Structure: ProfileHost 2091 Inherits: Profile 2092 KeyAuthentication: KeyData (Optional) Key used to authenticate 2093 service connections. 2095 KeyEncryption: KeyData (Optional) Key used to pass encrypted data to 2096 the device such as a 2098 10.2.15. Connection Assertions 2100 Connection assertions are used to authenticate and authorize 2101 interactions between devices and the service currently servicing the 2102 account. They SHOULD NOT be visible to external parties. 2104 10.2.16. Structure: ConnectionDevice 2106 Inherits: Connection 2108 Connection assertion used to authenticate service requests made by a 2109 device. 2111 AccountAddress: String (Optional) The account address 2113 DeviceSignature: KeyData (Optional) The signature key for use of the 2114 device under the profile 2116 DeviceEncryption: KeyData (Optional) The encryption key for use of 2117 the device under the profile 2119 DeviceAuthentication: KeyData (Optional) The authentication key for 2120 use of the device under the profile 2122 10.2.17. Structure: ConnectionApplication 2124 Inherits: Connection 2126 Connection assertion stating that a particular device is 2128 [No fields] 2130 10.2.18. Structure: ConnectionGroup 2132 Describes the connection of a member to a group. 2134 Inherits: Connection 2136 [No fields] 2138 10.2.19. Structure: ConnectionService 2140 Inherits: Connection 2142 [No fields] 2144 10.2.20. Structure: ConnectionHost 2146 Inherits: Connection 2148 [No fields] 2150 10.2.21. Activation Assertions 2152 10.2.22. Structure: ActivationDevice 2154 Contains activation data for device specific keys used in the context 2155 of a Mesh account. 2157 Inherits: Activation 2159 AccountUdf: String (Optional) The UDF of the account 2161 10.2.23. Structure: ActivationAccount 2163 Inherits: Activation 2165 ProfileSignature: KeyData (Optional) Grant access to profile online 2166 signing key used to sign updates to the profile. 2168 AdministratorSignature: KeyData (Optional) Grant access to Profile 2169 administration key used to make changes to administrator catalogs. 2171 AccountEncryption: KeyData (Optional) Grant access to ProfileUser 2172 account encryption key 2174 AccountAuthentication: KeyData (Optional) Grant access to 2175 ProfileUser account authentication key 2177 AccountSignature: KeyData (Optional) Grant access to ProfileUser 2178 account signature key 2180 10.2.24. Structure: ActivationApplication 2182 Inherits: Activation 2184 [No fields] 2186 10.3. Data Structures 2188 Classes describing data used in cataloged data. 2190 10.3.1. Structure: Contact 2192 Inherits: Assertion 2194 Base class for contact entries. 2196 Id: String (Optional) The globally unique contact identifier. 2198 Anchors: Anchor [0..Many] Mesh fingerprints associated with the 2199 contact. 2201 NetworkAddresses: NetworkAddress [0..Many] Network address entries 2203 Locations: Location [0..Many] The physical locations the contact is 2204 associated with. 2206 Roles: Role [0..Many] The roles of the contact 2208 Bookmark: Bookmark [0..Many] The Web sites and other online 2209 presences of the contact 2211 Sources: TaggedSource [0..Many] Source(s) from which this contact 2212 was constructed. 2214 10.3.2. Structure: Anchor 2216 Trust anchor 2218 Udf: String (Optional) The trust anchor. 2220 Validation: String (Optional) The means of validation. 2222 10.3.3. Structure: TaggedSource 2224 Source from which contact information was obtained. 2226 LocalName: String (Optional) Short name for the contact information. 2228 Validation: String (Optional) The means of validation. 2230 BinarySource: Binary (Optional) The contact data in binary form. 2232 EnvelopedSource: Enveloped (Optional) The contact data in enveloped 2233 form. If present, the BinarySource property is ignored. 2235 10.3.4. Structure: ContactGroup 2237 Inherits: Contact 2239 Contact for a group, including encryption groups. 2241 [No fields] 2243 10.3.5. Structure: ContactPerson 2245 Inherits: Contact 2247 CommonNames: PersonName [0..Many] List of person names in order of 2248 preference 2250 10.3.6. Structure: ContactOrganization 2252 Inherits: Contact 2254 CommonNames: OrganizationName [0..Many] List of person names in 2255 order of preference 2257 10.3.7. Structure: OrganizationName 2259 The name of an organization 2261 Inactive: Boolean (Optional) If true, the name is not in current 2262 use. 2264 RegisteredName: String (Optional) The registered name. 2266 DBA: String (Optional) Names that the organization uses including 2267 trading names and doing business as names. 2269 10.3.8. Structure: PersonName 2271 The name of a natural person 2273 Inactive: Boolean (Optional) If true, the name is not in current 2274 use. 2276 FullName: String (Optional) The preferred presentation of the full 2277 name. 2279 Prefix: String (Optional) Honorific or title, E.g. Sir, Lord, Dr., 2280 Mr. 2282 First: String (Optional) First name. 2284 Middle: String [0..Many] Middle names or initials. 2286 Last: String (Optional) Last name. 2288 Suffix: String (Optional) Nominal suffix, e.g. Jr., III, etc. 2290 PostNominal: String (Optional) Post nominal letters (if used). 2292 10.3.9. Structure: NetworkAddress 2294 Provides all means of contacting the individual according to a 2295 particular network address 2297 Inactive: Boolean (Optional) If true, the name is not in current 2298 use. 2300 Address: String (Optional) The network address, e.g. 2301 alice@example.com 2303 NetworkCapability: String [0..Many] The capabilities bound to this 2304 address. 2306 EnvelopedProfileAccount: Enveloped (Optional) The account profile 2308 Protocols: NetworkProtocol [0..Many] Public keys associated with the 2309 network address 2311 10.3.10. Structure: NetworkProtocol 2313 Protocol: String (Optional) The IANA protocol|identifier of the 2314 network protocols by which the contact may be reached using the 2315 specified Address. 2317 10.3.11. Structure: Role 2319 OrganizationName: String (Optional) The organization at which the 2320 role is held 2322 Titles: String [0..Many] The titles held with respect to that 2323 organization. 2325 Locations: Location [0..Many] Postal or physical addresses 2326 associated with the role. 2328 10.3.12. Structure: Location 2330 Appartment: String (Optional) 2331 Street: String (Optional) 2333 District: String (Optional) 2335 Locality: String (Optional) 2337 County: String (Optional) 2339 Postcode: String (Optional) 2341 Country: String (Optional) 2343 10.3.13. Structure: Bookmark 2345 Uri: String (Optional) 2347 Title: String (Optional) 2349 Role: String [0..Many] 2351 10.3.14. Structure: Reference 2353 MessageId: String (Optional) The received message to which this is a 2354 response 2356 ResponseId: String (Optional) Message that was generated in response 2357 to the original (optional). 2359 Relationship: String (Optional) The relationship type. This can be 2360 Read, Unread, Accept, Reject. 2362 10.3.15. Structure: Task 2364 Key: String (Optional) Unique key. 2366 Start: DateTime (Optional) 2368 Finish: DateTime (Optional) 2370 StartTravel: String (Optional) 2372 FinishTravel: String (Optional) 2374 TimeZone: String (Optional) 2376 Title: String (Optional) 2378 Description: String (Optional) 2379 Location: String (Optional) 2381 Trigger: String [0..Many] 2383 Conference: String [0..Many] 2385 Repeat: String (Optional) 2387 Busy: Boolean (Optional) 2389 10.4. Catalog Entries 2391 10.4.1. Structure: CatalogedEntry 2393 Base class for cataloged Mesh data. 2395 Labels: String [0..Many] The set of labels describing the entry 2397 10.4.2. Structure: CatalogedDevice 2399 Inherits: CatalogedEntry 2401 Public device entry, indexed under the device ID Hello 2403 Udf: String (Optional) UDF of the signature key of the device in the 2404 Mesh 2406 DeviceUdf: String (Optional) UDF of the offline signature key of the 2407 device 2409 SignatureUdf: String (Optional) UDF of the account online signature 2410 key 2412 EnvelopedProfileUser: Enveloped (Optional) The Mesh profile 2414 EnvelopedProfileDevice: Enveloped (Optional) The device profile 2416 EnvelopedConnectionUser: Enveloped (Optional) The public assertion 2417 demonstrating connection of the Device to the Mesh 2419 EnvelopedActivationDevice: Enveloped (Optional) The activation of 2420 the device within the Mesh account 2422 EnvelopedActivationAccount: Enveloped (Optional) The activation of 2423 the device within the Mesh account 2425 EnvelopedActivationApplication: Enveloped [0..Many] Application 2426 activations granted to the device. 2428 10.4.3. Structure: CatalogedPublication 2430 Inherits: CatalogedEntry 2432 A publication. 2434 Id: String (Optional) Unique identifier code 2436 Authenticator: String (Optional) The witness key value to use to 2437 request access to the record. 2439 EnvelopedData: DareEnvelope (Optional) Dare Envelope containing the 2440 entry data. The data type is specified by the envelope metadata. 2442 NotOnOrAfter: DateTime (Optional) Epiration time (inclusive) 2444 10.4.4. Structure: CatalogedCredential 2446 Inherits: CatalogedEntry 2448 Protocol: String (Optional) 2450 Service: String (Optional) 2452 Username: String (Optional) 2454 Password: String (Optional) 2456 10.4.5. Structure: CatalogedNetwork 2458 Inherits: CatalogedEntry 2460 Protocol: String (Optional) 2462 Service: String (Optional) 2464 Username: String (Optional) 2466 Password: String (Optional) 2468 10.4.6. Structure: CatalogedContact 2470 Inherits: CatalogedEntry 2472 Key: String (Optional) Unique key. 2474 Self: Boolean (Optional) If true, this catalog entry is for the user 2475 who created the catalog. 2477 10.4.7. Structure: CatalogedAccess 2479 Inherits: CatalogedEntry 2481 [No fields] 2483 10.4.8. Structure: CryptographicCapability 2485 Id: String (Optional) The identifier of the capability. If this is 2486 a user capability, MUST match the KeyData identifier. If this is 2487 a serviced capability, MUST match the value of ServiceId on the 2488 corresponding service capability. 2490 KeyData: KeyData (Optional) The key that enables the capability 2492 EnvelopedKeyShares: Enveloped [0..Many] One or more enveloped key 2493 shares. 2495 SubjectId: String (Optional) The identifier of the resource that is 2496 controlled using the key. 2498 SubjectAddress: String (Optional) The address of the resource that 2499 is controlled using the key. 2501 10.4.9. Structure: CapabilityDecrypt 2503 Inherits: CryptographicCapability 2505 The corresponding key is a decryption key 2507 [No fields] 2509 10.4.10. Structure: CapabilityDecryptPartial 2511 Inherits: CapabilityDecrypt 2513 The corresponding key is an encryption key 2515 ServiceId: String (Optional) The identifier used to claim the 2516 capability from the service.[Only present for a partial 2517 capability.] 2519 ServiceAddress: String (Optional) The service account that supports 2520 a serviced capability. [Only present for a partial capability.] 2522 10.4.11. Structure: CapabilityDecryptServiced 2524 Inherits: CapabilityDecrypt 2526 The corresponding key is an encryption key 2528 AuthenticationId: String (Optional) UDF of trust root under which 2529 request to use a serviced capability must be authorized. [Only 2530 present for a serviced capability] 2532 10.4.12. Structure: CapabilitySign 2534 Inherits: CryptographicCapability 2536 The corresponding key is an administration key 2538 [No fields] 2540 10.4.13. Structure: CapabilityKeyGenerate 2542 Inherits: CryptographicCapability 2544 The corresponding key is a key that may be used to generate key 2545 shares. 2547 [No fields] 2549 10.4.14. Structure: CapabilityFairExchange 2551 Inherits: CryptographicCapability 2553 The corresponding key is a decryption key to be used in accordance 2554 with the Micali Fair Electronic Exchange with Invisible Trusted 2555 Parties protocol. 2557 [No fields] 2559 10.4.15. Structure: CatalogedBookmark 2561 Inherits: CatalogedEntry 2563 Uri: String (Optional) 2565 Title: String (Optional) 2567 Path: String (Optional) 2569 10.4.16. Structure: CatalogedTask 2571 Inherits: CatalogedEntry 2573 EnvelopedTask: Enveloped (Optional) 2575 Title: String (Optional) 2577 Key: String (Optional) Unique key. 2579 10.4.17. Structure: CatalogedApplication 2581 Inherits: CatalogedEntry 2583 Key: String (Optional) 2585 EnvelopedCapabilities: DareEnvelope [0..Many] Enveloped keys for use 2586 with Application 2588 10.4.18. Structure: CatalogedMember 2590 ContactAddress: String (Optional) 2592 MemberCapabilityId: String (Optional) 2594 ServiceCapabilityId: String (Optional) 2596 Inherits: CatalogedEntry 2598 10.4.19. Structure: CatalogedGroup 2600 Inherits: CatalogedApplication 2602 EnvelopedProfileGroup: Enveloped (Optional) The Mesh profile 2604 EnvelopedActivationAccount: Enveloped (Optional) The activation of 2605 the device within the Mesh account 2607 10.4.20. Structure: CatalogedApplicationSSH 2609 Inherits: CatalogedApplication 2611 [No fields] 2613 10.4.21. Structure: CatalogedApplicationMail 2615 Inherits: CatalogedApplication 2617 [No fields] 2619 10.4.22. Structure: CatalogedApplicationNetwork 2621 Inherits: CatalogedApplication 2623 [No fields] 2625 10.5. Publications 2627 10.5.1. Structure: DevicePreconfiguration 2629 A data structure that is passed 2631 EnvelopedProfileDevice: Enveloped (Optional) The device profile 2633 EnvelopedConnectionDevice: Enveloped (Optional) The device 2634 connection 2636 ConnectUri: String (Optional) The connection URI. This would 2637 normally be printed on the device as a QR code. 2639 10.6. Messages 2641 10.6.1. Structure: Message 2643 MessageId: String (Optional) Unique per-message ID. When 2644 encapsulating a Mesh Message in a DARE envelope, the envelope 2645 EnvelopeID field MUST be a UDF fingerprint of the MessageId value. 2647 Sender: String (Optional) 2649 Recipient: String (Optional) 2651 10.6.2. Structure: MessageError 2653 Inherits: Message 2655 ErrorCode: String (Optional) 2657 10.6.3. Structure: MessageComplete 2659 Inherits: Message 2661 References: Reference [0..Many] 2663 10.6.4. Structure: MessagePinValidated 2665 Inherits: Message 2667 AuthenticatedData: DareEnvelope (Optional) Enveloped data that is 2668 authenticated by means of the PIN 2670 ClientNonce: Binary (Optional) Nonce provided by the client to 2671 validate the PIN 2673 PinId: String (Optional) Pin identifier value calculated from the 2674 PIN code, action and account address. 2676 PinWitness: Binary (Optional) Witness value calculated as KDF 2677 (Device.Udf + AccountAddress, ClientNonce) 2679 10.6.5. Structure: MessagePin 2681 Account: String (Optional) 2683 Inherits: Message 2685 Expires: DateTime (Optional) 2687 Automatic: Boolean (Optional) If true, authentication against the 2688 PIN code is sufficient to complete the associated action without 2689 further authorization. 2691 SaltedPin: String (Optional) PIN code bound to the specified action. 2693 Action: String (Optional) The action to which this PIN code is 2694 bound. 2696 10.6.6. Structure: RequestConnection 2698 Connection request message. This message contains the information 2700 Inherits: MessagePinValidated 2702 AccountAddress: String (Optional) 2704 10.6.7. Structure: AcknowledgeConnection 2706 Connection request message generated by a service on receipt of a 2707 valid MessageConnectionRequestClient 2709 Inherits: Message 2710 EnvelopedRequestConnection: Enveloped (Optional) The client 2711 connection request. 2713 ServerNonce: Binary (Optional) 2715 Witness: String (Optional) 2717 10.6.8. Structure: RespondConnection 2719 Respond to RequestConnection message to grant or refuse the 2720 connection request. 2722 Inherits: Message 2724 Result: String (Optional) The response to the request. One of 2725 "Accept", "Reject" or "Pending". 2727 CatalogedDevice: CatalogedDevice (Optional) The device information. 2728 MUST be present if the value of Result is "Accept". MUST be 2729 absent or null otherwise. 2731 10.6.9. Structure: MessageContact 2733 Inherits: MessagePinValidated 2735 Reply: Boolean (Optional) If true, requests that the recipient 2736 return their own contact information in reply. 2738 Subject: String (Optional) Optional explanation of the reason for 2739 the request. 2741 PIN: String (Optional) One time authentication code supplied to a 2742 recipient to allow authentication of the response. 2744 10.6.10. Structure: GroupInvitation 2746 Inherits: Message 2748 Text: String (Optional) 2750 10.6.11. Structure: RequestConfirmation 2752 Inherits: Message 2754 Text: String (Optional) 2756 10.6.12. Structure: ResponseConfirmation 2758 Inherits: Message 2760 Request: Enveloped (Optional) 2762 Accept: Boolean (Optional) 2764 10.6.13. Structure: RequestTask 2766 Inherits: Message 2768 [No fields] 2770 10.6.14. Structure: MessageClaim 2772 Inherits: Message 2774 PublicationId: String (Optional) 2776 ServiceAuthenticate: String (Optional) 2778 DeviceAuthenticate: String (Optional) 2780 Expires: DateTime (Optional) 2782 10.6.15. Structure: ProcessResult 2784 For future use, allows logging of operations and results 2786 Inherits: Message 2788 Success: Boolean (Optional) 2790 ErrorReport: String (Optional) The error report code. 2792 11. Security Considerations 2794 The security considerations for use and implementation of Mesh 2795 services and applications are described in the Mesh Security 2796 Considerations guide [draft-hallambaker-mesh-security]. 2798 12. IANA Considerations 2800 All the IANA considerations for the Mesh documents are specified in 2801 this document 2803 13. Acknowledgements 2805 A list of people who have contributed to the design of the Mesh is 2806 presented in [draft-hallambaker-mesh-architecture]. 2808 14. Appendix A: Example Container Organization (not normative) 2810 The means by which profiles are stored on devices is outside the 2811 scope of the specification. Only catalogs that are required to be 2812 shared between machines by means of accounts need to be standardized. 2814 14.1. Device 2816 Host Catalog: Host.dare Catalog of all the Mesh Profiles that the 2817 user has registered with the device and the latest version of the 2818 device profile for this device. 2820 MeshCatalog: [UDF-Mesh].dcat Catalog containing the Account Entries 2821 for the Mesh [UDF-Mesh]. 2823 Account Catalogs: [UDF-Account]/mmm_Device.dcat The device catalog 2824 associated with the specified account 2826 Account Catalogs: [UDF-Account]/[Catalog name].dcat The set of 2827 account catalogs that are shared verbatim between the devices 2828 connected to the account. 2830 14.1.1. Creating a new Mesh 2832 Create new Mesh Profile, Device Profile, Add to Host Catalog 2834 Create MeshCatalog 2836 14.1.2. Adding an Account 2838 Create new Account Profile, Add to MeshCatalog 2840 Create new Account Device Catalog 2842 For each device to be added to the account: Create Account Connection 2843 Assertion, add to Account Device Catalog. 2845 14.1.3. Adding a Device 2847 Create a Device Connection Assertion. 2849 For each account the device is to be added to: Create Account 2850 Connection Assertion, add to Account Device Catalog. 2852 14.2. Service 2854 Master Catalog Catalog of all services on machine 2856 Service Catalog Catalog of accounts in the service. 2858 14.2.1. Creating a Service 2860 Create a Service Description, add to Master Catalog 2862 14.2.2. Adding an Account 2864 Create the account entry, add to Service Catalog 2866 Create the Account Directory 2868 15. Appendix B: Collected Authentication and Encryption Requirements 2870 15.1. Mesh Messaging 2872 +=======================+=========+==================+ 2873 | Message | Signer | Recipients | 2874 +=======================+=========+==================+ 2875 | RequestConnection | Device | Service | 2876 +-----------------------+---------+------------------+ 2877 | AcknowledgeConnection | Service | Device, Receiver | 2878 +-----------------------+---------+------------------+ 2879 | OfferGroup | Sender | Receiver | 2880 +-----------------------+---------+------------------+ 2881 | RequestContact | Sender | Receiver | 2882 +-----------------------+---------+------------------+ 2883 | ReplyContact | Sender | Receiver | 2884 +-----------------------+---------+------------------+ 2885 | RequestConfirmation | Sender | Receiver | 2886 +-----------------------+---------+------------------+ 2887 | ResponseConfirmation | Sender | Receiver | 2888 +-----------------------+---------+------------------+ 2889 | RequestTask | Sender | Receiver | 2890 +-----------------------+---------+------------------+ 2891 | ResponseTask | Sender | Receiver | 2892 +-----------------------+---------+------------------+ 2894 Table 1 2896 16. Normative References 2898 [draft-hallambaker-mesh-architecture] 2899 Hallam-Baker, P., "Mathematical Mesh 3.0 Part I: 2900 Architecture Guide", Work in Progress, Internet-Draft, 2901 draft-hallambaker-mesh-architecture-15, 2 November 2020, 2902 . 2905 [draft-hallambaker-mesh-cryptography] 2906 Hallam-Baker, P., "Mathematical Mesh 3.0 Part VIII: 2907 Cryptographic Algorithms", Work in Progress, Internet- 2908 Draft, draft-hallambaker-mesh-cryptography-07, 2 November 2909 2020, . 2912 [draft-hallambaker-mesh-dare] 2913 Hallam-Baker, P., "Mathematical Mesh 3.0 Part III : Data 2914 At Rest Encryption (DARE)", Work in Progress, Internet- 2915 Draft, draft-hallambaker-mesh-dare-10, 2 November 2020, 2916 . 2919 [draft-hallambaker-mesh-discovery] 2920 Hallam-Baker, P., "Mathematical Mesh 3.0 Part VI: Mesh 2921 Discovery Service", Work in Progress, Internet-Draft, 2922 draft-hallambaker-mesh-discovery-00, 2 November 2020, 2923 . 2926 [draft-hallambaker-mesh-notary] 2927 "[Reference Not Found!]". 2929 [draft-hallambaker-mesh-protocol] 2930 Hallam-Baker, P., "Mathematical Mesh 3.0 Part V: Protocol 2931 Reference", Work in Progress, Internet-Draft, draft- 2932 hallambaker-mesh-protocol-07, 2 November 2020, 2933 . 2936 [draft-hallambaker-mesh-security] 2937 Hallam-Baker, P., "Mathematical Mesh 3.0 Part VII: 2938 Security Considerations", Work in Progress, Internet- 2939 Draft, draft-hallambaker-mesh-security-06, 2 November 2940 2020, . 2943 [draft-hallambaker-mesh-udf] 2944 Hallam-Baker, P., "Mathematical Mesh 3.0 Part II: Uniform 2945 Data Fingerprint.", Work in Progress, Internet-Draft, 2946 draft-hallambaker-mesh-udf-11, 2 November 2020, 2947 . 2950 [draft-hallambaker-threshold] 2951 Hallam-Baker, P., "Threshold Modes in Elliptic Curves", 2952 Work in Progress, Internet-Draft, draft-hallambaker- 2953 threshold-04, 2 November 2020, 2954 . 2957 [draft-hallambaker-threshold-sigs] 2958 Hallam-Baker, P., "Threshold Signatures in Elliptic 2959 Curves", Work in Progress, Internet-Draft, draft- 2960 hallambaker-threshold-sigs-05, 2 November 2020, 2961 . 2964 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2965 Requirement Levels", BCP 14, RFC 2119, 2966 DOI 10.17487/RFC2119, March 1997, 2967 . 2969 17. Informative References 2971 [draft-hallambaker-mesh-developer] 2972 Hallam-Baker, P., "Mathematical Mesh: Reference 2973 Implementation", Work in Progress, Internet-Draft, draft- 2974 hallambaker-mesh-developer-10, 27 July 2020, 2975 . 2978 [RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile", 2979 RFC 2426, DOI 10.17487/RFC2426, September 1998, 2980 . 2982 [RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling 2983 Core Object Specification (iCalendar)", RFC 5545, 2984 DOI 10.17487/RFC5545, September 2009, 2985 .