idnits 2.17.1 draft-hallambaker-mesh-reference-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 abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 18, 2017) is 2409 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 2149 -- Looks like a reference, but probably isn't: '0' on line 1196 == Unused Reference: 'RFC6335' is defined on line 2125, but no explicit reference was found in the text == Unused Reference: 'RFC822' is defined on line 2143, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 822 (Obsoleted by RFC 2822) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 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 September 18, 2017 5 Expires: March 22, 2018 7 Mathematical Mesh: Reference 8 draft-hallambaker-mesh-reference-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 This document is also available online at 19 http://prismproof.org/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 22, 2018. 39 Copyright Notice 41 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 59 2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 5 60 2.3. Related Specifications . . . . . . . . . . . . . . . . . 5 61 2.4. Implementation Status . . . . . . . . . . . . . . . . . . 5 62 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 63 3.1. Creating a new portal account . . . . . . . . . . . . . . 5 64 3.1.1. Checking Account Identifier for uniqueness . . . . . 5 65 3.2. Creating a new user profile . . . . . . . . . . . . . . . 6 66 3.2.1. Publishing a new user profile . . . . . . . . . . . . 13 67 3.3. Connecting a device profile to a user profile . . . . . . 15 68 3.3.1. Profile Authentication . . . . . . . . . . . . . . . 17 69 3.3.2. Connection request . . . . . . . . . . . . . . . . . 20 70 3.3.3. Administrator Polls Pending Connections . . . . . . . 21 71 3.3.4. Administrator updates and publishes the personal 72 profile. . . . . . . . . . . . . . . . . . . . . . . 23 73 3.3.5. Administrator posts completion request. . . . . . . . 24 74 3.3.6. Connecting device polls for status update. . . . . . 25 75 3.4. Adding an application profile to a user profile . . . . . 26 76 3.5. Creating a recovery profile . . . . . . . . . . . . . . . 27 77 3.6. Recovering a profile . . . . . . . . . . . . . . . . . . 28 78 4. Shared Classes . . . . . . . . . . . . . . . . . . . . . . . 28 79 4.1. Cryptographic Data Classes . . . . . . . . . . . . . . . 28 80 4.1.1. Structure: PublicKey . . . . . . . . . . . . . . . . 28 81 4.1.2. Structure: SignedData . . . . . . . . . . . . . . . . 29 82 4.1.3. Structure: EncryptedData . . . . . . . . . . . . . . 29 83 4.2. Common Application Classes . . . . . . . . . . . . . . . 29 84 4.2.1. Structure: Connection . . . . . . . . . . . . . . . . 29 85 5. Mesh Profile Objects . . . . . . . . . . . . . . . . . . . . 30 86 5.1. Base Profile Objects . . . . . . . . . . . . . . . . . . 30 87 5.1.1. Structure: Entry . . . . . . . . . . . . . . . . . . 30 88 5.1.2. Structure: SignedProfile . . . . . . . . . . . . . . 30 89 5.1.3. Structure: Advice . . . . . . . . . . . . . . . . . . 30 90 5.1.4. Structure: PortalAdvice . . . . . . . . . . . . . . . 30 91 5.1.5. Structure: Profile . . . . . . . . . . . . . . . . . 31 92 5.2. Device Profile Classes . . . . . . . . . . . . . . . . . 31 93 5.2.1. Structure: SignedDeviceProfile . . . . . . . . . . . 31 94 5.2.2. Structure: DeviceProfile . . . . . . . . . . . . . . 31 95 5.2.3. Structure: DevicePrivateProfile . . . . . . . . . . . 32 96 5.3. Master Profile Objects . . . . . . . . . . . . . . . . . 32 97 5.3.1. Structure: SignedMasterProfile . . . . . . . . . . . 32 98 5.3.2. Structure: MasterProfile . . . . . . . . . . . . . . 32 99 5.4. Personal Profile Objects . . . . . . . . . . . . . . . . 33 100 5.4.1. Structure: SignedPersonalProfile . . . . . . . . . . 33 101 5.4.2. Structure: PersonalProfile . . . . . . . . . . . . . 33 102 5.4.3. Structure: ApplicationProfileEntry . . . . . . . . . 33 103 5.5. Application Profile Objects . . . . . . . . . . . . . . . 34 104 5.5.1. Structure: SignedApplicationProfile . . . . . . . . . 34 105 5.5.2. Structure: ApplicationProfile . . . . . . . . . . . . 34 106 5.5.3. Structure: ApplicationProfilePrivate . . . . . . . . 34 107 5.5.4. Structure: ApplicationDevicePublic . . . . . . . . . 34 108 5.5.5. Structure: ApplicationDevicePrivate . . . . . . . . . 34 109 5.6. Key Escrow Objects . . . . . . . . . . . . . . . . . . . 35 110 5.6.1. Structure: EscrowEntry . . . . . . . . . . . . . . . 35 111 5.6.2. Structure: OfflineEscrowEntry . . . . . . . . . . . . 35 112 5.6.3. Structure: OnlineEscrowEntry . . . . . . . . . . . . 35 113 5.6.4. Structure: EscrowedKeySet . . . . . . . . . . . . . . 35 114 6. Portal Connection . . . . . . . . . . . . . . . . . . . . . . 35 115 6.1. Connection Request and Response Structures . . . . . . . 35 116 6.1.1. Structure: ConnectionRequest . . . . . . . . . . . . 35 117 6.1.2. Structure: SignedConnectionRequest . . . . . . . . . 36 118 6.1.3. Structure: ConnectionResult . . . . . . . . . . . . . 36 119 6.1.4. Structure: SignedConnectionResult . . . . . . . . . . 36 120 7. Mesh Portal Service Reference . . . . . . . . . . . . . . . . 36 121 7.1. Request Messages . . . . . . . . . . . . . . . . . . . . 37 122 7.1.1. Message: MeshRequest . . . . . . . . . . . . . . . . 37 123 7.2. Response Messages . . . . . . . . . . . . . . . . . . . . 37 124 7.2.1. Message: MeshResponse . . . . . . . . . . . . . . . . 37 125 7.3. Imported Objects . . . . . . . . . . . . . . . . . . . . 37 126 7.4. Common Structures . . . . . . . . . . . . . . . . . . . . 37 127 7.4.1. Structure: KeyValue . . . . . . . . . . . . . . . . . 37 128 7.4.2. Structure: SearchConstraints . . . . . . . . . . . . 38 129 7.5. Transaction: Hello . . . . . . . . . . . . . . . . . . . 38 130 7.6. Transaction: ValidateAccount . . . . . . . . . . . . . . 38 131 7.6.1. Message: ValidateRequest . . . . . . . . . . . . . . 39 132 7.6.2. Message: ValidateResponse . . . . . . . . . . . . . . 39 133 7.7. Transaction: CreateAccount . . . . . . . . . . . . . . . 40 134 7.7.1. Message: CreateRequest . . . . . . . . . . . . . . . 40 135 7.7.2. Message: CreateResponse . . . . . . . . . . . . . . . 40 136 7.8. Transaction: DeleteAccount . . . . . . . . . . . . . . . 40 137 7.8.1. Message: DeleteRequest . . . . . . . . . . . . . . . 41 138 7.8.2. Message: DeleteResponse . . . . . . . . . . . . . . . 41 139 7.9. Transaction: Get . . . . . . . . . . . . . . . . . . . . 41 140 7.9.1. Message: GetRequest . . . . . . . . . . . . . . . . . 41 141 7.9.2. Message: GetResponse . . . . . . . . . . . . . . . . 42 142 7.10. Transaction: Publish . . . . . . . . . . . . . . . . . . 42 143 7.10.1. Message: PublishRequest . . . . . . . . . . . . . . 42 144 7.10.2. Message: PublishResponse . . . . . . . . . . . . . . 43 146 7.11. Transaction: Status . . . . . . . . . . . . . . . . . . . 43 147 7.11.1. Message: StatusRequest . . . . . . . . . . . . . . . 43 148 7.11.2. Message: StatusResponse . . . . . . . . . . . . . . 43 149 7.12. Transaction: ConnectStart . . . . . . . . . . . . . . . . 44 150 7.12.1. Message: ConnectStartRequest . . . . . . . . . . . . 44 151 7.12.2. Message: ConnectStartResponse . . . . . . . . . . . 44 152 7.13. Transaction: ConnectStatus . . . . . . . . . . . . . . . 44 153 7.13.1. Message: ConnectStatusRequest . . . . . . . . . . . 45 154 7.13.2. Message: ConnectStatusResponse . . . . . . . . . . . 45 155 7.14. Transaction: ConnectPending . . . . . . . . . . . . . . . 45 156 7.14.1. Message: ConnectPendingRequest . . . . . . . . . . . 45 157 7.14.2. Message: ConnectPendingResponse . . . . . . . . . . 46 158 7.15. Transaction: ConnectComplete . . . . . . . . . . . . . . 46 159 7.15.1. Message: ConnectCompleteRequest . . . . . . . . . . 46 160 7.15.2. Message: ConnectCompleteResponse . . . . . . . . . . 46 161 7.16. Transaction: Transfer . . . . . . . . . . . . . . . . . . 47 162 7.16.1. Message: TransferRequest . . . . . . . . . . . . . . 47 163 7.16.2. Message: TransferResponse . . . . . . . . . . . . . 47 164 8. Security Considerations . . . . . . . . . . . . . . . . . . . 47 165 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 166 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 48 167 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 168 11.1. Normative References . . . . . . . . . . . . . . . . . . 48 169 11.2. Informative References . . . . . . . . . . . . . . . . . 48 170 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 48 171 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 48 173 1. Introduction 175 NB: The reference material in this document is generated from the 176 schema used to derive the source code. The tool used to create this 177 material has not been optimized to produce output for the IETF 178 documentation format at this time. Consequently, the formatting is 179 currently sub-optimal. 181 2. Definitions 183 This section presents the related specifications and standard, the 184 terms that are used as terms of art within the documents and the 185 terms used as requirements language. 187 2.1. Requirements Language 189 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 190 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 191 document are to be interpreted as described in [RFC2119] . 193 2.2. Defined Terms 195 The terms of art used in this document are described in the Mesh 196 Architecture Guide [draft-hallambaker-mesh-architecture] . 198 2.3. Related Specifications 200 The architecture of the Mathematical Mesh is described in the Mesh 201 Architecture Guide [draft-hallambaker-mesh-architecture] . The Mesh 202 documentation set and related specifications are described in this 203 document. 205 2.4. Implementation Status 207 The implementation status of the reference code base is described in 208 the companion document [draft-hallambaker-mesh-developer] . 210 3. Protocol Overview 212 [Account request does not specify the portal in the request body, 213 only the HTTP package includes this information. This is probably a 214 bug.] 216 3.1. Creating a new portal account 218 A user interacts with a Mesh service through a Mesh portal provider 219 with which she establishes a portal account. 221 For user convenience, a portal account identifier has the familiar 222 @ format established in [~RFC822]. 224 For example Alice selects example.com as her portal provider and 225 chooses the account name alice. Her portal account identifier is 226 alice. 228 A user MAY establish accounts with multiple portal providers and/or 229 change their portal provider at any time they choose. 231 3.1.1. Checking Account Identifier for uniqueness 233 The first step in creating a new account is to check to see if the 234 chosen account identifier is available. This allows a client to 235 validate user input and if necessary warn the user that they need to 236 choose a new account identifier when the data is first entered. 238 The ValidateRequest message contains the requested account identifier 239 and an optional language parameter to allow the service to provide 240 informative error messages in a language the user understands. The 241 Language field contains a list of ISO language identifier codes in 242 order of preference, most preferred first. 244 POST /.well-known/mmm/HTTP/1.1 245 Host: example.com 246 Content-Length: 90 248 { 249 "ValidateRequest": { 250 "Account": "test@prismproof.org", 251 "Language": ["en-uk"]}} 253 Figure 1 255 The ValidateResponse message returns the result of the validation 256 request in the Valid field. Note that even if the value true is 257 returned, a subsequent account creation request MAY still fail. 259 HTTP/1.1 200 OK 260 Date: Mon 18 Sep 2017 05:07:25 261 Content-Length: 190 263 { 264 "ValidateResponse": { 265 "Status": 201, 266 "StatusDescription": "Operation completed successfully", 267 "Valid": true, 268 "Minimum": 1, 269 "InvalidCharacters": ".,:;{}()[]<>?|\\@#"}} 271 Figure 2 273 [Note that for the sake of concise presentation, the HTTP binding 274 information is omitted from future examples.] 276 3.2. Creating a new user profile 278 The first step in creating a new personal profile is to create a 279 Master Profile object. This contains the long term Master Signing 280 Key that will remain constant for the life of the profile, at least 281 one Online Signature Key to be used for administering the personal 282 profile and (optionally), one or more master escrow keys. 284 For convenience, the descriptions of the Master Signing Key, Online 285 Signing Keys and Escrow Keys typically include PKIX certificates 286 signed by the Master Signing Key. This allows PKIX based applications 287 to make use of PKIX certificate chains to express the same trust 288 relationships described in the Mesh. 290 { 291 "MasterProfile": { 292 "Identifier": "MC2T7-JNCI5-YMAW4-3XHYM-SBGJN-UMF4C", 293 "MasterSignatureKey": { 294 "UDF": "MC2T7-JNCI5-YMAW4-3XHYM-SBGJN-UMF4C", 295 "X509Certificate": " 296 MIIFXDCCBESgAwIBAgIQcL7ySTJG8wNHO591_XBcPzANBgkqhkiG9w0BAQ0FADAu 297 MSwwKgYDVQQDFiNNQzJUNy1KTkNJNS1ZTUFXNC0zWEhZTS1TQkdKTi1VTUY0QzAe 298 ... 299 V3vWAmk5gx_bslvn62cX7-nXYHgNPhVzgsGZzyQ7xoQ" 300 , 301 "PublicParameters": { 302 "PublicKeyRSA": { 303 "kid": "MC2T7-JNCI5-YMAW4-3XHYM-SBGJN-UMF4C", 304 "n": " 305 0stVVlOfh0EjLAxxjUA3QqBf_YPgr_KpuwoeD0RFjhSGwVV-Sg1iXfW3vnzh9G45 306 VH0zf73WzlioIyzAKn_SX8K4VwqP0ruvRxh7tUjx6s9-eqTF_QLoGVy_yiGohjAh 307 TomN4RHKNzU6aXhAgQijFVDNhr72iSMxcQbR6-w2fowMhRWvuozgkWjEf87kaaU3 308 _D_4J3STB0Q_q8YmvHQzkcK9J44b0N3ElEGrpa_yztR2sDgZKF33wLoJIQqxnfKT 309 y2e5_zSkiitZVbdrrOBacf83tDayUnIqzi8tOObVl4PGmgAcDmsFXh5EyUlDDntW 310 7UoUvnXhO2vid80VNaKQBQ" 311 , 312 "e": " 313 AQAB" 314 }}}, 315 "MasterEscrowKeys": [{ 316 "UDF": "MAL7U-IDBDI-R6BYF-SLY3J-MCTRX-HHTTG", 317 "X509Certificate": " 318 MIIFXDCCBESgAwIBAgIQEG_YIz9AHtxBPygAWwXd1TANBgkqhkiG9w0BAQ0FADAu 319 MSwwKgYDVQQDFiNNQzJUNy1KTkNJNS1ZTUFXNC0zWEhZTS1TQkdKTi1VTUY0QzAe 320 ... 321 pNfaAH5VutN_byCXIJcOO7RaG4_5Q1DJ9fg509R4YOA" 322 , 323 "PublicParameters": { 324 "PublicKeyRSA": { 325 "kid": "MAL7U-IDBDI-R6BYF-SLY3J-MCTRX-HHTTG", 326 "n": " 327 3pbzrDX60CicvkVauO18cilQgX49H_cABCw0kVTgR0m0bz7GX_cRXOEXRWrll6OA 328 ZJ3O_S5iWXT7ftschA_hHualfNtMCb1p3RmjpWKVNd24-Nk_V_miIej0xONCbWnc 329 LZW1uFLvHK4sj6LdlyVwri9NLzQF2rREXVtnQztl6HOpLEBbGGbYiXg1wyyfvCtt 330 aB1_YtMU5dvSupEGym1OLv5vj24Y7lY1CKQHWycSrwCoEVMsZvypqKftuwXZzY8f 331 4WTX3G1qZiU9Ay5OdUnTxoRhWUIWkC3wmRO5rNWhJvJv-3zU4ObKKAobz4qPBqbH 332 ddhkdoWZGBE9AGVXtuShXQ" 333 , 334 "e": " 335 AQAB" 336 }}}], 337 "OnlineSignatureKeys": [{ 338 "UDF": "MA7XV-ZOTDR-TXEDM-O2QP7-F7JTG-FGFFE", 339 "X509Certificate": " 340 MIIFXTCCBEWgAwIBAgIRAI04UIvLHhp0RDWWNNAjKW0wDQYJKoZIhvcNAQENBQAw 341 LjEsMCoGA1UEAxYjTUMyVDctSk5DSTUtWU1BVzQtM1hIWU0tU0JHSk4tVU1GNEMw 342 ... 343 -ACINNDOx-GsXY0-b8HsRzfdTHjW-r982VbEv06ZUz_E" 344 , 345 "PublicParameters": { 346 "PublicKeyRSA": { 347 "kid": "MA7XV-ZOTDR-TXEDM-O2QP7-F7JTG-FGFFE", 348 "n": " 349 z0GLRVQtom0B8eH-mYziccDixsLQeK8VUPENOb5jAF0QnOVITe1I-oq3wfotxxa6 350 _ehMLGUMPjSotKhEyjW7iFrkH9VCIPGMppqqU3sEWWzLvAAjdbOzAqTKWpjvXTfy 351 SDZO6f5pAcOQNVqoIE3lfrBfcB8wH_cciuhaxUp92E06FKyX5W76M7S2csGIaDPL 352 rDzJQFBNwuVLEOQ1CU3TlwNz99JL-jgBKCyt3cZBNM1yozJQDCiZMp6ffuR_bdcc 353 W8Y3sCzFIjd4Y4CskqjiYdij1lHcA_ppmAUKAbHwH5K3WVpVoXJGEg17GBAWtT1F 354 HyAvPtEnXvExYUEtcugaoQ" 355 , 356 "e": " 357 AQAB" 358 }}}]}} 360 Figure 3 362 The Master Profile is always signed using the Master Signing Key: 364 { 365 "SignedMasterProfile": { 366 "Identifier": "MC2T7-JNCI5-YMAW4-3XHYM-SBGJN-UMF4C", 367 "SignedData": { 368 "unprotected": { 369 "dig": "S512"}, 370 "payload": " 371 ewogICJNYXN0ZXJQcm9maWxlIjogewogICAgIklkZW50aWZpZXIiOiAiTUMyVDct 372 Sk5DSTUtWU1BVzQtM1hIWU0tU0JHSk4tVU1GNEMiLAogICAgIk1hc3RlclNpZ25h 373 ... 374 In19fV19fQ" 375 , 376 "signatures": [{ 377 "header": { 378 "kid": "MC2T7-JNCI5-YMAW4-3XHYM-SBGJN-UMF4C"}, 379 "protected": " 380 ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCmZVbDB3d3dHamZsSFNzdGVz 381 MjcwNG4tOVJMNURUTHdrSmYxdzJuQTh2SnFYNUFZSGpYMXNCcDlObTJhUl9zbHEK 382 QVZGbk5SRDl1dzRmbFJGQVF1NjlBdyJ9" 383 , 384 "signature": " 385 Ij6qkuwdSEbllNnCh-Lbca9BwEBxOparME-tu0IDgJz9TwvAVLPSTyPnLA8oPxpU 386 YcSnHwWbj_1A3OMdYAfOZk6do4uNirrCc7l4meUvH8psl3t5avZtRzRu6LXkIuI9 387 myZzef2C3UvfIzdW3E26tzRHUKo3ytyHiurH_hbHkTAReLQA18DSsTv3qMtTcKgF 388 BovmL9BLLZlTT7qWt1mibEMJc4iG4RjkFnBResR6tB1Qq_cLYYLP1wB8H3LjBw5q 389 2KEXk-KZrXo1jBYnCed0qJX8axpI7fzLpCZIjMZJ_fz4gNXuNUaYpfqkiHFID41_ 390 yruKcfxntvzVPQ3e8aVb0A" 391 }]}}} 393 Figure 4 395 Since the device used to create the personal profile is typically 396 connected to the profile, a Device profile entry is created for it. 397 This contains a Device Signing Key, a Device Encryption Key and a 398 Device Authentication Key: 400 { 401 "JoseWebSignature": { 402 "unprotected": { 403 "dig": "S512"}, 404 "payload": " 405 ewogICJEZXZpY2VQcm9maWxlIjogewogICAgIklkZW50aWZpZXIiOiAiTUFVNjMt 406 WUJFSFQtRDJYUlYtUjJDRFQtRjMySFgtTEVXRFQiLAogICAgIk5hbWVzIjogWyJE 407 ... 408 ZW9ESjNRIiwKICAgICAgICAgICJlIjogIgpBUUFCIn19fX19" 409 , 410 "signatures": [{ 411 "header": { 412 "kid": "MAU63-YBEHT-D2XRV-R2CDT-F32HX-LEWDT"}, 413 "protected": " 414 ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCm81TjhEQnpYbXAydlRZUGYy 415 cFdQN2dkdm9iZmpNNktsTEpFTjhyN3BsUGRPZjVQeHhVT3BvbEE2eWxTbnNXc0gK 416 dWVHSFJTNUdZLXFFWHhPcUhZSWZqUSJ9" 417 , 418 "signature": " 419 MngvWlH1-_wpaiQ9vy9oYymY7HWY6lnyMqw9VvjAHyCOGK0la7WJTL74l4J5R1Ac 420 C3Hz2FH77gWraXksvEQICcUmfQA7L8RQ54yZ7Ns3VDutIjA6Mx6v-1LERCCUF3wJ 421 px85F7dgsS5NindawFAStOTnEq8zYHTi91tsKM0dGvELpXVuJqBA7DxK1qzLP21I 422 BhhCiiiB3zLMfMieBOZYlUshw8_bJi2cTpcpk4qf8ysAihZiCbVzRs6GKwxCY1qO 423 lCUkAqBwhALnNymGuhBNChwxGB0dJTtxtl_IghMqiJTdP2d1iQnBwQvu904kLTIQ 424 -nWESV29mAB_JaecLWSwBw" 425 }]}} 427 Figure 5 429 The Device Profile is signed using the Device Signing Key: 431 { 432 "SignedDeviceProfile": { 433 "Identifier": "MAU63-YBEHT-D2XRV-R2CDT-F32HX-LEWDT", 434 "SignedData": { 435 "unprotected": { 436 "dig": "S512"}, 437 "payload": " 438 ewogICJEZXZpY2VQcm9maWxlIjogewogICAgIklkZW50aWZpZXIiOiAiTUFVNjMt 439 WUJFSFQtRDJYUlYtUjJDRFQtRjMySFgtTEVXRFQiLAogICAgIk5hbWVzIjogWyJE 440 ... 441 ZW9ESjNRIiwKICAgICAgICAgICJlIjogIgpBUUFCIn19fX19" 442 , 443 "signatures": [{ 444 "header": { 445 "kid": "MAU63-YBEHT-D2XRV-R2CDT-F32HX-LEWDT"}, 446 "protected": " 447 ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCm81TjhEQnpYbXAydlRZUGYy 448 cFdQN2dkdm9iZmpNNktsTEpFTjhyN3BsUGRPZjVQeHhVT3BvbEE2eWxTbnNXc0gK 449 dWVHSFJTNUdZLXFFWHhPcUhZSWZqUSJ9" 450 , 451 "signature": " 452 MngvWlH1-_wpaiQ9vy9oYymY7HWY6lnyMqw9VvjAHyCOGK0la7WJTL74l4J5R1Ac 453 C3Hz2FH77gWraXksvEQICcUmfQA7L8RQ54yZ7Ns3VDutIjA6Mx6v-1LERCCUF3wJ 454 px85F7dgsS5NindawFAStOTnEq8zYHTi91tsKM0dGvELpXVuJqBA7DxK1qzLP21I 455 BhhCiiiB3zLMfMieBOZYlUshw8_bJi2cTpcpk4qf8ysAihZiCbVzRs6GKwxCY1qO 456 lCUkAqBwhALnNymGuhBNChwxGB0dJTtxtl_IghMqiJTdP2d1iQnBwQvu904kLTIQ 457 -nWESV29mAB_JaecLWSwBw" 458 }]}}} 460 Figure 6 462 A personal profile would typically contain at least one application 463 when first created. For the sake of demonstration, we will do this 464 later. 466 The personal profile thus consists of the master profile and the 467 device profile: 469 { 470 "PersonalProfile": { 471 "Identifier": "MC2T7-JNCI5-YMAW4-3XHYM-SBGJN-UMF4C", 472 "SignedMasterProfile": { 473 "Identifier": "MC2T7-JNCI5-YMAW4-3XHYM-SBGJN-UMF4C", 474 "SignedData": { 475 "unprotected": { 476 "dig": "S512"}, 477 "payload": " 478 ewogICJNYXN0ZXJQcm9maWxlIjogewogICAgIklkZW50aWZpZXIiOiAiTUMyVDct 479 Sk5DSTUtWU1BVzQtM1hIWU0tU0JHSk4tVU1GNEMiLAogICAgIk1hc3RlclNpZ25h 480 ... 481 In19fV19fQ" 482 , 483 "signatures": [{ 484 "header": { 485 "kid": "MC2T7-JNCI5-YMAW4-3XHYM-SBGJN-UMF4C"}, 486 "protected": " 487 ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCmZVbDB3d3dHamZsSFNzdGVz 488 MjcwNG4tOVJMNURUTHdrSmYxdzJuQTh2SnFYNUFZSGpYMXNCcDlObTJhUl9zbHEK 489 QVZGbk5SRDl1dzRmbFJGQVF1NjlBdyJ9" 490 , 491 "signature": " 492 Ij6qkuwdSEbllNnCh-Lbca9BwEBxOparME-tu0IDgJz9TwvAVLPSTyPnLA8oPxpU 493 YcSnHwWbj_1A3OMdYAfOZk6do4uNirrCc7l4meUvH8psl3t5avZtRzRu6LXkIuI9 494 myZzef2C3UvfIzdW3E26tzRHUKo3ytyHiurH_hbHkTAReLQA18DSsTv3qMtTcKgF 495 BovmL9BLLZlTT7qWt1mibEMJc4iG4RjkFnBResR6tB1Qq_cLYYLP1wB8H3LjBw5q 496 2KEXk-KZrXo1jBYnCed0qJX8axpI7fzLpCZIjMZJ_fz4gNXuNUaYpfqkiHFID41_ 497 yruKcfxntvzVPQ3e8aVb0A" 498 }]}}, 499 "Devices": [{ 500 "Identifier": "MAU63-YBEHT-D2XRV-R2CDT-F32HX-LEWDT", 501 "SignedData": { 502 "unprotected": { 503 "dig": "S512"}, 504 "payload": " 505 ewogICJEZXZpY2VQcm9maWxlIjogewogICAgIklkZW50aWZpZXIiOiAiTUFVNjMt 506 WUJFSFQtRDJYUlYtUjJDRFQtRjMySFgtTEVXRFQiLAogICAgIk5hbWVzIjogWyJE 507 ... 508 ZW9ESjNRIiwKICAgICAgICAgICJlIjogIgpBUUFCIn19fX19" 509 , 510 "signatures": [{ 511 "header": { 512 "kid": "MAU63-YBEHT-D2XRV-R2CDT-F32HX-LEWDT"}, 513 "protected": " 514 ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCm81TjhEQnpYbXAydlRZUGYy 515 cFdQN2dkdm9iZmpNNktsTEpFTjhyN3BsUGRPZjVQeHhVT3BvbEE2eWxTbnNXc0gK 516 dWVHSFJTNUdZLXFFWHhPcUhZSWZqUSJ9" 517 , 518 "signature": " 519 MngvWlH1-_wpaiQ9vy9oYymY7HWY6lnyMqw9VvjAHyCOGK0la7WJTL74l4J5R1Ac 520 C3Hz2FH77gWraXksvEQICcUmfQA7L8RQ54yZ7Ns3VDutIjA6Mx6v-1LERCCUF3wJ 521 px85F7dgsS5NindawFAStOTnEq8zYHTi91tsKM0dGvELpXVuJqBA7DxK1qzLP21I 522 BhhCiiiB3zLMfMieBOZYlUshw8_bJi2cTpcpk4qf8ysAihZiCbVzRs6GKwxCY1qO 523 lCUkAqBwhALnNymGuhBNChwxGB0dJTtxtl_IghMqiJTdP2d1iQnBwQvu904kLTIQ 524 -nWESV29mAB_JaecLWSwBw" 525 }]}}], 526 "Applications": []}} 527 Figure 7 529 The personal profile is then signed using the Online Signing Key: 531 { 532 "SignedPersonalProfile": { 533 "Identifier": "MC2T7-JNCI5-YMAW4-3XHYM-SBGJN-UMF4C", 534 "SignedData": { 535 "unprotected": { 536 "dig": "S512"}, 537 "payload": " 538 ewogICJQZXJzb25hbFByb2ZpbGUiOiB7CiAgICAiSWRlbnRpZmllciI6ICJNQzJU 539 Ny1KTkNJNS1ZTUFXNC0zWEhZTS1TQkdKTi1VTUY0QyIsCiAgICAiU2lnbmVkTWFz 540 ... 541 b25zIjogW119fQ" 542 , 543 "signatures": [{ 544 "header": { 545 "kid": "MA7XV-ZOTDR-TXEDM-O2QP7-F7JTG-FGFFE"}, 546 "protected": " 547 ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCnhHUlFPY21qdGtWbHhMdTFh 548 RTJjS1JKN2k4MWN0NmQ4MTZGSTZxRHVOS3RGbm9MYjRybDhoM2NvSS1neGI5aEMK 549 V3ExY3B6cU81SHJDMHRNdDlvRk1CQSJ9" 550 , 551 "signature": " 552 D4lfCt5MEKb-1xB4KFC62ZWZaiHnOLgiQOxGhUkuhx-hGnP6XUkyMBjM2Xn2ggeW 553 HTo7aa-SoeA8pEvCsX1udicW7uRqJPxUf4_fC4LxVhJko9pWkPs2BnuBcTlYjzKL 554 QuAx8Uby34lk_f2260R6gx9smxEAFuq-hE3KpPWOfa0_wDZnJ2T_LljDoDdThpef 555 fXuWfX9ehO7jGEObOWOImLb9anLrciLNIkxDgjs_urcAdsmciMBODIn5OtaUbxiU 556 zzRaOlofB3PFCWEg8bnJ4g9CsMbmUC0TfKAwtyvto5aD0z_t5JmKCyjrpeg6PlkV 557 NjmUpXfqwSE_E8Zmwv5PsQ" 558 }]}}} 560 Figure 8 562 3.2.1. Publishing a new user profile 564 Once the signed personal profile is created, the client can finaly 565 make the request for the service to create the account. The request 566 object contains the requested account identifier and profile: 568 { 569 "CreateRequest": { 570 "Account": "test@prismproof.org", 571 "Profile": { 572 "SignedPersonalProfile": { 573 "Identifier": "MC2T7-JNCI5-YMAW4-3XHYM-SBGJN-UMF4C", 574 "SignedData": { 575 "unprotected": { 576 "dig": "S512"}, 577 "payload": " 578 ewogICJQZXJzb25hbFByb2ZpbGUiOiB7CiAgICAiSWRlbnRpZmllciI6ICJNQzJU 579 Ny1KTkNJNS1ZTUFXNC0zWEhZTS1TQkdKTi1VTUY0QyIsCiAgICAiU2lnbmVkTWFz 580 ... 581 b25zIjogW119fQ" 582 , 583 "signatures": [{ 584 "header": { 585 "kid": "MA7XV-ZOTDR-TXEDM-O2QP7-F7JTG-FGFFE"}, 586 "protected": " 587 ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCnhHUlFPY21qdGtWbHhMdTFh 588 RTJjS1JKN2k4MWN0NmQ4MTZGSTZxRHVOS3RGbm9MYjRybDhoM2NvSS1neGI5aEMK 589 V3ExY3B6cU81SHJDMHRNdDlvRk1CQSJ9" 590 , 591 "signature": " 592 D4lfCt5MEKb-1xB4KFC62ZWZaiHnOLgiQOxGhUkuhx-hGnP6XUkyMBjM2Xn2ggeW 593 HTo7aa-SoeA8pEvCsX1udicW7uRqJPxUf4_fC4LxVhJko9pWkPs2BnuBcTlYjzKL 594 QuAx8Uby34lk_f2260R6gx9smxEAFuq-hE3KpPWOfa0_wDZnJ2T_LljDoDdThpef 595 fXuWfX9ehO7jGEObOWOImLb9anLrciLNIkxDgjs_urcAdsmciMBODIn5OtaUbxiU 596 zzRaOlofB3PFCWEg8bnJ4g9CsMbmUC0TfKAwtyvto5aD0z_t5JmKCyjrpeg6PlkV 597 NjmUpXfqwSE_E8Zmwv5PsQ" 598 }]}}}}} 600 Figure 9 602 The service reports the success (or failure) of the account creation 603 request: 605 { 606 "CreateResponse": { 607 "Status": 201, 608 "StatusDescription": "Operation completed successfully"}} 610 Figure 10 612 3.3. Connecting a device profile to a user profile 614 Connecting a device to a profile requires the client on the new 615 device to interact with a client on a device that has administration 616 capabilities, i.e. it has access to an Online Signing Key. Since 617 clients cannot interact directly with other clients, a service is 618 required to mediate the connection. This service is provided by a 619 Mesh portal provider. 621 All service transactions are initiated by the clients. First the 622 connecting device posts ConnectStart, after which it may poll for the 623 outcome of the connection request using ConnectStatus. 625 Periodically, the Administration Device polls for a list of pending 626 connection requests using ConnectPending. After posting a request, 627 the administration device posts the result using ConnectComplete: 629 Connecting Mesh Administration 630 Device Service Device 632 | | | 633 | ConnectStart | | 634 | ----------------------> | | 635 | | ConnectPending | 636 | | <---------------------- | 637 | | | 638 | | ConnectComplete | 639 | | <---------------------- | 640 | ConnectStatus | | 641 | ----------------------> | | 643 Figure 11 645 The first step in the process is for the client to generate a device 646 profile. Ideally the device profile is bound to the device in a 647 read-only fashion such that applications running on the device can 648 make use of the deencryption and authentication keys but these 649 private keys cannot be extracted from the device: 651 { 652 "DeviceProfile": { 653 "Identifier": "MDVIK-G4PQB-STGMV-2YP4F-RSG44-RURCQ", 654 "Names": ["Default"], 655 "Description": "Unknown", 656 "DeviceSignatureKey": { 657 "UDF": "MDVIK-G4PQB-STGMV-2YP4F-RSG44-RURCQ", 658 "PublicParameters": { 659 "PublicKeyRSA": { 660 "kid": "MDVIK-G4PQB-STGMV-2YP4F-RSG44-RURCQ", 661 "n": " 662 zqnfQp2q3wV31KUAMuvMkLTZ29SfqKuIIeGKWhrTMDoMKoj_NKqBaSmXh5ggsl2_ 663 9IkhaddFKwzJkYokxII5PQfPio9E8Kwp1roVOVhSRjVvQgIFTu43HNOL5EtO6ofN 664 iHbjtE8VhW4f827q_ViU3zfoRdyMRV_RYb8OV5bIFzWeKMjm8tYO_QbMZL5VYjJ_ 665 w5exDxq_-3l8tXA84RggCDWWVg-zXkmfOYVyV0T5zW9vUe4SFQQHBWtBy2nVh1-i 666 zNDPdJwgixh7Ey8vB3Wd_QcxFmoLZeDrGOIqZ4bVwC3wQdwb26GV3jJH30sQ46pw 667 w5nSX-oCnKLFtBORIPOE2Q" 668 , 669 "e": " 670 AQAB" 671 }}}, 672 "DeviceAuthenticationKey": { 673 "UDF": "MAMIP-V4HJY-EV2VR-2TL6C-22VZU-QAZT4", 674 "PublicParameters": { 675 "PublicKeyRSA": { 676 "kid": "MAMIP-V4HJY-EV2VR-2TL6C-22VZU-QAZT4", 677 "n": " 678 2HzzkEgoaqLyEf7MsykSt8l9rVUEgjNc9QJSw6-_kzKrOmmJaHS0KUWUKGR6G-Ps 679 QvG6TBAnGYzwihwCz8OoTqvwIXQGeI_4Wg_jwSj5qMWXgb2bIskbnQxJBxNMmLU_ 680 i7-EnuqYwwvy2DBKMz4p4-dJaiISPKZUXnrJQq6jotdMniAuVMWFMMif2Y3-DNGn 681 I7yBo3_KPmzqRID1EQJxWU0YffPo2bS8lcJTeiIQeViRtPpN7rEyvSVmoWirG_XY 682 LijjQnpZUdC_UZNTkdFkpZkJU-_IcWbegmEoxTbXgOdeGNy1SgEjNTUqUoiWKHk5 683 o__IzuqAkdXlrxRYsJu4iQ" 684 , 685 "e": " 686 AQAB" 687 }}}, 688 "DeviceEncryptiontionKey": { 689 "UDF": "MBZL4-6R2G4-3VA6V-XNMJS-B5ZAU-XZ4KZ", 690 "PublicParameters": { 691 "PublicKeyRSA": { 692 "kid": "MBZL4-6R2G4-3VA6V-XNMJS-B5ZAU-XZ4KZ", 693 "n": " 694 3PwWFh0nziWOWohD1dWQSjQHzS6MicVxnjOiyR0W5-_Xxz53R1phuEiU52o9epSx 695 vFVmYsf7_9qjKyESE19WUR6b-XeOhjnukV0V-7wRFvO5EAyr52WB49Kr3W5rQvGZ 696 ETGVVlL0ZtLo9FkDrqca0bcNK1yL8sg4wKBOxKe3Lt-f2W-WLGT0QkPHIfuafeci 697 WGVQSvFmtTTiK1L-Yfx9aqc8hxXFfOqVKnTHNIx9rYyQvw9XVQ6dSun-ljf8e1wP 698 Im7yriOyztMr0w6MHMASEDkdyqVRddUjyc_EJTdIHhHuoGkhjWfSnsMrfgDgyNe1 699 FDNY1xMja2Kol7ZSyWLuCQ" 700 , 701 "e": " 702 AQAB" 703 }}}}} 705 Figure 12 707 The device profile is then signed: 709 { 710 "SignedDeviceProfile": { 711 "Identifier": "MDVIK-G4PQB-STGMV-2YP4F-RSG44-RURCQ", 712 "SignedData": { 713 "unprotected": { 714 "dig": "S512"}, 715 "payload": " 716 ewogICJEZXZpY2VQcm9maWxlIjogewogICAgIklkZW50aWZpZXIiOiAiTURWSUst 717 RzRQUUItU1RHTVYtMllQNEYtUlNHNDQtUlVSQ1EiLAogICAgIk5hbWVzIjogWyJE 718 ... 719 ICAgICAgICAgImUiOiAiCkFRQUIifX19fX0" 720 , 721 "signatures": [{ 722 "header": { 723 "kid": "MDVIK-G4PQB-STGMV-2YP4F-RSG44-RURCQ"}, 724 "protected": " 725 ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCmRzLXpSNzV0TWtYTld4UG1X 726 RURBMU5jM3hUcGJhWWNDLWxCWFRUNXhNZDR0d2tMc1hsbXdlZ0N0bzVVTWFvem0K 727 U25KMFF1d2M2azBLSGh1ak9QNzJoZyJ9" 728 , 729 "signature": " 730 K5kWHWdOOK-cCWg-QbEiKPpNG5hexBHFrJNFh14g_LoFsUZQ8Jsa8hc0wQqD7S8E 731 qA3i8EEjYj0V-jxeEHNQPObpocy98Sgx3iV55nIH3eX9ccvdWE7pcYIwJ2kx5WNa 732 n7RmmviaFB-I_7vZ-WG7Mdr9LF6nlSSLrGUG1rh8cY558QCpxt1Fvx1qXTG9Upf6 733 fTsHG0WyAEnWtTGqd8VqWysD7O24QFlPWOSHS3OwuHZ-aRyt0Wfl3GgtIt2kLXWg 734 Vn8jZpbZzDgbjKhK4AsyLWopVOT_Tbs7wNGMwCwdKjyb56rKXCBJ50MePeoRFH3J 735 xxsjlZrC8wMTbIRNOI7krg" 736 }]}}} 738 Figure 13 740 3.3.1. Profile Authentication 742 One of the main architecutral principles of the Mesh is bilateral 743 authentication. Every device that is connected to a Mesh profile 744 MUST authenticate the profile it is connecting to and every Mesh 745 profile administrator MUST authenticate devices that are connected. 747 Having created the necessary profile, the device MUST verify that it 748 is connecting to the correct Mesh profile. The best mechanism for 749 achieving this purpose depends on the capabilities of the device 750 being connected. The administration device obviously requires some 751 means of communicating with the user to serve its function. But the 752 device being connected may have a limited display capability or no 753 user interaction capability at all. 755 3.3.1.1. Interactive Devices 757 If the device has user input and display capabilities, it can verify 758 that it is connecting to the correct display by first requesting the 759 user enter the portal account of the profile they wish to connect to, 760 retreiving the profile associated with the device and displaying the 761 profile fingerprint. 763 The client requests the profile for the requested account name: 765 { 766 "GetRequest": { 767 "Account": "test@prismproof.org", 768 "Multiple": false}} 770 Figure 14 772 The response contains the requested profile information. 774 { 775 "GetResponse": { 776 "Status": 201, 777 "StatusDescription": "Operation completed successfully", 778 "Entries": [{ 779 "SignedPersonalProfile": { 780 "Identifier": "MC2T7-JNCI5-YMAW4-3XHYM-SBGJN-UMF4C", 781 "SignedData": { 782 "unprotected": { 783 "dig": "S512"}, 784 "payload": " 785 ewogICJQZXJzb25hbFByb2ZpbGUiOiB7CiAgICAiSWRlbnRpZmllciI6ICJNQzJU 786 Ny1KTkNJNS1ZTUFXNC0zWEhZTS1TQkdKTi1VTUY0QyIsCiAgICAiU2lnbmVkTWFz 787 ... 788 b25zIjogW119fQ" 789 , 790 "signatures": [{ 791 "header": { 792 "kid": "MA7XV-ZOTDR-TXEDM-O2QP7-F7JTG-FGFFE"}, 793 "protected": " 794 ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCnhHUlFPY21qdGtWbHhMdTFh 795 RTJjS1JKN2k4MWN0NmQ4MTZGSTZxRHVOS3RGbm9MYjRybDhoM2NvSS1neGI5aEMK 796 V3ExY3B6cU81SHJDMHRNdDlvRk1CQSJ9" 797 , 798 "signature": " 799 D4lfCt5MEKb-1xB4KFC62ZWZaiHnOLgiQOxGhUkuhx-hGnP6XUkyMBjM2Xn2ggeW 800 HTo7aa-SoeA8pEvCsX1udicW7uRqJPxUf4_fC4LxVhJko9pWkPs2BnuBcTlYjzKL 801 QuAx8Uby34lk_f2260R6gx9smxEAFuq-hE3KpPWOfa0_wDZnJ2T_LljDoDdThpef 802 fXuWfX9ehO7jGEObOWOImLb9anLrciLNIkxDgjs_urcAdsmciMBODIn5OtaUbxiU 803 zzRaOlofB3PFCWEg8bnJ4g9CsMbmUC0TfKAwtyvto5aD0z_t5JmKCyjrpeg6PlkV 804 NjmUpXfqwSE_E8Zmwv5PsQ" 805 }]}}}]}} 807 Figure 15 809 Having received the profile data, the user can then verify that the 810 device is attempting to connect to the correct profile by verifying 811 that the fingerprint shown by the device attempting to connect is 812 correct. 814 3.3.1.2. Constrained Interaction Devices 816 Connection of an Internet of Things 'IoT' device that does not have 817 the ability to accept user input requires a mechanism by which the 818 user can identify the device they wish to connect to their profile 819 and a mechanism to authenticate the profile to the device. 821 If the connecting device has a wired communication capability such as 822 a USB port, this MAY be used to effect the device connection using a 823 standardized interaction profile. But an increasing number of 824 constrained IoT devices are only capable of wireless communication. 826 Configuration of such devices for the purpose of the Mesh requires 827 that we also consider configuration of the wireless networking 828 capabilities at the same time. The precise mechanism by which this 829 is achieved is therefore outside the scope of this particular 830 document. However prototypes have been built and are being 831 considered that make use of some or all of the following 832 communication techniques: 834 o Wired serial connection (RS232, RS485). 836 o DHCP signalling. 838 o Machine readable device identifiers (barcodes, QRCodes). 840 o Default device profile installed during manufacture. 842 o Optical communication path using camera on administrative device 843 and status light on connecting device to communicate the device 844 identifier, challenge nonce and confirm profile fingerprint. 846 o Speech output on audio capable connecting device. 848 3.3.2. Connection request 850 After the user verifies the device fingerprint as correct, the client 851 posts a device connection request to the portal: 853 { 854 "ConnectStartRequest": { 855 "SignedRequest": { 856 "Identifier": "MDVIK-G4PQB-STGMV-2YP4F-RSG44-RURCQ", 857 "SignedData": { 858 "unprotected": { 859 "dig": "S512"}, 860 "payload": " 861 ewogICJDb25uZWN0aW9uUmVxdWVzdCI6IHsKICAgICJQYXJlbnRVREYiOiAiTUMy 862 VDctSk5DSTUtWU1BVzQtM1hIWU0tU0JHSk4tVU1GNEMiLAogICAgIkRldmljZSI6 863 ... 864 fX0sCiAgICAiRGV2aWNlRGF0YSI6IFtdfX0" 865 , 866 "signatures": [{ 867 "header": { 868 "kid": "MDVIK-G4PQB-STGMV-2YP4F-RSG44-RURCQ"}, 869 "protected": " 870 ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCmZ1T0h4N3BWM19lU2Q4UXh5 871 bUgyQWFoWDR0a3VFM0ZjSHNzeE1LdVFDTDd3THFYeXgtZi1TZmloa1dRS3RVckYK 872 VGRtcWZUTHRrMFAxS2tQZmZDbElnQSJ9" 873 , 874 "signature": " 875 vsMjgztTeC9TK11ZSa8at7hlQbD51g0ImBypkGqwEvWOO6J7NSaR7kPtgukzIS75 876 Bii8coRZjSFBlieMWUj6pWp5Ge70wx7S8BBvqFol5YRqmqxnek9gPmxRWrPnPX8_ 877 nBytoATRY-sztfA1teN4fkKAp5yJxV9tLqYDuZlmw6jPZ_OpRKWQ16IOpHPdut_q 878 8IAdAuaerVXpk4DN5sqSRUMdNdW27DXwk3Y8crdj2UNpbQIhpBCgZMA7Fn6elmDN 879 rPHpDgRjQf-qAqpIIU_AGmylUk4M8I1eeuvf_-U0jxDG0FDM_WBJ58RUL0yFP-oM 880 NH6SyZFFszHl--u1SHO3kA" 881 }]}}, 882 "AccountID": "test@prismproof.org"}} 884 Figure 16 886 The portal verifies that the request is accepable and returns the 887 transaction result: 889 { 890 "ConnectStartResponse": {}} 892 Figure 17 894 3.3.3. Administrator Polls Pending Connections 896 The client can poll the portal for the status of pending requests at 897 any time (modulo any service throttling restrictions at the service 898 side). But the request status will only change when an update is 899 posted by an administration device. 901 Since the user is typically connecting a device to their profile, the 902 next step in connecting the device is to start the administration 903 client. When started, the client polls for pending connection 904 requests using ConnectPendingRequest. 906 { 907 "ConnectPendingRequest": { 908 "AccountID": "test@prismproof.org"}} 910 Figure 18 912 The service responds with a list of pending requests: 914 { 915 "ConnectPendingResponse": { 916 "Pending": [{ 917 "Identifier": "MDVIK-G4PQB-STGMV-2YP4F-RSG44-RURCQ", 918 "SignedData": { 919 "unprotected": { 920 "dig": "S512"}, 921 "payload": " 922 ewogICJDb25uZWN0aW9uUmVxdWVzdCI6IHsKICAgICJQYXJlbnRVREYiOiAiTUMy 923 VDctSk5DSTUtWU1BVzQtM1hIWU0tU0JHSk4tVU1GNEMiLAogICAgIkRldmljZSI6 924 ... 925 fX0sCiAgICAiRGV2aWNlRGF0YSI6IFtdfX0" 926 , 927 "signatures": [{ 928 "header": { 929 "kid": "MDVIK-G4PQB-STGMV-2YP4F-RSG44-RURCQ"}, 930 "protected": " 931 ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCmZ1T0h4N3BWM19lU2Q4UXh5 932 bUgyQWFoWDR0a3VFM0ZjSHNzeE1LdVFDTDd3THFYeXgtZi1TZmloa1dRS3RVckYK 933 VGRtcWZUTHRrMFAxS2tQZmZDbElnQSJ9" 934 , 935 "signature": " 936 vsMjgztTeC9TK11ZSa8at7hlQbD51g0ImBypkGqwEvWOO6J7NSaR7kPtgukzIS75 937 Bii8coRZjSFBlieMWUj6pWp5Ge70wx7S8BBvqFol5YRqmqxnek9gPmxRWrPnPX8_ 938 nBytoATRY-sztfA1teN4fkKAp5yJxV9tLqYDuZlmw6jPZ_OpRKWQ16IOpHPdut_q 939 8IAdAuaerVXpk4DN5sqSRUMdNdW27DXwk3Y8crdj2UNpbQIhpBCgZMA7Fn6elmDN 940 rPHpDgRjQf-qAqpIIU_AGmylUk4M8I1eeuvf_-U0jxDG0FDM_WBJ58RUL0yFP-oM 941 NH6SyZFFszHl--u1SHO3kA" 942 }]}}]}} 944 Figure 19 946 3.3.4. Administrator updates and publishes the personal profile. 948 The device profile is added to the Personal profile which is then 949 signed by the online signing key. The administration client 950 publishes the updated profile to the Mesh through the portal: 952 { 953 "ConnectPendingRequest": { 954 "AccountID": "test@prismproof.org"}} 956 Figure 20 958 As usual, the service returns the response code: 960 { 961 "ConnectPendingResponse": { 962 "Pending": [{ 963 "Identifier": "MDVIK-G4PQB-STGMV-2YP4F-RSG44-RURCQ", 964 "SignedData": { 965 "unprotected": { 966 "dig": "S512"}, 967 "payload": " 968 ewogICJDb25uZWN0aW9uUmVxdWVzdCI6IHsKICAgICJQYXJlbnRVREYiOiAiTUMy 969 VDctSk5DSTUtWU1BVzQtM1hIWU0tU0JHSk4tVU1GNEMiLAogICAgIkRldmljZSI6 970 ... 971 fX0sCiAgICAiRGV2aWNlRGF0YSI6IFtdfX0" 972 , 973 "signatures": [{ 974 "header": { 975 "kid": "MDVIK-G4PQB-STGMV-2YP4F-RSG44-RURCQ"}, 976 "protected": " 977 ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCmZ1T0h4N3BWM19lU2Q4UXh5 978 bUgyQWFoWDR0a3VFM0ZjSHNzeE1LdVFDTDd3THFYeXgtZi1TZmloa1dRS3RVckYK 979 VGRtcWZUTHRrMFAxS2tQZmZDbElnQSJ9" 980 , 981 "signature": " 982 vsMjgztTeC9TK11ZSa8at7hlQbD51g0ImBypkGqwEvWOO6J7NSaR7kPtgukzIS75 983 Bii8coRZjSFBlieMWUj6pWp5Ge70wx7S8BBvqFol5YRqmqxnek9gPmxRWrPnPX8_ 984 nBytoATRY-sztfA1teN4fkKAp5yJxV9tLqYDuZlmw6jPZ_OpRKWQ16IOpHPdut_q 985 8IAdAuaerVXpk4DN5sqSRUMdNdW27DXwk3Y8crdj2UNpbQIhpBCgZMA7Fn6elmDN 986 rPHpDgRjQf-qAqpIIU_AGmylUk4M8I1eeuvf_-U0jxDG0FDM_WBJ58RUL0yFP-oM 987 NH6SyZFFszHl--u1SHO3kA" 988 }]}}]}} 990 Figure 21 992 3.3.5. Administrator posts completion request. 994 Having accepted the device and connected it to the profile, the 995 administration client creates and signs a connection completion 996 result which is posted to the portal using ConnectCompleteRequest: 998 { 999 "ConnectCompleteRequest": { 1000 "Result": { 1001 "Identifier": "MDVIK-G4PQB-STGMV-2YP4F-RSG44-RURCQ", 1002 "SignedData": { 1003 "unprotected": { 1004 "dig": "S512"}, 1005 "payload": " 1006 ewogICJDb25uZWN0aW9uUmVzdWx0IjogewogICAgIkRldmljZSI6IHsKICAgICAg 1007 IklkZW50aWZpZXIiOiAiTURWSUstRzRQUUItU1RHTVYtMllQNEYtUlNHNDQtUlVS 1008 ... 1009 Cm9HYzJwWlhfbHFibHZxemhhSzBMNFEifV19fX19fQ" 1010 , 1011 "signatures": [{ 1012 "header": { 1013 "kid": "MA7XV-ZOTDR-TXEDM-O2QP7-F7JTG-FGFFE"}, 1014 "protected": " 1015 ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiClRtQzNKakpZLS1oQjdRT0Fp 1016 bFg0WGtlQ3ZoVG02MEkwM3F0OVlKdkEwVUVRb0Y3X2M0ems2UnZoSWZGVm02NDIK 1017 bmM5b1k2Y3FIV0ZLdnBwZlJobm9qZyJ9" 1018 , 1019 "signature": " 1020 DMNIqoQOKRFCaJTjHcR72StoWTqsaL3Kx1tL3P0QjPsI1sfo6DQPTQu6RP5ZNksm 1021 UF60KHGheopm-RvlxZjZ5qfMwWdCmmiCzAj-yrQoLcTEkq523mzDqZNc03IME6jn 1022 MDE2_oGkoa5FyXeQAtPEsbB8n4Ib2FE7nkcehGufiP5RiKi0dxDJaMJaEiSfkIvf 1023 XjUfypzW6nk_ALwi898icIXBxNatlUwgiikrchdu3PcG1c-dKndQqsd2Z74_vjKq 1024 hUeyTiZT33CMEMt74Gi8dX4C78W2QxApUdGsv6EzWZmL9Jjr_p2neerfZfuTik8C 1025 Xp1aigh1A0uyY30RbEwSQw" 1026 }]}}, 1027 "AccountID": "test@prismproof.org"}} 1029 Figure 22 1031 Again, the service returns the response code: 1033 { 1034 "ConnectCompleteResponse": {}} 1036 Figure 23 1038 3.3.6. Connecting device polls for status update. 1040 As stated previously, the connecting device polls the portal 1041 periodically to determine the status of the pending request using 1042 ConnectStatusRequest: 1044 { 1045 "ConnectStatusRequest": { 1046 "AccountID": "test@prismproof.org", 1047 "DeviceID": "MDVIK-G4PQB-STGMV-2YP4F-RSG44-RURCQ"}} 1049 Figure 24 1051 If the response is that the connection status has not changed, the 1052 service MAY return a response that specifies a minimum retry 1053 interval. In this case however there is a connection result: 1055 { 1056 "ConnectStatusResponse": { 1057 "Result": { 1058 "Identifier": "MDVIK-G4PQB-STGMV-2YP4F-RSG44-RURCQ", 1059 "SignedData": { 1060 "unprotected": { 1061 "dig": "S512"}, 1062 "payload": " 1063 ewogICJDb25uZWN0aW9uUmVzdWx0IjogewogICAgIkRldmljZSI6IHsKICAgICAg 1064 IklkZW50aWZpZXIiOiAiTURWSUstRzRQUUItU1RHTVYtMllQNEYtUlNHNDQtUlVS 1065 ... 1066 Cm9HYzJwWlhfbHFibHZxemhhSzBMNFEifV19fX19fQ" 1067 , 1068 "signatures": [{ 1069 "header": { 1070 "kid": "MA7XV-ZOTDR-TXEDM-O2QP7-F7JTG-FGFFE"}, 1071 "protected": " 1072 ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiClRtQzNKakpZLS1oQjdRT0Fp 1073 bFg0WGtlQ3ZoVG02MEkwM3F0OVlKdkEwVUVRb0Y3X2M0ems2UnZoSWZGVm02NDIK 1074 bmM5b1k2Y3FIV0ZLdnBwZlJobm9qZyJ9" 1075 , 1076 "signature": " 1077 DMNIqoQOKRFCaJTjHcR72StoWTqsaL3Kx1tL3P0QjPsI1sfo6DQPTQu6RP5ZNksm 1078 UF60KHGheopm-RvlxZjZ5qfMwWdCmmiCzAj-yrQoLcTEkq523mzDqZNc03IME6jn 1079 MDE2_oGkoa5FyXeQAtPEsbB8n4Ib2FE7nkcehGufiP5RiKi0dxDJaMJaEiSfkIvf 1080 XjUfypzW6nk_ALwi898icIXBxNatlUwgiikrchdu3PcG1c-dKndQqsd2Z74_vjKq 1081 hUeyTiZT33CMEMt74Gi8dX4C78W2QxApUdGsv6EzWZmL9Jjr_p2neerfZfuTik8C 1082 Xp1aigh1A0uyY30RbEwSQw" 1083 }]}}}} 1085 Figure 25 1087 [Should probably unpack further.] 1089 3.4. Adding an application profile to a user profile 1091 Application profiles are published separately from the personal 1092 profile to which they are linked. This allows a device to be given 1093 administration capability for a particular application without 1094 granting administration capability for the profile itself and the 1095 ability to connect additional profiles and devices. 1097 Another advantage of this separation is that an application profile 1098 might be managed by a separate party. In an enterprise, the 1099 application profile for a user's corporate email account could be 1100 managed by the corporate IT department. 1102 A user MAY have multiple application profiles for the same 1103 application. If a user has three email accounts, they would have 1104 three email application profiles, one for each account. 1106 In this example, the user has requested a PaswordProfile to be 1107 created. When populated, this records the usernames and passwords 1108 for the various Web sites that the user has created accounts at and 1109 has requested the Web browser store in the Mesh. 1111 Unlike a traditional password management service, the data stored the 1112 Password Profile is encrypted end to end and can only be decrypted by 1113 the devices that hold a decryption key. 1115 {Example.PasswordProfile1} 1117 Figure 26 1119 The application profile is published to the Mesh in the same way as 1120 any other profile update, via a a Publish transaction: 1122 % Point = Example.Traces.Get (Example.LabelApplicationWeb1); 1123 {Point.Messages[0].String()} 1125 The service returns a status response. 1127 {Point.Messages[1].String()} 1129 Note that the degree of verification to be performed by the service 1130 when an application profile is published is an open question. 1132 Having created the application profile, the administration client 1133 adds it to the personal profile and publishes it: 1135 {Point.Messages[0].String()} 1137 Note that if the publication was to happen in the reverse order, with 1138 the personal profile being published before the application profile, 1139 the personal profile might be rejected by the portal for 1140 inconsistency as it links to a non existent application profile. 1141 Though the value of such a check is debatable. It might well be 1142 preferable to not make such checks as it permits an application 1143 profile to have a degree of anonymity. 1145 {Point.Messages[1].String()} 1147 3.5. Creating a recovery profile 1149 The Mesh invites users to put all their data eggs in one 1150 cryptographic basket. If the private keys in their master profile 1151 are lost, they could lose all their digital assets. 1153 The debate over the desirability of key escrow is a complex one. Not 1154 least because voluntary key escrow by the user to protect the user's 1155 digital assets is frequently conflated with mechanisms to support 1156 'Lawful Access' through government managed backdoors. 1158 Accidents happen and so do disasters. For most users and most 1159 applications, data loss is a much more important concern than data 1160 disclosure. The option of using a robust key recovery mechanism is 1161 therefore essential for use of strong cryptography is to become 1162 ubiquitous. 1164 There are of course circumstances in which some users may prefer to 1165 risk losing some of their data rather than risk disclosure. Since 1166 any key recovery infrastructure necessarily introduces the risk of 1167 coercion, the choice of whether to use key recovery or not is left to 1168 the user to decide. 1170 The Mesh permits users to escrow their private keys in the Mesh 1171 itself in an OfflineEscrowEntry. Such entries are encrypted using 1172 the strongest degree of encryption available under a symmetric key. 1173 The symmetric key is then in turn split using Shamir secret sharing 1174 using an n of m threshold scheme. 1176 The OfflineEscrowEntry identifier is a UDF fingerprint of the 1177 symmetric key used to encrypt the data. This guarantees that a party 1178 that has the decryption key has the ability to locate the 1179 corresponding Escrow entry. 1181 The OfflineEscrowEntry is published using the usual Publish 1182 transaction: 1184 {Point.Messages[0].String()} 1186 The response indicates success or failure: 1188 {Point.Messages[1].String()} 1190 3.6. Recovering a profile 1192 To recover a profile, the user MUST supply the necessary number of 1193 secret shares. These are then used to calculate the UDF fingerprint 1194 to use as the locator in a Get transaction: 1196 {Point.Messages[0].String()} 1198 If the transaction succeeds, GetResponse is returned with the 1199 requested data. 1201 {Point.Messages[1].String()} 1203 The client can now decrypt the OfflineEscrowEntry to recover the 1204 private key(s). 1206 4. Shared Classes 1208 The following classes are used as common elements in Mesh profile 1209 specifications.a 1211 4.1. Cryptographic Data Classes 1213 Most Mesh objects are signed and/or encrypted. For consistency all 1214 Mesh classes make use of the cryptographic data classes described in 1215 this section. 1217 4.1.1. Structure: PublicKey 1219 The PublicKey class is used to describe public key pairs and trust 1220 assertions associated with a public key. 1222 UDF: String (Optional) UDF fingerprint of the public key parameters/ 1224 X509Certificate: Binary (Optional) List of X.509 Certificates 1226 X509Chain: Binary [0..Many] X.509 Certificate chain. 1228 X509CSR: Binary (Optional) X.509 Certificate Signing Request. 1230 4.1.2. Structure: SignedData 1232 Container for JOSE signed data and related attributes. 1234 Data: Binary (Optional) The signed data 1236 4.1.3. Structure: EncryptedData 1238 Container for JOSE encrypted data and related attributes. 1240 Data: Binary (Optional) The encrypted data 1242 4.2. Common Application Classes 1244 4.2.1. Structure: Connection 1246 Describes network connection parameters for an application 1248 ServiceName: String (Optional) DNS address of the server 1250 Port: Integer (Optional) TCP/UDP Port number 1252 Prefix: String (Optional) DNS service prefix as described in 1253 [!RFC6335] 1255 Security: String [0..Many] Describes the security mode to use. 1256 Valid choices are Direct/Upgrade/None 1258 UserName: String (Optional) Username to present to the service for 1259 authentication 1261 Password: String (Optional) Password to present to the service for 1262 authentication 1264 URI: String (Optional) Service connection parameters in URI format 1266 Authentication: String (Optional) List of the supported/acceptable 1267 authentication mechanisms, preferred mechanism first. 1269 TimeOut: Integer (Optional) Service timeout in seconds. 1271 Polling: Boolean (Optional) If set, the client should poll the 1272 specified service intermittently for updates. 1274 5. Mesh Profile Objects 1276 5.1. Base Profile Objects 1278 5.1.1. Structure: Entry 1280 Base class for all Mesh Profile objects. 1282 Identifier: String (Optional) Globally unique identifier that 1283 remains constant for the lifetime of the entry. 1285 5.1.2. Structure: SignedProfile 1287 Inherits: Entry 1289 Contains a signed profile entry 1291 SignedData: JoseWebSignature (Optional) The signed profile. 1293 Note that each child of SignedProfile requires that the Payload 1294 field of the SignedData object contain an object of a specific 1295 type. For example, a SignedDeviceProfile object MUST contain a 1296 Payload field that contains a DeviceProfile object. 1298 Unauthenticated: Advice (Optional) Additional data that is not 1299 authenticated. 1301 5.1.3. Structure: Advice 1303 Additional data bound to a signed profile that is not authenticated. 1305 Default: DateTime (Optional) If specified, the profile was the 1306 default profile at the specified date and time. The current 1307 default for that type of profile is the profile with the most 1308 recent Default timestamp. 1310 5.1.4. Structure: PortalAdvice 1312 Inherits: Advice 1314 Inherits: Advice 1316 PortalAddress: String [0..Many] A portal address at which this 1317 profile is registered. 1319 5.1.5. Structure: Profile 1321 Inherits: Entry 1323 Parent class from which all profile types are derived 1325 Names: String [0..Many] Fingerprints of index terms for profile 1326 retrieval. The use of the fingerprint of the name rather than the 1327 name itself is a precaution against enumeration attacks and other 1328 forms of abuse. 1330 Updated: DateTime (Optional) The time instant the profile was last 1331 modified. 1333 NotaryToken: String (Optional) A Uniform Notary Token providing 1334 evidence that a signature was performed after the notary token was 1335 created. 1337 5.2. Device Profile Classes 1339 5.2.1. Structure: SignedDeviceProfile 1341 Inherits: SignedProfile 1343 Contains a signed device profile 1345 [No fields] 1347 5.2.2. Structure: DeviceProfile 1349 Inherits: Profile 1351 Describes a mesh device. 1353 Description: String (Optional) Description of the device 1355 DeviceSignatureKey: PublicKey (Optional) Key used to sign 1356 certificates for the DAK and DEK. The fingerprint of the DSK is 1357 the UniqueID of the Device Profile 1359 DeviceAuthenticationKey: PublicKey (Optional) Key used to 1360 authenticate requests made by the device. 1362 DeviceEncryptiontionKey: PublicKey (Optional) Key used to pass 1363 encrypted data to the device such as a DeviceUseEntry 1365 5.2.3. Structure: DevicePrivateProfile 1367 Private portion of device encryption profile. 1369 DeviceSignatureKey: Key (Optional) Private portion of the 1370 DeviceSignatureKey 1372 DeviceAuthenticationKey: Key (Optional) Private portion of the 1373 DeviceAuthenticationKey 1375 DeviceEncryptiontionKey: Key (Optional) Private portion of the 1376 DeviceEncryptiontionKey 1378 5.3. Master Profile Objects 1380 5.3.1. Structure: SignedMasterProfile 1382 Inherits: SignedProfile 1384 Contains a signed Personal master profile 1386 [No fields] 1388 5.3.2. Structure: MasterProfile 1390 Inherits: Profile 1392 Describes the long term parameters associated with a personal 1393 profile. 1395 MasterSignatureKey: PublicKey (Optional) The root of trust for the 1396 Personal PKI, the public key of the PMSK is presented as a self- 1397 signed X.509v3 certificate with Certificate Signing use enabled. 1398 The PMSK is used to sign certificates for the PMEK, POSK and PKEK 1399 keys. 1401 MasterEscrowKeys: PublicKey [0..Many] A Personal Profile MAY contain 1402 one or more PMEK keys to enable escrow of private keys used for 1403 stored data. 1405 OnlineSignatureKeys: PublicKey [0..Many] A Personal profile contains 1406 at least one POSK which is used to sign device administration 1407 application profiles. 1409 5.4. Personal Profile Objects 1411 5.4.1. Structure: SignedPersonalProfile 1413 Inherits: SignedProfile 1415 Contains a signed Personal current profile 1417 [No fields] 1419 5.4.2. Structure: PersonalProfile 1421 Inherits: Profile 1423 Describes the current applications and devices connected to a 1424 personal master profile. 1426 SignedMasterProfile: SignedMasterProfile (Optional) The 1427 corresponding master profile. The profile MUST be signed by the 1428 PMSK. 1430 Devices: SignedDeviceProfile [0..Many] The set of device profiles 1431 connected to the profile. The profile MUST be signed by the DSK 1432 in the profile. 1434 Applications: ApplicationProfileEntry [0..Many] Application profiles 1435 connected to this profile. 1437 5.4.3. Structure: ApplicationProfileEntry 1439 Personal profile entry describing the privileges of specific devices. 1441 Identifier: String (Optional) The unique identifier of the 1442 application 1444 Type: String (Optional) The application type 1446 Friendly: String (Optional) Optional friendly name identifying the 1447 application. 1449 AdminDeviceUDF: String [0..Many] List of devices authorized to sign 1450 application profiles 1452 DecryptDeviceUDF: String [0..Many] List of devices authorized to 1453 read private parts of application profiles. 1455 5.5. Application Profile Objects 1457 5.5.1. Structure: SignedApplicationProfile 1459 Inherits: SignedProfile 1461 Contains a signed device profile 1463 [No fields] 1465 5.5.2. Structure: ApplicationProfile 1467 Inherits: Profile 1469 Parent class from which all application profiles inherit. 1471 [No fields] 1473 5.5.3. Structure: ApplicationProfilePrivate 1475 Inherits: Entry 1477 The base class for all private profiles. 1479 [No fields] 1481 5.5.4. Structure: ApplicationDevicePublic 1483 Inherits: Entry 1485 Describes the public per device data 1487 DeviceDescription: String (Optional) Description of the device for 1488 convenience of the user. 1490 DeviceUDF: String (Optional) Fingerprint of device that this key 1491 corresponds to. 1493 5.5.5. Structure: ApplicationDevicePrivate 1495 Inherits: Entry 1497 Describes the private per device data 1499 [No fields] 1501 5.6. Key Escrow Objects 1503 5.6.1. Structure: EscrowEntry 1505 Inherits: Entry 1507 Contains escrowed data 1509 EncryptedData: JoseWebEncryption (Optional) The encrypted escrow 1510 data 1512 5.6.2. Structure: OfflineEscrowEntry 1514 Inherits: EscrowEntry 1516 Contains data escrowed using the offline escrow mechanism. 1518 [No fields] 1520 5.6.3. Structure: OnlineEscrowEntry 1522 Inherits: EscrowEntry 1524 Contains data escrowed using the online escrow mechanism. 1526 [No fields] 1528 5.6.4. Structure: EscrowedKeySet 1530 A set of escrowed keys. 1532 [No fields] 1534 6. Portal Connection 1536 6.1. Connection Request and Response Structures 1538 6.1.1. Structure: ConnectionRequest 1540 Describes a connection request. 1542 ParentUDF: String (Optional) UDF of Mesh Profile to which connection 1543 is requested. 1545 Device: SignedDeviceProfile (Optional) The Device profile to be 1546 connected 1548 6.1.2. Structure: SignedConnectionRequest 1550 Inherits: SignedProfile 1552 Contains a ConnectionRequest signed by the corresponding device 1553 signature key. 1555 [No fields] 1557 6.1.3. Structure: ConnectionResult 1559 Describes the result of a connection request. 1561 Inherits: ConnectionRequest 1563 Inherits: ConnectionRequest 1565 Result: String (Optional) The result of the connection request. 1566 Valid responses are: Accepted, Refused, Query. 1568 6.1.4. Structure: SignedConnectionResult 1570 Inherits: SignedProfile 1572 Contains a signed connection result 1574 [No fields] 1576 7. Mesh Portal Service Reference 1578 SRV Prefix: _mmm._tcp 1580 SRV Prefix: _mmm._tcp 1582 HTTP Well Known Service Prefix: /.well-known/mmm 1584 Every Mesh Portal Service transaction consists of exactly one request 1585 followed by exactly one response. Mesh Service transactions MAY 1586 cause modification of the data stored in the Mesh Portal or the Mesh 1587 itself but do not cause changes to the connection state. The 1588 protocol itself is thus idempotent. There is no set sequence in 1589 which operations are required to be performed. It is not necessary 1590 to perform a Hello transaction prior to a ValidateAccount, Publish or 1591 any other transaction. 1593 7.1. Request Messages 1595 A Mesh Portal Service request consists of a payload object that 1596 inherits from the MeshRequest class. When using the HTTP binding, 1597 the request MUST specify the portal DNS address in the HTTP Host 1598 field. 1600 7.1.1. Message: MeshRequest 1602 Base class for all request messages. 1604 Portal: String (Optional) Name of the Mesh Portal Service to which 1605 the request is directed. 1607 7.2. Response Messages 1609 A Mesh Portal Service response consists of a payload object that 1610 inherits from the MeshResponse class. When using the HTTP binding, 1611 the response SHOULD report the Status response code in the HTTP 1612 response message. However the response code returned in the payload 1613 object MUST always be considered authoritative. 1615 7.2.1. Message: MeshResponse 1617 Base class for all response messages. Contains only the status code 1618 and status description fields. 1620 [No fields] 1622 7.3. Imported Objects 1624 The Mesh Service protocol makes use of JSON objects defined in the 1625 JOSE Signatgure and Encryption specifications. 1627 7.4. Common Structures 1629 The following common structures are used in the protocol messages: 1631 7.4.1. Structure: KeyValue 1633 Describes a Key/Value structure used to make queries for records 1634 matching one or more selection criteria. 1636 Key: String (Optional) The data retrieval key. 1638 Value: String (Optional) The data value to match. 1640 7.4.2. Structure: SearchConstraints 1642 Specifies constraints to be applied to a search result. These allow 1643 a client to limit the number of records returned, the quantity of 1644 data returned, the earliest and latest data returned, etc. 1646 NotBefore: DateTime (Optional) Only data published on or after the 1647 specified time instant is requested. 1649 Before: DateTime (Optional) Only data published before the specified 1650 time instant is requested. This excludes data published at the 1651 specified time instant. 1653 MaxEntries: Integer (Optional) Maximum number of data entries to 1654 return. 1656 MaxBytes: Integer (Optional) Maximum number of data bytes to return. 1658 PageKey: String (Optional) Specifies a page key returned in a 1659 previous search operation in which the number of responses 1660 exceeded the specified bounds. 1662 When a page key is specified, all the other search parameters 1663 except for MaxEntries and MaxBytes are ignored and the service 1664 returns the next set of data responding to the earlier query. 1666 7.5. Transaction: Hello 1668 Request: HelloRequest 1670 Request: HelloRequest 1672 Response: HelloResponse 1674 Report service and version information. 1676 The Hello transaction provides a means of determining which protocol 1677 versions, message encodings and transport protocols are supported by 1678 the service. 1680 7.6. Transaction: ValidateAccount 1682 Request: ValidateRequest 1684 Request: ValidateRequest 1686 Response: ValidateResponse 1687 Request validation of a proposed name for a new account. 1689 For validation of a user's account name during profile creation. 1691 7.6.1. Message: ValidateRequest 1693 Inherits: MeshRequest 1695 Describes the proposed account properties. Currently, these are 1696 limited to the account name but could be extended in future versions 1697 of the protocol. 1699 Account: String (Optional) Account name requested 1701 Reserve: Boolean (Optional) If true, request a reservation for the 1702 specified account name. Note that the service is not obliged to 1703 honor reservation requests. 1705 Language: String [0..Many] List of ISO language codes in order of 1706 preference. For creating explanatory text. 1708 7.6.2. Message: ValidateResponse 1710 Inherits: MeshResponse 1712 States whether the proposed account properties are acceptable and 1713 (optional) returns an indication of what properties are valid. 1715 Note that receiving a 'Valid' responseto a Validate Request does not 1716 guarantee creation of the account. In addition to the possibility 1717 that the account namecould be requested by another user between the 1718 Validate and Create transactions, a portal service MAY perform more 1719 stringent validation criteria when an account is actually being 1720 created. For example, checking with the authoritative list of 1721 current accounts rather than a cached copy. 1723 Valid: Boolean (Optional) If true, the specified account identifier 1724 is acceptable. If false, the account identifier is rejected. 1726 Minimum: Integer (Optional) Specifies the minimum length of an 1727 account name. 1729 Maximum: Integer (Optional) Specifies the maximum length of an 1730 account name. 1732 InvalidCharacters: String (Optional) A list of characters that the 1733 service does not accept in account names. The list of characters 1734 MAY not be exhaustive but SHOULD include any illegal characters in 1735 the proposed account name. 1737 Reason: String (Optional) Text explaining the reason an account name 1738 was rejected. 1740 7.7. Transaction: CreateAccount 1742 Request: CreateRequest 1744 Request: CreateRequest 1746 Response: CreateResponse 1748 Request creation of a new portal account. 1750 Unlike a profile, a mesh account is specific to a particular Mesh 1751 portal. A mesh account must be created and accepted before a profile 1752 can be published. 1754 7.7.1. Message: CreateRequest 1756 Request creation of a new portal account. The request specifies the 1757 requested account identifier and the Mesh profile to be associated 1758 with the account. 1760 Inherits: MeshRequest 1762 Inherits: MeshRequest 1764 Account: String (Optional) Account identifier requested. 1766 7.7.2. Message: CreateResponse 1768 Inherits: MeshResponse 1770 Reports the success or failure of a Create transaction. 1772 [No fields] 1774 7.8. Transaction: DeleteAccount 1776 Request: DeleteRequest 1778 Request: DeleteRequest 1780 Response: DeleteResponse 1781 Request deletion of a portal account. 1783 Deletes a portal account but not the underlying profile. Once 1784 registered, profiles are permanent. 1786 7.8.1. Message: DeleteRequest 1788 Request deletion of a new portal account. The request specifies the 1789 requested account identifier. 1791 Inherits: MeshRequest 1793 Inherits: MeshRequest 1795 Account: String (Optional) Account identifier to be deleted. 1797 7.8.2. Message: DeleteResponse 1799 Inherits: MeshResponse 1801 Reports the success or failure of a Delete transaction. 1803 [No fields] 1805 7.9. Transaction: Get 1807 Request: GetRequest 1809 Request: GetRequest 1811 Response: GetResponse 1813 Search for data in the mesh that matches a set of properties 1814 described by a sequence of key/value pairs. 1816 7.9.1. Message: GetRequest 1818 Describes the Portal or Mesh data to be retreived. 1820 Inherits: MeshRequest 1822 Inherits: MeshRequest 1824 Identifier: String (Optional) Lookup by profile ID 1826 Account: String (Optional) Lookup by Account ID 1827 KeyValues: KeyValue [0..Many] List of KeyValue pairs specifying the 1828 conditions to be met 1830 SearchConstraints: SearchConstraints (Optional) Constrain the search 1831 to a specific time interval and/or limit the number and/or total 1832 size of data records returned. 1834 Multiple: Boolean (Optional) If true return multiple responses if 1835 available 1837 Full: Boolean (Optional) If true, the client requests that the full 1838 Mesh data record be returned containing both the Mesh entry itself 1839 and the Mesh metadata that allows the date and time of the 1840 publication of the Mesh entry to be verified. 1842 7.9.2. Message: GetResponse 1844 Reports the success or failure of a Get transaction. If a Mesh entry 1845 matching the specified profile is found, containsthe list of entries 1846 matching the request. 1848 Inherits: MeshResponse 1850 Inherits: MeshResponse 1852 DataItems: DataItem [0..Many] List of mesh data records matching the 1853 request. 1855 PageKey: String (Optional) If non-null, indicates that the number 1856 and/or size of the data records returned exceeds either the 1857 SearchConstraints specified in the request or internal server 1858 limits. 1860 7.10. Transaction: Publish 1862 Request: PublishRequest 1864 Request: PublishRequest 1866 Response: PublishResponse 1868 Publish a profile or key escrow entry to the mesh. 1870 7.10.1. Message: PublishRequest 1872 Requests publication of the specified Mesh entry. 1874 Inherits: MeshRequest 1876 [No fields] 1878 7.10.2. Message: PublishResponse 1880 Reports the success or failure of a Publish transaction. 1882 Inherits: MeshResponse 1884 [No fields] 1886 7.11. Transaction: Status 1888 Request: StatusRequest 1890 Request: StatusRequest 1892 Response: StatusResponse 1894 Request the current status of the mesh as seen by the portal to which 1895 it is directed. 1897 The response to the status request contains the last signed 1898 checkpoint and proof chains for each of the peer portals that have 1899 been checkpointed. 1901 [Not currently implemented] 1903 7.11.1. Message: StatusRequest 1905 Inherits: MeshRequest 1907 Initiates a status transaction. 1909 [No fields] 1911 7.11.2. Message: StatusResponse 1913 Reports the success or failure of a Status transaction. 1915 Inherits: MeshResponse 1917 Inherits: MeshResponse 1919 LastWriteTime: DateTime (Optional) Time that the last write update 1920 was made to the Mesh 1922 LastCheckpointTime: DateTime (Optional) Time that the last Mesh 1923 checkpoint was calculated. 1925 NextCheckpointTime: DateTime (Optional) Time at which the next Mesh 1926 checkpoint should be calculated. 1928 CheckpointValue: String (Optional) Last checkpoint value. 1930 7.12. Transaction: ConnectStart 1932 Request: ConnectStartRequest 1934 Request: ConnectStartRequest 1936 Response: ConnectStartResponse 1938 Request connection of a new device to a mesh profile 1940 7.12.1. Message: ConnectStartRequest 1942 Inherits: MeshRequest 1944 Initial device connection request. 1946 SignedRequest: SignedConnectionRequest (Optional) Device connection 1947 request signed by thesignature key of the device requesting 1948 connection. 1950 AccountID: String (Optional) Account identifier of account to which 1951 the device is requesting connection. 1953 7.12.2. Message: ConnectStartResponse 1955 Reports the success or failure of a ConnectStart transaction. 1957 Inherits: MeshRequest 1959 [No fields] 1961 7.13. Transaction: ConnectStatus 1963 Request: ConnectStatusRequest 1965 Request: ConnectStatusRequest 1967 Response: ConnectStatusResponse 1969 Request status of pending connection request of a new device to a 1970 mesh profile 1972 7.13.1. Message: ConnectStatusRequest 1974 Inherits: MeshRequest 1976 Request status information for a pending request posted previously. 1978 AccountID: String (Optional) Account identifier for which pending 1979 connection information is requested. 1981 DeviceID: String (Optional) Device identifier of device requesting 1982 status information. 1984 7.13.2. Message: ConnectStatusResponse 1986 Reports the success or failure of a ConnectStatus transaction. 1988 Inherits: MeshRequest 1990 Inherits: MeshRequest 1992 Result: SignedConnectionResult (Optional) The signed 1993 ConnectionResult object. 1995 7.14. Transaction: ConnectPending 1997 Request: ConnectPendingRequest 1999 Request: ConnectPendingRequest 2001 Response: ConnectPendingResponse 2003 Request a list of pending requests for an administration profile. 2005 7.14.1. Message: ConnectPendingRequest 2007 Inherits: MeshRequest 2009 Specify the criteria for pending requests. 2011 AccountID: String (Optional) The account identifier of the account 2012 for which pending connection requests are requested. 2014 SearchConstraints: SearchConstraints (Optional) Constrain the search 2015 to a specific time interval and/or limit the number and/or total 2016 size of data records returned. 2018 7.14.2. Message: ConnectPendingResponse 2020 Reports the success or failure of a ConnectPending transaction. 2022 Inherits: MeshRequest 2024 Inherits: MeshRequest 2026 Pending: SignedConnectionRequest [0..Many] A list of pending 2027 requests satisfying the criteria set out in the request. 2029 PageKey: String (Optional) If non-null, indicates that the number 2030 and/or size of the data records returned exceeds either the 2031 SearchConstraints specified in the request or internal server 2032 limits. 2034 7.15. Transaction: ConnectComplete 2036 Request: ConnectCompleteRequest 2038 Request: ConnectCompleteRequest 2040 Response: ConnectCompleteResponse 2042 Post response to a pending connection request. 2044 7.15.1. Message: ConnectCompleteRequest 2046 Reports the success or failure of a ConnectComplete transaction. 2048 Inherits: MeshRequest 2050 Inherits: MeshRequest 2052 Result: SignedConnectionResult (Optional) The connection result to 2053 be posted to the portal. The result MUST be signed by a valid 2054 administration key for the Mesh profile. 2056 AccountID: String (Optional) The account identifier to which the 2057 connection result is posted. 2059 7.15.2. Message: ConnectCompleteResponse 2061 Inherits: MeshRequest 2063 Reports the success or failure of a ConnectComplete transaction. 2065 [No fields] 2067 7.16. Transaction: Transfer 2069 Request: TransferRequest 2071 Request: TransferRequest 2073 Response: TransferResponse 2075 Perform a bulk transfer of the log between the specified transaction 2076 identifiers. Requires appropriate authorization 2078 [Not currently implemented] 2080 7.16.1. Message: TransferRequest 2082 Request a bulk transfer of the log between the specified transaction 2083 identifiers. Requires appropriate authorization 2085 Inherits: MeshRequest 2087 Inherits: MeshRequest 2089 SearchConstraints: SearchConstraints (Optional) Constrain the search 2090 to a specific time interval and/or limit the number and/or total 2091 size of data records returned. 2093 7.16.2. Message: TransferResponse 2095 Inherits: MeshResponse 2097 Reports the success or failure of a Transfer transaction. If 2098 successful, contains the list of Mesh records to be transferred. 2100 DataItems: DataItem [0..Many] List of mesh data records matching the 2101 request. 2103 PageKey: String (Optional) If non-null, indicates that the number 2104 and/or size of the data records returned exceeds either the 2105 SearchConstraints specified in the request or internal server 2106 limits. 2108 8. Security Considerations 2110 9. IANA Considerations 2112 All the IANA considerations for the Mesh documents are specified in 2113 this document 2115 10. Acknowledgements 2117 11. References 2119 11.1. Normative References 2121 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2122 Requirement Levels", BCP 14, RFC 2119, 2123 DOI 10.17487/RFC2119, March 1997. 2125 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 2126 Cheshire, "Internet Assigned Numbers Authority (IANA) 2127 Procedures for the Management of the Service Name and 2128 Transport Protocol Port Number Registry", BCP 165, 2129 RFC 6335, DOI 10.17487/RFC6335, August 2011. 2131 11.2. Informative References 2133 [draft-hallambaker-mesh-architecture] 2134 Hallam-Baker, P., "Mathematical Mesh: Architecture", 2135 draft-hallambaker-mesh-architecture-03 (work in progress), 2136 May 2017. 2138 [draft-hallambaker-mesh-developer] 2139 Hallam-Baker, P., "Mathematical Mesh: Reference 2140 Implementation", draft-hallambaker-mesh-developer-04 (work 2141 in progress), September 2017. 2143 [RFC822] Crocker, D., "STANDARD FOR THE FORMAT OF ARPA INTERNET 2144 TEXT MESSAGES", STD 11, RFC 822, DOI 10.17487/RFC0822, 2145 August 1982. 2147 11.3. URIs 2149 [1] http://prismproof.org/Documents/draft-hallambaker-mesh- 2150 reference.html 2152 Author's Address 2154 Phillip Hallam-Baker 2155 Comodo Group Inc. 2157 Email: philliph@comodo.com