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 http://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 January 29, 2021¶

Copyright Notice

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

This document is subject to BCP 78 and the IETF Trust’s Legal Provisions Relating to IETF Documents (http://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

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

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

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

• The Profile is valid¶
• Every Conditions clause in the profile is understood by the relying party and evaluates to true.¶

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

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

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

{
  "ProfileMesh":{
    "KeyOfflineSignature":{
      "UDF":"MCOZ-GIZ3-34VQ-GQ6J-FCS7-BJIU-JCOY",
      "PublicParameters":{
        "PublicKeyECDH":{
          "crv":"Ed448",
          "Public":"Q1UAkB-XN8gVJq_GMQtzdY7frvwUf-68_glEuopcpNU1J6n
  SmKQ2d5dFFZ1TXm8hYCEpQWRNiX8A"}}},
    "KeysOnlineSignature":[{
        "UDF":"MDF4-YA2E-FVGJ-LAG5-IK5Y-FXBB-2I56",
        "PublicParameters":{
          "PublicKeyECDH":{
            "crv":"Ed448",
            "Public":"8GezL9glxq-CuHp4DPwgHZs2K5eXm_Pae43pp-o9nEgoL
  tlMXT1TveX4VjRLmA0jQh1HetI5AmmA"}}}
      ],
    "KeyEncryption":{
      "UDF":"MBLT-3BDA-SR4S-SRBA-JVFA-YCCG-DAG2",
      "PublicParameters":{
        "PublicKeyECDH":{
          "crv":"X448",
          "Public":"HKt8Fvp6AP4YoWjnCzMTfZy7TXYu360D98d7KvnhZaXWSH1
  8Ojs5_ca33B5YwqxHIKuBI4-DnseA"}}}}}¶

4.1.1.1. Creating a ProfileMaster

Creating a ProfileMaster comprises the steps of:¶

1. Creating a Master Signature key.¶
2. Creating an Online Signing Key¶
3. Signing the ProfileMaster using the Master Signature Key¶
4. Persisting the ProfileMaster on the administration device to the CatalogHost.¶
5. (Optional) Connecting at least one Administration Device and granting it the ActivationAdministration activation.¶

Updating a ProfileMaster comprises the steps of:¶

1. Making the necessary changes.¶
2. Signing the ProfileMaster using the Master Signature Key¶
3. Persisting the ProfileMaster on the administration device to the CatalogHost.¶

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

Unless exceptional circumstances require, a device should not require more than one Device profile even if the device supports use by multiple users under different accounts. But a device MAY have multiple profiles if this approach is more convenient for implementation.¶

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

{
  "ProfileDevice":{
    "KeyOfflineSignature":{
      "UDF":"MDNT-Y3SK-UGF5-NPYP-XDCK-OWHW-Z7FN",
      "PublicParameters":{
        "PublicKeyECDH":{
          "crv":"Ed448",
          "Public":"GUt8_DJU0kikQ37mFfAemQYy9YODDA-Y_8383-VLczRvGH2
  4ork1DbvZb1D_SPij2J8z0G8jHZyA"}}},
    "KeyEncryption":{
      "UDF":"MDUU-RE36-2XG4-2OAR-VYRN-EX65-XGZC",
      "PublicParameters":{
        "PublicKeyECDH":{
          "crv":"X448",
          "Public":"BkTowGixOBe2GWO1DwuEXBnctJ29bwRIxUQWTU-IT_mlTVf
  mNpY8Y0EsXpid7WwL9QUwlz9B5w-A"}}},
    "KeyAuthentication":{
      "UDF":"MATT-XVH7-P7BT-O2E7-SQYI-TXTZ-GPUJ",
      "PublicParameters":{
        "PublicKeyECDH":{
          "crv":"X448",
          "Public":"viYAKmU_8o-TcoXoo8xf_V9duUU6xrQ_wNeAGsSvnIwHysP
  6o8O5b16IE3Uwa2xtV0IPXtS_daoA"}}}}}¶

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

{
  "ConnectionDevice":{
    "KeySignature":{
      "UDF":"MC7B-CDOG-VA7F-TCBO-4JCY-QC6F-2F5A",
      "PublicParameters":{
        "PublicKeyECDH":{
          "crv":"Ed448",
          "Public":"rcc8y-VG-xyI-KKXH20tXcwTHrGwhDJr2bxTrVlK23Kzc9h
  fmwNkJgv79Ex6jyRhfarAHBOODIGA"}}},
    "KeyEncryption":{
      "UDF":"MDQV-A4FS-HZB2-PCYG-VP7Z-TK7L-F6FL",
      "PublicParameters":{
        "PublicKeyECDH":{
          "crv":"X448",
          "Public":"gvTkG2k594VcZheVBz-5CUExI0npHZTulyNVbHxnm-PZ83E
  aOPhbOLWF3gpKhb1moaVoO1e2GY0A"}}},
    "KeyAuthentication":{
      "UDF":"MD5D-VXEY-2JIX-RRUB-QXBE-JG66-DRP6",
      "PublicParameters":{
        "PublicKeyECDH":{
          "crv":"X448",
          "Public":"OxxFnhi6gYsENkX3xGGEZbU18lMmG-Djryfgqux6toyJZJs
  kdj-b4IIAqp4vOkHU7BqjxSgF9C4A"}}}}}¶

All the above are combined to form the CatalogedDevice entry: ¶

{
  "CatalogedDevice":{
    "UDF":"MC7B-CDOG-VA7F-TCBO-4JCY-QC6F-2F5A",
    "EnvelopedProfileMesh":[{
        "dig":"SHA2"},
      "ewogICJQcm9maWxlTWVzaCI6IHsKICAgICJLZXlPZmZsaW5lU2lnbmF0dXJl
  IjogewogICAgICAiVURGIjogIk1DT1otR0laMy0zNFZRLUdRNkotRkNTNy1CSklVL
  UpDT1kiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgICAiUHVibG
  ljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICAgICA
  gIlB1YmxpYyI6ICJRMVVBa0ItWE44Z1ZKcV9HTVF0emRZN2ZydndVZi02OF9nbEV1
  b3BjcE5VMUo2blNtS1EyCiAgZDVkRkZaMVRYbThoWUNFcFFXUk5pWDhBIn19fSwKI
  CAgICJLZXlzT25saW5lU2lnbmF0dXJlIjogW3sKICAgICAgICAiVURGIjogIk1ERj
  QtWUEyRS1GVkdKLUxBRzUtSUs1WS1GWEJCLTJJNTYiLAogICAgICAgICJQdWJsaWN
  QYXJhbWV0ZXJzIjogewogICAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAg
  ICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICAgICAgICAiUHVibGljIjogIjhHZ
  XpMOWdseHEtQ3VIcDREUHdnSFpzMks1ZVhtX1BhZTQzcHAtbzluRWdvTHRsTVhUMV
  QKICB2ZVg0VmpSTG1BMGpRaDFIZXRJNUFtbUEifX19XSwKICAgICJLZXlFbmNyeXB
  0aW9uIjogewogICAgICAiVURGIjogIk1CTFQtM0JEQS1TUjRTLVNSQkEtSlZGQS1Z
  Q0NHLURBRzIiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgICAiU
  HVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiWDQ0OCIsCiAgICAgIC
  AgICAiUHVibGljIjogIkhLdDhGdnA2QVA0WW9Xam5Dek1UZlp5N1RYWXUzNjBEOTh
  kN0t2bmhaYVhXU0gxOE9qczUKICBfY2EzM0I1WXdxeEhJS3VCSTQtRG5zZUEifX19
  fX0",
      {
        "signatures":[{
            "alg":"SHA2",
            "kid":"MCOZ-GIZ3-34VQ-GQ6J-FCS7-BJIU-JCOY",
            "signature":"-JM6TM7W2WmDOILniZJJBnfNVHW4VzPQ6Hbl8Td17r
  iEgJVUVBS40y_NBwRhfC_70vMJeuXRX40AT1G7zFBh_bUTLXBv7fqk4MDAoDdBt_v
  DGgK_LYhVSej_K-0pYIKovb0FiX5za_QuaMJW_HpPkDQA"}
          ],
        "PayloadDigest":"-E9oIRhcwUVwnNhf1-mRhX1mBqBsucvV_q6Va1zKLM
  k9G4HsfjGyBNi1CtOzqcTcOk3kwqcADQYmeQ8DaH3scw"}
      ],
    "DeviceUDF":"MDNT-Y3SK-UGF5-NPYP-XDCK-OWHW-Z7FN",
    "EnvelopedProfileDevice":[{
        "dig":"SHA2"},
      "ewogICJQcm9maWxlRGV2aWNlIjogewogICAgIktleU9mZmxpbmVTaWduYXR1
  cmUiOiB7CiAgICAgICJVREYiOiAiTUROVC1ZM1NLLVVHRjUtTlBZUC1YRENLLU9XS
  FctWjdGTiIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdW
  JsaWNLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6ICJFZDQ0OCIsCiAgICAgICA
  gICAiUHVibGljIjogIkdVdDhfREpVMGtpa1EzN21GZkFlbVFZeTlZT0REQS1ZXzgz
  ODMtVkxjelJ2R0gyNG9yazEKICBEYnZaYjFEX1NQaWoySjh6MEc4akhaeUEifX19L
  AogICAgIktleUVuY3J5cHRpb24iOiB7CiAgICAgICJVREYiOiAiTURVVS1SRTM2LT
  JYRzQtMk9BUi1WWVJOLUVYNjUtWEdaQyIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJ
  zIjogewogICAgICAgICJQdWJsaWNLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6
  ICJYNDQ4IiwKICAgICAgICAgICJQdWJsaWMiOiAiQmtUb3dHaXhPQmUyR1dPMUR3d
  UVYQm5jdEoyOWJ3Ukl4VVFXVFUtSVRfbWxUVmZtTnBZOAogIFkwRXNYcGlkN1d3TD
  lRVXdsejlCNXctQSJ9fX0sCiAgICAiS2V5QXV0aGVudGljYXRpb24iOiB7CiAgICA
  gICJVREYiOiAiTUFUVC1YVkg3LVA3QlQtTzJFNy1TUVlJLVRYVFotR1BVSiIsCiAg
  ICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdWJsaWNLZXlFQ0RII
  jogewogICAgICAgICAgImNydiI6ICJYNDQ4IiwKICAgICAgICAgICJQdWJsaWMiOi
  AidmlZQUttVV84by1UY29Yb284eGZfVjlkdVVVNnhyUV93TmVBR3NTdm5Jd0h5c1A
  2bzhPNQogIGIxNklFM1V3YTJ4dFYwSVBYdFNfZGFvQSJ9fX19fQ",
      {
        "signatures":[{
            "alg":"SHA2",
            "kid":"MDNT-Y3SK-UGF5-NPYP-XDCK-OWHW-Z7FN",
            "signature":"K39Ma4jDziIljv2jzTT5jJ50MHsDz-er6garpv5RUz
  FFWKvjPg785DtNmjGLqdIYivE9qULYHHgA-INwROlWG3y4vjvkwxcW268SrJwS0o2
  ao9ynBgvvlq2Zn0i-Ydq4l5zbDRmF2b7S_Ww2Vb-UmTIA"}
          ],
        "PayloadDigest":"1Jk8amSOEDoYRPopfjCcOGD2jebt-NPan3g1y8qAoS
  SMTXaRPmcBsAs13OlvxiSHe4MHRcD7Lo60SdWjB-v70g"}
      ],
    "EnvelopedConnectionDevice":[{
        "dig":"SHA2"},
      "ewogICJDb25uZWN0aW9uRGV2aWNlIjogewogICAgIktleVNpZ25hdHVyZSI6
  IHsKICAgICAgIlVERiI6ICJNQzdCLUNET0ctVkE3Ri1UQ0JPLTRKQ1ktUUM2Ri0yR
  jVBIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0
  tleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIkVkNDQ4IiwKICAgICAgICAgICJ
  QdWJsaWMiOiAicmNjOHktVkcteHlJLUtLWEgyMHRYY3dUSHJHd2hESnIyYnhUclZs
  SzIzS3pjOWhmbXdOawogIEpndjc5RXg2anlSaGZhckFIQk9PRElHQSJ9fX0sCiAgI
  CAiS2V5RW5jcnlwdGlvbiI6IHsKICAgICAgIlVERiI6ICJNRFFWLUE0RlMtSFpCMi
  1QQ1lHLVZQN1otVEs3TC1GNkZMIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB
  7CiAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIlg0
  NDgiLAogICAgICAgICAgIlB1YmxpYyI6ICJndlRrRzJrNTk0VmNaaGVWQnotNUNVR
  XhJMG5wSFpUdWx5TlZiSHhubS1QWjgzRWFPUGhiCiAgT0xXRjNncEtoYjFtb2FWb0
  8xZTJHWTBBIn19fSwKICAgICJLZXlBdXRoZW50aWNhdGlvbiI6IHsKICAgICAgIlV
  ERiI6ICJNRDVELVZYRVktMkpJWC1SUlVCLVFYQkUtSkc2Ni1EUlA2IiwKICAgICAg
  IlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7C
  iAgICAgICAgICAiY3J2IjogIlg0NDgiLAogICAgICAgICAgIlB1YmxpYyI6ICJPeH
  hGbmhpNmdZc0VOa1gzeEdHRVpiVTE4bE1tRy1EanJ5ZmdxdXg2dG95SlpKc2tkai1
  iCiAgNElJQXFwNHZPa0hVN0JxanhTZ0Y5QzRBIn19fX19",
      {
        "signatures":[{
            "alg":"SHA2",
            "kid":"MDF4-YA2E-FVGJ-LAG5-IK5Y-FXBB-2I56",
            "signature":"EKkjI3HoORnAS8lL_r-nCuEGfKg7oqL_KnZqlyPR-2
  ReRIRHVigkxXtQNQPmB56NZNdfuWC3V4qAQrNBEd8IYuxfomiWKvcl3eifFekt4Tp
  hzOkkHzQOETaACLEZuBwURWuvEnYkBJRNkNYDSbwelCoA"}
          ],
        "PayloadDigest":"jTc0_GpBot2m1F03vaOlZxJA8ywl78dpiFLd8a6OBW
  wY_Lm7Zt5sEG2tIGHr5VJPo6cW72wXAFHyA3LQuyTy4w"}
      ],
    "EnvelopedActivationDevice":[{
        "enc":"A256CBC",
        "dig":"SHA2",
        "kid":"EBQD-OOCD-I2BF-HRB7-PJYK-4POE-ZIRL",
        "Salt":"DBIuRwlk2nO7IkSdNuSDuA",
        "recipients":[{
            "kid":"MDUU-RE36-2XG4-2OAR-VYRN-EX65-XGZC",
            "epk":{
              "PublicKeyECDH":{
                "crv":"X448",
                "Public":"kez-kE6lKhWlw0UIDzelnq8BgT-RA2OnPpIMJk6cK
  yVIFtvVPGxotaibXISA5Kxkw2bkgdhsmW8A"}},
            "wmk":"rW6FFFj2_7quno0il3X9TsuTkspvZMqYh8nZfJfu6DnAk_eL
  HtpbsA"}
          ]},
      "-v7KPFVFY75pPqg9N2RD1sU7BBPhE9Yhzx4vs778YZIXgH2tQTnVVtAnCD3T
  bVrYH5RRfc9aEfwfyTHke-9XNjReYH5gg-V9Il9BNkIXoczefaKHdpj1cCK21RVdW
  MTS5yd4q4Vpp77NzyzSdSX5Q0IMpjzMHnWoGf2UN9xJruIEPVCtv2g-g41yPvcHzT
  eXBfI9hag2MopmKe1hM9foaFkS-5LUBbBGFCeglxuF06qaIuofdpy6W3TCHOsSx3A
  LfbsQa84XF9YgzugjYKXcGAvnA5v8jxMRiWr_gqgOtVvZhSUDGBJOMr7DqfQ5F0uE
  yTkQbgG2fx0caChFwMOCKPohHG0SNR0igrdEwfcYQbcNy8Ld1bmQh1OsTmSTUuR6c
  MFbf4rEYTYxOe22SJnb1ACLjodBY2cUES5J-xIS7RFlSDyycioC08kGFWrw1afySD
  CAwKXoINkoea_nMSRMEqBAhNlyQaCSgSgiydUBAFDHmuRPK3nLpRc3Lzq_0pcugsi
  ZAYIDZ8qCNVeJYj4c4eE5dVsQDnUeYhxaC5Wus7xrfvjqJjdAn0Tq5ln1Oc3gKnPz
  NXO4DtKxbuqOkHd1-5793-gk-y9eQzT0ZmSPM1-8VQAuL54DaR7Rgeewv_gD2CW-z
  -Z7MxQ4HLtiqItgOVQBe4PR2h_WDjLDkU8vJQ-iPXsNXPT4samxVyNfuKpfZ8bMTp
  _BClFTbd_wquJ5KJsT883mXgbiH0Mc2812fLdSSM7pjlm9mtOsebWyU3lgv1yqAbS
  Y7oDPiLoZkbHySi6eNXj2h6KtKdFAbd7-gSXE8gPP1DMCPyWVGjECzQR9BUrFfFZj
  WxKtMMiwTHCq0_FVg8OYLH0wVjm0zJvTyDfshFahFs_os6Us8qy0GFJKvulBZGJnN
  gsQn5e7bYxDV1XK2B4gdCgnJeDpyN1HUY6_MjJKd5-tbyFjc_s5rp6Tvj7Vr7TKzT
  AHZQpJcnG_iB0G4BFTB1DCDMCIzpPSCABpDVnhlyKoItoEal9N8hj_S_K_fMAE--N
  sFuY85EaSpYay8wl6zAO-BaWk1k92ULN0jLBgsiyEOJlwjk5Ec3n2ayICSzduAWzv
  vpG0OV1AAMVDOtVBW_tQdJSht13-wYNOnGRrfK7Rt7PiqSl0MmyaVXF5LqVdAM2Lj
  KpfLE1wBSJf9P4nCdunzwol6v5TQ-oxAXnI23uLTEbGASRnbzFXMr_S0zd-skj3zr
  ad_xPkp4yLYEQ4mwrNLUShjPn8x641TGiZHVAoSyiMlZj-sjzWSyXUKUv1BJY_Jvw
  gTAQ3ZU7Nah_nTueqymwZCMSZFWISf2zT0ogR4TvWLcMUQ_wYavvP82sqQZtYF-gL
  gc8ZwlmqSfQNsyFh9X6nsgPq4necldj-KLLx9AE8DdR8aq7msvO-VxrCwtwNOEmiU
  IOi720TwtYVVNhWucK-1TIM5pByTKTwlaai-0cnXbgT-u0ONGeLk0n7165k0yPmlO
  yEK_NKQ4u12dm1-rKtmi4KUSZP8zJUqZQNAmcXSfeCL11arj8XNg5w78sjZwAX4Sr
  JNLyeDYdp5LGU4t6Ni3K-U1SoXTPV3O_rgoXORH2h5zr4LXRGnHojODXxWtEJfElL
  sR55guzhhbMHZyEFWeC39XY-pc_v9oyKPFEdZf74yPaA1C2zr4l7ktLIHBdv0lmRH
  8VMFxvKmS2y4E0dC0UiJ7d9P-O665lZYhCwJjDaYy-Iheo2-c7OGFbk5EIx6oo8vp
  WpFmfYf3hRgEBp8pmX_qdSTW_vl68pnOXJDX068t3IIloA_cBv-s9PWDvACggTE0E
  64vYz9l3JE0pFbdF0puB5QR6llWJy_xbFK0V2bwD4Day_uw49H-eT6E3SCTm_LYl-
  _qinOJQqHIuwiItpbymqI8OOGvXQ7juPhmm-zwBxwbIKGPECcdblhE45upESIgBBH
  9wz2YoOo5JgmYlv5zKSgwzdn2XH7FBXavB-Z6ve50lQafGMqExy9Q_lBiEqMdZBwc
  6GZwdUjVLRGhPyWMb4GG938n7WlTUcs0Xpy6qWMMAalMrnRdpS97FcLWXsGruheNb
  QC8ymi8Aj36l0ztOWkwXP9S70vGiddLouRUvGjYdRdvM2hbJFuJ9g5K-jncAz5xXR
  vcD-fg0XwwhUG-onu1YADye7f6jWGyS2nc5Zon5eC4NEAjq3pSug8_qq79DWwqN_y
  d1iPt2VKUsm2mC71gzfPQ6TugUdD5EtvIIQR-nkcdpg-0qDyh9VozAoaFtALcFhc8
  _I4hFa5fUmRk7O9G686ismofNof5-D-Fmhqlr-u7Bl-4alAsrgcCc1fg",
      {
        "signatures":[{
            "alg":"SHA2",
            "kid":"MDF4-YA2E-FVGJ-LAG5-IK5Y-FXBB-2I56",
            "signature":"8kC6pG2NnimZw2vPjCZlWy22owYLG93SZNMqWkWeDO
  ggPsSZOfIQPAdtKk18r1JfNpY-HiSitnCAHpFbysLqt9xyk3ZJbC1h-Xl2tHh3aJm
  MMmgFH9siwAApxzNsEHaKS0LOgVos2HBIO4o5aXD1UQ8A",
            "witness":"HeZxvXPC3TV77uE6nO6SCobnS9rfNIOezZzQ7MSbfSE"}
          ],
        "PayloadDigest":"b9SWeL3WEIL-7zi0-hGbdGLcYMFUKMcJeJlxB53Pfo
  Je_7E_XcCKMAuHTB5NGwonnguhku6NgMT1a2u1LJ72rw"}
      ],
    "Accounts":[{
        "AccountUDF":"MBEA-67YL-KUQ7-LFXL-BDVK-WA6H-SV7Q",
        "EnvelopedProfileAccount":[{
            "dig":"SHA2"},
          "ewogICJQcm9maWxlQWNjb3VudCI6IHsKICAgICJLZXlPZmZsaW5lU2ln
  bmF0dXJlIjogewogICAgICAiVURGIjogIk1CRUEtNjdZTC1LVVE3LUxGWEwtQkRWS
  y1XQTZILVNWN1EiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgIC
  AiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICA
  gICAgICAgIlB1YmxpYyI6ICJwd2pESVR6VmhSMmJncFhGRjR6NFp1RTBBT1BiY0Jn
  UExzeWdOMjFEUG5KSUpaWDUwbVZpCiAgYXlTVUpnWXBVRFBKSmJEbktudm40bUVBI
  n19fSwKICAgICJLZXlzT25saW5lU2lnbmF0dXJlIjogW3sKICAgICAgICAiVURGIj
  ogIk1BVFMtTDVTTi1PNUFOLUxFUFEtS082WC1RM1BSLVlQUEYiLAogICAgICAgICJ
  QdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7
  CiAgICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICAgICAgICAiUHVibGljI
  jogIl94eGFKYThySHBtVjNVX3BDYTlFZkhwUkNtanlRb2U4eGxhNkpaaGxkRjR1NT
  Vsd3ZaVjYKICA3MDlSWEIyR00xWDB1b2x1aE95YW1hQ0EifX19XSwKICAgICJNZXN
  oUHJvZmlsZVVERiI6ICJNQ09aLUdJWjMtMzRWUS1HUTZKLUZDUzctQkpJVS1KQ09Z
  IiwKICAgICJLZXlFbmNyeXB0aW9uIjogewogICAgICAiVURGIjogIk1ENkQtU1lGN
  i0yMzZRLVE3UjctTVpHSS1JUVpSLUVYQ04iLAogICAgICAiUHVibGljUGFyYW1ldG
  VycyI6IHsKICAgICAgICAiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnY
  iOiAiWDQ0OCIsCiAgICAgICAgICAiUHVibGljIjogImFQQ1dEcEJKM3Qxd0RsemFx
  MURLeE13NFNKUjV3aDFlekcxU09CcWhXY3BBenpTWktJM20KICBmUTIwX0lpTnBsZ
  mpmMU4zWFRhTk1ZQUEifX19LAogICAgIktleUF1dGhlbnRpY2F0aW9uIjogewogIC
  AgICAiVURGIjogIk1DQzYtNlpCTy1XQVpULTNTTzQtRFpNTC1RMklSLU1QMzQiLAo
  gICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgICAiUHVibGljS2V5RUNE
  SCI6IHsKICAgICAgICAgICJjcnYiOiAiWDQ0OCIsCiAgICAgICAgICAiUHVibGljI
  jogImFLSG9ZdlBxVGhmbE9VejVhME41NENzUWdma0FnTmRGb3E0YzR1bW9YN1N2YT
  N0SHVtLTcKICAwdFZOSHdvSjVYRWdORzJLZTRzQXhnT0EifX19fX0",
          {
            "signatures":[{
                "alg":"SHA2",
                "kid":"MBEA-67YL-KUQ7-LFXL-BDVK-WA6H-SV7Q",
                "signature":"9BC3-7LcSpQbggNKVL5JJ8wdv6rzlPQq5tl6Vq
  qqkGImjX8A-xbknOMinXYQzRcX66xwkOT-WdwAlmfuspkN0oJyBANtLvcbjQOkKAK
  _FcSaZPtycLcxiSBZCw9L8bWvI7K0IGSycXsrgT-oCds7zykA"}
              ],
            "PayloadDigest":"DXwKYmecs5Jqz-NcxXaR54WFZ1_NtT0Jqe6PQP
  J0U6u69nPrak1-V8GLj3GR2cBbcnxtmkeYKvZbeizg8pF8uQ"}
          ],
        "EnvelopedConnectionAccount":[{
            "dig":"SHA2"},
          "ewogICJDb25uZWN0aW9uQWNjb3VudCI6IHsKICAgICJLZXlTaWduYXR1
  cmUiOiB7CiAgICAgICJVREYiOiAiTUJKRi0zM1FQLVk2M00tMjdCSS1TRDZRLUY0U
  UEtSlRKTCIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdW
  JsaWNLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6ICJFZDQ0OCIsCiAgICAgICA
  gICAiUHVibGljIjogIkotMy1zcm5xX2tTMmVUUDI5VEhoZGtqVi1uSC1ieU9JS28x
  eHVqUW1LU0dsbVRLbkZFLUcKICBJMXlSeHU0NDRMR00tbE9tcDNMU3RmOEEifX19L
  AogICAgIktleUVuY3J5cHRpb24iOiB7CiAgICAgICJVREYiOiAiTUFSSC1ETVAyLV
  dXWkwtSTdNWi1MNUlWLVdHQ0UtVzNUWCIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJ
  zIjogewogICAgICAgICJQdWJsaWNLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6
  ICJYNDQ4IiwKICAgICAgICAgICJQdWJsaWMiOiAiNDAzSmhpcWtfLXR5bDItckJxX
  y1Ga0tWc0JvTXBxWTc4YXV0MDJZaVFyU1E0OFdxeE13eQogIE1OR0V4a1NfY2JYUm
  R4Z0hTNzhuUmptQSJ9fX0sCiAgICAiS2V5QXV0aGVudGljYXRpb24iOiB7CiAgICA
  gICJVREYiOiAiTURZUC00SjNGLVFaWkItRFBDSy1aWkRGLUNKNjItU0dURyIsCiAg
  ICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdWJsaWNLZXlFQ0RII
  jogewogICAgICAgICAgImNydiI6ICJYNDQ4IiwKICAgICAgICAgICJQdWJsaWMiOi
  AidmxUb1FELXFUMFg4VXVOUEt4UUxMTHZPQzdGSWQ0UHNXSjlKZmd2YTBiMW5JYzJ
  nT2JSQQogIFZ5ajZrUzdKTGhSU094WEhHMGRVeU5nQSJ9fX19fQ",
          {
            "signatures":[{
                "alg":"SHA2",
                "kid":"MATS-L5SN-O5AN-LEPQ-KO6X-Q3PR-YPPF",
                "signature":"r6gZWWOxdkdgcrtH0II6L_S-MoMO-rz3vNbLqe
  cCNayy6kyaWxbatpiFBKWbtYrL9pYBe_5GPOiAbi4Y_ygvlhCLNfODYbzpHUpfX2f
  SzZ576oqsHrO5AvQNV-bbR9nI5_wv4QSPMFH_mxyIk71CLTwA"}
              ],
            "PayloadDigest":"KmYvrGFCUB4XVG7wQaXPI5N3CrP1e_8z6Xsx-d
  SUFWUmxUUuy9kkl9SbJpCYReMabWzL8y-QgKD_52oAQlYMaQ"}
          ],
        "EnvelopedActivationAccount":[{
            "enc":"A256CBC",
            "dig":"SHA2",
            "kid":"EBQP-BNWF-TCUP-EHZ4-EJ3B-3D7H-OMA2",
            "Salt":"eqV_QRR_dQrV57FYt09zVg",
            "recipients":[{
                "kid":"MDUU-RE36-2XG4-2OAR-VYRN-EX65-XGZC",
                "epk":{
                  "PublicKeyECDH":{
                    "crv":"X448",
                    "Public":"o7rAv-yR_afCmMGXcJaeK13Z7Lz1aX9WPgwQz
  M295sdoSHIItwh6XAvO23xkONPvWDUmPOC5jOoA"}},
                "wmk":"IHZ1DqRnLmkw-kD51_f1QASHKKp7YgZfoJRsmsdno5G-
  OVZ9xjFxOw"}
              ]},
          "Tb9CKZygmq9uBRY9Cdzf9oD3E6vOmZkRkDxcJsdcvvivS-kKXAHMGb3s
  NE3IsMBv5uGBc45ScggEJd8nf_uYQ17DBH3f9M-4NFBdUc6rAEOzHiQXsMSfgvAZl
  6K2Buz9OyUtrV0sRRtUJw3HYKV0uvvb3NMUOS4e6bn6DnQZd-qfyfQLV2r22dEaot
  4AwHi_RM7G7kSVkg3VDTKHy8Ag0L_07c9dnM5lJsYEMy0cL5n39iXSsfRzj9LAVX-
  Pe8ZgLU9GpjoZplTCxCqYxZUtMWzz_O_NYu8CLxhMJF8D7TRsTMfqF5wWKAEsP5OO
  oN_hLZBQUN1-vSxHAFg8u2GfU3jNDdACikYHuBu75uGkyCBmHMVVxljStyCEWkXxY
  o0tv_sQlRcQSY9nFYZrXfe8zaxOKyLO1GE-7duLfIa4ugXwc_jxUKU97im-VbEBFK
  urOWZ9MP-R8ELMU8zaPel5tcSR7Z1g768RxlUpaWOTI4Rs2Xx6Pe_LhuHAvxcH62U
  VgMFCLVrw3aoFuwO1B7coaadEBJkkkepT5GsntcP3tk55e03TQORTRB8oL7ZgB9SC
  GDdnqxp18STBoshJ02ZZvX5Fezbx7NeNHSZlf4Ww4o2itqu2lsCPUbiIJhjP3EfdI
  xlj-99qH767Y8dIfUVB1sT13ovcunMZ9WrhaUWbE4HqQcpcMr2OJN1mrvtcsBC-qk
  8AuEHOZywgsiT8BJuaVQYmno-Z1rRzihlP2O9leLGX14OXibRErWC4gkIUgOtoV_l
  kaVZyPrULcbg1oTlsQuL2HlDg6YzHHXRRRO9sUX4srQArhREeKGmASNyUYhTGFVke
  PXdcG8H0XzZcWk9PV7ZfwJ6n5_YU7LsR-hpViPhq2rhVFNnqPVvlwR63UEBx5Xjjc
  rHUTPWY9xOIWrckmPxRsK_8Tm-_Pkg4vi-XAn6uGVMafmeRTp05R2R4EQtDg44Hrd
  bihhP9lA9JRCOzNwWcDinogC3oRHOaCP69aqY5f3dvbWSD5oTA--toksA2lU35_jL
  HHW2XX6SL0-8Q5ey5E48sxArOCmTgKCmpWOzoYkKs1wPqTg6f_BCuRu6w7I1QEPpf
  xKnmvcsG7RJHBgJD466a_FwCuubHRyvVVS332TjdAgqrCDVFBF0jZ3ZFokq-o01Z_
  MHaI2lMQPNH6nXA-RtKAM1z9WaJaWdTT8_PXFjq25uYxCBL2k1clldRztmq0E9lQk
  QlQhf0q86x0vY_2aKsJrYM30RvORPfaM8BP6rXixIOMKwfxsWKHAwFMyVhCnSPmRR
  7SctpqsVo7STzHkD5qLXLXmjQhpohihdn1_iFQsbmx_Bpu38jU_r0gF1oM5DMSp_L
  eGYlawFIugTv2yWZ_EotqqYot2KjRSFDmfT7yvcC-Cuut8CQUkRwpsVqsI5qm9yWm
  v3i0pe9MWvvkC3bnSHG3V3WI4-dJmYEJ4O6x04kbTJZm5UWHZ36aABjEQfXlOBTYr
  WybJJ9Bos5Tlc_Se1FRA49_Ip0U7v15odFpsQ9kx69nN31jhOofJaJZYIEifSWL91
  izIvf0a8F8u6t-PFZ9XBNSVxCOgnTb6XPlTDMjsumG_coT676Pf9h4RZ7mFU8i1zG
  OaeE4QCWv75OhNQREINYOQKcBRyS3r6UGr2mZlS-zI3AGlAYkw4FGHnOuvQ7jxmAi
  kSXo8ALKYqgzCvXZ806Cq8oHsaEqVqOZZfkQeuRr4xY9PIkavU78hkE6GpdtqHUuu
  ccwX4c5KJSn1-OyKuV_uRkRwgdUxNj7GaC3z_rpixqxGo4Yvnbbme1AdW4_P2HF5X
  UJj4xVsqK0TeNJE03iF2tO0SBfWyKwkS1wWr3U7GIdJtJp1ABxeqGrqKb1J7f9Syx
  fbpPgFlYoHfEGfHLZGXUFAgEI9FG0pObM3-RDL9z2q_C6CLbjWMO1Tn9vNY4ZLyx4
  brwDljYt1P-nG2fEknV7OxmUHzs73RxYVuVFP0RcDPErAzw1Kd6PHEWaTVGMWYVSu
  1DZ1k_fhhi1ygL-wwnIMDzZXFoSBzCqtqS4egAdVmhYOKjwYi4Ifm9nMynnraQ8fV
  aCp1PduuMBkQ1yALnMRUEI5oFvVxCrIFRFtMq490dNB3BQSUn-g8p_s9OAVK7CLzh
  rRNaz6BV_w1FusH_zG1S3GwWfSZMIL70gX0By8XkOFcSdDbig8YiM1BdR7BJnh0_k
  jxDsHu2peubCH2-FVy3FYL_QskeVkkK0iGLWB51P1DxCu85bKhT_CELRlgWJBw5vc
  tYRTp5iQiFwkQczqiMJaKd_egWQlIkNNrZPV-WsCmqKgxe0e7dRczO4VNFtB78rhf
  nhFc2NSm0wPk04AjmUU7a380gPuW0CPR02z0ztnmi1DknTh7jUFfmdV8RXHUIbPFN
  pfOYdJUVFnJt4yfeKGB17CoEcnBY1LISn5eAEHltuRomHzno67OCs-RNMlazd1vKQ
  YAMiepuSTd7egtphEMP6_MkhTYaBXS91G-yE_sF2lJZsqpReX8fCuaM34lTRq6urU
  PRKh7IM4ZLqraaZ4ASK3QRfBj2uZS93i0A8dyN1f_ffR3RHT35xX5VaMRB1JkGicc
  yEHDCSyfNoA3LlzT8N1KPpyooqKkGDvbkLH88maxSsLqcoL0VIBTF-C5wVL_jeM3Q
  P_NTJ5zqnsSpJuJrTHiXUnHhfl4BLpEUfkcOrHb8XZ8WTRLyCYbgqBb6R2OVLZtH8
  SGfCJtRmCdKkKwH1BdIwMMX2zhTmmap8tnBvp2vsgWM3NabU0wTVx09aZxj5XDm9A
  NFJJinDj8dfNYFyN-eb9Zqzzp2BbV7FQ-3HmyRwk8hU_rwbyyXHWAMuFGgoa-j13l
  eh0O2S0FFWfTNmriqWJg2dKmKLFpwvEyOO7CA5IU534G7U3SoD8hPsXwWOG-6BNtu
  zMhUxch76711XC4MaOkxohDoslyfamvRVGvw6uaHM4Zd1n54Oy3RLR2MCUVShPLYT
  glCukkC8_nH4WnzBtfaeMq2dels",
          {
            "signatures":[{
                "alg":"SHA2",
                "kid":"MATS-L5SN-O5AN-LEPQ-KO6X-Q3PR-YPPF",
                "signature":"mkEOd7NA84EH36XeQV2hA6RSXTRd3FjBPxWOk3
  rjY0nXvKx_aFqGcu6ywa50Xa7DHooBh4L39FeAgGzBJlingimbwMCBq2M0y-4Ww7O
  wGD5ZqYH7juW5ODvkn8NOAYHdYjHKp3onkfdvee5IRkQqzBwA",
                "witness":"TUKDcII3VDgj9HesDUQelHjnWWQGpr0TlfeK2yWD
  8Y4"}
              ],
            "PayloadDigest":"iWrOT-Xm43AP3_yqR9ewCaePpWNM_QI6i-Tygq
  bgC0g5Rq3UwhGBOq_Z67T_Cuash2lWgSsY6znOpKLG0dViQA"}
          ]}
      ]}}¶

The derivation of the Connection encryption and signature keys from the Profile and Private contributions in this example is shown in [draft-hallambaker-mesh-cryptography].¶

4.1.2.1. Creating a ProfileDevice

Creating a ProfileDevice comprises the steps of:¶

1. Creating the necessary key ¶
2. Signing the ProfileDevice using the Master Signature Key¶
3. Once created, a ProfileDevice is never changed. In the unlikely event that any modification is required, a completely new ProfileDevice MUST be created.¶

Devices are only connected to a personal Mesh by administration device. This comprises the steps of:¶

1. Generating the PrivateDevice keys.¶
2. Creating the ConnectionDevice data from the public components of the ProfileDevice and PrivateDevice keys and signing it using the administration key.¶
3. Creating the Activations for the device and signing them using the administration key.¶
4. Creating the CatalogEntryDevice for the device and adding it to the CatalogDevice of the Personal Mesh.¶
5. If the Personal Mesh has accounts that are connected to a Mesh Service, synchronizing the CatalogEntryDevice to those services.¶

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

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":"MBEA-67YL-KUQ7-LFXL-BDVK-WA6H-SV7Q",
      "PublicParameters":{
        "PublicKeyECDH":{
          "crv":"Ed448",
          "Public":"pwjDITzVhR2bgpXFF4z4ZuE0AOPbcBgPLsygN21DPnJIJZX
  50mViaySUJgYpUDPJJbDnKnvn4mEA"}}},
    "KeysOnlineSignature":[{
        "UDF":"MATS-L5SN-O5AN-LEPQ-KO6X-Q3PR-YPPF",
        "PublicParameters":{
          "PublicKeyECDH":{
            "crv":"Ed448",
            "Public":"_xxaJa8rHpmV3U_pCa9EfHpRCmjyQoe8xla6JZhldF4u5
  5lwvZV6709RXB2GM1X0uoluhOyamaCA"}}}
      ],
    "AccountAddresses":["alice@example.com"
      ],
    "MeshProfileUDF":"MCOZ-GIZ3-34VQ-GQ6J-FCS7-BJIU-JCOY",
    "KeyEncryption":{
      "UDF":"MD6D-SYF6-236Q-Q7R7-MZGI-IQZR-EXCN",
      "PublicParameters":{
        "PublicKeyECDH":{
          "crv":"X448",
          "Public":"aPCWDpBJ3t1wDlzaq1DKxMw4SJR5wh1ezG1SOBqhWcpAzzS
  ZKI3mfQ20_IiNplfjf1N3XTaNMYAA"}}},
    "KeyAuthentication":{
      "UDF":"MCC6-6ZBO-WAZT-3SO4-DZML-Q2IR-MP34",
      "PublicParameters":{
        "PublicKeyECDH":{
          "crv":"X448",
          "Public":"aKHoYvPqThflOUz5a0N54CsQgfkAgNdFoq4c4umoX7Sva3t
  Hum-70tVNHwoJ5XEgNG2Ke4sAxgOA"}}},
    "EnvelopedProfileService":[{
        "dig":"SHA2"},
      "ewogICJQcm9maWxlU2VydmljZSI6IHsKICAgICJLZXlPZmZsaW5lU2lnbmF0
  dXJlIjogewogICAgICAiVURGIjogIk1EM0UtVFpHTC1UMktXLVhQVVQtTkxFRC1KU
  FJHLUFHTFUiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgICAiUH
  VibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICA
  gICAgIlB1YmxpYyI6ICI4eFFQdW5pUk56UE5tUkhtU2V5WnJiOVNjcXNTQ3A0cEVy
  Wl9Iemc2WVdqbDlNUUVLbk1OCiAgcTNyTU04MUZ5bl9OSkFjY2RsbUxITEdBIn19f
  SwKICAgICJLZXlFbmNyeXB0aW9uIjogewogICAgICAiVURGIjogIk1CQU8tVktGTS
  03TUxWLVhCTkUtVFJQWS1RQUdTLVdSNjMiLAogICAgICAiUHVibGljUGFyYW1ldGV
  ycyI6IHsKICAgICAgICAiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYi
  OiAiWDQ0OCIsCiAgICAgICAgICAiUHVibGljIjogIlVWVFFvTFRPYnVTQTlVSDFKS
  UFySWFMRmdreThfbXpHYVBOTGF4WFlSVWUxcW9YUV9PemEKICBlZzJCNk5xS2lKWk
  FsUzVrXy1QWEFzOEEifX19fX0",
      {
        "signatures":[{
            "alg":"SHA2",
            "kid":"MD3E-TZGL-T2KW-XPUT-NLED-JPRG-AGLU",
            "signature":"3zj3XnmuIgUloMGog19_b12uC1wvh--gPvvCMxPXj2
  iYvGUltDPgCqU5EJ9ZngM9TykT2OSsY8gA2m84D_Oy_KcrxcgKK37JRAHJlIAjJyE
  Cp5VgUBA6NYTa5iHnRaTqxrhc4GSBXIQTYNnLSJ_CIwkA"}
          ],
        "PayloadDigest":"Ma9b6EG7gYsal3dUonQ4BgH4ULYlbUFOtyLt25Jixb
  9bXBdhppSr0AdFj9Be8Akob_ZtAnRmhzizkK1egtUHWA"}
      ]}}¶

Each device using the account requires an activation record: ¶

{
  "ActivationAccount":{
    "EnvelopedConnection":[{
        "dig":"SHA2"},
      "ewogICJDb25uZWN0aW9uQWNjb3VudCI6IHsKICAgICJLZXlTaWduYXR1cmUi
  OiB7CiAgICAgICJVREYiOiAiTUJKRi0zM1FQLVk2M00tMjdCSS1TRDZRLUY0UUEtS
  lRKTCIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdWJsaW
  NLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6ICJFZDQ0OCIsCiAgICAgICAgICA
  iUHVibGljIjogIkotMy1zcm5xX2tTMmVUUDI5VEhoZGtqVi1uSC1ieU9JS28xeHVq
  UW1LU0dsbVRLbkZFLUcKICBJMXlSeHU0NDRMR00tbE9tcDNMU3RmOEEifX19LAogI
  CAgIktleUVuY3J5cHRpb24iOiB7CiAgICAgICJVREYiOiAiTUFSSC1ETVAyLVdXWk
  wtSTdNWi1MNUlWLVdHQ0UtVzNUWCIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjo
  gewogICAgICAgICJQdWJsaWNLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6ICJY
  NDQ4IiwKICAgICAgICAgICJQdWJsaWMiOiAiNDAzSmhpcWtfLXR5bDItckJxXy1Ga
  0tWc0JvTXBxWTc4YXV0MDJZaVFyU1E0OFdxeE13eQogIE1OR0V4a1NfY2JYUmR4Z0
  hTNzhuUmptQSJ9fX0sCiAgICAiS2V5QXV0aGVudGljYXRpb24iOiB7CiAgICAgICJ
  VREYiOiAiTURZUC00SjNGLVFaWkItRFBDSy1aWkRGLUNKNjItU0dURyIsCiAgICAg
  ICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdWJsaWNLZXlFQ0RIIjoge
  wogICAgICAgICAgImNydiI6ICJYNDQ4IiwKICAgICAgICAgICJQdWJsaWMiOiAidm
  xUb1FELXFUMFg4VXVOUEt4UUxMTHZPQzdGSWQ0UHNXSjlKZmd2YTBiMW5JYzJnT2J
  SQQogIFZ5ajZrUzdKTGhSU094WEhHMGRVeU5nQSJ9fX19fQ",
      {
        "signatures":[{
            "alg":"SHA2",
            "kid":"MATS-L5SN-O5AN-LEPQ-KO6X-Q3PR-YPPF",
            "signature":"r6gZWWOxdkdgcrtH0II6L_S-MoMO-rz3vNbLqecCNa
  yy6kyaWxbatpiFBKWbtYrL9pYBe_5GPOiAbi4Y_ygvlhCLNfODYbzpHUpfX2fSzZ5
  76oqsHrO5AvQNV-bbR9nI5_wv4QSPMFH_mxyIk71CLTwA"}
          ],
        "PayloadDigest":"KmYvrGFCUB4XVG7wQaXPI5N3CrP1e_8z6Xsx-dSUFW
  UmxUUuy9kkl9SbJpCYReMabWzL8y-QgKD_52oAQlYMaQ"}
      ],
    "ActivationKey":"ZAAQ-LHEO-K5PD-WAW5-2ZHC-3WGY-F4QF-ELKK-CQEB-YCA
        K-SGIU-QI3Z-CQ7Z-6JEE",
    "AccountUDF":"MDNT-Y3SK-UGF5-NPYP-XDCK-OWHW-Z7FN",
    "KeyAccountEncryption":{
      "UDF":"MD6D-SYF6-236Q-Q7R7-MZGI-IQZR-EXCN",
      "PublicParameters":{
        "PublicKeyECDH":{
          "crv":"X448",
          "Public":"aPCWDpBJ3t1wDlzaq1DKxMw4SJR5wh1ezG1SOBqhWcpAzzS
  ZKI3mfQ20_IiNplfjf1N3XTaNMYAA"}},
      "PrivateParameters":{
        "PrivateKeyECDH":{
          "crv":"X448",
          "Private":"ocf5RAK99c8jEm2DyekXfWfmZwKgOqA_Vznrefs0Wx6HAI
  9-YZpAt1KuxnJTCx9scpFDLcIQe_k"}}}}}¶

4.2.1. Creating a ProfileAccount

Creating a ProfileAccount comprises the steps of:¶

1. [TBS]¶
2. .¶
3. Signing the ProfileMaster using the Master Signature Key¶

Adding a device to an account comprises the steps of:¶

1. Creating a PrivateAccount instance for the device.¶
2. Creating a ConnectionAccountDevice for the device using the public keys from the PrivateAccount instance and the ProfileDevice.¶
3. Creating an ActivationAccount for the device containing the PrivateAccount and ConnectionAccountDevice instances.¶
4. Adding the ActivationAccount to the CatalogEntryDevice of the device.¶
5. If the Personal Mesh has accounts that are connected to a Mesh Service, synchronizing the CatalogEntryDevice to those services.¶

Binding a ProfileAccount to a Mesh Service the steps of:¶

1. [TBS]¶
2. .¶
3. Signing the ProfileMaster using the Master Signature Key¶

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

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 ¶

{
  "ProfileService":{
    "KeyOfflineSignature":{
      "UDF":"MD3E-TZGL-T2KW-XPUT-NLED-JPRG-AGLU",
      "PublicParameters":{
        "PublicKeyECDH":{
          "crv":"Ed448",
          "Public":"8xQPuniRNzPNmRHmSeyZrb9ScqsSCp4pErZ_Hzg6YWjl9MQ
  EKnMNq3rMM81Fyn_NJAccdlmLHLGA"}}},
    "KeyEncryption":{
      "UDF":"MBAO-VKFM-7MLV-XBNE-TRPY-QAGS-WR63",
      "PublicParameters":{
        "PublicKeyECDH":{
          "crv":"X448",
          "Public":"UVTQoLTObuSA9UH1JIArIaLFgky8_mzGaPNLaxXYRUe1qoX
  Q_Ozaeg2B6NqKiJZAlS5k_-PXAs8A"}}}}}¶

The host also has a profile ¶

{
  "ProfileHost":{
    "KeyOfflineSignature":{
      "UDF":"MCBZ-6BPF-XG3U-DPBF-5CUW-ERYV-EDYS",
      "PublicParameters":{
        "PublicKeyECDH":{
          "crv":"Ed448",
          "Public":"gJhMP-nkJ4L4cIYSK3KPnGgVcpUFI4UOFaDTYp0qUC7loWV
  2nkBem9vVFbjbAMlc6v1p5xzL0tMA"}}},
    "KeyAuthentication":{
      "UDF":"MDHQ-D6GD-T2WP-IGGV-23HS-EPGE-TX6K",
      "PublicParameters":{
        "PublicKeyECDH":{
          "crv":"X448",
          "Public":"sY8DKs05Nv4elEcUf4rjTkoTMAwXn8jkst2N6-thywUnuNK
  my_xw-O3ztQAz4YQz9fluWt8iqnKA"}}}}}¶

And there should be a connection of the host to the service but this isn't implemented yet: ¶

$$$$ Empty $$$$¶

4.3.1. Creating a ProfileService

[TBS]¶

Creating a ProfileService comprises the steps of:¶

1. [TBS]¶
2. .¶
3. [TBS]¶
4. ¶
5. Signing the ProfileMaster using the Master Signature Key¶

¶

4.3.2. Creating a ProfileHost

Creating a ProfileHost comprises the steps of:¶

1. [TBS]¶
2. .¶
3. [TBS]¶
4. ¶
5. Signing the ConnectionHost using the Master Signature Key of the ProfileService.¶

Creating a ConnectionHost comprises the steps of:¶

1. [TBS]¶
2. .¶
3. Signing the ConnectionHost using the Master Signature Key of the ProfileService.¶

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¶

The outbound Mesh Service checks to see that the message request does not violate its acceptable use policy. Accounts that make a large number of message requests that result in complaints SHOULD be subject to consequences ranging from restriction of the number and type of messages sent to suspending or terminating messaging privileges.¶

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

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

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

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

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

{
  "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 $$$$¶

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

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

[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

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

The KeyData 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. ¶

NotBefore: DateTime (Optional) ¶

If present specifies a time instant that use of the private key is not valid before. ¶

NotOnOrAfter: DateTime (Optional) ¶

If present specifies a time instant that use of the private key is not valid on or after. ¶

A set of escrowed keys. ¶

[No fields] ¶

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

Parent class from which all condition classes are derived. ¶

[No fields] ¶

7.2.3. Base Classes

Abstract classes from which the Profile, Activation and Connection classes are derrived. ¶

7.2.4. Structure: Profile

Inherits: Assertion ¶

Parent class from which all profile classes are derived ¶

KeyOfflineSignature: KeyData (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: KeyData [0..Many] ¶

A Personal profile contains at least one OSK which is used to sign device administration application profiles. ¶

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

EnvelopedConnection: DareEnvelope (Optional) ¶

The signed AssertionDeviceConnection. ¶

ActivationKey: String (Optional) ¶

The master secret from which all the key contributions are derrived. ¶

A Mesh profile does not have activation or connection classes associated with it. ¶

It might be more consistent to represent administation devices as activations on the ProfileMesh class though. ¶

7.2.9. Structure: ProfileMesh

Inherits: Profile ¶

Describes the long term parameters associated with a personal profile. ¶

KeysMasterEscrow: KeyData [0..Many] ¶

A Personal Profile MAY contain one or more PMEK keys to enable escrow of private keys used for stored data. ¶

KeyEncryption: KeyData (Optional) ¶

Key used to pass encrypted data to the device such as a DeviceUseEntry ¶

Describes a mesh device. ¶

Description: String (Optional) ¶

Description of the device ¶

KeyEncryption: KeyData (Optional) ¶

Key used to pass encrypted data to the device such as a DeviceUseEntry ¶

KeyAuthentication: KeyData (Optional) ¶

Key used to authenticate requests made by the device. ¶

[No fields] ¶

7.2.13. Structure: ConnectionDevice

Inherits: Connection ¶

Permissions: Permission [0..Many] ¶

List of the permissions that the device has been granted. ¶

KeySignature: KeyData (Optional) ¶

The signature key for use of the device under the profile ¶

KeyEncryption: KeyData (Optional) ¶

The encryption key for use of the device under the profile ¶

KeyAuthentication: KeyData (Optional) ¶

The authentication key for use of the device under the profile ¶

Public device entry, indexed under the device ID ¶

UDF: String (Optional) ¶

UDF of the signature key of the device in the Mesh ¶

EnvelopedProfileMesh: DareEnvelope (Optional) ¶

The Mesh profile ¶

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 ¶

A publication. ¶

ID: String (Optional) ¶

Unique identifier code ¶

Authenticator: String (Optional) ¶

The witness key value to use to request access to the record. ¶

EnvelopedData: DareEnvelope (Optional) ¶

Dare Envelope containing the entry data ¶

NotOnOrAfter: DateTime (Optional) ¶

Epiration time (inclusive) ¶

Account assertion. This is signed by the service hosting the account. ¶

AccountAddresses: String [0..Many] ¶

Service address(es). ¶

MeshProfileUDF: String (Optional) ¶

Master profile of the account being registered. ¶

KeyEncryption: KeyData (Optional) ¶

Key used to encrypt data under this profile ¶

KeyAuthentication: KeyData (Optional) ¶

Key used to authenticate requests made by the device. ¶

EnvelopedProfileService: DareEnvelope (Optional) ¶

The service profile ¶

Contains the Account information for an account with a CatalogedDevice. ¶

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 ¶

[No fields] ¶

7.2.22. Mesh Group Classes

7.2.23. 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. ¶

AccountAddresses: String [0..Many] ¶

Service address(es). ¶

KeyEncryption: KeyData (Optional) ¶

Key currently used to encrypt data under this profile ¶

Describes the connection of a member to a group. ¶

Inherits: Connection ¶

KeyEncryption: KeyComposite (Optional) ¶

The decryption key for the user within the group ¶

Profile of a Mesh Service ¶

KeyAuthentication: KeyData (Optional) ¶

Key used to authenticate service connections. ¶

KeyEncryption: KeyData (Optional) ¶

Key used to encrypt data under this profile ¶

[No fields] ¶

7.2.29. Mesh Host Classes

7.2.30. Structure: ProfileHost

Inherits: Profile ¶

KeyAuthentication: KeyData (Optional) ¶

Key used to authenticate service connections. ¶

[No fields] ¶

7.3. Cataloged items

7.3.1. Data Structures

Classes describing data used in cataloged data. ¶

7.3.2. Structure: Contact

Inherits: Assertion ¶

Base class for contact entries. ¶

Id: String (Optional) ¶

The globally unique contact identifier. ¶

Anchors: Anchor [0..Many] ¶

Mesh fingerprints associated with the contact. ¶

NetworkAddresses: NetworkAddress [0..Many] ¶

Network address entries ¶

Locations: Location [0..Many] ¶

The physical locations the contact is associated with. ¶

Roles: Role [0..Many] ¶

The roles of the contact ¶

Bookmark: Bookmark [0..Many] ¶

The Web sites and other online presences of the contact ¶

Sources: TaggedSource [0..Many] ¶

Source(s) from which this contact was constructed. ¶

Trust anchor ¶

UDF: String (Optional) ¶

The trust anchor. ¶

Validation: String (Optional) ¶

The means of validation. ¶

Source from which contact information was obtained. ¶

LocalName: String (Optional) ¶

Short name for the contact information. ¶

Validation: String (Optional) ¶

The means of validation. ¶

BinarySource: Binary (Optional) ¶

The contact data in binary form. ¶

EnvelopedSource: DareEnvelope (Optional) ¶

The contact data in enveloped form. If present, the BinarySource property is ignored. ¶

Contact for a group, including encryption groups. ¶

[No fields] ¶

7.3.6. Structure: ContactPerson

Inherits: Contact ¶

CommonNames: PersonName [0..Many] ¶

List of person names in order of preference ¶

The name of an organization ¶

Inactive: Boolean (Optional) ¶

If true, the name is not in current use. ¶

RegisteredName: String (Optional) ¶

The registered name. ¶

DBA: String (Optional) ¶

Names that the organization uses including trading names and doing business as names. ¶

The name of a natural person ¶

Inactive: Boolean (Optional) ¶

If true, the name is not in current use. ¶

FullName: String (Optional) ¶

The preferred presentation of the full name. ¶

Prefix: String (Optional) ¶

Honorific or title, E.g. Sir, Lord, Dr., Mr. ¶

First: String (Optional) ¶

First name. ¶

Middle: String [0..Many] ¶

Middle names or initials. ¶

Last: String (Optional) ¶

Last name. ¶

Suffix: String (Optional) ¶

Nominal suffix, e.g. Jr., III, etc. ¶

PostNominal: String (Optional) ¶

Post nominal letters (if used). ¶

Provides all means of contacting the individual according to a particular network address ¶

Inactive: Boolean (Optional) ¶

If true, the name is not in current use. ¶

Address: String (Optional) ¶

The network address, e.g. alice@example.com ¶

NetworkCapability: String [0..Many] ¶

The capabilities bound to this address. ¶

EnvelopedProfileAccount: DareEnvelope (Optional) ¶

Optional enveloped profile for the Address ¶

Protocols: NetworkProtocol [0..Many] ¶

Public keys associated with the network address ¶

Base class for cataloged Mesh data. ¶

Labels: String [0..Many] ¶

The set of labels describing the entry ¶

[No fields] ¶

7.4.6. Structure: CatalogedCapability

Inherits: CatalogedEntry ¶

[No fields] ¶

7.4.7. Structure: CryptographicCapability

Id: String (Optional) ¶

The identifier of the capability. If this is a user capability, MUST match the KeyData identifier. If this is a serviced capability, MUST match the value of ServiceId on the corresponding service capability. ¶

KeyData: KeyData (Optional) ¶

The key that enables the capability ¶

EnvelopedKeyShares: DareEnvelope [0..Many] ¶

One or more enveloped key shares. ¶

SubjectId: String (Optional) ¶

The identifier of the resource that is controlled using the key. ¶

SubjectAddress: String (Optional) ¶

The address of the resource that is controlled using the key. ¶

The corresponding key is a decryption key ¶

[No fields] ¶

7.4.9. Structure: CapabilityDecryptPartial

Inherits: CapabilityDecrypt ¶

The corresponding key is an encryption key ¶

ServiceId: String (Optional) ¶

The identifier used to claim the capability from the service.[Only present for a partial capability.] ¶

ServiceAddress: String (Optional) ¶

The service account that supports a serviced capability. [Only present for a partial capability.] ¶

The corresponding key is an encryption key ¶

AuthenticationId: String (Optional) ¶

UDF of trust root under which request to use a serviced capability must be authorized. [Only present for a serviced capability] ¶

The corresponding key is an administration key ¶

[No fields] ¶

7.4.12. Structure: CapabilityKeyGenerate

Inherits: CryptographicCapability ¶

The corresponding key is a key that may be used to generate key shares. ¶

[No fields] ¶

7.4.13. Structure: CapabilityFairExchange

Inherits: CryptographicCapability ¶

The corresponding key is a decryption key to be used in accordance with the Micali Fair Electronic Exchange with Invisible Trusted Parties protocol. ¶

[No fields] ¶

7.4.14. Structure: CatalogedBookmark

Inherits: CatalogedEntry ¶

Uri: String (Optional) ¶

Title: String (Optional) ¶

Path: String (Optional) ¶

[No fields] ¶

7.4.20. Structure: CatalogedApplicationMail

Inherits: CatalogedApplication ¶

[No fields] ¶

7.4.21. Structure: CatalogedApplicationNetwork

Inherits: CatalogedApplication ¶

[No fields] ¶

7.5. Static Assertions

7.5.1. Structure: DevicePreconfiguration

A data structure that is passed ¶

EnvelopedProfileDevice: DareEnvelope (Optional) ¶

The device profile ¶

ConnectUri: String (Optional) ¶

The connection URI. This would normally be printed on the device as a QR code. ¶

[No fields] ¶

7.6.4. Structure: MessagePinValidated

Inherits: Message ¶

AuthenticatedData: DareEnvelope (Optional) ¶

Enveloped data that is authenticated by means of the PIN ¶

ClientNonce: Binary (Optional) ¶

PinUDF: String (Optional) ¶

Fingerprint of the PIN value used to authenticate the request. ¶

PinWitness: Binary (Optional) ¶

Witness value calculated as KDF (Device.UDF + AccountAddress, ClientNonce) ¶

Connection request message. This message contains the information ¶

Inherits: MessagePinValidated ¶

AccountAddress: String (Optional) ¶

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

Respond to RequestConnection message to grant or refuse the connection request. ¶

Inherits: Message ¶

Result: String (Optional) ¶

The response to the request. One of "Accept", "Reject" or "Pending". ¶

CatalogedDevice: CatalogedDevice (Optional) ¶

The device information. MUST be present if the value of Result is "Accept". MUST be absent or null otherwise. ¶

[No fields] ¶

7.6.15. Structure: MessageClaim

Inherits: Message ¶

PublicationId: String (Optional) ¶

ServiceAuthenticate: String (Optional) ¶

DeviceAuthenticate: String (Optional) ¶

Expires: DateTime (Optional) ¶

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

Create new Mesh Profile, Device Profile, Add to Host Catalog¶

Create MeshCatalog¶

11.1.2. Adding an Account

Create new Account Profile, Add to MeshCatalog¶

Create new Account Device Catalog¶

For each device to be added to the account: Create Account Connection Assertion, add to Account Device Catalog.¶

11.1.3. Adding a Device

Create a Device Connection Assertion.¶

For each account the device is to be added to: Create Account Connection Assertion, add to Account Device Catalog.¶

11.2. Service

Master Catalog¶

Catalog of all services on machine¶

Service Catalog¶

Catalog of accounts in the 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

¶

¶

¶

¶

References

Author's Address