Internet DRAFT - draft-hallambaker-mesh-schema

draft-hallambaker-mesh-schema







Network Working Group                                 P. M. Hallam-Baker
Internet-Draft                                           16 January 2020
Intended status: Informational                                          
Expires: 19 July 2020


            Mathematical Mesh 3.0 Part IV: Schema Reference
                    draft-hallambaker-mesh-schema-05

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.

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 19 July 2020.

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Hallam-Baker              Expires 19 July 2020                  [Page 1]

Internet-Draft            Mesh Schema Reference             January 2020


   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.

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 . . . . . . . . . . . . . . . . . . . . . .  18
       4.2.1.  Creating a ProfileAccount . . . . . . . . . . . . . .  20
       4.2.2.  Connecting a Device to an Account . . . . . . . . . .  20
       4.2.3.  Binding and Account to a Service  . . . . . . . . . .  21
     4.3.  Mesh Services . . . . . . . . . . . . . . . . . . . . . .  21
       4.3.1.  Creating a ProfileService . . . . . . . . . . . . . .  22
       4.3.2.  Creating a ProfileHost  . . . . . . . . . . . . . . .  23
       4.3.3.  Creating a ConnectionHost . . . . . . . . . . . . . .  23
     4.4.  Mesh Messaging  . . . . . . . . . . . . . . . . . . . . .  23
       4.4.1.  Traffic Analysis  . . . . . . . . . . . . . . . . . .  24
   5.  Mesh Catalogs . . . . . . . . . . . . . . . . . . . . . . . .  24
     5.1.  Application . . . . . . . . . . . . . . . . . . . . . . .  26
       5.1.1.  Mesh Account  . . . . . . . . . . . . . . . . . . . .  26
       5.1.2.  SSH . . . . . . . . . . . . . . . . . . . . . . . . .  26
       5.1.3.  Mail  . . . . . . . . . . . . . . . . . . . . . . . .  27
     5.2.  Device  . . . . . . . . . . . . . . . . . . . . . . . . .  27
     5.3.  Contact . . . . . . . . . . . . . . . . . . . . . . . . .  27
     5.4.  Credential  . . . . . . . . . . . . . . . . . . . . . . .  27
     5.5.  Bookmark  . . . . . . . . . . . . . . . . . . . . . . . .  28
     5.6.  Task  . . . . . . . . . . . . . . . . . . . . . . . . . .  28
     5.7.  Network . . . . . . . . . . . . . . . . . . . . . . . . .  28
   6.  Mesh Messages . . . . . . . . . . . . . . . . . . . . . . . .  29
     6.1.  Completion  . . . . . . . . . . . . . . . . . . . . . . .  29
     6.2.  Connection  . . . . . . . . . . . . . . . . . . . . . . .  29
     6.3.  Contact . . . . . . . . . . . . . . . . . . . . . . . . .  30



Hallam-Baker              Expires 19 July 2020                  [Page 2]

Internet-Draft            Mesh Schema Reference             January 2020


     6.4.  Confirmation  . . . . . . . . . . . . . . . . . . . . . .  31
   7.  Schema  . . . . . . . . . . . . . . . . . . . . . . . . . . .  31
     7.1.  Shared Classes  . . . . . . . . . . . . . . . . . . . . .  32
       7.1.1.  Classes describing keys . . . . . . . . . . . . . . .  32
       7.1.2.  Structure: PublicKey  . . . . . . . . . . . . . . . .  32
       7.1.3.  Structure: KeyComposite . . . . . . . . . . . . . . .  32
       7.1.4.  Structure: DeviceRecryptionKey  . . . . . . . . . . .  32
       7.1.5.  Structure: KeyOverlay . . . . . . . . . . . . . . . .  32
       7.1.6.  Structure: EscrowedKeySet . . . . . . . . . . . . . .  32
     7.2.  Assertion classes . . . . . . . . . . . . . . . . . . . .  33
       7.2.1.  Structure: Assertion  . . . . . . . . . . . . . . . .  33
       7.2.2.  Structure: Condition  . . . . . . . . . . . . . . . .  33
       7.2.3.  Profile Classes . . . . . . . . . . . . . . . . . . .  33
       7.2.4.  Structure: Profile  . . . . . . . . . . . . . . . . .  33
       7.2.5.  Structure: ProfileMesh  . . . . . . . . . . . . . . .  33
       7.2.6.  Structure: ProfileDevice  . . . . . . . . . . . . . .  34
       7.2.7.  Structure: ProfileService . . . . . . . . . . . . . .  34
       7.2.8.  Structure: ProfileAccount . . . . . . . . . . . . . .  34
       7.2.9.  Structure: ProfileGroup . . . . . . . . . . . . . . .  35
       7.2.10. Structure: ProfileHost  . . . . . . . . . . . . . . .  35
       7.2.11. Connection Classes  . . . . . . . . . . . . . . . . .  35
       7.2.12. Structure: Connection . . . . . . . . . . . . . . . .  35
       7.2.13. Structure: Permission . . . . . . . . . . . . . . . .  35
       7.2.14. Structure: ConnectionDevice . . . . . . . . . . . . .  35
       7.2.15. Structure: ConnectionAccount  . . . . . . . . . . . .  36
       7.2.16. Structure: ConnectionGroup  . . . . . . . . . . . . .  36
       7.2.17. Structure: ConnectionService  . . . . . . . . . . . .  36
       7.2.18. Structure: ConnectionHost . . . . . . . . . . . . . .  36
       7.2.19. Structure: ConnectionApplication  . . . . . . . . . .  37
       7.2.20. Activation Classes  . . . . . . . . . . . . . . . . .  37
       7.2.21. Structure: Activation . . . . . . . . . . . . . . . .  37
       7.2.22. Structure: ActivationDevice . . . . . . . . . . . . .  37
       7.2.23. Structure: ActivationAccount  . . . . . . . . . . . .  37
       7.2.24. Structure: ActivationGroup  . . . . . . . . . . . . .  38
     7.3.  Cataloged items . . . . . . . . . . . . . . . . . . . . .  38
       7.3.1.  Data Structures . . . . . . . . . . . . . . . . . . .  38
       7.3.2.  Structure: ContactMesh  . . . . . . . . . . . . . . .  38
       7.3.3.  Structure: Contact  . . . . . . . . . . . . . . . . .  38
       7.3.4.  Structure: Role . . . . . . . . . . . . . . . . . . .  39
       7.3.5.  Structure: Address  . . . . . . . . . . . . . . . . .  39
       7.3.6.  Structure: Location . . . . . . . . . . . . . . . . .  39
       7.3.7.  Structure: Reference  . . . . . . . . . . . . . . . .  39
       7.3.8.  Structure: Task . . . . . . . . . . . . . . . . . . .  40
     7.4.  Catalog Entries . . . . . . . . . . . . . . . . . . . . .  40
       7.4.1.  Structure: CatalogedEntry . . . . . . . . . . . . . .  40
       7.4.2.  Structure: CatalogedDevice  . . . . . . . . . . . . .  40
       7.4.3.  Structure: AccountEntry . . . . . . . . . . . . . . .  41
       7.4.4.  Structure: CatalogedCredential  . . . . . . . . . . .  41



Hallam-Baker              Expires 19 July 2020                  [Page 3]

