Network Working Group P. Hallam-Baker Internet-Draft October 23, 2019 Intended status: Informational Expires: April 25, 2020 Mathematical Mesh 3.0 Part IV: Schema Reference draft-hallambaker-mesh-schema-04 Abstract The Mathematical Mesh 'The Mesh' is an end-to-end secure infrastructure that facilitates the exchange of configuration and credential data between multiple user devices. The core protocols of the Mesh are described with examples of common use cases and reference data. [Note to Readers] Discussion of this draft takes place on the MATHMESH mailing list (mathmesh@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=mathmesh. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh-schema.html [1] . Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 25, 2020. Hallam-Baker Expires April 25, 2020 [Page 1] Internet-Draft Mesh Schema Reference October 2019 Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Related Specifications . . . . . . . . . . . . . . . . . 5 2.4. Implementation Status . . . . . . . . . . . . . . . . . . 6 3. Mesh Assertions . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Mesh Profiles . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Mesh Connections . . . . . . . . . . . . . . . . . . . . 8 3.4. Mesh Private Declarations . . . . . . . . . . . . . . . . 8 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Device Management . . . . . . . . . . . . . . . . . . . . 9 4.1.1. Master Profile . . . . . . . . . . . . . . . . . . . 9 4.1.2. Mesh Devices . . . . . . . . . . . . . . . . . . . . 11 4.2. Mesh Accounts . . . . . . . . . . . . . . . . . . . . . . 19 4.2.1. Creating a ProfileAccount . . . . . . . . . . . . . . 21 4.2.2. Connecting a Device to an Account . . . . . . . . . . 21 4.2.3. Binding and Account to a Service . . . . . . . . . . 22 4.3. Mesh Services . . . . . . . . . . . . . . . . . . . . . . 22 4.3.1. Creating a ProfileService . . . . . . . . . . . . . . 23 4.3.2. Creating a ProfileHost . . . . . . . . . . . . . . . 24 4.3.3. Creating a ConnectionHost . . . . . . . . . . . . . . 24 4.4. Mesh Messaging . . . . . . . . . . . . . . . . . . . . . 24 4.4.1. Traffic Analysis . . . . . . . . . . . . . . . . . . 25 5. Mesh Catalogs . . . . . . . . . . . . . . . . . . . . . . . . 26 5.1. Application . . . . . . . . . . . . . . . . . . . . . . . 27 5.1.1. Mesh Account . . . . . . . . . . . . . . . . . . . . 27 5.1.2. SSH . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.1.3. Mail . . . . . . . . . . . . . . . . . . . . . . . . 28 5.2. Device . . . . . . . . . . . . . . . . . . . . . . . . . 28 Hallam-Baker Expires April 25, 2020 [Page 2] Internet-Draft Mesh Schema Reference October 2019 5.3. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 28 5.4. Credential . . . . . . . . . . . . . . . . . . . . . . . 29 5.5. Bookmark . . . . . . . . . . . . . . . . . . . . . . . . 29 5.6. Task . . . . . . . . . . . . . . . . . . . . . . . . . . 29 5.7. Network . . . . . . . . . . . . . . . . . . . . . . . . . 30 6. Mesh Messages . . . . . . . . . . . . . . . . . . . . . . . . 30 6.1. Completion . . . . . . . . . . . . . . . . . . . . . . . 30 6.2. Connection . . . . . . . . . . . . . . . . . . . . . . . 30 6.3. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 31 6.4. Confirmation . . . . . . . . . . . . . . . . . . . . . . 32 7. Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 7.1. Shared Classes . . . . . . . . . . . . . . . . . . . . . 33 7.1.1. Classes describing keys . . . . . . . . . . . . . . . 33 7.1.2. Structure: PublicKey . . . . . . . . . . . . . . . . 33 7.1.3. Structure: KeyComposite . . . . . . . . . . . . . . . 33 7.1.4. Structure: KeyOverlay . . . . . . . . . . . . . . . . 33 7.1.5. Structure: EscrowedKeySet . . . . . . . . . . . . . . 33 7.1.6. Structure: DeviceRecryptionKey . . . . . . . . . . . 34 7.2. Assertion classes . . . . . . . . . . . . . . . . . . . . 34 7.2.1. Structure: Assertion . . . . . . . . . . . . . . . . 34 7.2.2. Structure: Condition . . . . . . . . . . . . . . . . 34 7.2.3. Profile Classes . . . . . . . . . . . . . . . . . . . 34 7.2.4. Structure: Profile . . . . . . . . . . . . . . . . . 34 7.2.5. Structure: ProfileMesh . . . . . . . . . . . . . . . 35 7.2.6. Structure: ProfileDevice . . . . . . . . . . . . . . 35 7.2.7. Structure: ProfileService . . . . . . . . . . . . . . 35 7.2.8. Structure: ProfileAccount . . . . . . . . . . . . . . 36 7.2.9. Structure: ProfileGroup . . . . . . . . . . . . . . . 36 7.2.10. Structure: ProfileHost . . . . . . . . . . . . . . . 36 7.2.11. Connection Classes . . . . . . . . . . . . . . . . . 36 7.2.12. Structure: Connection . . . . . . . . . . . . . . . . 36 7.2.13. Structure: Permission . . . . . . . . . . . . . . . . 37 7.2.14. Structure: ConnectionDevice . . . . . . . . . . . . . 37 7.2.15. Structure: ConnectionAccount . . . . . . . . . . . . 37 7.2.16. Structure: ConnectionService . . . . . . . . . . . . 38 7.2.17. Structure: ConnectionHost . . . . . . . . . . . . . . 38 7.2.18. Structure: ConnectionApplication . . . . . . . . . . 38 7.2.19. Activation Classes . . . . . . . . . . . . . . . . . 38 7.2.20. Structure: Activation . . . . . . . . . . . . . . . . 38 7.2.21. Structure: ActivationDevice . . . . . . . . . . . . . 38 7.2.22. Structure: ActivationAccount . . . . . . . . . . . . 39 7.3. Cataloged items . . . . . . . . . . . . . . . . . . . . . 39 7.3.1. Data Structures . . . . . . . . . . . . . . . . . . . 39 7.3.2. Structure: Contact . . . . . . . . . . . . . . . . . 39 7.3.3. Structure: Role . . . . . . . . . . . . . . . . . . . 40 7.3.4. Structure: Address . . . . . . . . . . . . . . . . . 41 7.3.5. Structure: Location . . . . . . . . . . . . . . . . . 41 7.3.6. Structure: Reference . . . . . . . . . . . . . . . . 41 Hallam-Baker Expires April 25, 2020 [Page 3] Internet-Draft Mesh Schema Reference October 2019 7.3.7. Structure: Task . . . . . . . . . . . . . . . . . . . 42 7.4. Catalog Entries . . . . . . . . . . . . . . . . . . . . . 43 7.4.1. Structure: CatalogedEntry . . . . . . . . . . . . . . 43 7.4.2. Structure: CatalogedDevice . . . . . . . . . . . . . 43 7.4.3. Structure: AccountEntry . . . . . . . . . . . . . . . 43 7.4.4. Structure: CatalogedCredential . . . . . . . . . . . 44 7.4.5. Structure: CatalogedNetwork . . . . . . . . . . . . . 44 7.4.6. Structure: CatalogedContact . . . . . . . . . . . . . 44 7.4.7. Structure: CatalogedContactRecryption . . . . . . . . 45 7.4.8. Structure: CatalogedBookmark . . . . . . . . . . . . 45 7.4.9. Structure: CatalogedTask . . . . . . . . . . . . . . 45 7.4.10. Structure: CatalogedApplication . . . . . . . . . . . 46 7.4.11. Structure: CatalogedMember . . . . . . . . . . . . . 46 7.4.12. Structure: CatalogedGroup . . . . . . . . . . . . . . 46 7.4.13. Structure: CatalogedApplicationSSH . . . . . . . . . 46 7.4.14. Structure: CatalogedApplicationMail . . . . . . . . . 46 7.4.15. Structure: CatalogedApplicationNetwork . . . . . . . 46 7.5. Messages . . . . . . . . . . . . . . . . . . . . . . . . 46 7.5.1. Structure: Message . . . . . . . . . . . . . . . . . 46 7.5.2. Structure: MessageComplete . . . . . . . . . . . . . 47 7.5.3. Structure: MessagePIN . . . . . . . . . . . . . . . . 47 7.5.4. Structure: RequestConnection . . . . . . . . . . . . 47 7.5.5. Structure: AcknowledgeConnection . . . . . . . . . . 48 7.5.6. Structure: OfferGroup . . . . . . . . . . . . . . . . 48 7.5.7. Structure: RequestContact . . . . . . . . . . . . . . 48 7.5.8. Structure: ReplyContact . . . . . . . . . . . . . . . 49 7.5.9. Structure: RequestConfirmation . . . . . . . . . . . 49 7.5.10. Structure: ResponseConfirmation . . . . . . . . . . . 49 7.5.11. Structure: RequestTask . . . . . . . . . . . . . . . 49 8. Security Considerations . . . . . . . . . . . . . . . . . . . 49 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 49 11. Appendix A: Example Container Organization (not normative) . 50 11.1. Device . . . . . . . . . . . . . . . . . . . . . . . . . 50 11.1.1. Creating a new Mesh . . . . . . . . . . . . . . . . 50 11.1.2. Adding an Account . . . . . . . . . . . . . . . . . 50 11.1.3. Adding a Device . . . . . . . . . . . . . . . . . . 50 11.2. Service . . . . . . . . . . . . . . . . . . . . . . . . 51 11.2.1. Creating a Service . . . . . . . . . . . . . . . . . 51 11.2.2. Adding an Account . . . . . . . . . . . . . . . . . 51 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 12.1. Normative References . . . . . . . . . . . . . . . . . . 51 12.2. Informative References . . . . . . . . . . . . . . . . . 52 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 52 Hallam-Baker Expires April 25, 2020 [Page 4] Internet-Draft Mesh Schema Reference October 2019 1. Introduction This document describes the data structures of the Mathematical Mesh with illustrative examples. For an overview of the Mesh objectives and architecture, consult the accompanying Architecture Guide [draft-hallambaker-mesh-architecture] . For information on the implementation of the Mesh Service protocol, consult the accompanying Protocol Reference [draft-hallambaker-mesh-protocol] This document has two main sections. The first section presents examples of the Mesh assertions, catalog entry and messages in use. The second section contains the schema reference. All the material in both sections is generated from the Mesh reference implementation [draft-hallambaker-mesh-developer] . Although some of the services described in this document could be used to replace existing Internet protocols including FTP and SMTP, the principal value of any communication protocol lies in the size of the audience it allows them to communicate with. Thus, while the Mesh Messaging service is designed to support efficient and reliable transfer of messages ranging in size from a few bytes to multiple terabytes, the near-term applications of these services will be to applications that are not adequately supported by existing protocols if at all. 2. Definitions This section presents the related specifications and standard, the terms that are used as terms of art within the documents and the terms used as requirements language. 2.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] . 2.2. Defined Terms The terms of art used in this document are described in the Mesh Architecture Guide [draft-hallambaker-mesh-architecture] . 2.3. Related Specifications The architecture of the Mathematical Mesh is described in the Mesh Architecture Guide [draft-hallambaker-mesh-architecture] . The Mesh documentation set and related specifications are described in this document. Hallam-Baker Expires April 25, 2020 [Page 5] Internet-Draft Mesh Schema Reference October 2019 2.4. Implementation Status The implementation status of the reference code base is described in the companion document [draft-hallambaker-mesh-developer] . 3. Mesh Assertions Mesh Assertions are signed DARE Envelopes that contain one of more claims. Mesh Assertions provide the basis for trust in the Mathematical Mesh. Mesh Assertions are divided into two classes. Mesh Profiles are self-signed assertions. Assertions that are not self-signed are called declarations. The only type of declaration currently defined is a Connection Declaration describing the connection of one profile to another. Currently, five profile and four connection types are defined: [[This figure is not viewable in this format. The figure is available at http://mathmesh.com/Documents/draft-hallambaker-mesh- schema.html [2].]] Profiles And Connections 3.1. Encoding The payload of a Mesh Assertion is a JSON encoded object that is a subclass of the Assertion class which defines the following fields: Identifier An identifier for the assertion. Updated The date and time at which the assertion was issued or last updated NotaryToken An assertion may optionally contain one or more notary tokens issued by a Mesh Notary service. These establish a proof that the assertion was signed after the date the notary token was created. Conditions A list of conditions that MAY be used to verify the status of the assertion if the relying party requires. The implementation of the NotaryToken and Conditions mechanisms is to be specified in [draft-hallambaker-mesh-notary] at a future date. Note that the implementation of Conditions differs significantly from that of SAML. Relying parties are required to process condition Hallam-Baker Expires April 25, 2020 [Page 6] Internet-Draft Mesh Schema Reference October 2019 clauses in a SAML assertion to determine validity. Mesh Relying parties MAY verify the conditions clauses or rely on the trustworthiness of the provider. The reason for weakening the processing of conditions clauses in the Mesh is that it is only ever possible to validate a conditions clause of any type relative to a ground truth. In SAML applications, the relying party almost invariably has access to an independent source of ground truth. A Mesh device connected to a Mesh Service does not. Thus the types of verification that can be achieved in practice are limited to verifying the consistency of current and previous statements from the Mesh Service. 3.2. Mesh Profiles Mesh Profiles perform a similar role to X.509v3 certificates but with important differences: o Profiles describe credentials, they do not make identity statements o Profiles do not expire, there is therefore no need to support renewal processing. o Profiles may be modified over time, the current and past status of a profile being recorded in an append only log. Profiles provide the axioms of trust for the Mesh PKI. Unlike in the PKIX model in which all trust flows from axioms of trust held by a small number of Certificate Authorities, every part in the Mesh contributes their own axiom of trust. It should be noted however that the role of Certificate Authorities is redefined rather than eliminated. Rather than making assertions whose subject is represented by identities which are inherently mutable and subjective, Certificate Authorities can now make assertions about immutable cryptographic keys. Every Profile MUST contain a SignatureKey field and MUST be signed by the key specified in that field. A Profile is valid if and only if: o There is a SignatureKey field. o The profile is signed under the key specified in the SignatureKey field. Hallam-Baker Expires April 25, 2020 [Page 7] Internet-Draft Mesh Schema Reference October 2019 A profile has the status current if and only if: o The Profile is valid o Every Conditions clause in the profile is understood by the relying party and evaluates to true. 3.3. Mesh Connections 3.4. Mesh Private Declarations 4. Architecture The Mesh architecture has four principal components: Mesh Device Management Binds a collection of devices that the owner of the Mesh uses together to function as a single personal Mesh. Mesh Account Contains all the information (contacts, calendar entries, inbound and outbound messages, etc.) related to a particular persona used by the owner. Mesh Service Provides a service identifier (e.g. alice@example.com) through which devices and other Mesh users may interact with a Mesh Account. Mesh Messaging Allows short messages (less than 32KB) to be exchanged between Mesh devices connected to an account and between Mesh Accounts. Device management and Accounts components are defined by a data schema alone. The Service and Messaging components are defined by a data schema and a service protocol. The separation of accounts and services as separate components is a key distinction between the Mesh and earlier Internet applications. A Mesh account belongs to the owner of the Mesh and not the account service provider which the user may change at any time of their choosing. A Mesh account may be connected to multiple service providers to provide backup capability or to none. For example, Alice's personal Mesh has one Master Profile, multiple device profiles (two of which are shown here) and two Account Profiles. Her Personal account is connected to two Mesh services while her Business account is not currently connected to any service: Hallam-Baker Expires April 25, 2020 [Page 8] Internet-Draft Mesh Schema Reference October 2019 [[This figure is not viewable in this format. The figure is available at http://mathmesh.com/Documents/draft-hallambaker-mesh- schema.html [3].]] Alice's Personal Mesh In normal circumstances, a user will create a personal Mesh and add their first device, account and service at once. These are shown here as separate operations to illustrate the separation of the Mesh components. 4.1. Device Management Device Management provides the foundation for all Mesh functions allowing a collection of devices belonging to a user to function as a single personal Mesh. The device management layer of a personal Mesh consists of exactly one Master Profile and a catalog containing the entries describing the connected devices. 4.1.1. Master Profile A Mesh master profile provides the axiom of trust for a mesh user. It contains a Master Signature Key and one or more Administration Signature Keys. The unique identifier of the master profile is the UDF of the Master Signature Key. A Master Profile MAY contain one or more MasterEscrowKeys. These MAY be used to escrow private keys used for encryption. They SHOULD NOT be used to escrow authentication keys and MUST NOT be used to escrow signature keys. [[This figure is not viewable in this format. The figure is available at http://mathmesh.com/Documents/draft-hallambaker-mesh- schema.html [4].]] Master Profile and Associated Device and Account Connection Assertions. A user should not need to replace their master profile unless they intend to establish a separate identity. To minimize the risk of disclosure, the Master Signature Key is only ever used to sign updates to the master profile itself. This allows the user to secure their Master Signature Key by either keeping it on hardware token or Hallam-Baker Expires April 25, 2020 [Page 9] Internet-Draft Mesh Schema Reference October 2019 device dedicated to that purpose or by using the escrow mechanism and paper recovery keys as described in this document. Alice creates a ProfileMaster with one administration key and one master escrow key: { "ProfileMesh":{ "KeyOfflineSignature":{ "UDF":"MA4D-JPBO-ZPEK-JU62-RQWE-WO3F-77DD", "PublicParameters":{ "PublicKeyECDH":{ "crv":"Ed448", "Public":"Z3s7zihxwMXyCR-OZfS6BKKEz_bvfdarORwNQTuG6qicLW4 FrRjS4uj4oVsMzMrwvtWV2Ee4En8A"}}}, "KeysOnlineSignature":[{ "UDF":"MBVP-ETE2-3SCY-CD4N-UASC-HMHJ-4V7D", "PublicParameters":{ "PublicKeyECDH":{ "crv":"Ed448", "Public":"CQlMGm-IHWgr52CN89IQz4HpmQu9485yO-3cu6duXM5c9 qa1TqZ4nHVletYtuQ8C3yemUQ0BgSuA"}}} ], "KeyEncryption":{ "UDF":"MDWT-LPZ5-KZXO-IOAE-EGDW-KA5X-FFV7", "PublicParameters":{ "PublicKeyECDH":{ "crv":"Ed448", "Public":"rE_1nI8IIx8tu357zW4JquYAlo6G9kvAZtcqHZsYnHROzYa 8g4LRoXwc-tTBQVe8OjAQe0v20fAA"}}}}} 4.1.1.1. Creating a ProfileMaster Creating a ProfileMaster comprises the steps of: 1. Creating a Master Signature key. 2. Creating an Online Signing Key 3. Signing the ProfileMaster using the Master Signature Key 4. Persisting the ProfileMaster on the administration device to the CatalogHost. 5. (Optional) Connecting at least one Administration Device and granting it the ActivationAdministration activation. Hallam-Baker Expires April 25, 2020 [Page 10] Internet-Draft Mesh Schema Reference October 2019 4.1.1.2. Updating a ProfileMaster Updating a ProfileMaster comprises the steps of: 1. Making the necessary changes. 2. Signing the ProfileMaster using the Master Signature Key 3. Persisting the ProfileMaster on the administration device to the CatalogHost. 4.1.1.3. The Device Catalog Each personal Mesh has a Device Catalog CatalogDevice associated with it. The Device Catalog is used to manage the connection of devices to the Personal Mesh and has a CatalogEntryDevice for each device currently connected to the catalog. Each Administration Device MUST have access to an up to date copy of the Device Catalog in order to manage the devices connected to the Mesh. The Mesh Service protocol MAY be used to synchronize the Device Catalog between administration devices in the case that there is more than one administration device. The CatalogEntryDevice contains fields for the device profile, device private and device connection. 4.1.2. Mesh Devices The principle of radical distrust requires us to consider the possibility that a device might be compromised during manufacture. Once consequence of this possibility is that when an administration device connects a new device to a user's personal Mesh, we cannot put our full trust in either the device being connected or the administration device connecting it. This concern is resolved by (at minimum) combining keying material generated from both sources to create the keys to be used in the context of the user's personal Mesh with the process being fully verified by both parties. Additional keying material sources could be added if protection against the possibility of compromise at both devices was required but this is not supported by the current specifications. A device profile provides the axiom of trust and the key contributions of the device: Hallam-Baker Expires April 25, 2020 [Page 11] Internet-Draft Mesh Schema Reference October 2019 [[This figure is not viewable in this format. The figure is available at http://mathmesh.com/Documents/draft-hallambaker-mesh- schema.html [5].]] Mapping of Device Profile and Device Private to Device Connection Keys. Unless exceptional circumstances require, a device should not require more than one Device profile even if the device supports use by multiple users under different accounts. But a device MAY have multiple profiles if this approach is more convenient for implementation. Alice's Device Profile specifies keys for encryption, signature and exchange: { "ProfileDevice":{ "KeyOfflineSignature":{ "UDF":"MADC-EAFQ-SWVC-LZLN-OX3C-ZETW-OKBC", "PublicParameters":{ "PublicKeyECDH":{ "crv":"Ed448", "Public":"7bGDuzFFGFyvC87epJjQ11Rl73RsNlFCWV0gTM5S7HvgmlF sS5PmeR4UQw8EF8BsOOzQeymIDAsA"}}}, "KeyEncryption":{ "UDF":"MBJE-2H3U-L6I4-P35W-E6AP-OYWX-XYL6", "PublicParameters":{ "PublicKeyECDH":{ "crv":"Ed448", "Public":"KqnaidMDm3k9oAy8xqlKzLMJdwhupLfmPtaPp572JP2BT2S _0NCvhXgw-RKS0wl3FaCqzpLfnvSA"}}}, "KeyAuthentication":{ "UDF":"MB5H-MB4Q-D763-VGRJ-PXHD-4WOI-7WY6", "PublicParameters":{ "PublicKeyECDH":{ "crv":"Ed448", "Public":"aRtiUwCciVB12VsBpmT-hSF8PeK6BjTDDnhz3tcQAyFcg7n qJ7FRpyX6dv6n2zxzZ4JhWnkQxruA"}}}}} Since the Device Profile keys are ultimately under the control of the device and/or software provider, these are considered insufficiently trustworthy and the administration device creates key contributions to be added to the device keys to establish the key set to be used in the context of the user's personal Mesh: Hallam-Baker Expires April 25, 2020 [Page 12] Internet-Draft Mesh Schema Reference October 2019 { "ActivationDevice":{ "KeySignature":{ "UDF":"MBSX-KFPC-MKKB-RXMV-XLGT-7HPQ-NYKM", "BaseUDF":"MADC-EAFQ-SWVC-LZLN-OX3C-ZETW-OKBC", "Overlay":{ "PrivateKeyECDH":{ "crv":"Ed448", "Private":"AxEkV37vweGs-IXSys9bjkOEnRRnqr0fDeR1_QS6Y0GojA rv3o5CR4gg1dEaN1LL2U8ePxv3UjA"}}}, "KeyEncryption":{ "UDF":"MC7Q-CGGH-3WL4-IEKN-X7E5-R72X-5M3V", "BaseUDF":"MBJE-2H3U-L6I4-P35W-E6AP-OYWX-XYL6", "Overlay":{ "PrivateKeyECDH":{ "crv":"Ed448", "Private":"7yUtKDDI-9ScDVP_o_6kvYIWjsmy-07Cul3J5RRQ3APoZ2 xPeCZ81I2HG6ZoPpEsp2nPiSpsJRw"}}}, "KeyAuthentication":{ "UDF":"MBC6-HLLT-BB4J-ETRE-3TLH-E2VT-E7NM", "BaseUDF":"MB5H-MB4Q-D763-VGRJ-PXHD-4WOI-7WY6", "Overlay":{ "PrivateKeyECDH":{ "crv":"Ed448", "Private":"tEVrpfWX4Fu0rY-oHeIgBez_vZVXfCHol1Pgm6DhFAErzo kK5y9iguAWu7u-BDaN3gU8FYwmruo"}}}}} The resulting key set is specified in the device connection: Hallam-Baker Expires April 25, 2020 [Page 13] Internet-Draft Mesh Schema Reference October 2019 { "ConnectionDevice":{ "KeySignature":{ "UDF":"MBSX-KFPC-MKKB-RXMV-XLGT-7HPQ-NYKM", "PublicParameters":{ "PublicKeyECDH":{ "crv":"Ed448", "Public":"8T9yOusROXlqIhZzIgATST-5Ti2m7IOYFv8lLhvJJrotaff sVOkFOvokkjimhR8LjY4UWbXzhfwA"}}}, "KeyEncryption":{ "UDF":"MC7Q-CGGH-3WL4-IEKN-X7E5-R72X-5M3V", "PublicParameters":{ "PublicKeyECDH":{ "crv":"Ed448", "Public":"2_6ZI9ZF3TuTYsPfphIghrhNVNrOpo9kIbz6HlJ1Z0rVnG_ bxoB69bCC-6TooinwACC4aqxahxCA"}}}, "KeyAuthentication":{ "UDF":"MBC6-HLLT-BB4J-ETRE-3TLH-E2VT-E7NM", "PublicParameters":{ "PublicKeyECDH":{ "crv":"Ed448", "Public":"xtBpA3IjOO34t7on558tzTiYmTdmGy1cKVeLwPsHny5NN9H gqHdVVyJEXCc48hQylhuDfAeWnnqA"}}}}} All the above are combined to form the CatalogedDevice entry: { "CatalogedDevice":{ "UDF":"MBSX-KFPC-MKKB-RXMV-XLGT-7HPQ-NYKM", "DeviceUDF":"MADC-EAFQ-SWVC-LZLN-OX3C-ZETW-OKBC", "EnvelopedProfileDevice":[{ "dig":"S512"}, "ewogICJQcm9maWxlRGV2aWNlIjogewogICAgIktleU9mZmxpbmVTaWduYXR1 cmUiOiB7CiAgICAgICJVREYiOiAiTUFEQy1FQUZRLVNXVkMtTFpMTi1PWDNDLVpFV FctT0tCQyIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdW JsaWNLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6ICJFZDQ0OCIsCiAgICAgICA gICAiUHVibGljIjogIjdiR0R1ekZGR0Z5dkM4N2VwSmpRMTFSbDczUnNObEZDV1Yw Z1RNNVM3SHZnbWxGc1M1UG0KICBlUjRVUXc4RUY4QnNPT3pRZXltSURBc0EifX19L AogICAgIktleUVuY3J5cHRpb24iOiB7CiAgICAgICJVREYiOiAiTUJKRS0ySDNVLU w2STQtUDM1Vy1FNkFQLU9ZV1gtWFlMNiIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJ zIjogewogICAgICAgICJQdWJsaWNLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6 ICJFZDQ0OCIsCiAgICAgICAgICAiUHVibGljIjogIktxbmFpZE1EbTNrOW9BeTh4c WxLekxNSmR3aHVwTGZtUHRhUHA1NzJKUDJCVDJTXzBOQ3YKICBoWGd3LVJLUzB3bD NGYUNxenBMZm52U0EifX19LAogICAgIktleUF1dGhlbnRpY2F0aW9uIjogewogICA gICAiVURGIjogIk1CNUgtTUI0US1ENzYzLVZHUkotUFhIRC00V09JLTdXWTYiLAog ICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgICAiUHVibGljS2V5RUNES CI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICAgICAgIlB1YmxpYy I6ICJhUnRpVXdDY2lWQjEyVnNCcG1ULWhTRjhQZUs2QmpURERuaHozdGNRQXlGY2c Hallam-Baker Expires April 25, 2020 [Page 14] Internet-Draft Mesh Schema Reference October 2019 3bnFKN0ZSCiAgcHlYNmR2Nm4yenh6WjRKaFdua1F4cnVBIn19fX19", { "signatures":[{ "alg":"S512", "kid":"MADC-EAFQ-SWVC-LZLN-OX3C-ZETW-OKBC", "signature":"2oYgRVhqBk_3FhD0KCT27eB1nPCJ-LrKTZ6GceSr8g nSrFbt-Neb8asIweUs82graW98sjTI7ecAstxLekmMGJwqKWU9eQZWqHyw4l_tlBe AXpWXTqxGac3vEwndHGhBwQ4OARGQlmsEyijVVgQ63RsA"} ], "PayloadDigest":"KrMCxFjuvu01DmF7747jkDe3RBtr84y6e27hcs8y0o hz85yaFKzP5bwHXkrWFAGq8bpA8sVvRHMpXl4jzT9Djg"} ], "EnvelopedConnectionDevice":[{ "dig":"S512"}, "ewogICJDb25uZWN0aW9uRGV2aWNlIjogewogICAgIktleVNpZ25hdHVyZSI6 IHsKICAgICAgIlVERiI6ICJNQlNYLUtGUEMtTUtLQi1SWE1WLVhMR1QtN0hQUS1OW UtNIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0 tleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIkVkNDQ4IiwKICAgICAgICAgICJ QdWJsaWMiOiAiOFQ5eU91c1JPWGxxSWhaeklnQVRTVC01VGkybTdJT1lGdjhsTGh2 Skpyb3RhZmZzVk9rRgogIE92b2tramltaFI4TGpZNFVXYlh6aGZ3QSJ9fX0sCiAgI CAiS2V5RW5jcnlwdGlvbiI6IHsKICAgICAgIlVERiI6ICJNQzdRLUNHR0gtM1dMNC 1JRUtOLVg3RTUtUjcyWC01TTNWIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB 7CiAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIkVk NDQ4IiwKICAgICAgICAgICJQdWJsaWMiOiAiMl82Wkk5WkYzVHVUWXNQZnBoSWdoc mhOVk5yT3BvOWtJYno2SGxKMVowclZuR19ieG9CNgogIDliQ0MtNlRvb2lud0FDQz RhcXhhaHhDQSJ9fX0sCiAgICAiS2V5QXV0aGVudGljYXRpb24iOiB7CiAgICAgICJ VREYiOiAiTUJDNi1ITExULUJCNEotRVRSRS0zVExILUUyVlQtRTdOTSIsCiAgICAg ICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdWJsaWNLZXlFQ0RIIjoge wogICAgICAgICAgImNydiI6ICJFZDQ0OCIsCiAgICAgICAgICAiUHVibGljIjogIn h0QnBBM0lqT08zNHQ3b241NTh0elRpWW1UZG1HeTFjS1ZlTHdQc0hueTVOTjlIZ3F IZFYKICBWeUpFWENjNDhoUXlsaHVEZkFlV25ucUEifX19fX0", { "signatures":[{ "alg":"S512", "kid":"MBVP-ETE2-3SCY-CD4N-UASC-HMHJ-4V7D", "signature":"KFSQ4ottnwEJnRAVkw7LryjrLvw39Zxjyxqf8uFHOC yp7GsXreS7YFJHC4sV_-9bJLdEdh3UiHWA4BcwZ2Z5tqC1xLTsxknrVzCtoHCgMYm s2qYWpf2culeA1ghctIBRfpUx_lJDq3aKJ7TuhoZ3CQcA"} ], "PayloadDigest":"-MKymxWtQeb96U4k8-t5BHqCNle0RszYIQLstH9HNo bclozwhYi4s1Lz3k4LuAdRzR0aO1heosxv_YBhZODvJg"} ], "EnvelopedActivationDevice":[{ "enc":"none", "Salt":"yH6U-UisfZbsRfcMm47Yhw", "recipients":[{ "kid":"MBJE-2H3U-L6I4-P35W-E6AP-OYWX-XYL6", "epk":{ Hallam-Baker Expires April 25, 2020 [Page 15] Internet-Draft Mesh Schema Reference October 2019 "PublicKeyECDH":{ "crv":"Ed448", "Public":"uhu_tYq6szIlK9iXg9OIvsXfCyHM6pmFQHgl0Qfy6 K5BrFbTKRmdxd-GIa-fJ3BHneKTYHEQoUqA"}}, "wmk":"pqampqampqY"}, { "kid":"MDWT-LPZ5-KZXO-IOAE-EGDW-KA5X-FFV7", "epk":{ "PublicKeyECDH":{ "crv":"Ed448", "Public":"RDZJLrztNf5YtzSFHfu0MxR1oOUgiYnRCywVNCB6W yuky6KyyvCIiPPr3qzJi4GWX1zesOg3FXuA"}}, "wmk":"pqampqampqY"} ], "ContentMetaData":"ewogICJjdHkiOiAiYXBwbGljYXRpb24vbW1tIn0"}, "ewogICJBY3RpdmF0aW9uRGV2aWNlIjogewogICAgIktleVNpZ25hdHVyZSI6 IHsKICAgICAgIlVERiI6ICJNQlNYLUtGUEMtTUtLQi1SWE1WLVhMR1QtN0hQUS1OW UtNIiwKICAgICAgIkJhc2VVREYiOiAiTUFEQy1FQUZRLVNXVkMtTFpMTi1PWDNDLV pFVFctT0tCQyIsCiAgICAgICJPdmVybGF5IjogewogICAgICAgICJQcml2YXRlS2V 5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICAgICAgIlBy aXZhdGUiOiAiQXhFa1YzN3Z3ZUdzLUlYU3lzOWJqa09FblJSbnFyMGZEZVIxX1FTN lkwR29qQXJ2M281CiAgQ1I0Z2cxZEVhTjFMTDJVOGVQeHYzVWpBIn19fSwKICAgIC JLZXlFbmNyeXB0aW9uIjogewogICAgICAiVURGIjogIk1DN1EtQ0dHSC0zV0w0LUl FS04tWDdFNS1SNzJYLTVNM1YiLAogICAgICAiQmFzZVVERiI6ICJNQkpFLTJIM1Ut TDZJNC1QMzVXLUU2QVAtT1lXWC1YWUw2IiwKICAgICAgIk92ZXJsYXkiOiB7CiAgI CAgICAgIlByaXZhdGVLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6ICJFZDQ0OC IsCiAgICAgICAgICAiUHJpdmF0ZSI6ICI3eVV0S0RESS05U2NEVlBfb182a3ZZSVd qc215LTA3Q3VsM0o1UlJRM0FQb1oyeFBlQ1oKICA4MUkySEc2Wm9QcEVzcDJuUGlT cHNKUncifX19LAogICAgIktleUF1dGhlbnRpY2F0aW9uIjogewogICAgICAiVURGI jogIk1CQzYtSExMVC1CQjRKLUVUUkUtM1RMSC1FMlZULUU3Tk0iLAogICAgICAiQm FzZVVERiI6ICJNQjVILU1CNFEtRDc2My1WR1JKLVBYSEQtNFdPSS03V1k2IiwKICA gICAgIk92ZXJsYXkiOiB7CiAgICAgICAgIlByaXZhdGVLZXlFQ0RIIjogewogICAg ICAgICAgImNydiI6ICJFZDQ0OCIsCiAgICAgICAgICAiUHJpdmF0ZSI6ICJ0RVZyc GZXWDRGdTByWS1vSGVJZ0Jlel92WlZYZkNIb2wxUGdtNkRoRkFFcnpva0s1eTkKIC BpZ3VBV3U3dS1CRGFOM2dVOEZZd21ydW8ifX19fX0" ], "Accounts":[{ "AccountUDF":"MCW6-7L5H-5VSD-QG4G-AZLG-QMQA-MLVG", "EnvelopedProfileAccount":[{ "dig":"S512"}, "ewogICJQcm9maWxlQWNjb3VudCI6IHsKICAgICJLZXlPZmZsaW5lU2ln bmF0dXJlIjogewogICAgICAiVURGIjogIk1DVzYtN0w1SC01VlNELVFHNEctQVpMR y1RTVFBLU1MVkciLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgIC AiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICA gICAgICAgIlB1YmxpYyI6ICJJa2RybkU1WFJhaHJuanpJemI4d25Oc3JSWWZ0OG5k MnYzaktjYWdxVzBoZXFXVDJCSnkwCiAgVS1SdFR6M19WUnRaeFlnZ1ZaVWNuUmlBI n19fSwKICAgICJLZXlzT25saW5lU2lnbmF0dXJlIjogW3sKICAgICAgICAiVURGIj ogIk1BT0ItMzVCRS1BSVpKLUhRWkYtSEVPUi00T0JYLTZNRUUiLAogICAgICAgICJ Hallam-Baker Expires April 25, 2020 [Page 16] Internet-Draft Mesh Schema Reference October 2019 QdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7 CiAgICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICAgICAgICAiUHVibGljI jogIkw4ZUdPZ3ljSExoZG03TVBNcnFfbEJHUTR1cVNOak4zdV8tOUQ1UFdjdHRfSk 5JVEJjbkwKICA1cGx6WVdGSi0tekhsSk00Y1lQOWVoLUEifX19XSwKICAgICJNZXN oUHJvZmlsZVVERiI6ICJNQTRELUpQQk8tWlBFSy1KVTYyLVJRV0UtV08zRi03N0RE IiwKICAgICJLZXlFbmNyeXB0aW9uIjogewogICAgICAiVURGIjogIk1CVVYtSFdBS i1OWFRVLVFaWDItVVpQSC1GU05YLVJJWFciLAogICAgICAiUHVibGljUGFyYW1ldG VycyI6IHsKICAgICAgICAiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnY iOiAiRWQ0NDgiLAogICAgICAgICAgIlB1YmxpYyI6ICJmc0t5M096Z0pzcVhlWDhH b1Fmd3dMVERmRXlhQ2htTlA4SjM5LTVob2Npb3Z0bEtiNW1MCiAgazk1Njl0TS1ld S1vdlB4TE9vRTUyTHlBIn19fX19", { "signatures":[{ "alg":"S512", "kid":"MCW6-7L5H-5VSD-QG4G-AZLG-QMQA-MLVG", "signature":"D-6GRZjEBF8i1q38wiT6-wkltwWKl3kUo55UB1 7QzbkndFNm6LIbn-fUUW2yyeuukk9yD3_2jjCAuypkhzyM_m0B8t2GgwQijvOvGNC -h8k9YXAWiTyvx2M-n4TROcf2kLcOXk1x82RoTNkw_e5gZC4A"} ], "PayloadDigest":"5Uit3qVrRX7xwpxV712UDgEvFXuce3accLWRL3 XU0D27zNDdMK3htry8rtPd07Hb-sL6LvgjHXaFuK-A0vQDZw"} ], "EnvelopedConnectionAccount":[{ "dig":"S512"}, "ewogICJDb25uZWN0aW9uQWNjb3VudCI6IHsKICAgICJTdWJqZWN0VURG IjogIk1CQkstS1RNVC01QlNVLURUVEwtQk1VVy1QNTJELUM1RE8iLAogICAgIkF1d Ghvcml0eVVERiI6ICJNQ1c2LTdMNUgtNVZTRC1RRzRHLUFaTEctUU1RQS1NTFZHIi wKICAgICJLZXlTaWduYXR1cmUiOiB7CiAgICAgICJVREYiOiAiTUJCSy1LVE1ULTV CU1UtRFRUTC1CTVVXLVA1MkQtQzVETyIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJz IjogewogICAgICAgICJQdWJsaWNLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6I CJFZDQ0OCIsCiAgICAgICAgICAiUHVibGljIjogImlDeFQxNDlQRWY2X2c3SkFmUV JMUGZta2hOOWNEWlhLaldkSnkzdzc3ZlRibklLeU9MaVkKICBsbzJVbkg4RkZ1Uk5 VVmtjd2ZQRmRhQUEifX19LAogICAgIktleUF1dGhlbnRpY2F0aW9uIjogewogICAg ICAiVURGIjogIk1BSFQtT1RSQi1CVzIzLUhKVlctRVYzSi1BM0FNLVE1VEoiLAogI CAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgICAiUHVibGljS2V5RUNESC I6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICAgICAgIlB1YmxpYyI 6ICJpTC1JWTYzNFZHQ3dyb19SVlNXUnRRU0I5aDBXU0oxMlJZMkdoMC1McmVWemd6 RFVMeUZrCiAgcjdILTczQXNHMHd2aS10Wk9tWGd2ZU9BIn19fX19", { "signatures":[{ "alg":"S512", "kid":"MAOB-35BE-AIZJ-HQZF-HEOR-4OBX-6MEE", "signature":"kr9dawpfH2WJjTJivNtFMyIN6he0YNDL2U8ZDY ycxwb7PBY6fGnJX_8FawErWLqZrRaE0QJy_gAAvi4hrHlqT2S4udnoDg3j84VqcSy kn95KnlxV6Nd8-xw6_yF7qr-1V1QHE_Iy-F0rD6rAsbDKfyYA"} ], "PayloadDigest":"wCLNOTcP4P-1L4gHmgk4LW5IMVu6tih1Ifqspc IyiNlEU4z1kiFKJ3a8_5e223gjJTrxKbcl2htGnuIoamEA9g"} Hallam-Baker Expires April 25, 2020 [Page 17] Internet-Draft Mesh Schema Reference October 2019 ], "EnvelopedActivationAccount":[{ "dig":"S512"}, "ewogICJBY3RpdmF0aW9uQWNjb3VudCI6IHsKICAgICJBY2NvdW50VURG IjogIk1DVzYtN0w1SC01VlNELVFHNEctQVpMRy1RTVFBLU1MVkciLAogICAgIktle UVuY3J5cHRpb24iOiB7CiAgICAgICJVREYiOiAiTURRRC1XSlhOLU5GSUUtRUc0UC 1WRERTLUhGNDItRUFENyIsCiAgICAgICJCYXNlVURGIjogIk1CSkUtMkgzVS1MNkk 0LVAzNVctRTZBUC1PWVdYLVhZTDYiLAogICAgICAiT3ZlcmxheSI6IHsKICAgICAg ICAiUHJpdmF0ZUtleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIkVkNDQ4IiwKI CAgICAgICAgICJQcml2YXRlIjogIi1hb0Z1M21hbjFpd0FwbW15eFB4WDF2SjM0ak VjRnNxNDh1RzIyRFpnajR2WUFkc0dMTwogIGIyYTVyaDZxRjhMU1BfQzVSSGFnMkN WSSJ9fX0sCiAgICAiS2V5QXV0aGVudGljYXRpb24iOiB7CiAgICAgICJVREYiOiAi TUFIVC1PVFJCLUJXMjMtSEpWVy1FVjNKLUEzQU0tUTVUSiIsCiAgICAgICJCYXNlV URGIjogIk1CNUgtTUI0US1ENzYzLVZHUkotUFhIRC00V09JLTdXWTYiLAogICAgIC AiT3ZlcmxheSI6IHsKICAgICAgICAiUHJpdmF0ZUtleUVDREgiOiB7CiAgICAgICA gICAiY3J2IjogIkVkNDQ4IiwKICAgICAgICAgICJQcml2YXRlIjogIk85ekxrd0xl bHR1dmVXajh4TmdtdTNTT1IwWU5UazNKZFN0VWh6NnB2dEl1ek5JVzVNTgogIHFEU lhiRDQtRWlNUGpveVh2QTQ5Xzl6YyJ9fX0sCiAgICAiS2V5U2lnbmF0dXJlIjogew ogICAgICAiVURGIjogIk1CQkstS1RNVC01QlNVLURUVEwtQk1VVy1QNTJELUM1RE8 iLAogICAgICAiQmFzZVVERiI6ICJNQURDLUVBRlEtU1dWQy1MWkxOLU9YM0MtWkVU Vy1PS0JDIiwKICAgICAgIk92ZXJsYXkiOiB7CiAgICAgICAgIlByaXZhdGVLZXlFQ 0RIIjogewogICAgICAgICAgImNydiI6ICJFZDQ0OCIsCiAgICAgICAgICAiUHJpdm F0ZSI6ICJCeG1KZjdLQzFyd2lIa2hzTHJIT0ZuWFNhV0dzTkFYZ3BmbmZza2lQN05 tWGJTaThNanQKICBaU3lHNXdIRy1oSGxsdU04a1dYT1RvMUkifX19fX0", { "signatures":[{ "alg":"S512", "kid":"MAOB-35BE-AIZJ-HQZF-HEOR-4OBX-6MEE", "signature":"aPbV8iAgbFx6gHZdrpM96CDC_34jJo-nblow9P ClTTYNQmhtKNRrBnfcnpMrh6g0H7jnm1bFMk6AxHF6BXrwhpeRhZjB0E7kNqcvMYA 08eDF_i04Zc8XPipf8IMc-wu6ryO-C8Efhd9rzB7mAzgdJj0A"} ], "PayloadDigest":"OHYDXAunAtazdEzaQQdVuxojUZ5D1Ra6ZoVPFz pHvAwRm09ae9qW6lYNJtpaOEd8Q9Ts33yArBOgqdEPR1DpFA"} ]} ]}} The derivation of the Connection encryption and signature keys from the Profile and Private contributions in this example is shown in [draft-hallambaker-mesh-cryptography] . 4.1.2.1. Creating a ProfileDevice Creating a ProfileDevice comprises the steps of: 1. Creating the necessary key 2. Signing the ProfileDevice using the Master Signature Key Hallam-Baker Expires April 25, 2020 [Page 18] Internet-Draft Mesh Schema Reference October 2019 3. Once created, a ProfileDevice is never changed. In the unlikely event that any modification is required, a completely new ProfileDevice MUST be created. 4.1.2.2. Connection to a Personal Mesh Devices are only connected to a personal Mesh by administration device. This comprises the steps of: 1. Generating the PrivateDevice keys. 2. Creating the ConnectionDevice data from the public components of the ProfileDevice and PrivateDevice keys and signing it using the administration key. 3. Creating the Activations for the device and signing them using the administration key. 4. Creating the CatalogEntryDevice for the device and adding it to the CatalogDevice of the Personal Mesh. 5. If the Personal Mesh has accounts that are connected to a Mesh Service, synchronizing the CatalogEntryDevice to those services. 4.2. Mesh Accounts Mesh Accounts contains all the stateful information (contacts, calendar entries, inbound and outbound messages, etc.) related to a particular persona used by the owner. A Mesh Profile MAY be connected to multiple accounts at the same time allowing the user to maintain separate personas for separate purposes. Unlike traditional Internet application accounts, Mesh accounts are created by and belong to the user, not the Mesh Service provider. A user MAY change their Mesh Service provider at any time and disconnect the profile from all Mesh Services (e.g. to archive the account). Alice's personal account is connected to two Mesh services: [[This figure is not viewable in this format. The figure is available at http://mathmesh.com/Documents/draft-hallambaker-mesh- schema.html [6].]] Account Profile Connected to Devices and Services. Hallam-Baker Expires April 25, 2020 [Page 19] Internet-Draft Mesh Schema Reference October 2019 The account profile specifies the online and offline signature keys used to maintain the profile and the encryption key to be used by the account. { "ProfileAccount":{ "KeyOfflineSignature":{ "UDF":"MCW6-7L5H-5VSD-QG4G-AZLG-QMQA-MLVG", "PublicParameters":{ "PublicKeyECDH":{ "crv":"Ed448", "Public":"IkdrnE5XRahrnjzIzb8wnNsrRYft8nd2v3jKcagqW0heqWT 2BJy0U-RtTz3_VRtZxYggVZUcnRiA"}}}, "KeysOnlineSignature":[{ "UDF":"MAOB-35BE-AIZJ-HQZF-HEOR-4OBX-6MEE", "PublicParameters":{ "PublicKeyECDH":{ "crv":"Ed448", "Public":"L8eGOgycHLhdm7MPMrq_lBGQ4uqSNjN3u_-9D5PWctt_J NITBcnL5plzYWFJ--zHlJM4cYP9eh-A"}}} ], "ServiceIDs":["alice@example.com" ], "MeshProfileUDF":"MA4D-JPBO-ZPEK-JU62-RQWE-WO3F-77DD", "KeyEncryption":{ "UDF":"MBUV-HWAJ-NXTU-QZX2-UZPH-FSNX-RIXW", "PublicParameters":{ "PublicKeyECDH":{ "crv":"Ed448", "Public":"fsKy3OzgJsqXeX8GoQfwwLTDfEyaChmNP8J39-5hociovtl Kb5mLk9569tM-eu-ovPxLOoE52LyA"}}}}} Each device using the account requires an activation record: Hallam-Baker Expires April 25, 2020 [Page 20] Internet-Draft Mesh Schema Reference October 2019 { "ActivationAccount":{ "AccountUDF":"MCW6-7L5H-5VSD-QG4G-AZLG-QMQA-MLVG", "KeyEncryption":{ "UDF":"MDQD-WJXN-NFIE-EG4P-VDDS-HF42-EAD7", "BaseUDF":"MBJE-2H3U-L6I4-P35W-E6AP-OYWX-XYL6", "Overlay":{ "PrivateKeyECDH":{ "crv":"Ed448", "Private":"-aoFu3man1iwApmmyxPxX1vJ34jEcFsq48uG22DZgj4vYA dsGLOb2a5rh6qF8LSP_C5RHag2CVI"}}}, "KeyAuthentication":{ "UDF":"MAHT-OTRB-BW23-HJVW-EV3J-A3AM-Q5TJ", "BaseUDF":"MB5H-MB4Q-D763-VGRJ-PXHD-4WOI-7WY6", "Overlay":{ "PrivateKeyECDH":{ "crv":"Ed448", "Private":"O9zLkwLeltuveWj8xNgmu3SOR0YNTk3JdStUhz6pvtIuzN IW5MNqDRXbD4-EiMPjoyXvA49_9zc"}}}, "KeySignature":{ "UDF":"MBBK-KTMT-5BSU-DTTL-BMUW-P52D-C5DO", "BaseUDF":"MADC-EAFQ-SWVC-LZLN-OX3C-ZETW-OKBC", "Overlay":{ "PrivateKeyECDH":{ "crv":"Ed448", "Private":"BxmJf7KC1rwiHkhsLrHOFnXSaWGsNAXgpfnfskiP7NmXbS i8MjtZSyG5wHG-hHlluM8kWXOTo1I"}}}}} 4.2.1. Creating a ProfileAccount Creating a ProfileAccount comprises the steps of: 1. [TBS] 2. . 3. Signing the ProfileMaster using the Master Signature Key 4.2.2. Connecting a Device to an Account Adding a device to an account comprises the steps of: 1. Creating a PrivateAccount instance for the device. 2. Creating a ConnectionAccountDevice for the device using the public keys from the PrivateAccount instance and the ProfileDevice. Hallam-Baker Expires April 25, 2020 [Page 21] Internet-Draft Mesh Schema Reference October 2019 3. Creating an ActivationAccount for the device containing the PrivateAccount and ConnectionAccountDevice instances. 4. Adding the ActivationAccount to the CatalogEntryDevice of the device. 5. If the Personal Mesh has accounts that are connected to a Mesh Service, synchronizing the CatalogEntryDevice to those services. 4.2.3. Binding and Account to a Service Binding a ProfileAccount to a Mesh Service the steps of: 1. [TBS] 2. . 3. Signing the ProfileMaster using the Master Signature Key 4.3. Mesh Services A service profile provides the axiom of trust and cryptographic keys for a Mesh Service. A Mesh Service Host SHOULD return a copy of its ProfileHost and the parent ProfileService in response to a Hello transaction request. [[This figure is not viewable in this format. The figure is available at http://mathmesh.com/Documents/draft-hallambaker-mesh- schema.html [7].]] Service Profile and Delegated Host Assertion. The credentials provided by the ProfileService and ProfileHost are distinct from those provided by the WebPKI that typically services TLS requests. WebPKI credentials provide service introduction and authentication while a Mesh ProfileHost only provides authentication. Unless exceptional circumstances require, a service should not need to revise its Service Profile unless it is intended to change its identity. Service Profiles MAY be countersigned by Trusted Third Parties to establish accountability. The service profile Hallam-Baker Expires April 25, 2020 [Page 22] Internet-Draft Mesh Schema Reference October 2019 { "ProfileService":{ "KeyOfflineSignature":{ "UDF":"MACQ-QKOB-HNPU-CHCJ-7IY7-2IHI-E5PV", "PublicParameters":{ "PublicKeyECDH":{ "crv":"Ed448", "Public":"lztrV1xgnL-DGldDyvbNGOD-mbx1-eFSIND3Z8vtinTF4lI Ng8AesrG4G88-eh7VAxZLN0XGfZgA"}}}}} The host also has a profile { "ProfileHost":{ "KeyOfflineSignature":{ "UDF":"MAED-OJMH-EIY7-KI2Z-U63B-G24I-7STG", "PublicParameters":{ "PublicKeyECDH":{ "crv":"Ed448", "Public":"6n_aFAptjCXEQdiSbN5hpuiMyNMo5scJyXwHKM7u_yiCLSP dCK3G30lI6VULa1VjOQyQzzO0QE4A"}}}, "KeyAuthentication":{ "UDF":"MAPL-IPFB-VRV5-4SUF-HCS4-W7PA-36PR", "PublicParameters":{ "PublicKeyECDH":{ "crv":"Ed448", "Public":"HV5knDiIptJjTuT-j3ZpWLSJIk9LO_g-KniaGe8vAwNN5zD aoRMrB2J82EEMpY1K-4b8wOtKmmuA"}}}}} And there should be a connection of the host to the service but this isn't implemented yet: $$$$ Empty $$$$ 4.3.1. Creating a ProfileService [TBS] Creating a ProfileService comprises the steps of: 1. [TBS] 2. . 3. [TBS] 4. Hallam-Baker Expires April 25, 2020 [Page 23] Internet-Draft Mesh Schema Reference October 2019 5. Signing the ProfileMaster using the Master Signature Key 4.3.2. Creating a ProfileHost Creating a ProfileHost comprises the steps of: 1. [TBS] 2. . 3. [TBS] 4. 5. Signing the ConnectionHost using the Master Signature Key of the ProfileService. 4.3.3. Creating a ConnectionHost Creating a ConnectionHost comprises the steps of: 1. [TBS] 2. . 3. Signing the ConnectionHost using the Master Signature Key of the ProfileService. 4.4. Mesh Messaging Mesh Messaging is an end-to-end secure messaging system used to exchange short (32KB) messages between Mesh devices and services. In cases where exchange of longer messages is required, Mesh Messaging MAY be used to provide a control plane to advise the intended message recipient(s) of the type of data being offered and the means of retrieval (e.g an EARL). A four-corner messaging model is enforced. Mesh Services only accept outbound messages from devices connected to accounts that it services. Inbound messages are only accepted from other Mesh Services. This model enables access control at both the outbound and inbound services Hallam-Baker Expires April 25, 2020 [Page 24] Internet-Draft Mesh Schema Reference October 2019 [[This figure is not viewable in this format. The figure is available at http://mathmesh.com/Documents/draft-hallambaker-mesh- schema.html [8].]] Performing Access Control on Outbound Messages The outbound Mesh Service checks to see that the message request does not violate its acceptable use policy. Accounts that make a large number of message requests that result in complaints SHOULD be subject to consequences ranging from restriction of the number and type of messages sent to suspending or terminating messaging privileges. [[This figure is not viewable in this format. The figure is available at http://mathmesh.com/Documents/draft-hallambaker-mesh- schema.html [9].]] Performing Access Control on Outbound Messages The inbound Mesh Service also checks to see that messages received are consistent with the service Acceptable Use Policy and the user's personal access control settings. Mesh Services that fail to police abuse by their account holders SHOULD be subject to consequences in the same fashion as account holders. [[This figure is not viewable in this format. The figure is available at http://mathmesh.com/Documents/draft-hallambaker-mesh- schema.html [10].]] Performing Access Control on Inbound Messages 4.4.1. Traffic Analysis The Mesh Messaging protocol as currently specified provides only limited protection against traffic analysis attacks. The use of TLS to encrypt communication between Mesh Services limits the effectiveness of na?ve traffic analysis mechanisms but does not prevent timing attacks unless dummy traffic is introduced to obfuscate traffic flows. The limitation of the message size is in part intended to facilitate use of mechanisms capable of providing high levels of traffic analysis such as mixmaster and onion routing but the current Mesh Hallam-Baker Expires April 25, 2020 [Page 25] Internet-Draft Mesh Schema Reference October 2019 Service Protocol does not provide support for such approaches and there are no immediate plans to do so. 5. Mesh Catalogs Catalogs track sets of persistent objects associated with a Mesh Service Account. The Mesh Service has no access to the entries in any Mesh catalog except for the Device and Contacts catalog which are used in device authentication and authorization of inbound messages. Each Mesh Catalog managed by a Mesh Account has a name of the form: <_ Where < is the IANA assigned service name. The assigned service name for the Mathematical Mesh is mmm. Thus, all catalogs specified by the Mesh schema have names prefixed with the sequence mmm_. The following catalogs are currently specified within the Mathematical Mesh. Application: mmm_CatalogApplication Contains configuration information for applications including mail (SMTP, IMAP, OpenPGP, S/MIME, etc) and SSH and for the MeshAccount application itself. Device: mmm_CatalogDevice Contains descriptions of devices connected to the account and the permissions assigned to them Contact: mmm_CatalogContact Contains logical and physical contact information for people and organizations. Credential: mmm_CatalogCredential Contains credentials used to access network resources. Bookmark: mmm_CatalogBookmark Contains Web bookmarks and other citations allowing them to be shared between devices connected to the profile. Task: mmm_CatalogTask Contains tasks assigned to the user including calendar entries and to do lists. Network: mmm_CatalogNetwork Contains network settings such as WiFi access points, IPSEC and TLS VPN configurations, etc. In many cases, the Mesh Catalog offers capabilities that represent a superset of the capabilities of an existing application. For example, the task catalog supports the appointment tracking functions Hallam-Baker Expires April 25, 2020 [Page 26] Internet-Draft Mesh Schema Reference October 2019 of a traditional calendar application and the task tracking function of the traditional 'to do list' application. Combining these functions allows tasks to be triggered by other events other than the passage of time such as completion of other tasks, geographical presence, etc. In such cases, the Mesh Catalog entries are designed to provide a superset of the data representation capabilities of the legacy formats and (where available) recent extensions. Where a catalog entry is derived from input presented in a legacy format, the original data representation MAY be attached verbatim to facilitate interoperability. 5.1. Application The application catalog mmm_CatalogApplication contains CatalogEntryApplication entries which describe the use of specific applications under the Mesh Service Account. Multiple application accounts for a single application MAY be connected to a single Mesh Service Account. Each account being specified in a separate entry. The CatalogEntryApplication entries only contain configuration information for the application as it applies to the account as a whole. If the application requires separate configuration for individual devices, this is specified in separate activation records specified in the corresponding ConnectionDevice. 5.1.1. Mesh Account Mesh Accounts are described by CatalogEntryAccount entries. The corresponding activation records for the connected devices contain the contributions used to derive the private keys for use of the account. The CatalogEntryAccount entry is described in the section describing Mesh accounts above. 5.1.2. SSH SSH configuration profiles are described by CatalogEntryApplicationSSH entries. The corresponding activation records for the connected devices contain the contributions used to derive the private keys. A user may have separate SSH configurations for separate purposes within a single Mesh Account. This allows a system administrator servicing multiple clients to maintain separate SSH profiles for each Hallam-Baker Expires April 25, 2020 [Page 27] Internet-Draft Mesh Schema Reference October 2019 of her customers allowing credentials to be easily (and verifiably) revoked at contract termination. The SSH profile contains the information that is stored in the known_hosts and authorized_keys files of SSH clients and servers. $$$$ Empty $$$$ 5.1.3. Mail Mail configuration profiles are described by one or more CatalogEntryApplicationMail entries, one for each email account connected to the Mesh profile. The corresponding activation records for the connected devices contain information used to provide the device with the necessary decryption information. Entries specify the email account address(es), the inbound and outbound server configuration and the cryptographic keys to be used for S/MIME and OpenPGP encryption. $$$$ Empty $$$$ 5.2. Device The device catalog mmm_CatalogDevice contains CatalogEntryDevice entries which describe the devices connected to the account and the permissions assigned to them. The management of the device catalog is described in the section describing Mesh Device Management. 5.3. Contact The contacts catalog contains CatalogEntryContact entries which describe $$$$ Empty $$$$ The fields of the contact catalog provide a superset of the capabilities of vCard [RFC2426] . The Contact catalog is typically used by the MeshService as a source of authorization information to perform access control on inbound and outbound message requests. For this reason, Mesh Service SHOULD be granted read access to the contacts catalog by providing a decryption entry for the service. Hallam-Baker Expires April 25, 2020 [Page 28] Internet-Draft Mesh Schema Reference October 2019 5.4. Credential The credential catalog contains CatalogEntryCredential entries which describe credentials used to access network resources. Only username/password credentials are stored in the credential catalog. If public key credentials are to be used, these SHOULD be managed as an application profile allowing separate credentials to be created for each device. { "CatalogedCredential":{ "Service":"ftp.example.com", "Username":"alice1", "Password":"newpassword"}} 5.5. Bookmark The bookmark catalog contains CatalogEntryBookmark entries which describe Web bookmarks and other citations allowing them to be shared between devices connected to the profile. The fields currently supported by the Bookmarks catalog are currently limited to the fields required for tracking Web bookmarks. Specification of additional fields to track full academic citations is a work in progress. { "CatalogedBookmark":{ "Uri":"http://example.net/Bananas", "Title":"\"Banana", "Path":"Folder1/2"}} 5.6. Task The Task catalog contains CatalogEntryTask entries which describe tasks assigned to the user including calendar entries and to do lists. The fields of the task catalog currently reflect those offered by the iCalendar specification [RFC5545] . Specification of additional fields to allow task triggering on geographic location and/or completion of other tasks is a work in progress. { "CatalogedTask":{ "Key":"CalID1"}} Hallam-Baker Expires April 25, 2020 [Page 29] Internet-Draft Mesh Schema Reference October 2019 5.7. Network The network catalog contains CatalogEntryNetwork entries which describe network settings, IPSEC and TLS VPN configurations, etc. $$$$ Empty $$$$ 6. Mesh Messages All communications between Mesh accounts takes the form of a Mesh Message carried in a Dare Envelope. Mesh Messages are stored in two spools associated with the account, the SpoolOutbound and the SpoolInbound containing the messages sent and received respectively. This document only describes the representation of the messages within the message spool. The Mesh Service protocol by which the messages are exchanged between devices and services and between services is described in [draft-hallambaker-mesh-protocol] . 6.1. Completion Completion messages are dummy messages that are added to a Mesh Spool to change the status of messages previously posted. Any message that is in the inbound spool and has not been erased or redacted MAY be marked as read, unread or deleted. Any message in the outbound spool MAY be marked as sent, received or deleted. Services MAY erase or redact messages in accordance with local site policy. Since messages are not removed from the spool on being marked deleted, they may be undeleted by marking them as read or unread. Marking a message deleted MAY make it more likely that the Service will purge the message however. Having processed a message, a completion message is added to the spool so that other devices can see that it has been read: [NYI] 6.2. Connection Connection requests are sent by a device requesting connection to a Mesh Service Account. The MessageConnectionRequest is originally sent by the device requesting connection to the Mesh Service associated with the account. Hallam-Baker Expires April 25, 2020 [Page 30] Internet-Draft Mesh Schema Reference October 2019 If the connection request is accepted by the Mesh Service, it creates a MessageConnectionResponse containing the ServerNonce and Witness values used in the authentication of the response together with a verbatim copy of the original request. The MessageConnectionResponse is then returned to the device that made the original request and placed on the SpoolInbound of the account to which the request was directed. Further details of this mechanism are described in [draft-hallambaker-mesh-protocol] . The connection process begins with the assignment of a time-limited PIN value. This is described in a Message sent by the administration device to allow other admin devices to accept the request made. [NYI] The initial request is sent to the service [NYI] The service returns an acknowledgement giving the Witness value. Note that this is not a 'reply' since it comes from the service, not the user. [NYI] [Note, this mechanism should be revised to ensure that there is perfect forward secrecy. The device should provide a nonce key as a mixin] 6.3. Contact A contact request presents a proposed contact entry and requests that it be added to the Contacts catalog of the specified Mesh Service Account. A contact request is usually sent by the party requesting that their contact be added but this is not necessarily the case. The MessageContact contains a DARE Envelope containing the Contact information of the requester. If the request is accepted, this information will be added to the contact catalog of the relevant account. If the Reply field has the value 'true', this indicates that the sender is asking for the recipient to return their own credentials in reply. Since the sender requires the user's contact information before the request can be made, the MessageContact message MAY be encrypted under either the user's account encryption key (if known) or the Mesh Hallam-Baker Expires April 25, 2020 [Page 31] Internet-Draft Mesh Schema Reference October 2019 Service encryption key (which may be obtained from the service on request. Bob asks Alice to send her contact details and sends his. [NYI] Alice responds with her details: [NYI] [Note that this exchange could be performed automatically on Alice's behalf by the service if she delegates this action to it.] The current protocol assumes that all contact management will be performed end-to-end through the Mesh Services themselves. If the number of Mesh users were to become very large, additional infrastructure to facilitate contact management will be required. These topics are discussed at a high level in [draft-hallambaker-mesh-trust] . In situations where a user is well known and has a very large number of contacts, they are likely to make use of a tiered approach to contact management in which they keep separate accounts for their 'public' and 'restricted' personas and delegate management of their public account to a subordinate or to their Mesh Service provider. 6.4. Confirmation Confirmation messages are used to provide an improved form of second factor authentication capability. Two confirmation messages are specified, a request and response. A confirmation request is initiated by sending a MessageConfirmationRequest to the Mesh Service hosting the recipient Mesh Service Account. The request specifies the question that is to be put to the user. To respond to a confirmation request, a user generates a MessageConfirmationResponse. This MUST be signed by a device authorized to respond to confirmation requests by a Device Connection Assertion with the Confirmation privilege. The confirmation request [NYI] Hallam-Baker Expires April 25, 2020 [Page 32] Internet-Draft Mesh Schema Reference October 2019 The confirmation response [NYI] 7. Schema 7.1. Shared Classes The following classes are used as common elements in Mesh profile specifications. 7.1.1. Classes describing keys 7.1.2. Structure: PublicKey The PublicKey class is used to describe public key pairs and trust assertions associated with a public key. UDF: String (Optional) UDF fingerprint of the public key parameters/ X509Certificate: Binary (Optional) List of X.509 Certificates X509Chain: Binary [0..Many] X.509 Certificate chain. X509CSR: Binary (Optional) X.509 Certificate Signing Request. 7.1.3. Structure: KeyComposite Service: String (Optional) Service holding the additional contribution 7.1.4. Structure: KeyOverlay UDF: String (Optional) Fingerprint of the resulting composite key (to allow verification) BaseUDF: String (Optional) Fingerprint specifying the base key 7.1.5. Structure: EscrowedKeySet A set of escrowed keys. [No fields] Hallam-Baker Expires April 25, 2020 [Page 33] Internet-Draft Mesh Schema Reference October 2019 7.1.6. Structure: DeviceRecryptionKey UDF: String (Optional) The fingerprint of the encryption key RecryptionKey: PublicKey (Optional) The recryption key EnvelopedRecryptionKeyDevice: DareEnvelope (Optional) The decryption key encrypted under the user's device key. 7.2. Assertion classes Classes that are derived from an assertion. 7.2.1. Structure: Assertion Parent class from which all assertion classes are derived Names: String [0..Many] Fingerprints of index terms for profile retrieval. The use of the fingerprint of the name rather than the name itself is a precaution against enumeration attacks and other forms of abuse. Updated: DateTime (Optional) The time instant the profile was last modified. NotaryToken: String (Optional) A Uniform Notary Token providing evidence that a signature was performed after the notary token was created. 7.2.2. Structure: Condition Parent class from which all condition classes are derived. [No fields] 7.2.3. Profile Classes Profiles are self signed assertions. 7.2.4. Structure: Profile Inherits: Assertion Parent class from which all profile classes are derived KeyOfflineSignature: PublicKey (Optional) The permanent signature key used to sign the profile itself. The UDF of the key is used as the permanent object identifier of the profile. Thus, by Hallam-Baker Expires April 25, 2020 [Page 34] Internet-Draft Mesh Schema Reference October 2019 definition, the KeySignature value of a Profile does not change under any circumstance. The only case in which a KeysOnlineSignature: PublicKey [0..Many] A Personal profile contains at least one OSK which is used to sign device administration application profiles. 7.2.5. Structure: ProfileMesh Inherits: Profile Describes the long term parameters associated with a personal profile. KeysMasterEscrow: PublicKey [0..Many] A Personal Profile MAY contain one or more PMEK keys to enable escrow of private keys used for stored data. KeyEncryption: PublicKey (Optional) Key used to pass encrypted data to the device such as a DeviceUseEntry 7.2.6. Structure: ProfileDevice Inherits: Profile Describes a mesh device. Description: String (Optional) Description of the device KeyEncryption: PublicKey (Optional) Key used to pass encrypted data to the device such as a DeviceUseEntry KeyAuthentication: PublicKey (Optional) Key used to authenticate requests made by the device. 7.2.7. Structure: ProfileService Inherits: Profile Profile of a Mesh Service KeyAuthentication: PublicKey (Optional) Key used to authenticate service connections. Hallam-Baker Expires April 25, 2020 [Page 35] Internet-Draft Mesh Schema Reference October 2019 7.2.8. Structure: ProfileAccount Inherits: Profile Account assertion. This is signed by the service hosting the account. ServiceIDs: String [0..Many] Service address(es). MeshProfileUDF: String (Optional) Master profile of the account being registered. KeyEncryption: PublicKey (Optional) Key used to encrypt data under this profile 7.2.9. Structure: ProfileGroup Inherits: Profile Describes a group. Note that while a group is created by one person who becomes its first administrator, control of the group may pass to other administrators over time. [No fields] 7.2.10. Structure: ProfileHost Inherits: Profile Inherits: Profile KeyAuthentication: PublicKey (Optional) Key used to authenticate service connections. 7.2.11. Connection Classes 7.2.12. Structure: Connection Inherits: Assertion Inherits: Assertion SubjectUDF: String (Optional) UDF of the connection target. AuthorityUDF: String (Optional) UDF of the connection source. Hallam-Baker Expires April 25, 2020 [Page 36] Internet-Draft Mesh Schema Reference October 2019 7.2.13. Structure: Permission Name: String (Optional) Name: String (Optional) Role: String (Optional) Role: String (Optional) Capabilities: DareEnvelope (Optional) Keys or key contributions enabling the operation to be performed 7.2.14. Structure: ConnectionDevice Inherits: Connection Inherits: Connection Permissions: Permission [0..Many] List of the permissions that the device has been granted. KeySignature: PublicKey (Optional) The signature key for use of the device under the profile KeyEncryption: PublicKey (Optional) The encryption key for use of the device under the profile KeyAuthentication: PublicKey (Optional) The authentication key for use of the device under the profile 7.2.15. Structure: ConnectionAccount Inherits: Connection Inherits: Connection ServiceID: String [0..Many] The list of service identifiers. Permissions: Permission [0..Many] List of the permissions that the device has been granted. KeySignature: PublicKey (Optional) The signature key for use of the device under the profile KeyEncryption: PublicKey (Optional) The encryption key for use of the device under the profile Hallam-Baker Expires April 25, 2020 [Page 37] Internet-Draft Mesh Schema Reference October 2019 KeyAuthentication: PublicKey (Optional) The authentication key for use of the device under the profile 7.2.16. Structure: ConnectionService Inherits: Connection [No fields] 7.2.17. Structure: ConnectionHost Inherits: Connection [No fields] 7.2.18. Structure: ConnectionApplication Inherits: Connection [No fields] 7.2.19. Activation Classes 7.2.20. Structure: Activation Inherits: Assertion Contains the private activation information for a Mesh application running on a specific device [No fields] 7.2.21. Structure: ActivationDevice Inherits: Assertion Inherits: Assertion EnvelopedAssertionDeviceConnection: DareEnvelope (Optional) The signed AssertionDeviceConnection. KeySignature: KeyOverlay (Optional) The key overlay used to generate the account signature key from the device signature key KeyEncryption: KeyOverlay (Optional) The key overlay used to generate the account encryption key from the device encryption key Hallam-Baker Expires April 25, 2020 [Page 38] Internet-Draft Mesh Schema Reference October 2019 KeyAuthentication: KeyOverlay (Optional) The key overlay used to generate the account authentication key from the device authentication key 7.2.22. Structure: ActivationAccount Inherits: Activation Inherits: Activation AccountUDF: String (Optional) The UDF of the account KeyGroup: KeyComposite (Optional) The key contribution for the decryption key for the device. NB this is NOT an overlay on the device signature key, it is an overlay on the corresponding recryption key. KeyEncryption: KeyOverlay (Optional) The key overlay used to generate the account encryption key from the device encryption key KeyAuthentication: KeyOverlay (Optional) The key overlay used to generate the account authentication key from the device authentication key KeySignature: KeyOverlay (Optional) The key overlay used to generate the account signature key from the device signature key 7.3. Cataloged items 7.3.1. Data Structures Classes describing data used in cataloged data. 7.3.2. Structure: Contact Inherits: Assertion Inherits: Assertion Identifier: String (Optional) Identifier: String (Optional) FullName: String (Optional) FullName: String (Optional) Title: String (Optional) Hallam-Baker Expires April 25, 2020 [Page 39] Internet-Draft Mesh Schema Reference October 2019 Title: String (Optional) First: String (Optional) First: String (Optional) Middle: String (Optional) Middle: String (Optional) Last: String (Optional) Last: String (Optional) Suffix: String (Optional) Suffix: String (Optional) Labels: String [0..Many] Labels: String [0..Many] AssertionAccounts: ProfileAccount [0..Many] AssertionAccounts: ProfileAccount [0..Many] Addresses: Address [0..Many] Addresses: Address [0..Many] Locations: Location [0..Many] Locations: Location [0..Many] Roles: Role [0..Many] 7.3.3. Structure: Role CompanyName: String (Optional) CompanyName: String (Optional) Addresses: Address [0..Many] Addresses: Address [0..Many] Locations: Location [0..Many] Hallam-Baker Expires April 25, 2020 [Page 40] Internet-Draft Mesh Schema Reference October 2019 7.3.4. Structure: Address URI: String (Optional) URI: String (Optional) Labels: String [0..Many] 7.3.5. Structure: Location Appartment: String (Optional) Appartment: String (Optional) Street: String (Optional) Street: String (Optional) District: String (Optional) District: String (Optional) Locality: String (Optional) Locality: String (Optional) County: String (Optional) County: String (Optional) Postcode: String (Optional) Postcode: String (Optional) Country: String (Optional) 7.3.6. Structure: Reference MessageID: String (Optional) The received message to which this is a response ResponseID: String (Optional) Message that was generated in response to the original (optional). Relationship: String (Optional) The relationship type. This can be Read, Unread, Accept, Reject. Hallam-Baker Expires April 25, 2020 [Page 41] Internet-Draft Mesh Schema Reference October 2019 7.3.7. Structure: Task Key: String (Optional) Unique key. Start: DateTime (Optional) Start: DateTime (Optional) Finish: DateTime (Optional) Finish: DateTime (Optional) StartTravel: String (Optional) StartTravel: String (Optional) FinishTravel: String (Optional) FinishTravel: String (Optional) TimeZone: String (Optional) TimeZone: String (Optional) Title: String (Optional) Title: String (Optional) Description: String (Optional) Description: String (Optional) Location: String (Optional) Location: String (Optional) Trigger: String [0..Many] Trigger: String [0..Many] Conference: String [0..Many] Conference: String [0..Many] Repeat: String (Optional) Repeat: String (Optional) Hallam-Baker Expires April 25, 2020 [Page 42] Internet-Draft Mesh Schema Reference October 2019 Busy: Boolean (Optional) 7.4. Catalog Entries 7.4.1. Structure: CatalogedEntry Base class for cataloged Mesh data. [No fields] 7.4.2. Structure: CatalogedDevice Inherits: CatalogedEntry Public device entry, indexed under the device ID UDF: String (Optional) UDF of the signature key of the device in the Mesh DeviceUDF: String (Optional) UDF of the signature key of the device EnvelopedProfileDevice: DareEnvelope (Optional) The device profile EnvelopedConnectionDevice: DareEnvelope (Optional) The public assertion demonstrating connection of the Device to the Mesh EnvelopedActivationDevice: DareEnvelope (Optional) The activations of the device within the Mesh Accounts: AccountEntry [0..Many] The accounts that this device is connected to 7.4.3. Structure: AccountEntry AccountUDF: String (Optional) UDF of the account profile EnvelopedProfileAccount: DareEnvelope (Optional) The account profile EnvelopedConnectionAccount: DareEnvelope (Optional) The connection of this device to the account EnvelopedActivationAccount: DareEnvelope (Optional) The activation data for this device to the account Hallam-Baker Expires April 25, 2020 [Page 43] Internet-Draft Mesh Schema Reference October 2019 7.4.4. Structure: CatalogedCredential Inherits: CatalogedEntry Inherits: CatalogedEntry Protocol: String (Optional) Protocol: String (Optional) Service: String (Optional) Service: String (Optional) Username: String (Optional) Username: String (Optional) Password: String (Optional) 7.4.5. Structure: CatalogedNetwork Inherits: CatalogedEntry Inherits: CatalogedEntry Protocol: String (Optional) Protocol: String (Optional) Service: String (Optional) Service: String (Optional) Username: String (Optional) Username: String (Optional) Password: String (Optional) 7.4.6. Structure: CatalogedContact Inherits: CatalogedEntry Inherits: CatalogedEntry Self: Boolean (Optional) If true, this catalog entry is for the user who created the catalog. To be valid, such an entry MUST be Hallam-Baker Expires April 25, 2020 [Page 44] Internet-Draft Mesh Schema Reference October 2019 signed by an administration key for the Mesh profile containing the account to which the catalog belongs. Key: String (Optional) Unique key. Permissions: Permission [0..Many] List of the permissions that the contact has been granted. EnvelopedContact: DareEnvelope (Optional) The (signed) contact data. 7.4.7. Structure: CatalogedContactRecryption Inherits: CatalogedContact [No fields] 7.4.8. Structure: CatalogedBookmark Inherits: CatalogedEntry Inherits: CatalogedEntry Uri: String (Optional) Uri: String (Optional) Title: String (Optional) Title: String (Optional) Path: String (Optional) 7.4.9. Structure: CatalogedTask Inherits: CatalogedEntry Inherits: CatalogedEntry EnvelopedTask: DareEnvelope (Optional) EnvelopedTask: DareEnvelope (Optional) Key: String (Optional) Unique key. Hallam-Baker Expires April 25, 2020 [Page 45] Internet-Draft Mesh Schema Reference October 2019 7.4.10. Structure: CatalogedApplication Inherits: CatalogedEntry Inherits: CatalogedEntry Key: String (Optional) 7.4.11. Structure: CatalogedMember UDF: String (Optional) UDF: String (Optional) Inherits: CatalogedEntry 7.4.12. Structure: CatalogedGroup Inherits: CatalogedApplication [No fields] 7.4.13. Structure: CatalogedApplicationSSH Inherits: CatalogedApplication [No fields] 7.4.14. Structure: CatalogedApplicationMail Inherits: CatalogedApplication [No fields] 7.4.15. Structure: CatalogedApplicationNetwork Inherits: CatalogedApplication [No fields] 7.5. Messages 7.5.1. Structure: Message MessageID: String (Optional) MessageID: String (Optional) Hallam-Baker Expires April 25, 2020 [Page 46] Internet-Draft Mesh Schema Reference October 2019 Sender: String (Optional) Sender: String (Optional) Recipient: String (Optional) Recipient: String (Optional) References: Reference [0..Many] 7.5.2. Structure: MessageComplete Inherits: Message [No fields] 7.5.3. Structure: MessagePIN Account: String (Optional) Account: String (Optional) Inherits: Message Inherits: Message Expires: DateTime (Optional) Expires: DateTime (Optional) PIN: String (Optional) 7.5.4. Structure: RequestConnection Connection request message. This message contains the information Inherits: Message Inherits: Message ServiceID: String (Optional) ServiceID: String (Optional) EnvelopedProfileDevice: DareEnvelope (Optional) Device profile of the device making the request. ClientNonce: Binary (Optional) Hallam-Baker Expires April 25, 2020 [Page 47] Internet-Draft Mesh Schema Reference October 2019 ClientNonce: Binary (Optional) PinUDF: String (Optional) Fingerprint of the PIN value used to authenticate the request. 7.5.5. Structure: AcknowledgeConnection Connection request message generated by a service on receipt of a valid MessageConnectionRequestClient Inherits: Message Inherits: Message EnvelopedRequestConnection: DareEnvelope (Optional) The client connection request. ServerNonce: Binary (Optional) ServerNonce: Binary (Optional) Witness: String (Optional) 7.5.6. Structure: OfferGroup Inherits: Message [No fields] 7.5.7. Structure: RequestContact Inherits: Message Inherits: Message Reply: Boolean (Optional) Reply: Boolean (Optional) Subject: String (Optional) Subject: String (Optional) Self: DareEnvelope (Optional) The contact data. Hallam-Baker Expires April 25, 2020 [Page 48] Internet-Draft Mesh Schema Reference October 2019 7.5.8. Structure: ReplyContact Inherits: RequestContact [No fields] 7.5.9. Structure: RequestConfirmation Inherits: Message Inherits: Message Text: String (Optional) 7.5.10. Structure: ResponseConfirmation Inherits: Message Inherits: Message Request: RequestConfirmation (Optional) Request: RequestConfirmation (Optional) Accept: Boolean (Optional) 7.5.11. Structure: RequestTask Inherits: Message [No fields] 8. Security Considerations The security considerations for use and implementation of Mesh services and applications are described in the Mesh Security Considerations guide [draft-hallambaker-mesh-security] . 9. IANA Considerations All the IANA considerations for the Mesh documents are specified in this document 10. Acknowledgements A list of people who have contributed to the design of the Mesh is presented in [draft-hallambaker-mesh-architecture] . Hallam-Baker Expires April 25, 2020 [Page 49] Internet-Draft Mesh Schema Reference October 2019 11. Appendix A: Example Container Organization (not normative) The means by which profiles are stored on devices is outside the scope of the specification. Only catalogs that are required to be shared between machines by means of accounts need to be standardized. 11.1. Device Host Catalog: Host.dare Catalog of all the Mesh Profiles that the user has registered with the device and the latest version of the device profile for this device. MeshCatalog: [UDF-Mesh].dcat Catalog containing the Account Entries for the Mesh [UDF-Mesh]. Account Catalogs: [UDF-Account]/mmm_Device.dcat The device catalog associated with the specified account Account Catalogs: [UDF-Account]/[Catalog name].dcat The set of account catalogs that are shared verbatim between the devices connected to the account. 11.1.1. Creating a new Mesh Create new Mesh Profile, Device Profile, Add to Host Catalog Create MeshCatalog 11.1.2. Adding an Account Create new Account Profile, Add to MeshCatalog Create new Account Device Catalog For each device to be added to the account: Create Account Connection Assertion, add to Account Device Catalog. 11.1.3. Adding a Device Create a Device Connection Assertion. For each account the device is to be added to: Create Account Connection Assertion, add to Account Device Catalog. Hallam-Baker Expires April 25, 2020 [Page 50] Internet-Draft Mesh Schema Reference October 2019 11.2. Service Master Catalog Catalog of all services on machine Service Catalog Catalog of accounts in the service. 11.2.1. Creating a Service Create a Service Description, add to Master Catalog 11.2.2. Adding an Account Create the account entry, add to Service Catalog Create the Account Directory 12. References 12.1. Normative References [draft-hallambaker-mesh-architecture] Hallam-Baker, P., "Mathematical Mesh 3.0 Part I: Architecture Guide", draft-hallambaker-mesh- architecture-10 (work in progress), August 2019. [draft-hallambaker-mesh-cryptography] Hallam-Baker, P., "Mathematical Mesh 3.0 Part VIII: Cryptographic Algorithms", draft-hallambaker-mesh- cryptography-02 (work in progress), July 2019. [draft-hallambaker-mesh-notary] "[Reference Not Found!]". [draft-hallambaker-mesh-protocol] Hallam-Baker, P., "Mathematical Mesh 3.0 Part V: Protocol Reference", draft-hallambaker-mesh-protocol-02 (work in progress), August 2019. [draft-hallambaker-mesh-security] Hallam-Baker, P., "Mathematical Mesh Part VII: Security Considerations", draft-hallambaker-mesh-security-01 (work in progress), July 2019. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. Hallam-Baker Expires April 25, 2020 [Page 51] Internet-Draft Mesh Schema Reference October 2019 12.2. Informative References [draft-hallambaker-mesh-developer] Hallam-Baker, P., "Mathematical Mesh: Reference Implementation", draft-hallambaker-mesh-developer-08 (work in progress), April 2019. [draft-hallambaker-mesh-trust] Hallam-Baker, P., "Mathematical Mesh Part VI: The Trust Mesh", draft-hallambaker-mesh-trust-02 (work in progress), July 2019. [RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile", RFC 2426, DOI 10.17487/RFC2426, September 1998. [RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 5545, DOI 10.17487/RFC5545, September 2009. 12.3. URIs [1] http://mathmesh.com/Documents/draft-hallambaker-mesh-schema.html [2] http://mathmesh.com/Documents/draft-hallambaker-mesh-schema.html [3] http://mathmesh.com/Documents/draft-hallambaker-mesh-schema.html [4] http://mathmesh.com/Documents/draft-hallambaker-mesh-schema.html [5] http://mathmesh.com/Documents/draft-hallambaker-mesh-schema.html [6] http://mathmesh.com/Documents/draft-hallambaker-mesh-schema.html [7] http://mathmesh.com/Documents/draft-hallambaker-mesh-schema.html [8] http://mathmesh.com/Documents/draft-hallambaker-mesh-schema.html [9] http://mathmesh.com/Documents/draft-hallambaker-mesh-schema.html [10] http://mathmesh.com/Documents/draft-hallambaker-mesh-schema.html Author's Address Phillip Hallam-Baker Email: phill@hallambaker.com Hallam-Baker Expires April 25, 2020 [Page 52]