idnits 2.17.1 draft-hallambaker-mesh-reference-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 402 has weird spacing: '... Create alice...' -- The document date (August 31, 2018) is 2064 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 1915 == Unused Reference: 'RFC6335' is defined on line 1900, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hallam-Baker 3 Internet-Draft Comodo Group Inc. 4 Intended status: Informational August 31, 2018 5 Expires: March 4, 2019 7 Mathematical Mesh Part II: Reference 8 draft-hallambaker-mesh-reference-10 10 Abstract 12 The Mathematical Mesh ?The Mesh? is an end-to-end secure 13 infrastructure that facilitates the exchange of configuration and 14 credential data between multiple user devices. The core protocols of 15 the Mesh are described with examples of common use cases and 16 reference data. 18 This document is also available online at 19 http://mathmesh.com/Documents/draft-hallambaker-mesh-reference.html 20 [1] . 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on March 4, 2019. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 59 2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 5 60 2.3. Related Specifications . . . . . . . . . . . . . . . . . 5 61 2.4. Implementation Status . . . . . . . . . . . . . . . . . . 5 62 3. Mesh Profiles . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3.1. Mesh Master Profile . . . . . . . . . . . . . . . . . . . 6 64 3.2. Mesh Device Profile . . . . . . . . . . . . . . . . . . . 7 65 3.3. Mesh Personal Profile . . . . . . . . . . . . . . . . . . 7 66 3.4. Mesh Application Profile . . . . . . . . . . . . . . . . 8 67 4. Mesh Portal Service . . . . . . . . . . . . . . . . . . . . . 8 68 4.1. Creating a Mesh Service Account . . . . . . . . . . . . . 8 69 4.2. Using Recovery Records . . . . . . . . . . . . . . . . . 9 70 4.2.1. Creating a Recovery Record . . . . . . . . . . . . . 9 71 4.2.2. Recovering a Profile. . . . . . . . . . . . . . . . . 11 72 4.3. Connecting a Device to a Portal Account . . . . . . . . . 11 73 4.3.1. Deleting a Portal Account . . . . . . . . . . . . . . 13 74 5. Mesh Catalogs . . . . . . . . . . . . . . . . . . . . . . . . 14 75 5.1. Synchronizing a Device to a Catalog . . . . . . . . . . . 14 76 6. Mesh Catalog Services . . . . . . . . . . . . . . . . . . . . 16 77 6.1. The Contacts Catalog . . . . . . . . . . . . . . . . . . 16 78 6.2. Credential Catalog . . . . . . . . . . . . . . . . . . . 16 79 6.3. Tasks Catalog . . . . . . . . . . . . . . . . . . . . . . 16 80 6.4. Mail Catalog . . . . . . . . . . . . . . . . . . . . . . 17 81 6.5. SSH Catalog . . . . . . . . . . . . . . . . . . . . . . . 17 82 6.6. Recryption Catalog . . . . . . . . . . . . . . . . . . . 17 83 7. Mesh Messaging . . . . . . . . . . . . . . . . . . . . . . . 17 84 7.1. Message Origination . . . . . . . . . . . . . . . . . . . 18 85 7.2. Message Transit . . . . . . . . . . . . . . . . . . . . . 19 86 7.3. Receiving Messages . . . . . . . . . . . . . . . . . . . 20 87 7.3.1. Responding to Messages . . . . . . . . . . . . . . . 21 88 8. Messaging Services . . . . . . . . . . . . . . . . . . . . . 21 89 8.1. Contact Messaging Service . . . . . . . . . . . . . . . . 21 90 8.2. Confirmation Messaging Service . . . . . . . . . . . . . 21 91 8.3. Asynchronous Messaging Service . . . . . . . . . . . . . 21 92 8.4. Synchronous Messaging Service . . . . . . . . . . . . . . 21 93 9. Shared Classes . . . . . . . . . . . . . . . . . . . . . . . 21 94 9.1. Cryptographic Data Classes . . . . . . . . . . . . . . . 21 95 9.1.1. Structure: PublicKey . . . . . . . . . . . . . . . . 22 96 9.1.2. Structure: SignedData . . . . . . . . . . . . . . . . 22 97 9.1.3. Structure: EncryptedData . . . . . . . . . . . . . . 22 98 9.2. Common Application Classes . . . . . . . . . . . . . . . 22 99 9.2.1. Structure: Connection . . . . . . . . . . . . . . . . 22 100 10. Mesh Profile Objects . . . . . . . . . . . . . . . . . . . . 23 101 10.1. Base Profile Objects . . . . . . . . . . . . . . . . . . 23 102 10.1.1. Structure: Entry . . . . . . . . . . . . . . . . . . 23 103 10.1.2. Structure: SignedProfile . . . . . . . . . . . . . . 23 104 10.1.3. Structure: Advice . . . . . . . . . . . . . . . . . 23 105 10.1.4. Structure: PortalAdvice . . . . . . . . . . . . . . 24 106 10.1.5. Structure: Profile . . . . . . . . . . . . . . . . . 24 107 10.2. Device Profile Classes . . . . . . . . . . . . . . . . . 24 108 10.2.1. Structure: SignedDeviceProfile . . . . . . . . . . . 24 109 10.2.2. Structure: DeviceProfile . . . . . . . . . . . . . . 24 110 10.2.3. Structure: DevicePrivateProfile . . . . . . . . . . 25 111 10.3. Master Profile Objects . . . . . . . . . . . . . . . . . 25 112 10.3.1. Structure: SignedMasterProfile . . . . . . . . . . . 25 113 10.3.2. Structure: MasterProfile . . . . . . . . . . . . . . 25 114 10.4. Personal Profile Objects . . . . . . . . . . . . . . . . 26 115 10.4.1. Structure: SignedPersonalProfile . . . . . . . . . . 26 116 10.4.2. Structure: PersonalProfile . . . . . . . . . . . . . 26 117 10.4.3. Structure: ApplicationProfileEntry . . . . . . . . . 26 118 10.5. Application Profile Objects . . . . . . . . . . . . . . 27 119 10.5.1. Structure: SignedApplicationProfile . . . . . . . . 27 120 10.5.2. Structure: ApplicationProfile . . . . . . . . . . . 27 121 10.5.3. Structure: ApplicationProfilePrivate . . . . . . . . 27 122 10.5.4. Structure: ApplicationDevicePublic . . . . . . . . . 27 123 10.5.5. Structure: ApplicationDevicePrivate . . . . . . . . 28 124 10.6. Key Escrow Objects . . . . . . . . . . . . . . . . . . . 28 125 10.6.1. Structure: EscrowEntry . . . . . . . . . . . . . . . 28 126 10.6.2. Structure: OfflineEscrowEntry . . . . . . . . . . . 28 127 10.6.3. Structure: OnlineEscrowEntry . . . . . . . . . . . . 28 128 10.6.4. Structure: EscrowedKeySet . . . . . . . . . . . . . 28 129 11. Portal Connection . . . . . . . . . . . . . . . . . . . . . . 28 130 11.1. Connection Request and Response Structures . . . . . . . 28 131 11.1.1. Structure: ConnectionRequest . . . . . . . . . . . . 29 132 11.1.2. Structure: SignedConnectionRequest . . . . . . . . . 29 133 11.1.3. Structure: ConnectionResult . . . . . . . . . . . . 29 134 11.1.4. Structure: SignedConnectionResult . . . . . . . . . 29 135 12. Mesh Portal Service Reference . . . . . . . . . . . . . . . . 29 136 12.1. Request Messages . . . . . . . . . . . . . . . . . . . . 30 137 12.1.1. Message: MeshRequest . . . . . . . . . . . . . . . . 30 138 12.2. Response Messages . . . . . . . . . . . . . . . . . . . 30 139 12.2.1. Message: MeshResponse . . . . . . . . . . . . . . . 30 140 12.3. Imported Objects . . . . . . . . . . . . . . . . . . . . 30 141 12.4. Common Structures . . . . . . . . . . . . . . . . . . . 30 142 12.4.1. Structure: KeyValue . . . . . . . . . . . . . . . . 30 143 12.4.2. Structure: SearchConstraints . . . . . . . . . . . . 31 144 12.5. Transaction: Hello . . . . . . . . . . . . . . . . . . . 31 145 12.6. Transaction: ValidateAccount . . . . . . . . . . . . . . 31 146 12.6.1. Message: ValidateRequest . . . . . . . . . . . . . . 32 147 12.6.2. Message: ValidateResponse . . . . . . . . . . . . . 32 148 12.7. Transaction: CreateAccount . . . . . . . . . . . . . . . 33 149 12.7.1. Message: CreateRequest . . . . . . . . . . . . . . . 33 150 12.7.2. Message: CreateResponse . . . . . . . . . . . . . . 33 151 12.8. Transaction: DeleteAccount . . . . . . . . . . . . . . . 33 152 12.8.1. Message: DeleteRequest . . . . . . . . . . . . . . . 34 153 12.8.2. Message: DeleteResponse . . . . . . . . . . . . . . 34 154 12.9. Transaction: Get . . . . . . . . . . . . . . . . . . . . 34 155 12.9.1. Message: GetRequest . . . . . . . . . . . . . . . . 34 156 12.9.2. Message: GetResponse . . . . . . . . . . . . . . . . 35 157 12.10. Transaction: Publish . . . . . . . . . . . . . . . . . . 35 158 12.10.1. Message: PublishRequest . . . . . . . . . . . . . . 35 159 12.10.2. Message: PublishResponse . . . . . . . . . . . . . 36 160 12.11. Transaction: Status . . . . . . . . . . . . . . . . . . 36 161 12.11.1. Message: StatusRequest . . . . . . . . . . . . . . 36 162 12.11.2. Message: StatusResponse . . . . . . . . . . . . . . 36 163 12.12. Transaction: ConnectStart . . . . . . . . . . . . . . . 37 164 12.12.1. Message: ConnectStartRequest . . . . . . . . . . . 37 165 12.12.2. Message: ConnectStartResponse . . . . . . . . . . . 37 166 12.13. Transaction: ConnectStatus . . . . . . . . . . . . . . . 37 167 12.13.1. Message: ConnectStatusRequest . . . . . . . . . . . 38 168 12.13.2. Message: ConnectStatusResponse . . . . . . . . . . 38 169 12.14. Transaction: ConnectPending . . . . . . . . . . . . . . 38 170 12.14.1. Message: ConnectPendingRequest . . . . . . . . . . 38 171 12.14.2. Message: ConnectPendingResponse . . . . . . . . . . 39 172 12.15. Transaction: ConnectComplete . . . . . . . . . . . . . . 39 173 12.15.1. Message: ConnectCompleteRequest . . . . . . . . . . 39 174 12.15.2. Message: ConnectCompleteResponse . . . . . . . . . 39 175 12.16. Transaction: Transfer . . . . . . . . . . . . . . . . . 40 176 12.16.1. Message: TransferRequest . . . . . . . . . . . . . 40 177 12.16.2. Message: TransferResponse . . . . . . . . . . . . . 40 178 13. Security Considerations . . . . . . . . . . . . . . . . . . . 40 179 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 180 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41 181 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 182 16.1. Normative References . . . . . . . . . . . . . . . . . . 41 183 16.2. Informative References . . . . . . . . . . . . . . . . . 41 184 16.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 41 185 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 41 187 1. Introduction 189 This document describes the data structures and network protocols of 190 the Mathematical Mesh illustrated with illustrative examples. For an 191 overview of the Mesh objectives and architecture, consult the 192 accompanying Architecture Guide [draft-hallambaker-mesh-architecture] 193 This document has two main sections. The first section presents 194 examples of using the Mesh to address common use cases. The second 195 section contains the Mesh profile and service schemas. All the 196 material in both sections is generated from the Mesh reference 197 implementation [draft-hallambaker-mesh-developer] . 199 Although some of the services described in this document could be 200 used to replace existing Internet protocols including FTP and SMTP, 201 the principal value of any communication protocol lies in the size of 202 the audience it allows them to communicate with. Thus, while the 203 Mesh Messaging service is designed to support efficient and reliable 204 transfer of messages ranging in size from a few bytes to multiple 205 terabytes, the near term applications of these services will be to 206 applications that are not adequately supported by existing protocols 207 if at all. 209 2. Definitions 211 This section presents the related specifications and standard, the 212 terms that are used as terms of art within the documents and the 213 terms used as requirements language. 215 2.1. Requirements Language 217 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 218 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 219 document are to be interpreted as described in [RFC2119] . 221 2.2. Defined Terms 223 The terms of art used in this document are described in the Mesh 224 Architecture Guide [draft-hallambaker-mesh-architecture] . 226 2.3. Related Specifications 228 The architecture of the Mathematical Mesh is described in the Mesh 229 Architecture Guide [draft-hallambaker-mesh-architecture] . The Mesh 230 documentation set and related specifications are described in this 231 document. 233 2.4. Implementation Status 235 The implementation status of the reference code base is described in 236 the companion document [draft-hallambaker-mesh-developer] . 238 3. Mesh Profiles 240 Every Mesh user has a Mesh profile which contains all the 241 configuration information for all their devices and all their network 242 services. For convenience, the mesh profile is divided into four 243 separate parts, the Master profile, the Personal Profile, Device 244 Profiles and Application Profiles as follows: 246 3.1. Mesh Master Profile 248 The Mesh Master Profile describes the criteria for validating an 249 owner's personal profile. In particular, the master profile 250 specifies the Master Signature Key that is used as the root of trust 251 under which the master profile is validated and a set of 252 Administration Signature Keys under which the personal profile is 253 validated. 255 Master Signature Key is immutable. By definition, it is not possible 256 to change the Master Signature Key without creating a new master 257 profile. 259 The UDF fingerprint of the Master Signature Key is the fingerprint of 260 the Master Profile and the Personal Profile created underneath it. 262 For example, Alice creates the following Master Profile, it has a 263 Master Signature Key and a Master Recovery Key. There is one 264 administration device specified, the correcponding device profile is 265 described in the next section. 267 {AliceMasterProfile} 269 Figure 1 271 The UDF fingerprint of Alice's Master signature key is: 273 {AliceFingerprint} 275 Figure 2 277 A Master Profile MAY be revoked but never expires. It is the 278 intended that a user should not normally need to change their master 279 profile. 281 The only means of expiring a master profile that is currently 282 supported is to sign a 'suicide note' for the profile. This is an 283 assertion that the master profile is invalid that has been signed by 284 the user. An application MAY generate such a suicide note at the 285 time that the master profile is created and archive it so that the 286 profile owner's executors can revoke the profile after death. 288 {AliceMasterProfileSuicide} 290 Figure 3 292 Since a Master Signature Key is immutable, no provision is made for 293 modifying a Master Signature Key, nor is such provision possible. 294 Should a user lose control of the private keys listed in their master 295 profile, the only remediation possible is to create a new Master 296 Signature Key and master profile and then persuade parties relying on 297 the original that it is the successor. 299 3.2. Mesh Device Profile 301 To make use of the Mesh Profile, Alice needs to connect at least one 302 device. Every device profile has an encryption, signature and 303 authentication key. 305 Alice decides to use her desktop personal computer as her first 306 administration device. Her device profile is: 308 {AliceDeviceProfile} 310 Figure 4 312 Note that each of the keys is a Diffie-Hellman Key. This enables the 313 use of distributed key generation techniques as described in part 314 III. These will be transitioned to Elliptic Curve Diffie Hellman 315 keys for production use. 317 3.3. Mesh Personal Profile 319 Alice's personal profile contains her master profile and a list of 320 device profiles. It is signed by her administration device using its 321 signature key. 323 Alice's personal profile specifies her master profile and the device 324 profile of her personal computer: 326 {AlicePersonalProfile} 328 Figure 5 330 A personal profile instance MUST specify the device profile of the 331 administration profile that signed that instance. 333 3.4. Mesh Application Profile 335 Alice also creates one or more application profiles, each of which 336 are signed by her administration key. 338 Alice creates a credential catalog to allow her to create strong 339 passwords with a work factor of 2^128 and use them on multiple 340 devices, in this case, her administration device and her 342 {AliceApplicationProfile} 344 Figure 6 346 4. Mesh Portal Service 348 The Mesh Portal Service is the subset of Mesh Service operations that 349 manage Mesh profiles. A Mesh Service MUST support the Mesh Portal 350 Service but is not required to support any other service. 352 4.1. Creating a Mesh Service Account 354 Having created a personal profile, Alice requests creation of an 355 account at a Mesh Service. The first step in this process is 356 choosing a Mesh Service account address 'Mesh address' 358 A Mesh address has the format user@domain where domain is the DNS 359 name of the Mesh service and user is the name of their account at 360 that service. 362 Services MAY support the use of any unicode character sequence 363 permitted for use as an SMTP email address by RFC6530. Matching of 364 Mesh addresses is case insensitive for latin characters (a-z, A-Z) 365 but no similar mappings are supported for other character sets. 367 Alice selects the Mesh Service 'example.com' and the name 'alice'. 368 Her Mesh client first checks to see if the name is available: 370 Request {Verify alice@example.com} 372 Figure 7 374 The Mesh service responds stating that the address is available. 376 The ValidateRequest message contains the requested account identifier 377 and an optional language parameter to allow the service to provide 378 informative error messages in a language the user understands. The 379 Language field contains a list of ISO language identifier codes in 380 order of preference, most preferred first. 382 Response {Verify alice@example.com} 384 Figure 8 386 The ValidateResponse message returns the result of the validation 387 request in the Valid field. Note that even if the value true is 388 returned, a subsequent account creation request MAY still fail. 390 [Note that for the sake of concise presentation, the HTTP binding 391 information is omitted from future examples.] 393 The Mesh client requests that the account be created and bound to the 394 (provided) personal profile: 396 Request {Account Create alice@example.com} 398 Figure 9 400 The Mesh service responds stating that the address is available: 402 Response {Account Create alice@example.com} 404 Figure 10 406 4.2. Using Recovery Records 408 Before using her newly created profile, Alice makes sure that she can 409 recover it in the case of a catastrophe. She also wants to make sure 410 that her master profile won't be compromised if the machine she 411 created it on is compromised by deleting the key information from the 412 machine. To do this, she creates a Recovery Record. 414 A recovery record contains the private keys associated with her 415 master profile encrypted using a strong symmetric cipher (AES 256 in 416 this case). Recovery records are indexed by means of the UDF 417 fingerprint derrived from the decryption key. Thus, knowledge of the 418 decryption key is sufficient to locate the recovery record in a 419 collection of recovery records and knowledge of the index is evidence 420 that a requestor knows the decryption key. 422 4.2.1. Creating a Recovery Record 424 The plaintext of the recovery record specifies the private keys 425 associated with the Master Signature Key and Master Escrow Key: 427 {Recovery RecordPlaintext} 429 Figure 11 431 A Master Recovery Key is created. In this case, Alice is using a 432 Master Recovery Key of 128 bits so that the recovery key shares are 433 as compact as possible. 435 {MasterRecoveryKey} 437 Figure 12 439 The HKDF function is used to derrive the Encryption Key for the 440 Recovery Record and the Recovery index: 442 {RecoveryEncryptionKey} 443 {RecoveryIndex} 445 Figure 13 447 The Recovery record is encrypted using the DARE Message Format 449 {Recovery RecordDARE} 451 Figure 14 453 The Mesh client then creates an authenticated request to post the 454 recovery record to the profile: 456 {AuthenticatedRecoveryRequest} 458 Figure 15 460 The Mesh Service returns its response: 462 {AuthenticatedRecoveryResponse} 464 Figure 16 466 [Note that for the sake of concise presentation, the request and 467 response authentication information is omitted from future examples.] 469 Having successfully posted the recovery data to the service, the 470 client presents Alice with a list of recovery shares that can be used 471 to recover the data. The calculation of the recovery shares is 472 described in part III. 474 {Recovery shares 2 of 3} 476 Figure 17 478 4.2.2. Recovering a Profile. 480 To test her ability to recover her master profile, Alice deletes her 481 master profile from her administration device=. To recover her 482 profile, Alice reconstructs the recovery secret from two of her 483 shares and uses this information to request recovery: 485 {RecoveryRecordRequest} 487 Figure 18 489 Note that this request is not authenticated. 491 The Mesh Service locates the requested data and responds: 493 {RecoveryRecordResponse} 495 Figure 19 497 The client recovers the Master profile information and verifies it, 498 then uses the data to reactivate the 500 4.3. Connecting a Device to a Portal Account 502 Connecting a device to a profile requires the client on the new 503 device to interact with a client on a device that has administration 504 capabilities, i.e. it has access to an Online Signing Key. Since 505 clients cannot interact directly with other clients, a service is 506 required to mediate the connection. This service is provided by a 507 Mesh portal provider. 509 All service transactions are initiated by the clients. First the 510 connecting device posts ConnectStart, after which it may poll for the 511 outcome of the connection request using ConnectStatus. 513 Periodically, the Administration Device polls for a list of pending 514 connection requests using ConnectPending. After posting a request, 515 the administration device posts the result using ConnectComplete: 517 Connecting Mesh Administration 518 Device Service Device 520 | | | 521 | ConnectStart | | 522 | ----------------------> | | 523 | | ConnectPending | 524 | | <---------------------- | 525 | | | 526 | | ConnectComplete | 527 | | <---------------------- | 528 | ConnectStatus | | 529 | ----------------------> | | 531 Figure 20 533 The Device connection flow is actually an example of the Messaging 534 flow in that it is initiated by an untrusted device making a 535 connection request to the Mesh Service which the user's 536 administration device collects and responds to in the same fashion as 537 any other messaging flow. 539 The process is initiated by a request from the device to post a 540 connection request. 542 Request {ConnectStart alice@example.com} 544 Figure 21 546 The request is accepted. Note that if abuse is a concern, we may 547 have required the use of a one time passcode to validate the request. 548 The service responds with the personal profile bound to the account. 550 Response {ConnectStart alice@example.com} 552 Figure 22 554 The fingerprint of the device profile and the fingerprint of the 555 personal profile are combined to create a request verification code. 556 This is displayed on Alice's device 558 {Verification code.} 560 Figure 23 562 To authorize the request, the administration device begins by 563 synchronizing the connect message spool: 565 Request {SyncPending Connect alice@example.com} 567 Figure 24 569 The service responds with a list of pending requests optionally 570 filtered according to criteria provided by Alice: 572 Response {SyncPending Connect alice@example.com} 574 Figure 25 576 Alice Accepts the request. Her administration device creates and 577 signs a Device Authorization and posts it to the Mesh Service where 578 it is added to the Device Catalog: 580 Request {ConnectPost alice@example.com} 582 Figure 26 584 The request is successful: 586 Response {ConnectPost alice@example.com} 588 Figure 27 590 Finally, the device polls the service and recieves notice that the 591 request has been accepted: 593 Request {ConnectStatus alice@example.com} 595 Figure 28 597 The acceptance includes a copy of the Device Authorization(s). 599 Response {ConnectStatus alice@example.com} 601 Figure 29 603 4.3.1. Deleting a Portal Account 605 Should she ever decide to stop using the Mesh Service, Alice can 606 request that her account be deleted. Note that this only affects her 607 account on the service and not on her local machine. 609 {DeleteRequest} 611 Figure 30 613 The Mesh Service returns its response: 615 {DeleteResponse} 617 Figure 31 619 Once a Mesh address has been deleted, reuse of the address by a new 620 profile is entirely a matter for site policy. A Mesh Service MAY 621 refuse to allow any request to create an account with a previously 622 used address under any circumstances or MAY allow any party to reuse 623 the address. 625 Mesh addresses are inherently transient. If a permanent and 626 immutable address is required for some purpose, the Strong Internet 627 Name of the Mesh Address SHOULD be used instead. This name binds the 628 Mesh profile fingerprint to the Mesh Address, thus creating a name 629 that can be regarded as unambiguously identifying the profile owner 630 and means of contact. 632 5. Mesh Catalogs 634 A Mesh Catalog Service contains a set of entries that are created by 635 the user for their own use. 637 A catalog entry MUST be signed by the signature key of a device that 638 is specified in the user's Personal Profile. 640 Each entry in a Mesh catalog has a unique identifier that acts as its 641 primary key. 643 Mesh catalogs are typically compact and updated infrequently. Given 644 current storage costs and typical network bandwidth, it is to be 645 expected that most users will be best served by a model in which 646 every device contains a complete copy of the user's catalog(s) that 647 are of interest to it rather than support a model in which connected 648 devices hunt an peck for the desired records on the server. Such an 649 approach is in any case likely to be impossible for the majority of 650 Mesh applications in which the server content is end-to-end 651 encrypted. 653 5.1. Synchronizing a Device to a Catalog 655 Synchronization of the catalog data stored on a device with that 656 stored by the Mesh service is bidirectional. Catalog updates stored 657 on the device are merged with those stored on the service and any 658 conflicts reported to the user. 660 Each device that has the access privilege to update catalog entries 661 thus has two separate queues, one containing a (possibly incomplete) 662 copy of the append-only log held by the service, the other containing 663 updates that have been made on the device but have not yet been 664 accepted by the service. 666 When a device synchronizes, it: 668 o Downloads relevant updates from the service to the device. 670 Devices MAY perform these operations in either order or 671 simultaneously (if the service permits). But regardless of the order 672 in which these are performed by a particular device, there is only 673 one catalog and it is maintaind by the service. Thus all updates 674 that are accepted SHALL be applied to the catalog after all the 675 previous updates. 677 Since every object has a distinct and independent lifecycle in the 678 Mesh persistence model, detecting a conflict early on in the 679 synchronization process does not invalidate updates to other objects 680 which are independent. 682 For example, consider the scenario in which Alice synchronizes two 683 devices to her credential catalog. 685 Alice is already using the password management features of her 686 browser but this service does not provide end-to-end encryption. 687 Alice's Mesh client provides a feature that allows her to export the 688 usernames and passwords from her browser and store them in a Mesh 689 catalog. 691 Alice's first device creates two credential entries. 693 {AliceCredential1} 695 Figure 32 697 When multiple catalog entries are being encrypted at the same time, 698 these MAY be encrypted under a single key agreement or under a 699 separate key agreement for each entry. Here, a single key agreement 700 is shared: 702 {AliceCredential1Request} 704 Figure 33 706 Since the catalog is empty, the service accepts the update entries 707 and responds with the catalog index before and after the items were 708 accepted. 710 {AliceCredential1Response} 712 Figure 34 714 Alice then attempts to syncrhonize a second device. The browser on 715 the second device has two entries, one of which maches an entry in 716 the first and the other of which is different: 718 {AliceCredential2} 720 Figure 35 722 When the service responds to the second request, the first entry is 723 rejected as a possible conflict and the second is accepted. Note 724 that even though the username/password values are identical, the 725 service does not know this because they are end-to-end encrypted and 726 the service does not have a decryption key. The service responds 727 with a list of the frame numbers of the rejected entries. 729 {AliceCredential1Response} 731 Figure 36 733 Entries are deleted from a catalog with the delete method. The 734 request specifies the catalog to be updated and the list of entries 735 to be deleted: 737 {AliceDeleteCredential} 739 Figure 37 741 6. Mesh Catalog Services 743 6.1. The Contacts Catalog 745 {includes recryption membership notifications} 747 6.2. Credential Catalog 749 6.3. Tasks Catalog 750 6.4. Mail Catalog 752 6.5. SSH Catalog 754 6.6. Recryption Catalog 756 The recryption catalog is unique in that it is the only Mesh Service 757 that contains entries that are to be decrypted by the Mesh Service 758 itself 760 Recryption Group Administrator entries Contain the information that 761 an administrator requires to administer a recryption group. These 762 are encrypted such that only the administrators can decrypt them. 764 Recryption Group Member entries Contain the information that the 765 Recryption Service requires to respond to recryption requests 766 encrypted under the server key. 768 7. Mesh Messaging 770 Mesh messaging services are very similar to Mesh catalog services but 771 with one important difference: Requests to append or update message 772 entries come from a third party that may prove untrustworthy. It is 773 therefore necessary to apply access control to inbound message 774 requests. 776 The persistence store for a messaging service is called a spool. As 777 with the catalog store of a catalog service, the DARE Container 778 format is designed to support the requirements of managing a 779 messaging service spool but Mesh Services MAY use any persistence 780 technology that meets their needs. 782 Some Mesh messaging services are standalone while others are closely 783 related to a catalog service. 785 o Accepting a recryption membership notification SHOULD result in an 786 entry being added to the recipient's credential catalog. 788 o Accepting a device connection request MUST result in an entry 789 being added to the user's devices catalog. 791 The PostUpdate method allows a Mesh client to reply to an inbound 792 request and post an entry to the accompanying catalog at the same 793 time. 795 Mesh messaging services adopt a four corner communication mode in 796 which the sender of a message forwards the request to their own Mesh 797 Service which in turn contacts the recipient's Mesh service to 798 organize delivery. As with any other four Mesh Service MAY act for 799 both the sender and receiver 801 The only circumstance in which the sender and recipient communicate 802 directly is in a two phase synchronous protocol in which a four 803 corner first phase is used to negotiate parameters for a direct 804 connection in the second phase. 806 7.1. Message Origination 808 Messages are posted to the senders outbound Mesh Service using the 809 Post method. 811 Alice meets Bob and they 'bump' phones performing a QR code exchange. 812 To begin this exchange, Alice's device generates a random one-time 813 use passcode. Note that since this passcode is only used to 814 authenticate the exchange to mitigate abuse, a work factor of 2^64 is 815 more than sufficient. 817 lYFAVLNJLkC 819 Figure 38 821 The QR code is: 823 [QR code image] 825 The decoded URI is: 827 mmm:alice@example.com.mmm-wekjhwkjehrkjwher:c:lYFAVLNJLkC 829 Figure 39 831 Bob's phone reads the QR code and creates a contact request message 832 containing Bob's information. The contact request asks to be able to 833 send various types of message. 835 {BobContactPostRequest} 837 Figure 40 839 Messages are subject to access control by both the inbound and 840 outbound services. 842 Bob's Mesh Service checks to see if the rate of contact requests he 843 has made in the past is excessive. Finding that it is not, the 844 contact request is accepted and placed in the outbound messages 845 queue. 847 Bob's service responds with a unique identifier that MAY be used to 848 check on the status of the message: 850 {BobContactPostRequest} 852 Figure 41 854 A short while later, Bob's phone asks for a status update on the 855 request. 857 {BobContactStatusRequest} 859 Figure 42 861 Alice has not responded yet (she is talking to Bob in person). 863 {BobContactStatusRequest} 865 Figure 43 867 If Bob decides not to connect after all, he can cancel the request. 869 7.2. Message Transit 871 Passing of messages between Mesh Services is called transit. 873 To begin a message transfer, the outbound service makes a PostRequest 874 to the inbound service which contains the message headers and the 875 maximum size of the payload. 877 {OutboundPostRequest} 879 Figure 44 881 The inbound service performs access control on the PostRequest 882 according to site policy which MAY include use any resources the 883 inbound service chooses to use, including: 885 o Valid one time use authorization code issued by the recipient to 886 the sender 888 o Credentials provided by the inbound service. 890 o The sender's entry in the recipient's contact catalog. 892 o The type of access requested. 894 The access control policy is set by the Mesh Service and the user. 895 When setting an access control policy, both should consider the 896 likelihood that the recipient would wish to accept the message and 897 the risk of harm resulting. 899 Different users will naturally require different access policies. A 900 celebrity receiving hundreds of contacts a day is likely to require 901 closer access control criteria than a person receiving one request a 902 week. A request to send email messages presents a lower degree of 903 risk than a request to send invoices or program code. 905 In this case, the request has been pre-approved by means of a one 906 time use authentication code provided by Alice's device. The inbound 907 service has no means of verifying the authentication code at this 908 stage but accepts the request knowing that it will be rejected by 909 Alice's client if it proves to be bogus. 911 {OutboundPostResponse} 913 Figure 45 915 Since the contact request message is short, the inbound service 916 authorizes the outbound service to send the message body immediately. 917 If the message was longer, the inbound service might tell the 918 outbound to defer delivery of the message body which might be 919 completed by means of an incremental transfer (e.g. in chunks of 4MB 920 at a time). 922 This mechanism allows the same messaging protocol to be used to 923 transfer messages of a few bytes to multiple terabytes. A Mesh 924 Service is not required to support such messages however and 925 particularly in the case of very large messages, may delgate 926 collection of the message payload to the destination device. 928 7.3. Receiving Messages 930 Pending messages are received by synchronizing the message spool of 931 the device with the message spool of the messaging service. This 932 process is identical to synchonizing a catalog. 934 {SyncRequest} 936 Figure 46 938 There is only one message in the contact request spool to be 939 synchronized: 941 {SyncResponse} 943 Figure 47 945 A device MAY improve the user experience by requesting the service 946 provide just the headers of the queued messages or to filter messages 947 of a particular type or which have particular characteristics. 949 7.3.1. Responding to Messages 951 As previously noted, the response to a message request frequently 952 entails an update to the user's corresponding catalog. Otherwise, 953 posting a response is the same as a request. 955 Alice's phone verifies the authentication code on Bob's request and 956 automatically approves it for the level of access Alice specified 957 when they bumped phones. A new contact entry is created together 958 with a contact request message to be returned to Bob notifying him 959 that his request was approved by Alice and providing him with her 960 details for his contact catalog. 962 {ContactAddResponse} 964 Figure 48 966 8. Messaging Services 968 8.1. Contact Messaging Service 970 8.2. Confirmation Messaging Service 972 8.3. Asynchronous Messaging Service 974 8.4. Synchronous Messaging Service 976 9. Shared Classes 978 The following classes are used as common elements in Mesh profile 979 specifications.a 981 9.1. Cryptographic Data Classes 983 Most Mesh objects are signed and/or encrypted. For consistency all 984 Mesh classes make use of the cryptographic data classes described in 985 this section. 987 9.1.1. Structure: PublicKey 989 The PublicKey class is used to describe public key pairs and trust 990 assertions associated with a public key. 992 UDF: String (Optional) UDF fingerprint of the public key parameters/ 994 X509Certificate: Binary (Optional) List of X.509 Certificates 996 X509Chain: Binary [0..Many] X.509 Certificate chain. 998 X509CSR: Binary (Optional) X.509 Certificate Signing Request. 1000 9.1.2. Structure: SignedData 1002 Container for JOSE signed data and related attributes. 1004 Data: Binary (Optional) The signed data 1006 9.1.3. Structure: EncryptedData 1008 Container for JOSE encrypted data and related attributes. 1010 Data: Binary (Optional) The encrypted data 1012 9.2. Common Application Classes 1014 9.2.1. Structure: Connection 1016 Describes network connection parameters for an application 1018 ServiceName: String (Optional) DNS address of the server 1020 Port: Integer (Optional) TCP/UDP Port number 1022 Prefix: String (Optional) DNS service prefix as described in 1023 [!RFC6335] 1025 Security: String [0..Many] Describes the security mode to use. 1026 Valid choices are Direct/Upgrade/None 1028 UserName: String (Optional) Username to present to the service for 1029 authentication 1031 Password: String (Optional) Password to present to the service for 1032 authentication 1034 URI: String (Optional) Service connection parameters in URI format 1035 Authentication: String (Optional) List of the supported/acceptable 1036 authentication mechanisms, preferred mechanism first. 1038 TimeOut: Integer (Optional) Service timeout in seconds. 1040 Polling: Boolean (Optional) If set, the client should poll the 1041 specified service intermittently for updates. 1043 10. Mesh Profile Objects 1045 10.1. Base Profile Objects 1047 10.1.1. Structure: Entry 1049 Base class for all Mesh Profile objects. 1051 Identifier: String (Optional) Globally unique identifier that 1052 remains constant for the lifetime of the entry. 1054 10.1.2. Structure: SignedProfile 1056 Inherits: Entry 1058 Contains a signed profile entry 1060 SignedData: JoseWebSignature (Optional) The signed profile. 1062 Note that each child of SignedProfile requires that the Payload 1063 field of the SignedData object contain an object of a specific 1064 type. For example, a SignedDeviceProfile object MUST contain a 1065 Payload field that contains a DeviceProfile object. 1067 Unauthenticated: Advice (Optional) Additional data that is not 1068 authenticated. 1070 10.1.3. Structure: Advice 1072 Additional data bound to a signed profile that is not authenticated. 1074 Default: DateTime (Optional) If specified, the profile was the 1075 default profile at the specified date and time. The current 1076 default for that type of profile is the profile with the most 1077 recent Default timestamp. 1079 10.1.4. Structure: PortalAdvice 1081 Describes the portal(s) at which the profile is registered. 1083 Inherits: Advice 1085 Inherits: Advice 1087 PortalAddress: String [0..Many] A portal address at which this 1088 profile is registered. 1090 10.1.5. Structure: Profile 1092 Inherits: Entry 1094 Parent class from which all profile types are derived 1096 Names: String [0..Many] Fingerprints of index terms for profile 1097 retrieval. The use of the fingerprint of the name rather than the 1098 name itself is a precaution against enumeration attacks and other 1099 forms of abuse. 1101 Updated: DateTime (Optional) The time instant the profile was last 1102 modified. 1104 NotaryToken: String (Optional) A Uniform Notary Token providing 1105 evidence that a signature was performed after the notary token was 1106 created. 1108 10.2. Device Profile Classes 1110 10.2.1. Structure: SignedDeviceProfile 1112 Inherits: SignedProfile 1114 Contains a signed device profile 1116 [No fields] 1118 10.2.2. Structure: DeviceProfile 1120 Inherits: Profile 1122 Describes a mesh device. 1124 Description: String (Optional) Description of the device 1125 DeviceSignatureKey: PublicKey (Optional) Key used to sign 1126 certificates for the DAK and DEK. The fingerprint of the DSK is 1127 the UniqueID of the Device Profile 1129 DeviceAuthenticationKey: PublicKey (Optional) Key used to 1130 authenticate requests made by the device. 1132 DeviceEncryptiontionKey: PublicKey (Optional) Key used to pass 1133 encrypted data to the device such as a DeviceUseEntry 1135 10.2.3. Structure: DevicePrivateProfile 1137 Private portion of device encryption profile. 1139 DeviceSignatureKey: Key (Optional) Private portion of the 1140 DeviceSignatureKey 1142 DeviceAuthenticationKey: Key (Optional) Private portion of the 1143 DeviceAuthenticationKey 1145 DeviceEncryptiontionKey: Key (Optional) Private portion of the 1146 DeviceEncryptiontionKey 1148 10.3. Master Profile Objects 1150 10.3.1. Structure: SignedMasterProfile 1152 Inherits: SignedProfile 1154 Contains a signed Personal master profile 1156 [No fields] 1158 10.3.2. Structure: MasterProfile 1160 Inherits: Profile 1162 Describes the long term parameters associated with a personal 1163 profile. 1165 MasterSignatureKey: PublicKey (Optional) The root of trust for the 1166 Personal PKI, the public key of the PMSK is presented as a self- 1167 signed X.509v3 certificate with Certificate Signing use enabled. 1168 The PMSK is used to sign certificates for the PMEK, POSK and PKEK 1169 keys. 1171 MasterEscrowKeys: PublicKey [0..Many] A Personal Profile MAY contain 1172 one or more PMEK keys to enable escrow of private keys used for 1173 stored data. 1175 OnlineSignatureKeys: PublicKey [0..Many] A Personal profile contains 1176 at least one POSK which is used to sign device administration 1177 application profiles. 1179 10.4. Personal Profile Objects 1181 10.4.1. Structure: SignedPersonalProfile 1183 Inherits: SignedProfile 1185 Contains a signed Personal current profile 1187 [No fields] 1189 10.4.2. Structure: PersonalProfile 1191 Inherits: Profile 1193 Describes the current applications and devices connected to a 1194 personal master profile. 1196 SignedMasterProfile: SignedMasterProfile (Optional) The 1197 corresponding master profile. The profile MUST be signed by the 1198 PMSK. 1200 Devices: SignedDeviceProfile [0..Many] The set of device profiles 1201 connected to the profile. The profile MUST be signed by the DSK 1202 in the profile. 1204 Applications: ApplicationProfileEntry [0..Many] Application profiles 1205 connected to this profile. 1207 10.4.3. Structure: ApplicationProfileEntry 1209 Personal profile entry describing the privileges of specific devices. 1211 Identifier: String (Optional) The unique identifier of the 1212 application 1214 Type: String (Optional) The application type 1216 Friendly: String (Optional) Optional friendly name identifying the 1217 application. 1219 AdminDeviceUDF: String [0..Many] List of devices authorized to sign 1220 application profiles 1222 DecryptDeviceUDF: String [0..Many] List of devices authorized to 1223 read private parts of application profiles. 1225 AccountID: String (Optional) The account at which the profile is 1226 located. 1228 10.5. Application Profile Objects 1230 10.5.1. Structure: SignedApplicationProfile 1232 Inherits: SignedProfile 1234 Contains a signed device profile 1236 [No fields] 1238 10.5.2. Structure: ApplicationProfile 1240 Inherits: Profile 1242 Parent class from which all application profiles inherit. 1244 [No fields] 1246 10.5.3. Structure: ApplicationProfilePrivate 1248 Inherits: Entry 1250 The base class for all private profiles. 1252 [No fields] 1254 10.5.4. Structure: ApplicationDevicePublic 1256 Inherits: Entry 1258 Describes the public per device data 1260 DeviceDescription: String (Optional) Description of the device for 1261 convenience of the user. 1263 DeviceUDF: String (Optional) Fingerprint of device that this key 1264 corresponds to. 1266 10.5.5. Structure: ApplicationDevicePrivate 1268 Inherits: Entry 1270 Describes the private per device data 1272 [No fields] 1274 10.6. Key Escrow Objects 1276 10.6.1. Structure: EscrowEntry 1278 Inherits: Entry 1280 Contains escrowed data 1282 EncryptedData: JoseWebEncryption (Optional) The encrypted escrow 1283 data 1285 10.6.2. Structure: OfflineEscrowEntry 1287 Inherits: EscrowEntry 1289 Contains data escrowed using the offline escrow mechanism. 1291 [No fields] 1293 10.6.3. Structure: OnlineEscrowEntry 1295 Inherits: EscrowEntry 1297 Contains data escrowed using the online escrow mechanism. 1299 [No fields] 1301 10.6.4. Structure: EscrowedKeySet 1303 A set of escrowed keys. 1305 [No fields] 1307 11. Portal Connection 1309 11.1. Connection Request and Response Structures 1310 11.1.1. Structure: ConnectionRequest 1312 Describes a connection request. 1314 ParentUDF: String (Optional) UDF of Mesh Profile to which connection 1315 is requested. 1317 Device: SignedDeviceProfile (Optional) The Device profile to be 1318 connected 1320 11.1.2. Structure: SignedConnectionRequest 1322 Inherits: SignedProfile 1324 Contains a ConnectionRequest signed by the corresponding device 1325 signature key. 1327 [No fields] 1329 11.1.3. Structure: ConnectionResult 1331 Describes the result of a connection request. 1333 Inherits: ConnectionRequest 1335 Inherits: ConnectionRequest 1337 Result: String (Optional) The result of the connection request. 1338 Valid responses are: Accepted, Refused, Query. 1340 11.1.4. Structure: SignedConnectionResult 1342 Inherits: SignedProfile 1344 Contains a signed connection result 1346 [No fields] 1348 12. Mesh Portal Service Reference 1350 HTTP Well Known Service Prefix: /.well-known/mmm 1352 Every Mesh Portal Service transaction consists of exactly one request 1353 followed by exactly one response. Mesh Service transactions MAY 1354 cause modification of the data stored in the Mesh Portal or the Mesh 1355 itself but do not cause changes to the connection state. The 1356 protocol itself is thus idempotent. There is no set sequence in 1357 which operations are required to be performed. It is not necessary 1358 to perform a Hello transaction prior to a ValidateAccount, Publish or 1359 any other transaction. 1361 12.1. Request Messages 1363 A Mesh Portal Service request consists of a payload object that 1364 inherits from the MeshRequest class. When using the HTTP binding, 1365 the request MUST specify the portal DNS address in the HTTP Host 1366 field. 1368 12.1.1. Message: MeshRequest 1370 Base class for all request messages. 1372 Portal: String (Optional) Name of the Mesh Portal Service to which 1373 the request is directed. 1375 12.2. Response Messages 1377 A Mesh Portal Service response consists of a payload object that 1378 inherits from the MeshResponse class. When using the HTTP binding, 1379 the response SHOULD report the Status response code in the HTTP 1380 response message. However the response code returned in the payload 1381 object MUST always be considered authoritative. 1383 12.2.1. Message: MeshResponse 1385 Base class for all response messages. Contains only the status code 1386 and status description fields. 1388 [No fields] 1390 12.3. Imported Objects 1392 The Mesh Service protocol makes use of JSON objects defined in the 1393 JOSE Signatgure and Encryption specifications. 1395 12.4. Common Structures 1397 The following common structures are used in the protocol messages: 1399 12.4.1. Structure: KeyValue 1401 Describes a Key/Value structure used to make queries for records 1402 matching one or more selection criteria. 1404 Key: String (Optional) The data retrieval key. 1406 Value: String (Optional) The data value to match. 1408 12.4.2. Structure: SearchConstraints 1410 Specifies constraints to be applied to a search result. These allow 1411 a client to limit the number of records returned, the quantity of 1412 data returned, the earliest and latest data returned, etc. 1414 NotBefore: DateTime (Optional) Only data published on or after the 1415 specified time instant is requested. 1417 Before: DateTime (Optional) Only data published before the specified 1418 time instant is requested. This excludes data published at the 1419 specified time instant. 1421 MaxEntries: Integer (Optional) Maximum number of data entries to 1422 return. 1424 MaxBytes: Integer (Optional) Maximum number of data bytes to return. 1426 PageKey: String (Optional) Specifies a page key returned in a 1427 previous search operation in which the number of responses 1428 exceeded the specified bounds. 1430 When a page key is specified, all the other search parameters 1431 except for MaxEntries and MaxBytes are ignored and the service 1432 returns the next set of data responding to the earlier query. 1434 12.5. Transaction: Hello 1436 Request: HelloRequest 1438 Request: HelloRequest 1440 Response: HelloResponse 1442 Report service and version information. 1444 The Hello transaction provides a means of determining which protocol 1445 versions, message encodings and transport protocols are supported by 1446 the service. 1448 12.6. Transaction: ValidateAccount 1450 Request: ValidateRequest 1452 Request: ValidateRequest 1453 Response: ValidateResponse 1455 Request validation of a proposed name for a new account. 1457 For validation of a user's account name during profile creation. 1459 12.6.1. Message: ValidateRequest 1461 Inherits: MeshRequest 1463 Describes the proposed account properties. Currently, these are 1464 limited to the account name but could be extended in future versions 1465 of the protocol. 1467 Account: String (Optional) Account name requested 1469 Reserve: Boolean (Optional) If true, request a reservation for the 1470 specified account name. Note that the service is not obliged to 1471 honor reservation requests. 1473 Language: String [0..Many] List of ISO language codes in order of 1474 preference. For creating explanatory text. 1476 12.6.2. Message: ValidateResponse 1478 Inherits: MeshResponse 1480 States whether the proposed account properties are acceptable and 1481 (optional) returns an indication of what properties are valid. 1483 Note that receiving a 'Valid' responseto a Validate Request does not 1484 guarantee creation of the account. In addition to the possibility 1485 that the account namecould be requested by another user between the 1486 Validate and Create transactions, a portal service MAY perform more 1487 stringent validation criteria when an account is actually being 1488 created. For example, checking with the authoritative list of 1489 current accounts rather than a cached copy. 1491 Valid: Boolean (Optional) If true, the specified account identifier 1492 is acceptable. If false, the account identifier is rejected. 1494 Minimum: Integer (Optional) Specifies the minimum length of an 1495 account name. 1497 Maximum: Integer (Optional) Specifies the maximum length of an 1498 account name. 1500 InvalidCharacters: String (Optional) A list of characters that the 1501 service does not accept in account names. The list of characters 1502 MAY not be exhaustive but SHOULD include any illegal characters in 1503 the proposed account name. 1505 Reason: String (Optional) Text explaining the reason an account name 1506 was rejected. 1508 12.7. Transaction: CreateAccount 1510 Request: CreateRequest 1512 Request: CreateRequest 1514 Response: CreateResponse 1516 Request creation of a new portal account. 1518 Unlike a profile, a mesh account is specific to a particular Mesh 1519 portal. A mesh account must be created and accepted before a profile 1520 can be published. 1522 12.7.1. Message: CreateRequest 1524 Request creation of a new portal account. The request specifies the 1525 requested account identifier and the Mesh profile to be associated 1526 with the account. 1528 Inherits: MeshRequest 1530 Inherits: MeshRequest 1532 Account: String (Optional) Account identifier requested. 1534 12.7.2. Message: CreateResponse 1536 Inherits: MeshResponse 1538 Reports the success or failure of a Create transaction. 1540 [No fields] 1542 12.8. Transaction: DeleteAccount 1544 Request: DeleteRequest 1546 Request: DeleteRequest 1547 Response: DeleteResponse 1549 Request deletion of a portal account. 1551 Deletes a portal account but not the underlying profile. Once 1552 registered, profiles are permanent. 1554 12.8.1. Message: DeleteRequest 1556 Request deletion of a new portal account. The request specifies the 1557 requested account identifier. 1559 Inherits: MeshRequest 1561 Inherits: MeshRequest 1563 Account: String (Optional) Account identifier to be deleted. 1565 12.8.2. Message: DeleteResponse 1567 Inherits: MeshResponse 1569 Reports the success or failure of a Delete transaction. 1571 [No fields] 1573 12.9. Transaction: Get 1575 Request: GetRequest 1577 Request: GetRequest 1579 Response: GetResponse 1581 Search for data in the mesh that matches a set of properties 1582 described by a sequence of key/value pairs. 1584 12.9.1. Message: GetRequest 1586 Describes the Portal or Mesh data to be retreived. 1588 Inherits: MeshRequest 1590 Inherits: MeshRequest 1592 Identifier: String (Optional) Lookup by profile ID 1594 Account: String (Optional) Lookup by Account ID 1595 KeyValues: KeyValue [0..Many] List of KeyValue pairs specifying the 1596 conditions to be met 1598 SearchConstraints: SearchConstraints (Optional) Constrain the search 1599 to a specific time interval and/or limit the number and/or total 1600 size of data records returned. 1602 Multiple: Boolean (Optional) If true return multiple responses if 1603 available 1605 Full: Boolean (Optional) If true, the client requests that the full 1606 Mesh data record be returned containing both the Mesh entry itself 1607 and the Mesh metadata that allows the date and time of the 1608 publication of the Mesh entry to be verified. 1610 12.9.2. Message: GetResponse 1612 Reports the success or failure of a Get transaction. If a Mesh entry 1613 matching the specified profile is found, containsthe list of entries 1614 matching the request. 1616 Inherits: MeshResponse 1618 Inherits: MeshResponse 1620 DataItems: DataItem [0..Many] List of mesh data records matching the 1621 request. 1623 PageKey: String (Optional) If non-null, indicates that the number 1624 and/or size of the data records returned exceeds either the 1625 SearchConstraints specified in the request or internal server 1626 limits. 1628 12.10. Transaction: Publish 1630 Request: PublishRequest 1632 Request: PublishRequest 1634 Response: PublishResponse 1636 Publish a profile or key escrow entry to the mesh. 1638 12.10.1. Message: PublishRequest 1640 Requests publication of the specified Mesh entry. 1642 Inherits: MeshRequest 1644 [No fields] 1646 12.10.2. Message: PublishResponse 1648 Reports the success or failure of a Publish transaction. 1650 Inherits: MeshResponse 1652 [No fields] 1654 12.11. Transaction: Status 1656 Request: StatusRequest 1658 Request: StatusRequest 1660 Response: StatusResponse 1662 Request the current status of the mesh as seen by the portal to which 1663 it is directed. 1665 The response to the status request contains the last signed 1666 checkpoint and proof chains for each of the peer portals that have 1667 been checkpointed. 1669 [Not currently implemented] 1671 12.11.1. Message: StatusRequest 1673 Inherits: MeshRequest 1675 Initiates a status transaction. 1677 [No fields] 1679 12.11.2. Message: StatusResponse 1681 Reports the success or failure of a Status transaction. 1683 Inherits: MeshResponse 1685 Inherits: MeshResponse 1687 LastWriteTime: DateTime (Optional) Time that the last write update 1688 was made to the Mesh 1690 LastCheckpointTime: DateTime (Optional) Time that the last Mesh 1691 checkpoint was calculated. 1693 NextCheckpointTime: DateTime (Optional) Time at which the next Mesh 1694 checkpoint should be calculated. 1696 CheckpointValue: String (Optional) Last checkpoint value. 1698 12.12. Transaction: ConnectStart 1700 Request: ConnectStartRequest 1702 Request: ConnectStartRequest 1704 Response: ConnectStartResponse 1706 Request connection of a new device to a mesh profile 1708 12.12.1. Message: ConnectStartRequest 1710 Inherits: MeshRequest 1712 Initial device connection request. 1714 SignedRequest: SignedConnectionRequest (Optional) Device connection 1715 request signed by thesignature key of the device requesting 1716 connection. 1718 AccountID: String (Optional) Account identifier of account to which 1719 the device is requesting connection. 1721 12.12.2. Message: ConnectStartResponse 1723 Reports the success or failure of a ConnectStart transaction. 1725 Inherits: MeshRequest 1727 [No fields] 1729 12.13. Transaction: ConnectStatus 1731 Request: ConnectStatusRequest 1733 Request: ConnectStatusRequest 1735 Response: ConnectStatusResponse 1737 Request status of pending connection request of a new device to a 1738 mesh profile 1740 12.13.1. Message: ConnectStatusRequest 1742 Inherits: MeshRequest 1744 Request status information for a pending request posted previously. 1746 AccountID: String (Optional) Account identifier for which pending 1747 connection information is requested. 1749 DeviceID: String (Optional) Device identifier of device requesting 1750 status information. 1752 12.13.2. Message: ConnectStatusResponse 1754 Reports the success or failure of a ConnectStatus transaction. 1756 Inherits: MeshRequest 1758 Inherits: MeshRequest 1760 Result: SignedConnectionResult (Optional) The signed 1761 ConnectionResult object. 1763 12.14. Transaction: ConnectPending 1765 Request: ConnectPendingRequest 1767 Request: ConnectPendingRequest 1769 Response: ConnectPendingResponse 1771 Request a list of pending requests for an administration profile. 1773 12.14.1. Message: ConnectPendingRequest 1775 Inherits: MeshRequest 1777 Specify the criteria for pending requests. 1779 AccountID: String (Optional) The account identifier of the account 1780 for which pending connection requests are requested. 1782 SearchConstraints: SearchConstraints (Optional) Constrain the search 1783 to a specific time interval and/or limit the number and/or total 1784 size of data records returned. 1786 12.14.2. Message: ConnectPendingResponse 1788 Reports the success or failure of a ConnectPending transaction. 1790 Inherits: MeshRequest 1792 Inherits: MeshRequest 1794 Pending: SignedConnectionRequest [0..Many] A list of pending 1795 requests satisfying the criteria set out in the request. 1797 PageKey: String (Optional) If non-null, indicates that the number 1798 and/or size of the data records returned exceeds either the 1799 SearchConstraints specified in the request or internal server 1800 limits. 1802 12.15. Transaction: ConnectComplete 1804 Request: ConnectCompleteRequest 1806 Request: ConnectCompleteRequest 1808 Response: ConnectCompleteResponse 1810 Post response to a pending connection request. 1812 12.15.1. Message: ConnectCompleteRequest 1814 Reports the success or failure of a ConnectComplete transaction. 1816 Inherits: MeshRequest 1818 Inherits: MeshRequest 1820 Result: SignedConnectionResult (Optional) The connection result to 1821 be posted to the portal. The result MUST be signed by a valid 1822 administration key for the Mesh profile. 1824 AccountID: String (Optional) The account identifier to which the 1825 connection result is posted. 1827 12.15.2. Message: ConnectCompleteResponse 1829 Inherits: MeshRequest 1831 Reports the success or failure of a ConnectComplete transaction. 1833 [No fields] 1835 12.16. Transaction: Transfer 1837 Request: TransferRequest 1839 Request: TransferRequest 1841 Response: TransferResponse 1843 Perform a bulk transfer of the log between the specified transaction 1844 identifiers. Requires appropriate authorization 1846 [Not currently implemented] 1848 12.16.1. Message: TransferRequest 1850 Request a bulk transfer of the log between the specified transaction 1851 identifiers. Requires appropriate authorization 1853 Inherits: MeshRequest 1855 Inherits: MeshRequest 1857 SearchConstraints: SearchConstraints (Optional) Constrain the search 1858 to a specific time interval and/or limit the number and/or total 1859 size of data records returned. 1861 12.16.2. Message: TransferResponse 1863 Inherits: MeshResponse 1865 Reports the success or failure of a Transfer transaction. If 1866 successful, contains the list of Mesh records to be transferred. 1868 DataItems: DataItem [0..Many] List of mesh data records matching the 1869 request. 1871 PageKey: String (Optional) If non-null, indicates that the number 1872 and/or size of the data records returned exceeds either the 1873 SearchConstraints specified in the request or internal server 1874 limits. 1876 13. Security Considerations 1878 TBS 1880 14. IANA Considerations 1882 All the IANA considerations for the Mesh documents are specified in 1883 this document 1885 15. Acknowledgements 1887 16. References 1889 16.1. Normative References 1891 [draft-hallambaker-mesh-architecture] 1892 Hallam-Baker, P., "Mathematical Mesh: Architecture", 1893 draft-hallambaker-mesh-architecture-05 (work in progress), 1894 August 2018. 1896 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1897 Requirement Levels", BCP 14, RFC 2119, 1898 DOI 10.17487/RFC2119, March 1997. 1900 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 1901 Cheshire, "Internet Assigned Numbers Authority (IANA) 1902 Procedures for the Management of the Service Name and 1903 Transport Protocol Port Number Registry", BCP 165, 1904 RFC 6335, DOI 10.17487/RFC6335, August 2011. 1906 16.2. Informative References 1908 [draft-hallambaker-mesh-developer] 1909 Hallam-Baker, P., "Mathematical Mesh: Reference 1910 Implementation", draft-hallambaker-mesh-developer-07 (work 1911 in progress), April 2018. 1913 16.3. URIs 1915 [1] http://mathmesh.com/Documents/draft-hallambaker-mesh- 1916 reference.html 1918 Author's Address 1920 Phillip Hallam-Baker 1921 Comodo Group Inc. 1923 Email: philliph@comodo.com