Internet-Draft            Mesh Schema Reference             January 2020


       7.4.5.  Structure: CatalogedNetwork . . . . . . . . . . . . .  41
       7.4.6.  Structure: CatalogedContact . . . . . . . . . . . . .  42
       7.4.7.  Structure: CatalogedContactRecryption . . . . . . . .  42
       7.4.8.  Structure: CatalogedBookmark  . . . . . . . . . . . .  42
       7.4.9.  Structure: CatalogedTask  . . . . . . . . . . . . . .  42
       7.4.10. Structure: CatalogedApplication . . . . . . . . . . .  42
       7.4.11. Structure: CatalogedMember  . . . . . . . . . . . . .  43
       7.4.12. Structure: CatalogedGroup . . . . . . . . . . . . . .  43
       7.4.13. Structure: CatalogedApplicationSSH  . . . . . . . . .  43
       7.4.14. Structure: CatalogedApplicationMail . . . . . . . . .  43
       7.4.15. Structure: CatalogedApplicationNetwork  . . . . . . .  43
     7.5.  Messages  . . . . . . . . . . . . . . . . . . . . . . . .  43
       7.5.1.  Structure: Message  . . . . . . . . . . . . . . . . .  43
       7.5.2.  Structure: MessageComplete  . . . . . . . . . . . . .  43
       7.5.3.  Structure: MessagePIN . . . . . . . . . . . . . . . .  44
       7.5.4.  Structure: RequestConnection  . . . . . . . . . . . .  44
       7.5.5.  Structure: AcknowledgeConnection  . . . . . . . . . .  44
       7.5.6.  Structure: OfferGroup . . . . . . . . . . . . . . . .  44
       7.5.7.  Structure: RequestContact . . . . . . . . . . . . . .  45
       7.5.8.  Structure: ReplyContact . . . . . . . . . . . . . . .  45
       7.5.9.  Structure: GroupInvitation  . . . . . . . . . . . . .  45
       7.5.10. Structure: RequestConfirmation  . . . . . . . . . . .  45
       7.5.11. Structure: ResponseConfirmation . . . . . . . . . . .  45
       7.5.12. Structure: RequestTask  . . . . . . . . . . . . . . .  45
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  46
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  46
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  46
   11. Appendix A: Example Container Organization (not normative)  .  46
     11.1.  Device . . . . . . . . . . . . . . . . . . . . . . . . .  46
       11.1.1.  Creating a new Mesh  . . . . . . . . . . . . . . . .  46
       11.1.2.  Adding an Account  . . . . . . . . . . . . . . . . .  46
       11.1.3.  Adding a Device  . . . . . . . . . . . . . . . . . .  47
     11.2.  Service  . . . . . . . . . . . . . . . . . . . . . . . .  47
       11.2.1.  Creating a Service . . . . . . . . . . . . . . . . .  47
       11.2.2.  Adding an Account  . . . . . . . . . . . . . . . . .  47
   12. Appendix B: Collected Authentication and Encryption
        Requirements . . . . . . . . . . . . . . . . . . . . . . . .  47
     12.1.  Mesh Messaging . . . . . . . . . . . . . . . . . . . . .  47
   13. Normative References  . . . . . . . . . . . . . . . . . . . .  48
   14. Informative References  . . . . . . . . . . . . . . . . . . .  49











Hallam-Baker              Expires 19 July 2020                  [Page 4]

Internet-Draft            Mesh Schema Reference             January 2020


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 19 July 2020                  [Page 5]

Internet-Draft            Mesh Schema Reference             January 2020


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:

   (Artwork only available as svg: No external link available, see
   draft-hallambaker-mesh-schema-05.html for artwork.)

                                  Figure 1

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
   clauses in a SAML assertion to determine validity.  Mesh Relying




Hallam-Baker              Expires 19 July 2020                  [Page 6]

Internet-Draft            Mesh Schema Reference             January 2020


   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:

   *  Profiles describe credentials, they do not make identity
      statements

   *  Profiles do not expire, there is therefore no need to support
      renewal processing.

   *  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:

   *  There is a "SignatureKey" field.

   *  The profile is signed under the key specified in the
      "SignatureKey" field.

   A profile has the status "current" if and only if:



Hallam-Baker              Expires 19 July 2020                  [Page 7]

Internet-Draft            Mesh Schema Reference             January 2020


   *  The Profile is valid

   *  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:

   (Artwork only available as svg: No external link available, see
   draft-hallambaker-mesh-schema-05.html for artwork.)




Hallam-Baker              Expires 19 July 2020                  [Page 8]

Internet-Draft            Mesh Schema Reference             January 2020


                                  Figure 2

   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.

   (Artwork only available as svg: No external link available, see
   draft-hallambaker-mesh-schema-05.html for artwork.)

                                  Figure 3

   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
   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:







Hallam-Baker              Expires 19 July 2020                  [Page 9]

Internet-Draft            Mesh Schema Reference             January 2020


   {
     "ProfileMesh":{
       "KeyOfflineSignature":{
         "UDF":"MCSC-2POG-PH7T-ODJX-HOCA-B4XY-AFSK",
         "PublicParameters":{
           "PublicKeyECDH":{
             "crv":"Ed448",
             "Public":"AqOm-eLsUPySPkemMvVIJctXUSTa6EC5c_w0kLHZCh4xLlF
     ow4SJzsDj2xSX5ofUl1XcuCBj9qaA"}}},
       "KeysOnlineSignature":[{
           "UDF":"MDI7-LMMT-LTJE-6C5Z-AFZN-6OXW-YLW3",
           "PublicParameters":{
             "PublicKeyECDH":{
               "crv":"Ed448",
               "Public":"tQhM2lUiBnKgk9PASigebdZH18nDC4qFSZIJgmwTPYrpd
     AKsSnuZPH7UPu3AtYjFF8aGMyyF8UuA"}}}
         ],
       "KeyEncryption":{
         "UDF":"MATS-37J5-26DG-MYUR-7BMU-PPJJ-UUO4",
         "PublicParameters":{
           "PublicKeyECDH":{
             "crv":"Ed448",
             "Public":"SUJNzpDLHT9dxOyYdzfuhPL0mkR1tw-JTjuIVgU7X-bFqi2
     z66efQv1cwSeVL-oZn2COpIHN-lKA"}}}}}

4.1.1.1.  Creating a ProfileMaster

   Creating a "ProfileMaster" comprises the steps of:

   0.  Creating a Master Signature key.

   1.  Creating an Online Signing Key

   2.  Signing the "ProfileMaster" using the Master Signature Key

   3.  Persisting the "ProfileMaster" on the administration device to
       the "CatalogHost".

   4.  (Optional) Connecting at least one Administration Device and
       granting it the "ActivationAdministration" activation.

4.1.1.2.  Updating a ProfileMaster

   Updating a "ProfileMaster" comprises the steps of:

   0.  Making the necessary changes.

   1.  Signing the ProfileMaster using the Master Signature Key



Hallam-Baker              Expires 19 July 2020                 [Page 10]

Internet-Draft            Mesh Schema Reference             January 2020


   2.  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:

   (Artwork only available as svg: No external link available, see
   draft-hallambaker-mesh-schema-05.html for artwork.)

                                  Figure 4

   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



Hallam-Baker              Expires 19 July 2020                 [Page 11]

Internet-Draft            Mesh Schema Reference             January 2020


   multiple profiles if this approach is more convenient for
   implementation.

   Alice's Device Profile specifies keys for encryption, signature and
   exchange:

   {
     "ProfileDevice":{
       "KeyOfflineSignature":{
         "UDF":"MCYS-TOQJ-CDAX-EDU7-6EZ3-OLPG-KMLG",
         "PublicParameters":{
           "PublicKeyECDH":{
             "crv":"Ed448",
             "Public":"m54L_jENmDdwE9vFeDZgBuJHbV3HTZxWr6Ep-tVdQhudcpw
     25rOBvp6l5OhKbNUfoKRWFKTS93qA"}}},
       "KeyEncryption":{
         "UDF":"MCZP-AMNO-JHWY-ZQ22-N3ZP-V2KW-52JE",
         "PublicParameters":{
           "PublicKeyECDH":{
             "crv":"Ed448",
             "Public":"W-E1XmOgjze4ozrhkkft5nV_Zcr90En9vT6WswBe3VBCrxW
     RKGI48Ud9EWSDlJfEqQWRbhMyZp0A"}}},
       "KeyAuthentication":{
         "UDF":"MDYO-XAHJ-RXT6-YO4J-X7WV-L3IW-5NEP",
         "PublicParameters":{
           "PublicKeyECDH":{
             "crv":"Ed448",
             "Public":"OlJMs9_Dcm7XuFzvbypI5WC3xLLgPOjohsg5dkqA61gCfsF
     9J4syqcZnOFrAsk-pFWFDm0DESoAA"}}}}}

   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:

   $$$$ Empty $$$$

   The resulting key set is specified in the device connection:












Hallam-Baker              Expires 19 July 2020                 [Page 12]

Internet-Draft            Mesh Schema Reference             January 2020


   {
     "ConnectionDevice":{
       "KeySignature":{
         "UDF":"MBPL-MIIT-KOHN-FC6P-6V5Y-ZQ4R-3NKY",
         "PublicParameters":{
           "PublicKeyECDH":{
             "crv":"Ed448",
             "Public":"D-g5vilsBjZ_6BKRG9O3cl30IrN3hCGNzVO_C6YT5OkOkVC
     IO47FRho9xdoJ8zCcH938WlTDBLeA"}}},
       "KeyEncryption":{
         "UDF":"MBLY-KNQG-YT6V-ENLJ-KMIT-MRYT-YOHQ",
         "PublicParameters":{
           "PublicKeyECDH":{
             "crv":"Ed448",
             "Public":"aEe3u24gwMh-ygY0HqjVbBxzFEYJyPVhB_h1-Ma3F_nz6Ae
     vA0fSMaJKprA-qv-JpHSsMCbA74iA"}}},
       "KeyAuthentication":{
         "UDF":"MDVV-QJE7-UYR4-24TQ-JK54-QDTU-BZF3",
         "PublicParameters":{
           "PublicKeyECDH":{
             "crv":"Ed448",
             "Public":"kV_ODrLu4jWdT0hJibnEcujjxu-E4ofRlI7o2eyy3eSbGaA
     EES0KYv5N8BaawmWP67athBZZDjeA"}}}}}

   All the above are combined to form the CatalogedDevice entry:

   {
     "CatalogedDevice":{
       "UDF":"MBPL-MIIT-KOHN-FC6P-6V5Y-ZQ4R-3NKY",
       "DeviceUDF":"MCYS-TOQJ-CDAX-EDU7-6EZ3-OLPG-KMLG",
       "EnvelopedProfileDevice":[{
           "dig":"SHA2"},
         "ewogICJQcm9maWxlRGV2aWNlIjogewogICAgIktleU9mZmxpbmVTaWduYXR1
     cmUiOiB7CiAgICAgICJVREYiOiAiTUNZUy1UT1FKLUNEQVgtRURVNy02RVozLU9MU
     EctS01MRyIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdW
     JsaWNLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6ICJFZDQ0OCIsCiAgICAgICA
     gICAiUHVibGljIjogIm01NExfakVObURkd0U5dkZlRFpnQnVKSGJWM0hUWnhXcjZF
     cC10VmRRaHVkY3B3MjVyT0IKICB2cDZsNU9oS2JOVWZvS1JXRktUUzkzcUEifX19L
     AogICAgIktleUVuY3J5cHRpb24iOiB7CiAgICAgICJVREYiOiAiTUNaUC1BTU5PLU
     pIV1ktWlEyMi1OM1pQLVYyS1ctNTJKRSIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJ
     zIjogewogICAgICAgICJQdWJsaWNLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6
     ICJFZDQ0OCIsCiAgICAgICAgICAiUHVibGljIjogIlctRTFYbU9nanplNG96cmhra
     2Z0NW5WX1pjcjkwRW45dlQ2V3N3QmUzVkJDcnhXUktHSTQKICA4VWQ5RVdTRGxKZk
     VxUVdSYmhNeVpwMEEifX19LAogICAgIktleUF1dGhlbnRpY2F0aW9uIjogewogICA
     gICAiVURGIjogIk1EWU8tWEFISi1SWFQ2LVlPNEotWDdXVi1MM0lXLTVORVAiLAog
     ICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgICAiUHVibGljS2V5RUNES
     CI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICAgICAgIlB1YmxpYy
     I6ICJPbEpNczlfRGNtN1h1Rnp2YnlwSTVXQzN4TExnUE9qb2hzZzVka3FBNjFnQ2Z



Hallam-Baker              Expires 19 July 2020                 [Page 13]

Internet-Draft            Mesh Schema Reference             January 2020


     zRjlKNHN5CiAgcWNabk9GckFzay1wRldGRG0wREVTb0FBIn19fX19",
         {
           "signatures":[{
               "alg":"SHA2",
               "kid":"MCYS-TOQJ-CDAX-EDU7-6EZ3-OLPG-KMLG",
               "signature":"9uexE_-IFBMWisUSR9xLXgJskkYDoYnbXVONBUR0NV
     P5vC5_N2-m4uXUkpN1ClBKcDPhQmX0tk0AjY-xZhrTpdB9GjQmiBSyCGsl5I0VBAh
     y9ogTegiNXyYznYw6cukAHrcRH7_h2dFsv2_WFT8OWTEA"}
             ],
           "PayloadDigest":"Eo6k0vBBU9dfLJA0MTEt87qdGpzCMJi4PEFOxE9w5a
     2AaC3izRZYoobWz0fJ5vjwLEfte-_ggv9wKc8GcITekw"}
         ],
       "EnvelopedConnectionDevice":[{
           "dig":"SHA2"},
         "ewogICJDb25uZWN0aW9uRGV2aWNlIjogewogICAgIktleVNpZ25hdHVyZSI6
     IHsKICAgICAgIlVERiI6ICJNQlBMLU1JSVQtS09ITi1GQzZQLTZWNVktWlE0Ui0zT
     ktZIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0
     tleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIkVkNDQ4IiwKICAgICAgICAgICJ
     QdWJsaWMiOiAiRC1nNXZpbHNCalpfNkJLUkc5TzNjbDMwSXJOM2hDR056Vk9fQzZZ
     VDVPa09rVkNJTzQ3RgogIFJobzl4ZG9KOHpDY0g5MzhXbFREQkxlQSJ9fX0sCiAgI
     CAiS2V5RW5jcnlwdGlvbiI6IHsKICAgICAgIlVERiI6ICJNQkxZLUtOUUctWVQ2Vi
     1FTkxKLUtNSVQtTVJZVC1ZT0hRIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB
     7CiAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIkVk
     NDQ4IiwKICAgICAgICAgICJQdWJsaWMiOiAiYUVlM3UyNGd3TWgteWdZMEhxalZiQ
     nh6RkVZSnlQVmhCX2gxLU1hM0Zfbno2QWV2QTBmUwogIE1hSktwckEtcXYtSnBIU3
     NNQ2JBNzRpQSJ9fX0sCiAgICAiS2V5QXV0aGVudGljYXRpb24iOiB7CiAgICAgICJ
     VREYiOiAiTURWVi1RSkU3LVVZUjQtMjRUUS1KSzU0LVFEVFUtQlpGMyIsCiAgICAg
     ICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdWJsaWNLZXlFQ0RIIjoge
     wogICAgICAgICAgImNydiI6ICJFZDQ0OCIsCiAgICAgICAgICAiUHVibGljIjogIm
     tWX09Eckx1NGpXZFQwaEppYm5FY3Vqanh1LUU0b2ZSbEk3bzJleXkzZVNiR2FBRUV
     TMEsKICBZdjVOOEJhYXdtV1A2N2F0aEJaWkRqZUEifX19fX0",
         {
           "signatures":[{
               "alg":"SHA2",
               "kid":"MDI7-LMMT-LTJE-6C5Z-AFZN-6OXW-YLW3",
               "signature":"R51-7cQTb4f2nK69t77YamP7ny0i9TOw0CdXl0X3dp
     vgSiZ2I1OWbxncJqqkOpj7AW5e7uiOBumAc0j3tiWXSwKIQZAtoUsGvcYFY2Yq11K
     OHC9kMS4ea2Hcu0IMd8tpoIglnJC38ajl_pFBCbrJVAAA"}
             ],
           "PayloadDigest":"Td9sSenLRJHoZ0YtbwztmpadlzOv2AVb9JtOCgnuiX
     X1xwkuJ5KYAAlOoSusI6pyT1iM6TtYYh0hpCSEooizgg"}
         ],
       "EnvelopedActivationDevice":[{
           "enc":"A256CBC",
           "Salt":"Wv42VzJRlBdLKIqwODqHYg",
           "recipients":[{
               "kid":"MCZP-AMNO-JHWY-ZQ22-N3ZP-V2KW-52JE",
               "epk":{



Hallam-Baker              Expires 19 July 2020                 [Page 14]

Internet-Draft            Mesh Schema Reference             January 2020


                 "PublicKeyECDH":{
                   "crv":"Ed448",
                   "Public":"80ofnf812P3naGy_KG6a1IUAdQKcZ9fF5TKZ8q8yR
     ZsWn870qm1QKgXYxOz82RpWKEqGHGdWEYcA"}},
               "wmk":"_-0e3rNNbEIvH8zjSe1tBz84FEg71dzdhHJnfQvbteecigqM
     sZaFZA"},
             {
               "kid":"MATS-37J5-26DG-MYUR-7BMU-PPJJ-UUO4",
               "epk":{
                 "PublicKeyECDH":{
                   "crv":"Ed448",
                   "Public":"Y64tNqhJuEREoAm3pFqXSQqBdbmN7qPhmnKKmwOWh
     VnVxVvBuRFjAwM6HuVpgLa53kK3Ucl7uCsA"}},
               "wmk":"G3nEbaXRHIgdaXcx-DyKXuOA1QXKG-coa4q3urbu6L4bti4c
     uI5_og"}
             ],
           "ContentMetaData":"ewogICJjdHkiOiAiYXBwbGljYXRpb24vbW1tIn0"},
         "xq7fBwbgcYBrqZgcleQhT92CfS5uLMEO2xAbhr2c4clU0i6tX67Z-sx5opqd
     MrSDHGuaDUShWce9JhSwBomvs_8un_0V9vhqwV5gSP_fTsvSU2nnCBT0ziEk19B5z
     57AsGwAWL9lTa9kX3M6AfF92UIog4vZGTHrJ_m1yLJc_etVBAeL4GF_M9_LSZ4zjf
     eZZGSwOBwQKGSWGqCfEdWRec0OZ_q4WUg3Fh6NyrdG8kaUwkF3EYgfBhN2OyLQ7oH
     ybuQs-J2w_m_ev79C-o0eUYz8TJQTLeYpQb3cFmXkD71BLqBn0nWBp4BeR73UMWoo
     Nv1OkyHw9HXmreaDeCOeWWqZsfNqE47xvNX1DWbwlxBYMJLqoz3y_XUSTaQFJqa1s
     uX_c7ZhtbXDVEWyDFBOayf64r68LDbAI-1yVEpcBF8h9XwBvZnGXyC5iUzFGCL0WY
     MlH1oC8JU8rG3kp12pDhaGR0V8OHJ6C_AL1mk2Wm39XqZFOTjIy7KJM69EN-U4MNx
     -ph8Pil78inOTcfUCNffepP5XGbeNO0pse1Og35eiGnZFLf9yRB_iZtQwJmMsEZ0p
     sW8qXp7vnYd2Qk5vwAmizYqRZ7oViTVotGHHgvNRTliuJgmTGHRlYYUxlsH3lUxDv
     5UHJzSBKiXK5g4a3Vf5I10qaFLi2V0Gh3P-MkEXyvrcRGZVkix8K6mLYIVzZueskl
     hJ28M-WlattxnV4Kdjd_0Q85HZLoKlsJryf7VUDBzfrtpoCKH19r2BWBLCC-HlsTx
     NN0CArNk_Lt7FXxuAuKnB0jAPOmZhjbP2W13gP6B3IsTZQon9EGgEEWLwThyGZmh3
     DwTQscUUc0tz5Gu5KywANKqXpjbhrPS-vRPogByOLAa2u_gzeCuSq6RqTva0-dCgb
     gFMkqZic25BqO9BpmTmnLKTOumhGhKA2r2aNfhMeQp12wpH3zLfNsYHwTUwQj--KJ
     CRgRlYt6lVBs-9U8BEgcWI_bThDod3d-CNuU7A0IveifojNeUScA9UniJPjympL1P
     Q953B46-nb8Y7LodudjuEbbmJxcTzlg6Rao66oMo0rGDeEyxb0RaYPQ41gKqAi1MM
     bBc80flGgxdlN4nGPYXtyQBCZQJ0Rlk-1nWujdf6LoCBg_-dpteR54N9o_Mc-aNsP
     i_FpdSVrGweQp6HpoQuwpXOncHyMG257iCxZN0Fev-nviLkXn8JA_iJ72vvJzHZMH
     J33XOhFlbvwDIN5g4Drn448i0t9u_G5n--3kN9nt916fUFM6tq"
         ],
       "Accounts":[{
           "AccountUDF":"MC23-X3CT-EUNB-DR3M-QIBI-W2IJ-ATEP",
           "EnvelopedProfileAccount":[{
               "dig":"SHA2"},
             "ewogICJQcm9maWxlQWNjb3VudCI6IHsKICAgICJLZXlPZmZsaW5lU2ln
     bmF0dXJlIjogewogICAgICAiVURGIjogIk1DMjMtWDNDVC1FVU5CLURSM00tUUlCS
     S1XMklKLUFURVAiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgIC
     AiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICA
     gICAgICAgIlB1YmxpYyI6ICI5dXBQMWlhazMwX0pyRzFwZVl3aGtUMDBEcHc4SjBq
     d0dRQTBuZWhuQlZQdU9hRzloNlNzCiAgRmUwRGV6MmIzYVFwbGRBR1VLb1VCZENBI



Hallam-Baker              Expires 19 July 2020                 [Page 15]

Internet-Draft            Mesh Schema Reference             January 2020


     n19fSwKICAgICJLZXlzT25saW5lU2lnbmF0dXJlIjogW3sKICAgICAgICAiVURGIj
     ogIk1DUlItSkZMWi1UMkpILUlOR0QtU0JZRi1OTzZYLTU1Uk4iLAogICAgICAgICJ
     QdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7
     CiAgICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICAgICAgICAiUHVibGljI
     jogIkZfTUpmMHc4ZFVIaVBZeTk3WEtRbXBmRlZMbk5uZHNqUUg1cDFjM3ozSGxucV
     RhMmE3YkUKICBVQ09veGE0SEFpc2Y5QnFueEpFZE9tZ0EifX19XSwKICAgICJNZXN
     oUHJvZmlsZVVERiI6ICJNQ1NDLTJQT0ctUEg3VC1PREpYLUhPQ0EtQjRYWS1BRlNL
     IiwKICAgICJLZXlFbmNyeXB0aW9uIjogewogICAgICAiVURGIjogIk1CV1ktSUlLW
     S1WT0I1LUJYSVAtRElYWC1SNFRILVpJRjIiLAogICAgICAiUHVibGljUGFyYW1ldG
     VycyI6IHsKICAgICAgICAiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnY
     iOiAiRWQ0NDgiLAogICAgICAgICAgIlB1YmxpYyI6ICJzd3BlNkg1eWlVNHZKb3Ri
     b1hiRnd3SUVwX2xYTy1rYm05emo5UE9GTEx3ZnFlNkJVTXN1CiAgOUZCQ0w2R0hwO
     TN3Y21MTTI3dEdSbjRBIn19fX19",
             {
               "signatures":[{
                   "alg":"SHA2",
                   "kid":"MC23-X3CT-EUNB-DR3M-QIBI-W2IJ-ATEP",
                   "signature":"xBUh419PqcBn2XAGToSaPRxDiUJSEABsZubx-z
     OaEqZsotZceYNIj6h2axaL0ZsJAwO3vPNCgCOAbX6LLqeJk4qheJ5FLmZ53_T66gD
     PqaTIE0NhFp8ulQuDE0aAvU0eH7vPV1HhqUMaQMc-lZGPQCUA"}
                 ],
               "PayloadDigest":"aXMNPb2KrzIznCZVP28IrDLCOsVirh1Oy_VRZc
     sqX0Y3JMuCTXOJ8BpIMc_bjer2T8a4m0e5SzYoRe4S-gXP6w"}
             ],
           "EnvelopedConnectionAccount":[{
               "dig":"SHA2"},
             "ewogICJDb25uZWN0aW9uQWNjb3VudCI6IHsKICAgICJTdWJqZWN0VURG
     IjogIk1DWkwtTVFPQS1YTFlVLVJMUFctVlJSSC02VUZELUtESUUiLAogICAgIkF1d
     Ghvcml0eVVERiI6ICJNQzIzLVgzQ1QtRVVOQi1EUjNNLVFJQkktVzJJSi1BVEVQIi
     wKICAgICJLZXlTaWduYXR1cmUiOiB7CiAgICAgICJVREYiOiAiTUNaTC1NUU9BLVh
     MWVUtUkxQVy1WUlJILTZVRkQtS0RJRSIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJz
     IjogewogICAgICAgICJQdWJsaWNLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6I
     CJFZDQ0OCIsCiAgICAgICAgICAiUHVibGljIjogImFDdnlmT2d1YVlBRm5XeTlfNX
     JYdy1rY0U0NWtNWGsyWGRtMkt0VWVWSjhnVkpTakQwZHIKICBMUzZpQ3J4SFBWdUl
     hb0lGNW84UWhnVUEifX19LAogICAgIktleUF1dGhlbnRpY2F0aW9uIjogewogICAg
     ICAiVURGIjogIk1DTDQtS1JCNC1QTVROLTNDTEktVVBGWi1NVjJaLTZUVUciLAogI
     CAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgICAiUHVibGljS2V5RUNESC
     I6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICAgICAgIlB1YmxpYyI
     6ICJpR0Y0X19vRk9PWVotVm5QZHFoQlZ4bEVpTEF4UllQRnNRLVlxclVJdTVlbXlF
     cjRXUlBMCiAgLTl6M2VMMmQ5SXgwSm9raUI3RUYyRm9BIn19fX19",
             {
               "signatures":[{
                   "alg":"SHA2",
                   "kid":"MCRR-JFLZ-T2JH-INGD-SBYF-NO6X-55RN",
                   "signature":"DXZyUQa06ki6HuDtd7ooofkLlX6_d341Gq0YD8
     3sLOVFcKwP-C12JWOBRcp_iVdd_tlx94nkrqWAH9ZI6__XrfavdqFWbrkl9kLCQi5
     mpisnx9zxOTZ_0a_kE7KAnjl7SoSV5G7Z9MqlWhZ1OVCmyR0A"}
                 ],



Hallam-Baker              Expires 19 July 2020                 [Page 16]

Internet-Draft            Mesh Schema Reference             January 2020


               "PayloadDigest":"eKZx9Y5JQGXuaXE1o1BfwSqeDRX0h4VYUWZZIT
     _wFfh391cZxAp3x5GSiex1vMw4oy_I1oKLC7QdKxthACTz2Q"}
             ],
           "EnvelopedActivationAccount":[{
               "dig":"SHA2"},
             "ewogICJBY3RpdmF0aW9uQWNjb3VudCI6IHsKICAgICJBY2NvdW50VURG
     IjogIk1DMjMtWDNDVC1FVU5CLURSM00tUUlCSS1XMklKLUFURVAiLAogICAgIktle
     UVuY3J5cHRpb24iOiB7CiAgICAgICJVREYiOiAiTUNDQS00WTM3LU5SR0wtQkVKUy
     1ENDdaLTRQSVotVlNDTiIsCiAgICAgICJCYXNlVURGIjogIk1DWlAtQU1OTy1KSFd
     ZLVpRMjItTjNaUC1WMktXLTUySkUiLAogICAgICAiT3ZlcmxheSI6IHsKICAgICAg
     ICAiUHJpdmF0ZUtleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIkVkNDQ4IiwKI
     CAgICAgICAgICJQcml2YXRlIjogIkozX0cyYkxmcjhkRkRaSDRnYjNQc0dwVTE0T0
     VjMmJib3YtdDFJOTR4WDJaQmVOWGN6TQogIFFDdGVYWDNsNnNrQm1TejA0S2VKd2p
     hVSJ9fX0sCiAgICAiS2V5QXV0aGVudGljYXRpb24iOiB7CiAgICAgICJVREYiOiAi
     TUNMNC1LUkI0LVBNVE4tM0NMSS1VUEZaLU1WMlotNlRVRyIsCiAgICAgICJCYXNlV
     URGIjogIk1EWU8tWEFISi1SWFQ2LVlPNEotWDdXVi1MM0lXLTVORVAiLAogICAgIC
     AiT3ZlcmxheSI6IHsKICAgICAgICAiUHJpdmF0ZUtleUVDREgiOiB7CiAgICAgICA
     gICAiY3J2IjogIkVkNDQ4IiwKICAgICAgICAgICJQcml2YXRlIjogIk9OUE5BMlVu
     SXNEYnljcGl4YXkzZ3JGenh5T241dmk4bTNnV1lxUGFsVG9YRHljUlQ2UwogIFRNN
     XZETjZXR0M3VC1ncDNhbnZWT3VGayJ9fX0sCiAgICAiS2V5U2lnbmF0dXJlIjogew
     ogICAgICAiVURGIjogIk1DWkwtTVFPQS1YTFlVLVJMUFctVlJSSC02VUZELUtESUU
     iLAogICAgICAiQmFzZVVERiI6ICJNQ1lTLVRPUUotQ0RBWC1FRFU3LTZFWjMtT0xQ
     Ry1LTUxHIiwKICAgICAgIk92ZXJsYXkiOiB7CiAgICAgICAgIlByaXZhdGVLZXlFQ
     0RIIjogewogICAgICAgICAgImNydiI6ICJFZDQ0OCIsCiAgICAgICAgICAiUHJpdm
     F0ZSI6ICJPZ0pSOEJZWXpKTGNqRVJrVzVYY2x0OUsyWUhhaHVVZzROQkRKWHNjVWt
     LQTRIWVYzN0wKICByWE1nbDVpNmVHZTh5SG9TWVcwRlRWcFkifX19fX0",
             {
               "signatures":[{
                   "alg":"SHA2",
                   "kid":"MCRR-JFLZ-T2JH-INGD-SBYF-NO6X-55RN",
                   "signature":"DG3O45F_0CUD9TEOKgkLtRK1BZDqWey5JO3Kt6
     foye8lvR13l6P6UnieF9jDNO0WQY-yPI4LjyuAVNSZWi97IF4M--zrduv7ZpjCthk
     sLnlQvH-oYIfGb-dZfAOza6B7zvgU6IbxPWWWCo4zQOj6qBkA"}
                 ],
               "PayloadDigest":"4pwNPnQPWuciKHFFtXv7zXN7MN4bEsRJ78KmRG
     8F3cR5pK32CcQ-aI5-qF2yL_gL8hJuU6S04mPpZEpE_acOWg"}
             ]}
         ]}}

   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:

   0.  Creating the necessary key



Hallam-Baker              Expires 19 July 2020                 [Page 17]

Internet-Draft            Mesh Schema Reference             January 2020


   1.  Signing the "ProfileDevice" using the Master Signature Key

   2.  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:

   0.  Generating the PrivateDevice keys.

   1.  Creating the ConnectionDevice data from the public components of
       the ProfileDevice and PrivateDevice keys and signing it using the
       administration key.

   2.  Creating the Activations for the device and signing them using
       the administration key.

   3.  Creating the "CatalogEntryDevice" for the device and adding it to
       the "CatalogDevice" of the Personal Mesh.

   4.  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:

   (Artwork only available as svg: No external link available, see
   draft-hallambaker-mesh-schema-05.html for artwork.)




Hallam-Baker              Expires 19 July 2020                 [Page 18]

Internet-Draft            Mesh Schema Reference             January 2020


                                  Figure 5

   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":"MC23-X3CT-EUNB-DR3M-QIBI-W2IJ-ATEP",
         "PublicParameters":{
           "PublicKeyECDH":{
             "crv":"Ed448",
             "Public":"9upP1iak30_JrG1peYwhkT00Dpw8J0jwGQA0nehnBVPuOaG
     9h6SsFe0Dez2b3aQpldAGUKoUBdCA"}}},
       "KeysOnlineSignature":[{
           "UDF":"MCRR-JFLZ-T2JH-INGD-SBYF-NO6X-55RN",
           "PublicParameters":{
             "PublicKeyECDH":{
               "crv":"Ed448",
               "Public":"F_MJf0w8dUHiPYy97XKQmpfFVLnNndsjQH5p1c3z3Hlnq
     Ta2a7bEUCOoxa4HAisf9BqnxJEdOmgA"}}}
         ],
       "ServiceIDs":["alice@example.com"
         ],
       "MeshProfileUDF":"MCSC-2POG-PH7T-ODJX-HOCA-B4XY-AFSK",
       "KeyEncryption":{
         "UDF":"MBWY-IIKY-VOB5-BXIP-DIXX-R4TH-ZIF2",
         "PublicParameters":{
           "PublicKeyECDH":{
             "crv":"Ed448",
             "Public":"swpe6H5yiU4vJotboXbFwwIEp_lXO-kbm9zj9POFLLwfqe6
     BUMsu9FBCL6GHp93wcmLM27tGRn4A"}}}}}

   Each device using the account requires an activation record:
















Hallam-Baker              Expires 19 July 2020                 [Page 19]

Internet-Draft            Mesh Schema Reference             January 2020


   {
     "ActivationAccount":{
       "AccountUDF":"MC23-X3CT-EUNB-DR3M-QIBI-W2IJ-ATEP",
       "KeyEncryption":{
         "UDF":"MCCA-4Y37-NRGL-BEJS-D47Z-4PIZ-VSCN",
         "BaseUDF":"MCZP-AMNO-JHWY-ZQ22-N3ZP-V2KW-52JE",
         "Overlay":{
           "PrivateKeyECDH":{
             "crv":"Ed448",
             "Private":"J3_G2bLfr8dFDZH4gb3PsGpU14OEc2bbov-t1I94xX2ZBe
     NXczMQCteXX3l6skBmSz04KeJwjaU"}}},
       "KeyAuthentication":{
         "UDF":"MCL4-KRB4-PMTN-3CLI-UPFZ-MV2Z-6TUG",
         "BaseUDF":"MDYO-XAHJ-RXT6-YO4J-X7WV-L3IW-5NEP",
         "Overlay":{
           "PrivateKeyECDH":{
             "crv":"Ed448",
             "Private":"ONPNA2UnIsDbycpixay3grFzxyOn5vi8m3gWYqPalToXDy
     cRT6STM5vDN6WGC7T-gp3anvVOuFk"}}},
       "KeySignature":{
         "UDF":"MCZL-MQOA-XLYU-RLPW-VRRH-6UFD-KDIE",
         "BaseUDF":"MCYS-TOQJ-CDAX-EDU7-6EZ3-OLPG-KMLG",
         "Overlay":{
           "PrivateKeyECDH":{
             "crv":"Ed448",
             "Private":"OgJR8BYYzJLcjERkW5Xclt9K2YHahuUg4NBDJXscUkKA4H
     YV37LrXMgl5i6eGe8yHoSYW0FTVpY"}}}}}

4.2.1.  Creating a ProfileAccount

   Creating a "ProfileAccount" comprises the steps of:

   0.  [TBS]

   1.  .

   2.  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:

   0.  Creating a PrivateAccount instance for the device.

   1.  Creating a ConnectionAccountDevice for the device using the
       public keys from the PrivateAccount instance and the
       ProfileDevice.




Hallam-Baker              Expires 19 July 2020                 [Page 20]

Internet-Draft            Mesh Schema Reference             January 2020


   2.  Creating an ActivationAccount for the device containing the
       PrivateAccount and ConnectionAccountDevice instances.

   3.  Adding the ActivationAccount to the "CatalogEntryDevice" of the
       device.

   4.  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:

   0.  [TBS]

   1.  .

   2.  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.

   (Artwork only available as svg: No external link available, see
   draft-hallambaker-mesh-schema-05.html for artwork.)

                                  Figure 6

   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 19 July 2020                 [Page 21]

Internet-Draft            Mesh Schema Reference             January 2020


   {
     "ProfileService":{
       "KeyOfflineSignature":{
         "UDF":"MAZN-ABCG-4UH7-NN3H-5G7D-KP7X-HRGO",
         "PublicParameters":{
           "PublicKeyECDH":{
             "crv":"Ed448",
             "Public":"4_-7mv9dECSF5ihqS7wRP-KZbo4ExJc5JjoH4iudjymQ9Qb
     HPUYWHD1YSpVypaHgyg-XkfhaqkSA"}}}}}

   The host also has a profile

   {
     "ProfileHost":{
       "KeyOfflineSignature":{
         "UDF":"MDNG-3RJS-N6BJ-MU63-U7TZ-RKVB-SYZT",
         "PublicParameters":{
           "PublicKeyECDH":{
             "crv":"Ed448",
             "Public":"Bn3Yo-Hh_donsmk1AQxSd1nzR-SEzRcJudwoC174DEV-Vm4
     t6Sl2jVFAq3GBG7lOUEF5HfeVqQiA"}}},
       "KeyAuthentication":{
         "UDF":"MDSO-WOVL-R4YG-7OUT-PB6O-2DBW-KUND",
         "PublicParameters":{
           "PublicKeyECDH":{
             "crv":"Ed448",
             "Public":"hFtmh1ErT93IUy-FJbPHt7QFIAP-ohQNLSzUwtXc2E0IH7r
     XE6u92gnCUQpJVECuTNrHuwALJB4A"}}}}}

   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:

   0.  [TBS]

   1.  .

   2.  [TBS]


   4.  Signing the ProfileMaster using the Master Signature Key



Hallam-Baker              Expires 19 July 2020                 [Page 22]

Internet-Draft            Mesh Schema Reference             January 2020


4.3.2.  Creating a ProfileHost

   Creating a "ProfileHost" comprises the steps of:

   0.  [TBS]

   1.  .

   2.  [TBS]


   4.  Signing the "ConnectionHost" using the Master Signature Key of
       the "ProfileService".

4.3.3.  Creating a ConnectionHost

   Creating a "ConnectionHost" comprises the steps of:

   0.  [TBS]

   1.  .

   2.  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

   (Artwork only available as svg: No external link available, see
   draft-hallambaker-mesh-schema-05.html for artwork.)

                                  Figure 7

   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



Hallam-Baker              Expires 19 July 2020                 [Page 23]

Internet-Draft            Mesh Schema Reference             January 2020


   subject to consequences ranging from restriction of the number and
   type of messages sent to suspending or terminating messaging
   privileges.

   (Artwork only available as svg: No external link available, see
   draft-hallambaker-mesh-schema-05.html for artwork.)

                                  Figure 8

   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.

   (Artwork only available as svg: No external link available, see
   draft-hallambaker-mesh-schema-05.html for artwork.)

                                  Figure 9

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
   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:

   "<<prefix>_<name>"




Hallam-Baker              Expires 19 July 2020                 [Page 24]

Internet-Draft            Mesh Schema Reference             January 2020


   Where "<<prefix>" 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
   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.





Hallam-Baker              Expires 19 July 2020                 [Page 25]

Internet-Draft            Mesh Schema Reference             January 2020


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
   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 $$$$










Hallam-Baker              Expires 19 July 2020                 [Page 26]

Internet-Draft            Mesh Schema Reference             January 2020


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.

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.



Hallam-Baker              Expires 19 July 2020                 [Page 27]

Internet-Draft            Mesh Schema Reference             January 2020


   {
     "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.

   $$$$ Empty $$$$

5.7.  Network

   The network catalog contains "CatalogEntryNetwork" entries which
   describe network settings, IPSEC and TLS VPN configurations, etc.

   $$$$ Empty $$$$









Hallam-Baker              Expires 19 July 2020                 [Page 28]

Internet-Draft            Mesh Schema Reference             January 2020


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.

   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.



Hallam-Baker              Expires 19 July 2020                 [Page 29]

Internet-Draft            Mesh Schema Reference             January 2020


   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
   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:



Hallam-Baker              Expires 19 July 2020                 [Page 30]

Internet-Draft            Mesh Schema Reference             January 2020


   [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]

   The confirmation response

   [NYI]

7.  Schema







Hallam-Baker              Expires 19 July 2020                 [Page 31]

Internet-Draft            Mesh Schema Reference             January 2020


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: DeviceRecryptionKey

   UDF: String (Optional)  The fingerprint of the encryption key

   Contact: Contact (Optional)  The User's Mesh contact information

   RecryptionKey: PublicKey (Optional)  The recryption key

   EnvelopedRecryptionKeyDevice: DareEnvelope (Optional)  The decryption
      key encrypted under the user's device key.

7.1.5.  Structure: KeyOverlay

   UDF: String (Optional)  Fingerprint of the resulting composite key
      (to allow verification)

   BaseUDF: String (Optional)  Fingerprint specifying the base key

7.1.6.  Structure: EscrowedKeySet

   A set of escrowed keys.

   [No fields]



Hallam-Baker              Expires 19 July 2020                 [Page 32]

Internet-Draft            Mesh Schema Reference             January 2020


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
      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




Hallam-Baker              Expires 19 July 2020                 [Page 33]

Internet-Draft            Mesh Schema Reference             January 2020


   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.

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.





Hallam-Baker              Expires 19 July 2020                 [Page 34]

Internet-Draft            Mesh Schema Reference             January 2020


   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.

   ServiceIDs: String [0..Many]  Service address(es).

   KeyEncryption: PublicKey (Optional)  Key currently used to encrypt
      data under this profile

7.2.10.  Structure: ProfileHost

   Inherits: Profile  

   KeyAuthentication: PublicKey (Optional)  Key used to authenticate
      service connections.

7.2.11.  Connection Classes

7.2.12.  Structure: Connection

   Inherits: Assertion  

   SubjectUDF: String (Optional)  UDF of the connection target.

   AuthorityUDF: String (Optional)  UDF of the connection source.

7.2.13.  Structure: Permission

   Name: 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  

   Permissions: Permission [0..Many]  List of the permissions that the
      device has been granted.



Hallam-Baker              Expires 19 July 2020                 [Page 35]

Internet-Draft            Mesh Schema Reference             January 2020


   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  

   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

   KeyAuthentication: PublicKey (Optional)  The authentication key for
      use of the device under the profile

7.2.16.  Structure: ConnectionGroup

   Describes the connection of a member to a group.

   Inherits: Connection  

   KeyEncryption: KeyComposite (Optional)  The decryption key for the
      user within the group

7.2.17.  Structure: ConnectionService

   Inherits: Connection  

   [No fields]

7.2.18.  Structure: ConnectionHost

   Inherits: Connection  

   [No fields]




Hallam-Baker              Expires 19 July 2020                 [Page 36]

Internet-Draft            Mesh Schema Reference             January 2020


7.2.19.  Structure: ConnectionApplication

   Inherits: Connection  

   [No fields]

7.2.20.  Activation Classes

7.2.21.  Structure: Activation

   Inherits: Assertion  

   Contains the private activation information for a Mesh application
   running on a specific device

   [No fields]

7.2.22.  Structure: ActivationDevice

   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

   KeyAuthentication: KeyOverlay (Optional)  The key overlay used to
      generate the account authentication key from the device
      authentication key

7.2.23.  Structure: ActivationAccount

   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




Hallam-Baker              Expires 19 July 2020                 [Page 37]

Internet-Draft            Mesh Schema Reference             January 2020


   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.2.24.  Structure: ActivationGroup

   Inherits: Activation  

   GroupUDF: String (Optional)  The UDF of the group

   KeyEncryption: KeyOverlay (Optional)  The key overlay that
      compliments the member's group decryption key.

7.3.  Cataloged items

7.3.1.  Data Structures

   Classes describing data used in cataloged data.

7.3.2.  Structure: ContactMesh

   UDF: String (Optional)  

   ServiceID: String [0..Many]  

7.3.3.  Structure: Contact

   Inherits: Assertion  

   MeshAccounts: DareEnvelope [0..Many]  The Mesh Account Connection -
      the main event really

   Email: String (Optional)  

   Identifier: String (Optional)  

   FullName: String (Optional)  

   Title: String (Optional)  

   First: String (Optional)  

   Middle: String (Optional)  

   Last: String (Optional)  



Hallam-Baker              Expires 19 July 2020                 [Page 38]

Internet-Draft            Mesh Schema Reference             January 2020


   Suffix: String (Optional)  

   Labels: String [0..Many]  

   AssertionAccounts: ProfileAccount [0..Many]  

   Addresses: Address [0..Many]  

   Locations: Location [0..Many]  

   Roles: Role [0..Many]  

7.3.4.  Structure: Role

   CompanyName: String (Optional)  

   Addresses: Address [0..Many]  

   Locations: Location [0..Many]  

7.3.5.  Structure: Address

   URI: String (Optional)  

   Labels: String [0..Many]  

7.3.6.  Structure: Location

   Appartment: String (Optional)  

   Street: String (Optional)  

   District: String (Optional)  

   Locality: String (Optional)  

   County: String (Optional)  

   Postcode: String (Optional)  

   Country: String (Optional)  

7.3.7.  Structure: Reference

   MessageID: String (Optional)  The received message to which this is a
      response





Hallam-Baker              Expires 19 July 2020                 [Page 39]

Internet-Draft            Mesh Schema Reference             January 2020


   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.

7.3.8.  Structure: Task

   Key: String (Optional)  Unique key.

   Start: DateTime (Optional)  

   Finish: DateTime (Optional)  

   StartTravel: String (Optional)  

   FinishTravel: String (Optional)  

   TimeZone: String (Optional)  

   Title: String (Optional)  

   Description: String (Optional)  

   Location: String (Optional)  

   Trigger: String [0..Many]  

   Conference: String [0..Many]  

   Repeat: String (Optional)  

   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




Hallam-Baker              Expires 19 July 2020                 [Page 40]

Internet-Draft            Mesh Schema Reference             January 2020


   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

7.4.4.  Structure: CatalogedCredential

   Inherits: CatalogedEntry  

   Protocol: String (Optional)  

   Service: String (Optional)  

   Username: String (Optional)  

   Password: String (Optional)  

7.4.5.  Structure: CatalogedNetwork

   Inherits: CatalogedEntry  

   Protocol: String (Optional)  

   Service: String (Optional)  




Hallam-Baker              Expires 19 July 2020                 [Page 41]

Internet-Draft            Mesh Schema Reference             January 2020


   Username: String (Optional)  

   Password: String (Optional)  

7.4.6.  Structure: CatalogedContact

   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
      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  

   Uri: String (Optional)  

   Title: String (Optional)  

   Path: String (Optional)  

7.4.9.  Structure: CatalogedTask

   Inherits: CatalogedEntry  

   EnvelopedTask: DareEnvelope (Optional)  

   Title: String (Optional)  

   Key: String (Optional)  Unique key.

7.4.10.  Structure: CatalogedApplication




Hallam-Baker              Expires 19 July 2020                 [Page 42]

Internet-Draft            Mesh Schema Reference             January 2020


   Inherits: CatalogedEntry  

   Key: String (Optional)  

7.4.11.  Structure: CatalogedMember

   UDF: String (Optional)  

   Inherits: CatalogedEntry  

7.4.12.  Structure: CatalogedGroup

   Inherits: CatalogedApplication  

   Profile: ProfileGroup (Optional)  

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)  

   Sender: String (Optional)  

   Recipient: String (Optional)  

   References: Reference [0..Many]  

7.5.2.  Structure: MessageComplete




Hallam-Baker              Expires 19 July 2020                 [Page 43]

Internet-Draft            Mesh Schema Reference             January 2020


   Inherits: Message  

   [No fields]

7.5.3.  Structure: MessagePIN

   Account: String (Optional)  

   Inherits: Message  

   Expires: DateTime (Optional)  

   PIN: String (Optional)  

7.5.4.  Structure: RequestConnection

   Connection request message.  This message contains the information

   Inherits: Message  

   ServiceID: String (Optional)  

   EnvelopedProfileDevice: DareEnvelope (Optional)  Device profile of
      the device making the request.

   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  

   EnvelopedRequestConnection: DareEnvelope (Optional)  The client
      connection request.

   ServerNonce: Binary (Optional)  

   Witness: String (Optional)  

7.5.6.  Structure: OfferGroup

   Inherits: Message  




Hallam-Baker              Expires 19 July 2020                 [Page 44]

Internet-Draft            Mesh Schema Reference             January 2020


   [No fields]

7.5.7.  Structure: RequestContact

   Inherits: Message  

   Reply: Boolean (Optional)  

   Subject: String (Optional)  

   Self: DareEnvelope (Optional)  The contact data.

7.5.8.  Structure: ReplyContact

   Inherits: RequestContact  

   [No fields]

7.5.9.  Structure: GroupInvitation

   Inherits: Message  

   Text: String (Optional)  

   EncryptedPartDecrypt: DareEnvelope (Optional)  

7.5.10.  Structure: RequestConfirmation

   Inherits: Message  

   Text: String (Optional)  

7.5.11.  Structure: ResponseConfirmation

   Inherits: Message  

   Request: RequestConfirmation (Optional)  

   Accept: Boolean (Optional)  

7.5.12.  Structure: RequestTask

   Inherits: Message  

   [No fields]






Hallam-Baker              Expires 19 July 2020                 [Page 45]

Internet-Draft            Mesh Schema Reference             January 2020


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].

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




Hallam-Baker              Expires 19 July 2020                 [Page 46]

Internet-Draft            Mesh Schema Reference             January 2020


   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.

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.  Appendix B: Collected Authentication and Encryption Requirements

12.1.  Mesh Messaging


          +-----------------------+---------+------------------+
          | Message               | Signer  | Recipients       |
          +=======================+=========+==================+
          | RequestConnection     | Device  | Service          |
          +-----------------------+---------+------------------+
          | AcknowledgeConnection | Service | Device, Receiver |
          +-----------------------+---------+------------------+
          | OfferGroup            | Sender  | Receiver         |
          +-----------------------+---------+------------------+
          | RequestContact        | Sender  | Receiver         |
          +-----------------------+---------+------------------+
          | ReplyContact          | Sender  | Receiver         |
          +-----------------------+---------+------------------+



Hallam-Baker              Expires 19 July 2020                 [Page 47]

Internet-Draft            Mesh Schema Reference             January 2020


          | RequestConfirmation   | Sender  | Receiver         |
          +-----------------------+---------+------------------+
          | ResponseConfirmation  | Sender  | Receiver         |
          +-----------------------+---------+------------------+
          | RequestTask           | Sender  | Receiver         |
          +-----------------------+---------+------------------+
          | ResponseTask          | Sender  | Receiver         |
          +-----------------------+---------+------------------+

                                 Table 1




13.  Normative References

   [draft-hallambaker-mesh-architecture]
              Hallam-Baker, P., "Mathematical Mesh 3.0 Part I:
              Architecture Guide", Work in Progress, Internet-Draft,
              draft-hallambaker-mesh-architecture-12, 16 January 2020,
              <https://tools.ietf.org/html/draft-hallambaker-mesh-
              architecture-12>.

   [draft-hallambaker-mesh-cryptography]
              Hallam-Baker, P., "Mathematical Mesh 3.0 Part VIII:
              Cryptographic Algorithms", Work in Progress, Internet-
              Draft, draft-hallambaker-mesh-cryptography-04, 1 November
              2019, <https://tools.ietf.org/html/draft-hallambaker-mesh-
              cryptography-04>.

   [draft-hallambaker-mesh-notary]
              "[Reference Not Found!]".

   [draft-hallambaker-mesh-protocol]
              Hallam-Baker, P., "Mathematical Mesh 3.0 Part V: Protocol
              Reference", Work in Progress, Internet-Draft, draft-
              hallambaker-mesh-protocol-03, 23 October 2019,
              <https://tools.ietf.org/html/draft-hallambaker-mesh-
              protocol-03>.

   [draft-hallambaker-mesh-security]
              Hallam-Baker, P., "Mathematical Mesh 3.0 Part VII:
              Security Considerations", Work in Progress, Internet-
              Draft, draft-hallambaker-mesh-security-02, 23 October
              2019, <https://tools.ietf.org/html/draft-hallambaker-mesh-
              security-02>.





Hallam-Baker              Expires 19 July 2020                 [Page 48]

Internet-Draft            Mesh Schema Reference             January 2020


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

14.  Informative References

   [draft-hallambaker-mesh-developer]
              Hallam-Baker, P., "Mathematical Mesh: Reference
              Implementation", Work in Progress, Internet-Draft, draft-
              hallambaker-mesh-developer-09, 23 October 2019,
              <https://tools.ietf.org/html/draft-hallambaker-mesh-
              developer-09>.

   [draft-hallambaker-mesh-trust]
              Hallam-Baker, P., "Mathematical Mesh 3.0 Part VI: The
              Trust Mesh", Work in Progress, Internet-Draft, draft-
              hallambaker-mesh-trust-03, 23 October 2019,
              <https://tools.ietf.org/html/draft-hallambaker-mesh-trust-
              03>.

   [RFC2426]  Dawson, F. and T. Howes, "vCard MIME Directory Profile",
              RFC 2426, DOI 10.17487/RFC2426, September 1998,
              <https://www.rfc-editor.org/rfc/rfc2426>.

   [RFC5545]  Desruisseaux, B., "Internet Calendaring and Scheduling
              Core Object Specification (iCalendar)", RFC 5545,
              DOI 10.17487/RFC5545, September 2009,
              <https://www.rfc-editor.org/rfc/rfc5545>.






















Hallam-Baker              Expires 19 July 2020                 [Page 49]