Mathematical Mesh 3.0 Part IV: Schema Reference

Internet-Draft	Mesh Schema Reference	October 2024
Hallam-Baker	Expires 17 April 2025	[Page]

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 ([email protected]), 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.¶

3. Actors

The Mesh mediates interactions between three principal actors: Accounts, Devices, and Services.¶

Currently two account types are specified, user accounts which belong to an individual user and group accounts that are used to share access to confidential information between a group of users. It may prove useful to define new types of account over time or to eliminate the distinction entirely. When active a Mesh account is bound to a Mesh Service. The service to which an account is bound MAY be changed over time but an account can only be bound to a single service at a time.¶

A Mesh account is an abstract construct that (when active) is instantiated across one or more physical machines called a device. Each device that is connected to an account has a separate set of cryptographic keys that are used to interact with other devices connected to the account and MAY be provisioned with access to the account private keys which MAY or MAY NOT be mediated by the current Mesh Service. A user's Mesh accounts and the devices connected to them constitute that user's Personal Mesh.¶

A Mesh Service is an abstract construct that is provided by one or more physical machines called Hosts. A Mesh Host is a device that is attached to a service rather than an account.¶

3.1. Accounts

A Mesh Account is described by a Profile descended from Profile Account and contains a set of Mesh stores. Currently two account profiles are defined:¶

ProfileUser: Describes a user account.¶
ProfileGroup: Describes a group account used to share confidential information between a group of users.¶

Both types of profile specify the following fields:¶

ProfileSignature: The public signature key used to authenticate the profile itself¶
AccountAddress: The account name to which the account is currently bound. (e.g. [email protected], @alice).¶
ServiceUdf: If the account is active, specifies the fingerprint of the service profile to which the account is currently bound.¶
AdministratorSignature: The public signature key used to verify administrative actions on the account. In particular addition of devices to a user account or members to a group account.¶
AccountEncryption: The public encryption key for the account. All messages sent to the account MUST be encrypted under this key. By definition, all data encrypted under this account is encrypted under this key.¶

User accounts specify two additional public keys, AccountSignature and AccountAuthentication which allow signature and authentication operations under the account context.¶

Every account contains a set of catalogs and spools that are managed by the service as directed by the contents of the associated Access catalog.¶

For example, the personal account profile Alice created in¶

For example, Alice creates a personal account:¶

Alice> meshman account create [email protected]
[email protected]
UDF=MBQC-7OHA-RNBA-FRDL-R4GI-YQHA-DL36

The account profile created is:¶

{
  "ProfileUser":{
    "CommonSignature":{
      "Udf":"MDNT-WT3G-346G-4I5T-YV7F-LTQX-PSNT",
      "PublicParameters":{
        "PublicKeyECDH":{
          "crv":"Ed448",
          "Public":"IMyMo7fEy2vHp8syQ0VU4XivpJEhgQQSX3j8mva4HC_T0
  5UnhQYqVZyuvIQEVo2dyMCRm60Q3E0A"}}},
    "AccountAddress":"[email protected]",
    "ServiceUdf":"MBQD-ETXU-HZRW-A26O-WDTR-K7GI-X6JD",
    "EscrowEncryption":{
      "Udf":"MCKD-3MR6-P2TE-M6U4-4LIO-ZTRG-DZVS",
      "PublicParameters":{
        "PublicKeyECDH":{
          "crv":"X448",
          "Public":"1vNUAAp3rszIphG8EsfoaO5Y6sZCn0Hc8zCgdQivYpJAc
  DtmkSsCeI2gmDTCK6SrS1UgPtuYmTwA"}}},
    "AdministratorSignature":{
      "Udf":"MD2L-6M7C-Z3Z3-Q3AL-JFYI-ZIUC-BKUR",
      "PublicParameters":{
        "PublicKeyECDH":{
          "crv":"Ed448",
          "Public":"bHoKb0c12F7cibM_3gZcJXMzOOX4snHgPVwOfRYk6ARJO
  sGPemsd2Bm0WfmAkRYO3EQ6fj8_NzSA"}}},
    "CommonEncryption":{
      "Udf":"MAYF-D7LJ-5IMP-EUCG-HSGH-7LSR-AAPZ",
      "PublicParameters":{
        "PublicKeyECDH":{
          "crv":"X448",
          "Public":"c7oorJ808sc9d40KXDhIHgCTFz39MK3JjO0Q7K_ufDEGD
  KiwVKhd3oPQ44PEqGjwkpp7OfbcBbSA"}}},
    "CommonAuthentication":{
      "Udf":"MAFT-SINA-SFXI-PBDY-WRHE-NXYL-DXVT",
      "PublicParameters":{
        "PublicKeyECDH":{
          "crv":"X448",
          "Public":"XcgEz9y2cqsx4ZebGERTjrN-xzN83D-pcx0651x-WUCqY
  NrsnzTH40CpoMxuN-FnpT5m_b0MyuKA"}}},
    "RootUdfs":["YBJR3jR2PljdYk5qxbWdHY0rTYEaFAkHY3MmsR8zvN1Dr33Rn
  LUL3ThrG9DMWBZ3P-8ZyGzyKaQYweco2ZUtcKw"
      ]}}

3.2. Device

Every Mesh device has a set of private keys that are unique to that device. These keys MAY be installed during manufacture, installed from an external source after manufacture or generated on the device. If the platform capabilities allow, device private keys SHOULD be bound to the device so that they cannot be extracted or exported without substantial effort.¶

The public keys corresponding to the device private keys are specified in a ProfileDevice. This MUST contain at least the following fields:¶

ProfileSignature: The public signature key used to authenticate the profile itself.¶
Encryption: Public encryption key used as a share contribution to generation of device encryption keys to be used in the context of an account and to decrypt data during the process of connecting to an account.¶
Authentication: Public authentication key used as a share contribution to generation of device authentication keys to be used in the context of an account and to authenticate the device to a service during the process of connecting to an account.¶
Signature: Public signature key used as a share contribution to generation of device signature keys to be used in the context of an account.¶

For example, the device profile corresponding to one of the devices belonging to Alice is:¶

{
  "ProfileDevice":{
    "Encryption":{
      "Udf":"MB5H-7FO4-AZRD-OJHX-OUZG-XHVG-KH2C",
      "PublicParameters":{
        "PublicKeyECDH":{
          "crv":"X448",
          "Public":"PhO96KmXS1Sui4SYmM75-4prHdG-am-TnSFcmsc9uKWhw
  Vr2RimLPVpI5se5aU1Jeo0s7-dyv_eA"}}},
    "Signature":{
      "Udf":"MCUP-MUZ6-5D5T-5KWI-HV57-7BDX-TFEI",
      "PublicParameters":{
        "PublicKeyECDH":{
          "crv":"Ed448",
          "Public":"NrPD354a6P1EkIUlaPHdo3PnEmNqY4P7q-UB0LANce0am
  Ail6vdx5F7VYGZthntsCBRmO6EzBD2A"}}},
    "Authentication":{
      "Udf":"MAZI-3SYG-RZ2X-TQDP-SL63-4OHD-5OTW",
      "PublicParameters":{
        "PublicKeyECDH":{
          "crv":"X448",
          "Public":"wFMa92pypOQLQPZpZfkUlx6S4OEjJfXsG5i1XBaO7QxZg
  zZoIynMpJ8eiqEWr84MHjmXk7U_UVkA"}}},
    "RootUdfs":["YOQFOuBha6ISPv3BO5hV5VcCfsP4CPiBYhzK1T2FktsOEtZ_T
  TQQIaoOnfMEzFMpnwTMLpEtHQV60gZdRAQ7gwU"
      ]}}

3.2.1. Activation

The device private keys are only used to perform cryptographic operations during the process of connecting a device to an account. During that connection process, a threshold key generation scheme is used to generate a second set of device keys bound to the account by combining the base key held by the device with a second device private key provided by the administration device approving the connection of the device to the account. The resulting key is referred to as the device key. The process of combining the base keys with the contributions to form the device keys is called Activation.¶

For example, Alice connects the device whose profile is shown above to her account:¶

Alice2> meshman device complete
   Device UDF = MBQO-4TTM-QOTS-MKEG-XQTU-XNFM-WUWM
   Account = [email protected]
   Account UDF = MBQC-7OHA-RNBA-FRDL-R4GI-YQHA-DL36

The activation record granting the device rights to operate as a part of the account is:¶

{
  "ActivationAccount":{
    "AccountUdf":"MBQO-4TTM-QOTS-MKEG-XQTU-XNFM-WUWM",
    "ActivationKey":"ZAAQ-HGFE-VOLA-P6ZX-JZE4-EZ4C-DXGM-TLP6-TEO2-F
RZG-QWVW-N7KB-NTFB-F2PC"}}

And:¶

{
  "ActivationCommon":{
    "Encryption":{
      "Udf":"MAYF-D7LJ-5IMP-EUCG-HSGH-7LSR-AAPZ",
      "PublicParameters":{
        "PublicKeyECDH":{
          "crv":"X448",
          "Public":"c7oorJ808sc9d40KXDhIHgCTFz39MK3JjO0Q7K_ufDEGD
  KiwVKhd3oPQ44PEqGjwkpp7OfbcBbSA"}},
      "PrivateParameters":{
        "PrivateKeyECDH":{
          "Private":"raIIVpKe7NlAykMg0rPWUHzL9LnCy4ScwprV5eySGKGG
  Ab7nyjN8rbDM-opg8xVBV_dXkEKqE3I",
          "crv":"X448"}}},
    "Authentication":{
      "Udf":"MAFT-SINA-SFXI-PBDY-WRHE-NXYL-DXVT",
      "PublicParameters":{
        "PublicKeyECDH":{
          "crv":"X448",
          "Public":"XcgEz9y2cqsx4ZebGERTjrN-xzN83D-pcx0651x-WUCqY
  NrsnzTH40CpoMxuN-FnpT5m_b0MyuKA"}},
      "PrivateParameters":{
        "PrivateKeyECDH":{
          "Private":"dXpwcov9RC5WhoBy892-kQjM3MjM0ddEk9sCcjobjwxj
  0u9khiVzsHiPqc1ufphftj0Zzv9C05I",
          "crv":"X448"}}},
    "Signature":{
      "Udf":"MDNT-WT3G-346G-4I5T-YV7F-LTQX-PSNT",
      "PublicParameters":{
        "PublicKeyECDH":{
          "crv":"Ed448",
          "Public":"IMyMo7fEy2vHp8syQ0VU4XivpJEhgQQSX3j8mva4HC_T0
  5UnhQYqVZyuvIQEVo2dyMCRm60Q3E0A"}},
      "PrivateParameters":{
        "PrivateKeyECDH":{
          "Private":"19gC3rbly9Y-D-OtdKPQvar-X7WhDb9IAezvuWotnELc
  tO8Ic4BTWq2MSKcAk3lhMOKezRy_s7Y",
          "crv":"Ed448"}}},
    "Entries":[{
        "Resource":"Contact",
        "Key":{
          "Udf":"MAYS-HKIQ-VCQL-6MUD-ASPW-Y3OT-BLVW",
          "PublicParameters":{
            "PublicKeyECDH":{
              "crv":"X448",
              "Public":"2-LI9YOozzShdL-nfu7WJDsedbsOyRw0nEEor3-xj
  UvAxJPS_VptsleZUg7u1jcLy3JMUQCFdGMA"}},
          "PrivateParameters":{
            "PrivateKeyECDH":{
              "Private":"A3gNBuZ0xVggNIF6G6aftBhIeliF9IZCbn_KURJP
  M9srop-v3BfNjvkUDS29iPubM7-_OkrdlXE",
              "crv":"X448"}}}},
      {
        "Resource":"Publication",
        "Key":{
          "Udf":"MD7I-NZQC-FAUT-EHTA-WQQA-Y4YP-L5YR",
          "PublicParameters":{
            "PublicKeyECDH":{
              "crv":"X448",
              "Public":"JwemETcr0SYLj_UWf5focJPoINqhfYxvM7l4Kn9yy
  UB6u7avc2WpEkNn6qJQFCYJEtaNR1n8OnaA"}},
          "PrivateParameters":{
            "PrivateKeyECDH":{
              "Private":"JIVLbaj2PU9KZb6O7HPfR8z9RufcLx8bbIbCgE4h
  6aoCqGdrAz8C99i554Kdr6Nrm7K4NrYSCgk",
              "crv":"X448"}}}},
      {
        "Resource":"Inbound",
        "Key":{
          "Udf":"MBZU-KE6J-TYNI-HXJL-ZW7W-WNLU-MQHF",
          "PublicParameters":{
            "PublicKeyECDH":{
              "crv":"X448",
              "Public":"035fQLltWxs7fJYOK4BrmcFTnLwTPhmNnyXBbpuG_
  w_jnCJJYjsTi7RExq2idvkJACnj7jz8TfsA"}},
          "PrivateParameters":{
            "PrivateKeyECDH":{
              "Private":"dNVMbq-Q0aYujHbpGKjqeYlRZJF4dgwlUkGlRNDs
  VxQW0BKIPCcWEZVS0_waS8uO_Cv7BqG03Xg",
              "crv":"X448"}}}},
      {
        "Resource":"Outbound",
        "Key":{
          "Udf":"MAJP-XDZ7-4WK5-CBVG-AAN4-SUVN-FWUT",
          "PublicParameters":{
            "PublicKeyECDH":{
              "crv":"X448",
              "Public":"oMblSsk2vfcnjsSTLBR_17PUMJQlVCnXvRzFzXx7r
  tIbEmUj65hHlF6oT54IQJ9IaSQrQlZfNEAA"}},
          "PrivateParameters":{
            "PrivateKeyECDH":{
              "Private":"8M43qEAlZ1x3j8TTdWxPt4Htt-sB3oWjBd0645wA
  dlejcjNiD4UBz8nBVuusYtXln04GEmiFZ4U",
              "crv":"X448"}}}},
      {
        "Resource":"Network",
        "Key":{
          "Udf":"MARE-FHHS-74PF-LSN2-K4HO-26SC-YDQG",
          "PublicParameters":{
            "PublicKeyECDH":{
              "crv":"X448",
              "Public":"IFi9wVeI1vSj_hGcL2Lk0Kv5BWWXITvuy4Qg999aS
  K4jPen-E8wqzJPAPaxSzbbD64zAcgKOWzuA"}},
          "PrivateParameters":{
            "PrivateKeyECDH":{
              "Private":"TXyKjn5pSVgmTawLEQDiudySemfHxHxRboLyPNB3
  q2HNysiaDFJT4rpGVijePPApOAWuvyRWtec",
              "crv":"X448"}}}},
      {
        "Resource":"Application",
        "Key":{
          "Udf":"MDSC-47UI-TFUH-P6V5-QNI7-UW3Y-5YZV",
          "PublicParameters":{
            "PublicKeyECDH":{
              "crv":"X448",
              "Public":"3jQ2DNaUz5JkJYCRptcJh_jV2vQm_QCbdHQIoNcxu
  42PClekweR9TtQ0oUhP4R3A5irxVIgCPPAA"}},
          "PrivateParameters":{
            "PrivateKeyECDH":{
              "Private":"N21lQKGlBzcge-0GZudkOmivKiiyxhBlE9-Tloqg
  E2JqC-MPyQXXB3o23MjyAyb5lTbxHcqPQ5w",
              "crv":"X448"}}}},
      {
        "Resource":"Credential",
        "Key":{
          "Udf":"MDFG-UKLG-VUPZ-XAY3-BDMH-FI35-RW3Y",
          "PublicParameters":{
            "PublicKeyECDH":{
              "crv":"X448",
              "Public":"kVrnMmX7RDcikA8LCHrX1c8e_TEKo17gvAWpVvh36
  bRRf2hIQLdWFb7JG8zbHqjODuMzhTdfLeEA"}},
          "PrivateParameters":{
            "PrivateKeyECDH":{
              "Private":"wRDSEDUGGiyjK7-uBHoNTCpn6ON6SaUUTEzK1ZUJ
  QUP3lqYjP0U816YEk7FInDyNuSD_CSesjHU",
              "crv":"X448"}}}},
      {
        "Resource":"Task",
        "Key":{
          "Udf":"MALW-PHPA-PCXM-W3DU-WMPU-XCEW-YAM7",
          "PublicParameters":{
            "PublicKeyECDH":{
              "crv":"X448",
              "Public":"sbOJcelezmPlW-RNZYyvG0-C4fwxecksenqB8okSK
  fiihirXl01I-jtP1MRvN47QdXqzgjKqL9QA"}},
          "PrivateParameters":{
            "PrivateKeyECDH":{
              "Private":"TOD3L2wkwDHT878UOcZERxcaVVE37UQupHbQU_bY
  BB-vcl5uKdMJNVqwwF1_LeG87zYUiOMS9S4",
              "crv":"X448"}}}},
      {
        "Resource":"Bookmark",
        "Key":{
          "Udf":"MDZV-J4CB-QLA5-K6GU-GGP2-OAXS-3FB6",
          "PublicParameters":{
            "PublicKeyECDH":{
              "crv":"X448",
              "Public":"nEw2RAKhuQN2RJUi9_XmVy_aLVGpM7n6dd-rk_I2Q
  RmfFZYZRLtab_yRE-5A6HfgfsFndUbnOfQA"}},
          "PrivateParameters":{
            "PrivateKeyECDH":{
              "Private":"QjrRmPp0wcYgC4z-vgyr_BQfbZwCOzwbl2GQZyBe
  0RDtHQQuigxURbfpoqcxV0tWJ_p4rkrcBQk",
              "crv":"X448"}}}}
      ]}}

The Mesh protocols are designed so that there is never a need to export or escrow private keys of any type associated with a device, neither the base key, nor the device key nor the contribution from the administration device.¶

This approach to device configuration ensures that the keys that are used by the device when operating within the context of the account are entirely separate from those originally provided by the device manufacturer or generated on the device, provided only that the key contributions from the administration device are sufficiently random and unguessable.¶

3.2.2. Connection Assertion

The administration device combines the public keys specified in the device profile with the public components of the keys specified in the activation record to calculate the public keys of the device operating in the context of the account. These public keys are then used to create at a ConnectionDevice and a ConnectionService assertion signed by the account administration signature key.¶

The ConnectionDevice assertion is used by the device to authenticate it to other devices connected to the account. This connection assertion specifies the Encryption, Authentication, and Signature keys the device is to use in the context of the account and the list of roles that have been authorized for the device..¶

{
  "ConnectionDevice":{
    "Roles":["message",
      "web"
      ],
    "Signature":{
      "Udf":"MBPI-BITH-EPYS-3FYE-E35S-NDB3-VTP4",
      "PublicParameters":{
        "PublicKeyECDH":{
          "crv":"Ed448",
          "Public":"Y46EhbDyrvyXR2rxUE3tdjUjBHow3KIVzJ6K0PxrZDFPE
  Qkrna4Q_LG9g3LBwAn9BkyFFszknh0A"}}},
    "Encryption":{
      "Udf":"MCBL-DEQY-N5WP-FY2B-SGYT-6PH3-LTZV",
      "PublicParameters":{
        "PublicKeyECDH":{
          "crv":"X448",
          "Public":"tfB8Ulcsp7A8OuymEMZtCe45ktAJGvnFeATg9n-QB81dU
  Zsxc3IGA0Gh7khkNhLBfvd3KH-a95OA"}}},
    "ProfileUdf":"MBQC-7OHA-RNBA-FRDL-R4GI-YQHA-DL36",
    "Authentication":{
      "Udf":"MB7K-AWT2-34F5-TVCT-BV2K-VMRH-JKVS",
      "PublicParameters":{
        "PublicKeyECDH":{
          "crv":"X448",
          "Public":"5zHjLDHVNHALaDaO0YyASwifAmiNGTtJG-LrCsA5Oyx6i
  UVJ4Xu4WUAN_smNBRg8k85_qaMkHuYA"}}}}}

The ConnectionService assertion is used to authenticate the device to the Mesh service. In order to allow the assertion to fit in a single packet, it is important that this assertion be as small as possible. Only the Authentication key is specified.¶

The corresponding ConnectionService assertion is:¶

{
  "ConnectionService":{
    "ProfileUdf":"MBQC-7OHA-RNBA-FRDL-R4GI-YQHA-DL36",
    "Authentication":{
      "Udf":"MB7K-AWT2-34F5-TVCT-BV2K-VMRH-JKVS",
      "PublicParameters":{
        "PublicKeyECDH":{
          "crv":"X448",
          "Public":"5zHjLDHVNHALaDaO0YyASwifAmiNGTtJG-LrCsA5Oyx6i
  UVJ4Xu4WUAN_smNBRg8k85_qaMkHuYA"}}}}}

The ConnectionDevice assertion MAY be used in the same fashion as an X.509v3/PKIX certificate to mediate interactions between devices connected to the same account without the need for interaction with the Mesh service. Thus, a coffee pot device connected to the account can receive and authenticate instructions issued by a voice recognition device connected to that account.¶

While the ConnectionDevice assertion MAY be used to mediate external interactions, this approach is typically undesirable as it provides the external parties with visibility to the internal configuration of the account, in particular which connected devices are being used on which occasions. Furthermore, the lack of the need to interact with the service means that the service is necessarily unable to mediate the exchange and enforce authorization policy on the interactions.¶

Device keys are intended to be used to secure communications between devices connected to the same account. All communication between Mesh accounts SHOULD be mediated by a Mesh service. This enables abuse mitigation by applying access control to every outbound and every inbound message.¶

3.3. Service

Mesh services are described by a ProfileService. This specifies the encryption, and signature authentication keys used to interact with the abstract service.¶

{
  "ProfileService":{
    "ServiceAuthentication":{
      "Udf":"MDYI-I2BH-HML3-H6YK-GNYW-JJXF-NVDH",
      "PublicParameters":{
        "PublicKeyECDH":{
          "crv":"X448",
          "Public":"gH6QMyYx5qfORaNNvsZyR83BM0anEj-VqCoL-6k_BhdFY
  Q8Qpro58p0hrTRMTLZrrBdWpjtPKiuA"}}},
    "ServiceEncryption":{
      "Udf":"MA4L-UE5A-E4VG-UGRK-TVT2-3LHG-Y7NV",
      "PublicParameters":{
        "PublicKeyECDH":{
          "crv":"X448",
          "Public":"KPrn6aPtRHGLbI2aEHzI_dtPDgaGMSSLxkD_dWsTBYVE1
  KfT3kAOqR29P82C-NrtZapnwxZfFTgA"}}},
    "ServiceSignature":{
      "Udf":"MC6L-T5P6-UZCQ-RRD7-VMJM-E2KQ-AZHE",
      "PublicParameters":{
        "PublicKeyECDH":{
          "crv":"Ed448",
          "Public":"y5a7XXdof_Azi8ueTddSIZx9fFgD7ZfXBT9-N6e5qeB_p
  QtnurylRNxe2w5HrCV9sYz2jr3u4XqA"}}},
    "RootUdfs":["YBLkkXVQbdqea81QVIkppp0DOBttJFcoTI7UVewreuMBAJ3z6
  nMmf31Fb4hFy-OJjYWh95E0spNUvPjMjw3NopA"
      ]}}

Since Mesh accounts and services are both abstract constructs, they cannot interact directly. A device connected to an account can only interact with a service by interacted with a device authorized to provide services on behalf of one or more accounts connected to the service. Such a device is called a Mesh Host.¶

Mesh hosts MAY be managed using the same ProfileDevice and device connection mechanism provided for management of user devices or by whatever other management protocols prove convenient. The only part of the Service/Host interaction that is visible to devices connected to a profile and to hosts connected to other services is the ConnectionHost structure that describes the set of device keys to use in interactions with that specific host.¶

{
  "ConnectionService":{
    "ProfileUdf":"MBQL-QXMC-6B6G-6RF3-BCJN-CDNU-N2K2",
    "Subject":"MC6U-BVUM-RRCG-OM6V-HB63-4BCG-TVRL",
    "Authority":"MBQD-ETXU-HZRW-A26O-WDTR-K7GI-X6JD",
    "Authentication":{
      "PublicParameters":{
        "PublicKeyECDH":{
          "crv":"X448",
          "Public":"fjAiJJe143FCODQ70z5RT-IT7MJ_SbHqs1sKk8JJ1WjUx
  cFyjOsYmG74_UbHIeM7vwZjCQJ2eQ6A"}}}}}

Mesh Services MAY make use of the profile and activation mechanism used to connect devices to accounts to manage the connection of hosts to services. But this is optional. It is never necessary for a device to publish a ProfileHost assertion.¶

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

Access: mmm_Access: Describes access control policy for performing operations on the account. The Access catalog is the only Mesh catalog whose contents are readable by the Mesh Service under normal circumstances.¶
Application: mmm_Application: Describes configuration information for applications including mail (SMTP, IMAP, OpenPGP, S/MIME, etc) and SSH and for the MeshAccount application itself.¶
Bookmark: mmm_Bookmark: Describes Web bookmarks and other citations allowing them to be shared between devices connected to the profile.¶
Contact: mmm_Contact: Describes logical and physical contact information for people and organizations.¶
Credential: mmm_Credential: Describes credentials used to access network resources.¶
Device: mmm_Device: Describes the set of devices connected to the account and the permissions assigned to them¶
Network: mmm_Network: Describes network settings such as WiFi access points, IPSEC and TLS VPN configurations, etc.¶
Member: mmm_Member: Describes the set of members connected to a group account.¶
Publication: mmm_Publication: Describes data published under the account context. The data MAY be stored in the publication catalog itself or on a separate service (e.g. a Web server).¶
Task: mmm_CatalogTask: Describes tasks assigned to the user including calendar entries and to do lists.¶

The Access, and Publication catalogs are used by the service in certain Mesh Service Protocol interactions. The Device and Member catalogs are used to track the connection of devices to a user account and members to a group for administrative purposes. These interactions are further described below.¶

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

4.1. Access

The access catalog mmm_Access contains a list of access control entries providing authorization to devices authenticated by a particular credential. The access catalog provides information that is necessary for the Mesh Service to act on behalf of the user. It is therefore necessary for the service to be able to decrypt entries in the catalog.¶

The entries in the catalog have type CatalogedAccess and specify a capability. The following capabilities are defined:¶

NullCapability: A capability granting no access rights. May be used to establish a positive statement denying all access.¶
AccessCapability: Authorizes a device authenticated by specified means to request privileged account operations. For example, requesting the status of an account catalog. Also used to provision devices with a copy of their CatalogedDevice entry encrypted under a key held by the device.¶
CryptographicCapability: Specifies a private key encrypted under the encryption key of the service and criteria specifying the parties authorized to request use of the key.¶
PublicationCapability: Authorizes a device authenticated by specified means to obtain a data item.¶

The Access catalog plays a central role in all operations performed by the service on behalf of the user.¶

Every access capability is gated by a specified set of authentication criteria. The following authentication criteria are currently defined:¶

Profile Authentication Key

The account profile authentication key authorizes any account action without the need for an access catalog entry. This capability is normally only used during account binding. Administration devices SHOULD NOT have access to the account profile authentication key after binding is completed.¶

Device Authentication Key

The service will only perform the operation if the device making the request presents the specified authentication key.¶

This form of authentication is necessary to restrict access to account operations so that only connected devices can interact with stores, etc.¶

Account Profile Identifier

The service will only perform the operation if the device making the request presents an authentication key that is credentialed by a connection assertion to the specified account profile.¶

This form of authentication is necessary to perform administration operations on a group account since it is the account rather than the device that is authorized to perform the operation.¶

Proof of Knowledge

The service will only perform the operation if proof of knowledge of the identified shared secret is provided.¶

This form of authentication criteria is used to allow device connection and contact exchange by means of static (i.e. printed) QR codes.¶

Future: Currently, the set of authentication criteria is limited to direct grants of a single capability to a single specified device or account. This approach may prove to be unnecessarily verbose requiring the same information to be repeated multiple times.¶

4.1.1. Access Capability

The access capability permits a specified service operation on the account. Optionally, an access capability MAY specify a Data entry encrypted to a key held by the device.¶

The access capability specifies the set of rights granted to the requester and optionally specifies an EnvelopedCatalogedDevice entry containing the CatalogedDevice entry for the device encrypted under the base encryption key or account encryption key of the device.¶

The CatalogedDeviceDigest value serves as a tag for the cached data.¶

4.1.1.1. Operation Rights

The reference code does not currently implement operation rights beyond denying all operations to devices that do not have an access capability entry.¶

Expansion of the rights handling is planned to permit granular expression of access rights.¶

mmm_o_UnbindAccount: UnbindAccount¶
mmm_o_Connect: Connect¶
mmm_o_Complete: Complete¶
mmm_o_Status: Status (of specified catalogs or all catalogs)¶
mmm_o_Download: Download (of specified catalogs or all catalogs)¶
mmm_o_Transact: Transact (of specified catalogs or all catalogs)¶
mmm_o_Post: Post outbound message¶

4.1.1.2. Messaging

The reference code has limited messaging capabilities at present and messaging rights are not specified. The following is a list of possible rights:¶

mmm_m_Contact: Contact messages from the specified subject.¶
mmm_m_Confirmation: Confirmation messages from the specified subject.¶
mmm_m_Async: Asynchronous delivery messages (e.g. mail)¶
mmm_m_Sync: Synchronous delivery messages (e.g. chat)¶
mmm_m_Presence: Forward presence request.¶

The following media are defined¶

mmm_c_Text: Text that MUST NOT contain links or external references¶
mmm_c_Linked: Text that MAY contain links or external reference¶
mmm_c_Audio: Audio data (e.g. VOIP, voicemail)¶
mmm_c_Video: Video data¶
mmm_c_Code: Content containing active code including macros, scripts and executables.¶

4.1.2. Null Capability

The null capability is used to affirmatively deny access to a function. This allows access requests from previously authorized devices whose credentials have been revoked to be handled separately from requests from devices that were never authorized.¶

4.1.3. Cryptographic Capabilities

A Mesh Service can perform cryptographic operations on a private key according to access criteria specified by the user. This capability is used to support use of threshold cryptography to mitigate compromise of a particular device or individual. The splitting of a cryptographic key into two or more parts allows the use of that key to be split into two or more roles.¶

Note that this approach limits rather than eliminates trust in the service. As with services presenting themselves as 'zero trust', a Mesh service becomes a trusted service after a sufficient number of breaches in other parts of the system have occurred. And the user trusts the service to provide availability of the service.¶

A Mesh Service MAY also offer to perform private key operations for other purposes. An embargo agent might offer to decrypt data under a private key but only after a specified date and time. An expiry agent might offer to decrypt data but only before a specified date and time. Such services MAY be reserved to the customers of a specified service or provided to the general public. Users of such services MAY combine key services provided by multiple service providers using threshold techniques to achieve separation of roles.¶

Since a service might not willingly co-operate with an account transfer request, extension of the Mesh service protocol will be required to enable threshold sharing of the keys required to effect account transfer. This would require one administration device to act as a proxy for threshold signature etc. operations being requested by another administration device. While implementation of such a scheme to support this limited function could be achieved with little difficulty, such a scheme might not support the wider range of peer-to-peer threshold capabilities that might be useful. For example, the confirmation protocol might be modified so that instead of merely providing non-repudiable evidence of the user's response to a request, the confirmation device served as a policy enforcement point through control of a necessary threshold share.¶

The following service cryptographic operations are specified:¶

4.1.3.2. Key Agreement

A private key share s, held by the service is used to calculate the value (sl + c).P where l, c are integers specified by the requestor and P is a point on the curve.¶

This operation is used¶

4.1.3.3. Threshold Signature

A private key share s, held by the service is used to calculate a contribution to a threshold signature scheme.¶

The implementation of the cryptographic operations described above is described in [draft-hallambaker-threshold].¶

Implementation of signatures is not currently covered pending completion of [draft-irtf-cfrg-frost].¶

4.1.3.4. Fair Exchange

Perform a Micali Fair Exchange trusted intermediary operation.¶

On receipt of a signature SIG_B(Z), where Z=E_k(A, B, M), the service decrypts Z and returns the result to B.¶

4.1.4. Publication Capability

The publication capability is not currently implemented. Implementation would allow the Claim/PollClaim mechanism to be eliminated in favor of a mechanism capable of re-use for other purposes.¶

4.2. Application

The application catalog mmm_Application 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 the device activation record.¶

Two applications are currently defined:¶

Mail: An SMTP email account and associated encryption and signature keys for S/MIME and OpenPGP.¶
SSH: Secure Shell Client.¶

Accounts MAY specify multiple instances of each but each application instance is considered as describing a single application account. Thus, if Alice has email accounts [email protected] and [email protected], she will have application entries for each. Accounts connected to Alice's Mesh account may be authorized to use either, both or none of the email accounts.¶

Note: The implementation of these features in the current specification is considered to be a 'proof of concept' rather than a proposed final form. There are many issues that need to be considered when integrating a legacy protocol with extensive deployment into a new platform.¶

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

{
  "CatalogedApplicationMail":{
    "AccountAddress":"[email protected]",
    "InboundConnect":"imap://[email protected]",
    "OutboundConnect":"submit://[email protected]",
    "SmimeSign":{
      "Udf":"MCCJ-IANC-HEWS-7XZI-OR72-ZFC4-SCQL",
      "PublicParameters":{
        "PublicKeyRSA":{
          "n":"ujaNN0wJkcUTdJLUHPgHjzIliAMp_6-I1BwqAzaW3zIRto2aRQ
  i6oMGjqigiFq4BMt-9Jo4YAYd655FgebcfC82bu2v8kQyNJ3zUdoblMUDOFrTRffc
  zo_9h1zyBzGAnYzbGYPiEIjOubceFwlH-ZmY_3VzmWWkIuhFhgExvWQm_Ej05yyx4
  Tl8fh8TA5k1jSZM2VYTVr_3pqUXWxivDvRSFUbT6_tWH8l8WtxbDToMq70bECWW2T
  zOZ_mBTBGx4H5qXkO2upWadEtlMFOhlEfBhAOx9yBE4_TmAT-_YWJxvaCtcy-6FlN
  DWKl5J0HJ_56DP9bZJAtxPSn0-20jT9Q",
          "e":"AQAB",
          "kid":"MCCJ-IANC-HEWS-7XZI-OR72-ZFC4-SCQL"}}},
    "SmimeEncrypt":{
      "Udf":"MDO5-36TO-HN5V-6SZ5-MD5B-63BZ-737K",
      "PublicParameters":{
        "PublicKeyRSA":{
          "n":"rDdENxO4dTXs-G2Esue3P0lym8e-WF3sKyv2eOP5Dn_IBRlJiS
  wbPWzfj9gMPE8z0Yx80RUwQ0AmyiACD6nPRHOtVPIzF3OFuwFZjMvDdY4Tkgg60dd
  BOV6X_U3fCzA_aThwFU8sQXw69imT6GnLpYf0Wt2AEojFY8rEStVC2yZRqPxcbXo2
  1aTHwgoyly9LmhmHmxSJ3XqJNq0OJNWG19UXy3qHyRG_SvsKsN2I-AlxDBBno3m1M
  vvzmYwM-XCYkXDbeCtyiPOqD4UPj-XPryBx00-aOFozP6T2WncC7xi48MPq3AK0bp
  K9HnqRccSCpFCEW1L1sqFNoB5HinhOyQ",
          "e":"AQAB",
          "kid":"MDO5-36TO-HN5V-6SZ5-MD5B-63BZ-737K"}}},
    "OpenpgpSign":{
      "Udf":"MAII-NUGV-FX7P-IAQ2-UXZ3-CP3J-6MKN",
      "PublicParameters":{
        "PublicKeyRSA":{
          "n":"wgbGU8SvN9kyykGSaAcsOpA9x6m3axF1vnGk1O_sedVRTrK5jB
  I-EbVL-nFthAMh1TqO25sh5kJYZTX43pfpEUOeyoNo_U5uQf6n1bskQjkdpjMG3xR
  TNzCOajO_NnyuETebUuNkBNoPQZEw9BcwbJIGiqH63vZyM-TiZ6r8vPNoeTCmlOtz
  u9heJ0ULAs4K7yiGNmfto5YdAOBgMrd27_a-kLIRusmPBrPq2kFIYSlP_z9VKKKra
  PWv4vskwHPb3UGF4fc_aL2hfSIDxn4jif9Uq_GUSHNO5xLlKCqFgq5tHCxD_5oK0k
  H-CJF9xnyqFolyZDaAVBWEeDEUEUZPcQ",
          "e":"AQAB",
          "kid":"MAII-NUGV-FX7P-IAQ2-UXZ3-CP3J-6MKN"}}},
    "OpenpgpEncrypt":{
      "Udf":"MB74-LYO7-NBVD-EZ3E-7ADE-AR4N-2AY7",
      "PublicParameters":{
        "PublicKeyRSA":{
          "n":"8Ygw69BbA8aPA2m24HqBfV6o9pJtbx8PoJLIszlROyRQZy_CxY
  v0gCsh5oKEVxAdTV5m_u7rgZOuSuwsMe-8HjTfbgBpL1pfuu76Ih-5KBsoJvWH5Ag
  dYJV2HrLxuHi4BvVZbD3DckOEtMPU03paGmHF7V6SISGfGLvlmpsIwhw-44EjMVPZ
  GD_Y-4eF6FmN2wVb0SjAmc9pUKUG5pNj6-HmM-d0pGFFjwrGW2L2-NVhPy29z9spZ
  4DZq17Xi-HqCq5acAdbd3AN-B0UCJkYhoperKT8x3CUyluLE0Y-Edn3NXTXBCxTlQ
  86aAhwuHQx9nahW7KaHR8VYwfGyr7L_Q",
          "e":"AQAB",
          "kid":"MB74-LYO7-NBVD-EZ3E-7ADE-AR4N-2AY7"}}},
    "Key":"mailto:[email protected]",
    "Grant":["web"
      ],
    "EnvelopedEscrow":[[{
          "enc":"A256CBC",
          "kid":"EBQI-M6QR-LVYR-SCFV-XSFJ-EJLN-HS7F",
          "Salt":"4XORHvoh7KKpsffW8AqIlg",
          "recipients":[{
              "kid":"MCKD-3MR6-P2TE-M6U4-4LIO-ZTRG-DZVS",
              "epk":{
                "PublicKeyECDH":{
                  "crv":"X448",
                  "Public":"olkRv5dHpel7vSLrt0X4_prek7ZL3bXATFnvp
  nUw8EtlYvXDko5QBCkPuZeicmBZuFzqo81869-A"}},
              "wmk":"f1ztYcg-UkEnjLFN4uHFPxi_pO425ANr3hsI_A-4dp0w
  ZHhDfAO1bw"}
            ]},
        "vxZ7o219ECnin-AdOfCgnR4OknBud7h9kAZk1tjWYMfFSrDSQorTDDwg
  6o1IqpG77rB-n5Qmv-33edsRoxSmUcNaLSjeSv5TaocuYw6KbFLV-nQZGTzzcMp4N
  aU4YwEAhalBwrBfkyOOSmegVjxm4edPRkAnDsZ8rxgodl1btYVwJJMWoSuclMmRE-
  DKaT0yyTh9X0RLXLv8GVe0yUlVKafcm3hoQ5M5U5rzW2MenoDBzY6oFOR_OJXvcJ_
  -_xreztE8oj-modyUY3fpxYmbEVM_mrw1nsYWDik_qZ5CJlPFvPaVEEtEfWtqbowK
  xgGLTCLm8E00z3iZPKWFOrjh0nIgGAZJfKBikIzLIb0romccHCT8OI8feAfM2ytz-
  ymk_aat6I21n5SM9ltm8P5OGsAT9v1gS-v8x-OJCSKLnfS7No86Re1WCr1z790N1f
  gDM89OzchpQHS-EzM73PGb2VdqNGSp_4VjLk2EAJ5JkeNBktOO1kZQWoA4dfhxR41
  6hE7uiGxg4o4uP81eUGPfzHvFxwwvo8GoMSQ91OECfHzvNzcg2zDLUgpzIc6QtqSH
  NYkqH3BI3GhAjDMKtMz9qX2DZ0r7mOwzmD6ith6AhA1X_Jtuo2Gqi6JLb_FbPLdlf
  Js9HN5HDl2Ns3i4S7KjG6eTEG9sZQb1EnZo1JSDg0Yt9iAwjJ4O0qs15Y2QLpkn8X
  hiimlOLCWaAW2NoxkoViSpLjn8Pn9DVWOcw8-1_jDdlO8n0B5S5i3N_jDY0iY8T4c
  qi4LuC6IivrmIr4kHwWOB9lYjQlJO_oHjBoO7wOqeub_YG8EhSNM-CBaYDEP7DU31
  Nph2lVqLeZWQh3NbdfXS5oE8PAFrdc1TsS8Hvqi6-9xfc0hLoH_zCluX09DP1a7gN
  miq9-kkAEcSRPLJ0-IN57olUKCajmGOviQySO7Nf5qBm5J7GKDqsxIWhBBpe6JHXM
  p2Dc6YgfTrNBFhQAa7clb5UT553XFTskfF6KwzQObEzuAFeAIfeKZndt4veSgDJHL
  -F_02NGKO8deQJ6S2T7CGJLLjec9jskQy07T6jJDoH9lebDTO8OtX2n6k5USBZsYy
  4C1XnPk27MVA_lTIpr8d2uUM__m4q3cTpe92ygicGIopViiqGccwgPblHMksUoLHc
  kZ2uCd1CO181cZ9JF0abEtFegEe0WoH81tq7wTBFIMHxL6JYQnTrXkmo3o06LSaNx
  5QkwF1HndTBMdCgy-OZR7KNyBWr9v3SnV4e1MvTU4mJG7YlyxUInXubhjevv5vo4D
  aMz7BfegeeGLKYYOQOJTgHkcFuWaoHxSs9PLVmnjUl8B1EhuDRYXEpiagZ0e6lMhL
  nhatKd_LjGse91ax5BEnquoQN_XU4yM2g8m_FqO5yy5v1E-UPuGuI70u5burwoLEd
  ZFgoh08e9n0INJja4WgzZkjTe5gTmgtP85cCwtiyws9d3kkbxI9S7NFUP5Ws7xSBz
  _Ox3hsODPaBvBrkl-4-6REESus47pCoB9z8YIC6YD0hCYTi67E6oHvzEogOYaLpT7
  JzBtpRhE6orPK44OOKtWbpgxgwQ7TROK2ReWdKhCr8EtpyqogxZ9_OX07al-lppfC
  OeBUHB_P1RQ9AiE5hHjmXxTFu3iJcRFE7UxTePv2P5NCofBeqYHA0u-xziSyoHswa
  R7Z6q3FNzA9M_kujDZh3ukF5um3PEltaHBjmSMWE9RFvgVqq0UVF1Y1zeVuxcFaqN
  T_OGbxTReiymDpWYsD0gUgQ3J-zzFk1QZPBQbCJsUwbiE6VPBVEKb_NBRxOdhFH1Y
  _UxaAnvL1YHjVBeDwy3hNXGYQJdxQc6vH2onZtZpthvfMKh9r0UIbLQ3gyoDItGJj
  N2WId3CssskJh29T0Unv5Epa-pRgVqEUWyKvEWm-P-glwdTeO_Q56WrE63UJukURn
  M9pKBqxR9AgiH95jJpTGiEKXtpoox1LllWWYTHg2V-SvV7Lyjkt3eOEYb-GErAopy
  ehB5sxLuGqCXxEfd2l_GXPhkt7EKQxC_6nxkkOatJgh5zUSj5grJckxmet04OONUr
  apS6tuG78Tmlinfki0xedSo9kKl_gBLaaI6MCEYrrDC7y1U39pGFusa0qr9-3ocYp
  v3MbdBe58IKV1yWBH3fzDxxjiHZjrBKjlTvjv5xgagxFn3dowEh1OOqoAl3FBXD6A
  iPHZB1buWkuBZFWygawj_ORMvNQSCYJ9vQ4iqpqTxNDu23Kh2_IwdgMw9T5XlQXJ0
  Tcd0z7HYLEskjnWl7ierMFjzawbgxaE1nDiK2nm7D519EHpDdKevchnDOjx28Cojo
  hAPWT7hykOSubdfmxpXFKG2nHI0zxIZJQKQqJQ2cE7Row5r_vxXnmbrcOPbsU0XH1
  VmvYUrxsLbbny5qpnxFK1wBvRxRx5QqZedVeso1AN3vrhfAkNVtm7Nds1kySjShFX
  MCJsXQq8umUyMEAOLFn0AqJedR-jXGR_p5ALu3SsDfpBjk-l7eCE6F-G6F4ffdEYQ
  jr-qLvO1c4D94yY5wd_1wQXaXjTyAXKlcxOX0MgGaR294OQQuHge2gFXueHGVS7n7
  kc9QJL66MQ1WtwLe9vquNVA3827vN7rz79BVINhL7J2TNbI8vV_tvP7OVlOlG6bT2
  P0FuFBoT0546_xwCKC-nPkcpjRk9-qHJXr6eQV7tiWEHJL6g813VoOjdXBB0oEIVB
  cE7_oIhPfz3VJyIETGroZSJYgzCCRDuHU4KsUsFXm9vzrkvqGmbgv52zCcVP3BAVG
  G_RZIe-9BbSP-G_QdQ30vKJqKa2Lzblk4jwMDTjcH-VH-tJrt3h2zVIirshEYiwZR
  0cXj8DOxoE7idqDYH3ncDIJRYvbFNeXtAuNxNQauaeRZKqcNI7VvhySoxo2jYUqap
  gfKVeAYQQHwtljCyGfum9umwhRvXBvMlOQY59JLaJW6GSECIVmDMmEk_d-FHJgpg8
  tRGsIC0Cq56onKEPMZsYXob2dnRAaB3eQYxuP1N47tKQ6cgvaGfR5OWw8A32rnxs-
  oWtlNjYXQ7KUdDekY81CNdkVAZbZ8iOYjs1fmoWOHw5siuiG6rrXQFJP1y1PZiiYK
  DIrDMpjN_7q2e1Bq6S4CNQEXOVrdAZCRuF2qFG50ASoapx6KZwcorX-WCAsuB6tkg
  OE1caLzi8sE3c7qKIBukrvffsx4BmxMLf2rpxIsGn_Q0OQ"
        ],
      [{
          "enc":"A256CBC",
          "kid":"EBQD-XY75-2IST-C6DH-KTEU-363I-CWBR",
          "Salt":"2AwJI4VHneTLk2UMSbaLAw",
          "recipients":[{
              "kid":"MCKD-3MR6-P2TE-M6U4-4LIO-ZTRG-DZVS",
              "epk":{
                "PublicKeyECDH":{
                  "crv":"X448",
                  "Public":"7wk9t2JK-Gx9ESxA7jAPJXjZ4rRhH2RHUidz8
  n5FsDxMQPXtO78_F3d3__RefNRiPoCfTm8D0DmA"}},
              "wmk":"N6SgC4MEtbxrHyFLpsETbTsZDgqxnfnxnm7EhGQNpuFX
  o73GCEMCXQ"}
            ]},
        "kCV8prvbW_p60KlyLR1zhjmhHhgewBXXgL_e_cDouqjSJY6c50Wz6-OQ
  9kRXOIlLOnFt_Vepyl8IT_6zF97Kw09EluhJBrcQVYCpxNVWcOMMKeUk2FnZ6vCFZ
  LhXLWvW4sQ9tThkNzJ9XdxAl4KUASEjvm6J3Khi5n_-HeUPiK-tfYQsHfEqskZ1t5
  AoYnGf7ubTxElHI13SHdD-UqPd1wR1TUJVHpgCrdXtHrnFvxRR-ZmyTlX4AAiUYXd
  fPSZPTewmu7anrKOS8FzJUu4YtZlWNl8ImSG748cHmW5QkfVviX6AE27rdGqgEuI7
  1o2ehr06HG7s9NoR_ybGLnufxyPN6IbP4EHQ397mh1xiPujLADJc8saEolXbfvlu9
  F8kDJIir2vnvIwWT-dw4bMDeyLp3QykbgPAonpNVZfUpwHxHRLmxD06CMFvlWfGga
  O-mUI18qhrRArJE4UIQysYimOE0GDk5jTXWaXcNiMkpFvdNOVaH7sXjAU9t_uvUbl
  ztPqxV-LOgpelu0ibJxPmN3YS_N5hOskUsB0R1pBmYJHYpD2Y5VuiSwlX7xaEpmAA
  8wQCmQXutzV8qkzmBDZ6dpw1buyV7cCSx1ybx2jZuhfKwEUbEB9QcmykytEsGK-32
  Aq7mjMh4ojSjL7XPOkLnD5pILneufxFJlpXfjI_KNijXVzKtA6JrZYWxbffIWXSSu
  6u0JXiPZvsmGv_aMHn0nGnV0jaJgpRG-177s0JHGIRClhgi0y68_dmrovRH6Uk9Tj
  uthhTeKdW6FxouFy1p6uZxqwoiTraBpBbfOBUUkbEsUvffE-92_gD1-bet9tHjY7z
  7jum2bhuN_Uc-fESQ62IYZm7ZXy5r9tDOvToR8XcADPCF6lGLOkjQESgsCgJ_megl
  2zB4FEbfEVU5k9doplzWHSItIa8ZMhY9Q4Ma1FAe6NGuUlPCyRyW5Kat2fPVcyiKA
  qh99VU9f51cozay6zlOiyWCGCNWf-6AMHF-OBhbubXMiwlvrxcKLMFT5CfYDVEDkG
  hLizxIqHW_B8cEljiA0GJ7Ouo9WLSJetqhpWkGFl1hpTrvOXTe0qzLwHW_m38F5je
  Gwp-zqY7CfYRHTrPzshbQ9-E7-cClZPUtC3q0LH8ZjKZMeiuoarQQIbDt4cIpmCrr
  szMo_oQksjYQwAsjdRBl8SpJgyMJvE-JEv7Iimg-Ua7DKL0m3XTXDoUmlyRB9-LQR
  zvlXSDaVvTKzMNUOrOwHMcBvlzwW6XgCdFwBVpSeGHGJrTvvGLCgudAhibzfkBy6h
  waaCwTmNNbZ3d0Kz5Cu416upM0N6rTGDY2fo0TC8E7cmFQ9Nkib-raTNF_GHBjzvK
  KzBJlKBCueP48Mn2wwqlL1CTr65GW4jPNoHAnE6Ki_f8jDtPjzNBgfO_FzF1Z8Uv6
  Xej135jBEiDQGVYd24t5R2yUh2v1q4X4Gz4RB_bYskqjPKlEdxTD8FIk1A0M41OjD
  BG49WcYLIEggLMfwBMOez6XPkLBQOOnVcufxX1hpRQ1keLVLaOM9IRm01fsbrd1_i
  DDZ_MdIpV11y0gxqKQlQar75w5U-z0RtzV9W3rtYd3-rsb6X-AQzlEQC3p-hYBiRL
  WITvY5KYv1gYK33oeDuoFR5eXRWPiAc-SJiQf-qq6mxCTrmzm6nZ_b3sKHGt8bRNf
  r41wRKq5tF4tt-F-5fQlt5BHPWH0nTWvUMi31xVP3tKLPAr1ho9PkQsJtuFh7JSJ0
  c6327d7K0MMph5XNp-HsclCBOO1vJNQ_v75g99P6Pg9keZcqM04wZtzsUQgTuAVBC
  Mi319yfJQzGLOn3Q0MEatN67h1Eu49lPC0aSYWXxos6-D35acpGKC8s7xutiK5xt0
  wSxXDw2H1-u7MWeevmAzkRQTPWN1z_Hq6rLTFegLjhb24QnK_ARgWOj6mHNpEPFbL
  rxIG5JbtVVVXAJs0JGfaJ8uWP619qhgmUwwgsxhYoAsW3jCyfu7twLCzhQM8TI87z
  1veaO0XJevLK5mVWHVojB-d6WiU3-Hjsqvefaubt9yXutKI_POazUuxS-yvc59jyp
  iQ0V4fq-W41FoYG1Im0yi8RlcNKhcY4PKq4EpyYy2gVhGKgpXfEX1RMUFD1SixnvW
  HQog_ECPi9qveuKlXk8uFEMkKlIFn8vLUlfKRXoqxUUTJtxCEjbcx7TampvDxMhOC
  vzrknfLbJiAWl_Fu9Xh4MXtcF6MxNdneu-yBKg68VZHNXkjaDUedM_NiQIme8O1a4
  uya2CdoZJqHAsbm-87hjpuiIzulpUynFjsQKxU_Ytni5I6p1YWp21HRiIrYyF5UQv
  XH_7D8sLzHfdy2U2JItW0RdmI5cAawDUayKuX2Rz6sZVWjftbrlApwXUbqRR2tuyn
  V9wBu9XcLYwjftIIFBiHZXSTk4WP4oIklOpvgLb6LRPD93FzVRA3XAS65flR_a3IC
  Fu4DS7jqu1t7AKN57Z4x2me_5m2ICBunKksVMO1_MO5525X8L5OXhvmH21DafczOU
  0EiDNA3FYFeBX-f6NPGJ0mxLO2ftEHUXT6z1Z0O1z7HnvYH0-K3zKvWyFHMnJZM3g
  9SLELkc8gv-ZH4M2ArOX_tZWLO7Wj8OmgzWv3Pz7IsNNYyWvdGJfnKyyUIJ5b2WJU
  3mdzM-DtgXo4YOEFvJ01K9cr5xjvPrN54MaMhv12ZG_0aKpP3rTLCkVe4KCyY6S1G
  UMwmCcCK6T6AzZHJSQbC4cudTRjh71LrRTKfVdLHrsGHsHurVOdLR_DtttkFQwmmg
  HM0LPgiMU2RVZ-ghyQms5LsegIYp4WnF6WkDAC7WO9frpBkPA2a1KHHs5_0LMpxc5
  3ianEojz7Nuqw6_SvbuVZQic9eYA4DqFYmTS3jeKxcwZ_tza9pb2YHWqiia9kW_0Q
  jbPWzue_TcIHP-FBFtTkX1MiN66LyGsapKOLkyiedgKl_KIKXIt857GLuujpe4IR7
  WcFJhyjxNTNUsdpUWvNdFA7K8de7XM0Pn7o2sZH9iCKx0FfJImxBehcUUNqGef5Q2
  dRpecGs9GXbbFzQ5aLQ5O2dUDZ6A8dZ1u3eDJfdQ4lE6ccn4bxO37nQSULfgEqmlQ
  l6cqettCB6K3q9JGmP3PpMW9Pn610ufF-5T0LwEiQGF-aebS7Y5_oYHyASA14eUk2
  MQOhFGDZYL0JveIlsD7byYer5FQTD35ocK5L05-O6LR9Hw"
        ],
      [{
          "enc":"A256CBC",
          "kid":"EBQF-IX7C-VHUN-ISB4-RYQT-HJ7O-INMS",
          "Salt":"6dSZ908dT3Syo4-z_eEiRw",
          "recipients":[{
              "kid":"MCKD-3MR6-P2TE-M6U4-4LIO-ZTRG-DZVS",
              "epk":{
                "PublicKeyECDH":{
                  "crv":"X448",
                  "Public":"jYcxhXOF8j1YycxnOuz8yRuSUEZwKwZ9FZCXg
  0PvFYuHMfPUr_86-sSWj5hBPrlVrSKg3rZn9jCA"}},
              "wmk":"3kUOWUxLusSNPJcEmSU2y7hLEqhp2MDcxyOESqIJMXJn
  oY15hx_b1g"}
            ]},
        "YzYa8qjVovYBXq-PaIU_fijaNfSi-lt-1SLv-BgTvE30cvyXlS7orQzy
  82bFZ9gxRceRfFYvenzQmPTimvPwW-vLz7KR5NP0gZDsQF5jGlzE321tUMvl35psc
  d1a_vwQGBF0xSNQ0Gzp_O7qNFjb0OCQ1Bhx6NKdrhrHWe8sGQmAnMa5zB6iKGDX08
  id6L2RJC0gwzNM96VhTjinHCm8yrn3i8gXyGoAoc__NCu70Dx3xMl_LAzXf1FgiD2
  ET3sUHROzT2q0uMP-bEAXKuNVldw8UA1h2moS2X5gOzcDV73YilYoxgM1anM4MJ_y
  3t-HzwrWBcGGNaecCNSxB2y55PbMaeDY_D0elguxNaBPSiX31UYAYoRNeivdR8LcS
  em9lOleXqWwES-9PSmhFMxOTJc8l5J3hcInJBHqfNy73JBdkOCdjnYh89i-p3rJVP
  oGGMOlgX4WZuDe0O3m8ko2a-ErcHLTSGUZ2LB3dRZIwHrIJsGHjfThCuQCjmP_Qb6
  qTnbWnUtulhojghMNYJQfGsheMpk7qS_nKSmqtR4VV55l_xooDhsFcKZ5gytwuN8B
  dUxQ0HnMAwzNEcUQsFteAopQ9NksIkXv1wFNzoID2poZ4A9FAOGw_GtHVQGFmUhaJ
  c81iCbGupF45AvzYuTJzjJY3IxVfomaHCS1-bynKhwz1MAwl4Lxzppp_qh8cewACm
  zUr9OpnRVTVgC7BEJUKmqxKncCplFA0TyYwliu69BvIX-P41F0cAVcbGZJb06ZGDV
  -lqmbirmFoZLoIpulvDMPuLmxHOIIhNhETsrP8WUdjuadiGKk7gQenDFlltVn62Op
  yiPX_NoQxyjbI3ztHAdCgLK3urhPN6H6bro-PLSbs_n7rt68EY2Br5HnDflyIrx9-
  BK9O17AFNO0V__UYimzFrk35b_Zt5iaj8cXeraq9ghWjXaRJEPkX6qyx1S-uH4gXB
  oBZbfVOAcVX_Zd-JrFW7VRz5ik0LDGb0RX65bHKTffY3bNFClVPPhDrjhiyKdITQl
  FCrbhEeDmY5D7XxoVvtdReY6QrRg8Q9M2kikh9fcXmwXpvTH7x9eaT8nhtgjg-zCA
  qd7CTYfBgoWmVMUiUKXsv6HI7aHlgYsgWzu8bHs2AJMAvLlMX7vVYMvfmC63AFLcE
  PNLWYDKk8q9fXM8c4f-v4O-w_H4JO33Xgj7MEqkCOmFIzxoXOnlSp2jHwMvImxcdM
  g5ttz8pxjoCBARrobbqL2RdkmdMUq1IA3GGaR3fuPmHVABBDKyICi90el5jTnT6qP
  WtTZ39bm0omPC_OCjKt10EFdmQS-_nsI66hqDMIuTSUEVKzT8eqb4fMDgpG8Rzq6d
  KDL8qyuySIZAxx59lWEcLOyDxe9dqD5_9HH0GogCgFUfn7dkZZSuC-pvEfLEsVKse
  Yjqmr7JDqgisgxgc8zZHLdL9WMw3uQoV4il_ZFrCag3-oLncO52Dl_vX0gazI7xMI
  8Fj1xIOgBNg-x8UdbK76_r9eWDImj-7s7Nwh-4XEXuMJsWErLiALTB3-9Nino2BJj
  DtYqbjqjoYOVohtkNemqw5kD5g5V0rRygsnbYOM9F7bP6usopeLnxZFlifdFc5mlT
  cVR9JfgzK3xBC9qgbHQcOBlx4rSTa3YwFgz1MqyfeSFrNLOtdbCYiob9xwQaB-MkV
  OiXB991CKenhh3Ju_sQp6iTMsoI7BOgvbwV7X9mAMlqzJY5trvhtLh2aUgn-_VqkF
  wohja2W-RY5tQVLB3uWBApKNr5Y6diPxcBrHAK-8JWKl81jeq9sVrCT1HDdmas6O1
  PCuyvfQQgw8DZs_5jnQTBPwhb60o85X4kq4_tLLDnkIF-Rn4X1ErZJr9dkWfwTWSG
  LropqyN1MfFLSNjP3PQ4EHjmEW_YrF-cYxnI1gWVYv3Q3jQMqun1n_wGzC4pPdJFs
  8bJWwvi_Df7vBii5IiQYGuAAdk8cPcYVu1EjqbIZLnWD3pSzTQR487kauzkm6ahuY
  Y_qxD0kfMQxtJxTKv3_q4yCCzk0DJpGFWltPywFhfcErWK398sM9YSWVvAtCntWXB
  h6hqqkJwV5EBh9QhjnL1n-V4TxxQ2HHJHFb2zmtLs6kxOclLs-XG7HZfcWga_CYiX
  6rj3loM2GIjRZBLMnVkizuLQY2Dw_rJASYKBLSq2KoqNpTfPmiTNCVII7DGBhlMtR
  jnPcREaCNmg3NyA6xc_t4SvmXLQ39w5YeEXWXtoSNGVBfxaJTqRtI8sh2c0tTCBQy
  NhTZ62rhnkEC1QePE1uu_K-HKokMExACQyAy2mlWaNkBWQoOvsantfgzQ1ea_csM_
  r01QaYHMWHqPVNUagH33XiuFutCTV9LURRLmKG-OIoUKGVumsr4pBrf6iJDRbvLyo
  rOwuzub-jiqHr3frjCsOBs8i0Kd9-sxZtl-WW-yfOWvS2ZsUlI02eHwpeZBS3WQwX
  8Alyg5AiqHUn5frCNsEvOxZSzMkoH8mTgqgyHbqappdUJcYZNV54KDayHHChW2C21
  ySG09kZgu9iLkdQM_KOqrwmSt0Zf8sJXLQOIhCpdJuR3sC2Z4XZ3KGQRwpponVoh_
  1IKv7ZzV5JJLy6UT5WXc_b8-eqVOK-itOa0x1pDF3EiD1ncsS7463mTJfMWRZY5IT
  l271t-rWFtccLFTdupiLbfbU-vxGG4fJXPLEvRJg13-XLbBcVQe4HEWHb_Rg7e1I8
  veVmJm0oVZEOoESNxVWtHXjfqTAUaSKQW8b6ZdbjwLntSzIkdSld8ZThdEOPaELDi
  OHsOx4UnUyE6rkGK1CA_-ZQPeECpV4VKE2dmwQtzbqimZD9dXeIzS8ZjXk77ScTVY
  Yzo69loheL0BIULRlXCvteBVxvbKayuLtYX4QkyirxHeDv9b8cQJZ-RY5S6wyFt4G
  n8AtFcqJJyxUg_8o5QeRjpEebcmrKA34PG1ZnPNxvH0r-Lo8ywkMzfJryMwD-OFAM
  AglGeQy0h3_6ETedIrDsdqN82KR080qcwBb6-3t-dkR4bcOvTZ51lGcXieHLLycEZ
  sF-yHIfL2GRjzU0HsORsKGtDobIDCbtRvB0_q-LI6X_jm5VfQ3Zs6s2HNKXVBeu9O
  i4Hhl5pWow5JJq8inSfh0nJ2hPTO5Xzu0coLP-nY6CEJcEp5q2VFRmatdyrR9xKgP
  jlyeG23nMiXPftXx1ArGktMMa6cXCWoGsie_eEYtdvBtkg"
        ],
      [{
          "enc":"A256CBC",
          "kid":"EBQK-IU54-MJW2-YRQM-SYJU-743K-YTXR",
          "Salt":"5RPrUS8eme48PmJoq26bKg",
          "recipients":[{
              "kid":"MCKD-3MR6-P2TE-M6U4-4LIO-ZTRG-DZVS",
              "epk":{
                "PublicKeyECDH":{
                  "crv":"X448",
                  "Public":"1amXlZFcG0dN2W6d2J_sogC_13U0fI_yWEoVa
  6w5SJkypaYe2B1Gu2rnWlC2QZdRfCUOl2nvKpeA"}},
              "wmk":"ZMwe3K0dUh4iVBckg5dm-ganKo9sj84Br949or4ncCGN
  KbDj8q9V-g"}
            ]},
        "grWcZT_x2PRQEoyKnocey2ABDHyjREDaxna5csQ0KbUaBik7bZ9VxDDi
  oIQ-0ZTw35IR_mFOmBHPfowqP8KKef7ZsJM8m6JkmJT148--u0QxgrrCkRC_z5alM
  yJS6XGbt-Jr8mlI5UXKYW_upxn7_9wamJLg3_ZbS83Y0X4cqG7TxSiDn6EJNQAgO2
  e8z7k59d7Sz87P1zXRVSI2JX1MIXhgqVLoQ_3B4F-vnIrdnc9Xs7L2W48sT2lJD3b
  N9Ydq8bQ19GSIvJxCa86hDdtGtS4fAi2uqEgVt5TA2Ta3xvavn602WSIOhNPjzT2a
  QvL-CcKp2-tBT01u7TL2cXK0MmQTBvt_Zwv4gP2pN9cibb9gBnPqGIzeeb8djwXfo
  -D6la1dNAGijjWwPNZhFGoInGIvI37zLlBMHAxBXhXXssxveCQOje_SvYvjKQnx6L
  nM9v_grPpoP3rmlAI-6qy0-Wuq05itgMEZE-1LDJhhVx9c8sqTL6huXrWdiriuzMO
  qAg1J6Bt_mdgR6smB-HNu5b_2SCJ1WjbmCS4FI7C5s4NMeNLmz6jHjIax8Dguj5b4
  7a--SWXtWu2Nt2tEMNtUKNkBnI5y0bBfEJupV8pUXo-lTTrSmFm7HG0kgGM4bqWiw
  knl65pdDnfMbgRrcC3c0zF_uTHqPGDkEQabVPcUYouAezsLAVeVCnqkqsu7uUh_nI
  36i_TwptzGrolIGzc8WbBMgwfZRUbCRSx-fLslVN1fxirWx9-AqHFw3vXp5eJME7W
  Wwx0WKVO4paXaFcVa_hxrNnrr8fAcXRxRNWaW-eZiq7Vm-X4jgCthiVyvM62Gq6WR
  4qUjZm3XOss1of11dJbY-zCCbPIhfyzIcUzfckexfpZ1N_KeDUuKwiZPPjN8Zjqti
  3lGOhZQPpIIn2Nv8CGUl6mMWlMY3kIfmaY3019x069HVkx7Uvi2RazcnHvVydwyq0
  yr4clO8A27qjcHarFJ7XNTnZkx-0oJl_t56DxyZpgal0NJHDU-jT1LlF1fnmqZB2d
  lW6FPilrVFjXFHhQVADznJvC3HrM61jCclhV2aV-ZXYbrvcxFw_Bo8teH_OEH55qQ
  8TbB_PcliJ9B_QnnCqGiTSHm7uT8RV04QCHYhcsWgTj93AEQIXc2k3ZYmP-h-Qi9-
  1fypICMRh2bI6fPWP8SXkmI7MczDRYsSFqfvxwMZsYGbTEBX4esn2zkRAJdcRjbT4
  bGt-VjEOzjT4ttMmKOHheVvm6cfP4zqAEcCiy8rETFUq-Ij928UHaA5aJi2NytUhb
  kQE8TStrxzCq7qihZrjIUuWsjv0d8xRHO66B6uvozI0hkRyeSqwUxNg2PXpT7euOz
  Je4Y8WP9406Xt-IrXk6uRYSj6hBpK8WF16pBj1Htrg80TWoDvOH8wM-0VSfD3ZsXm
  p46-BAl1kOKkHIU6eFOtRaPXgfrYvIyHurR5J0XWFAEHINx2PHbwUa0gFug8unHek
  Bch_kgcovrCxymBKAaS5v9aDJKtRHkgRHsXBqAiVyzvLavQOE5ZjFNFoQ9d1JsE6k
  buT2KPhp-dKzF9aYd1pYX7Ts6vdA-HquZ1yugCantVoNqsSWg0QLlcxt-FEbkVq0N
  2fbTP2bWxFYI0rC3hTFFUs5tjgea8eQgHa9bIXqWlmBbO1D5qnWDNgKfZySx6eyEv
  MbsRJgOc2YGDcRhgU1Xd0-ivdY3Zw3vnJUU_qcbSque34uCtPVz52kxet81P-J4b-
  2KvNOiZKOAFQUoXjUmX3Sodnc_OMCbMG0iLVCgDrkGiy9R6Kg40gY5ivuRJD6CesD
  nViZCdlIKPjH79hWxGIPVjPthApieQ8wGlDie_4aWi9GFVvCgFWCiQI3XLADfbP7r
  gWJComS-FFk4y_fXkmpqDNpHN9CeW_7t_6kM1PZ4H9TepYsrNltCytmvXcvGoK4Lo
  Uj_D5xxNEaxpkxxfqxm8e0BR9uojPaXGlAe1Fwbsl3jTRI5xHOf5ToXm6AGydfVR9
  0LfX7mmMvjdXqRsG5c428aRWa3ShMSOdcYRIgQJ7VSMjOe8AVV0huCOKMWzK8DpPC
  7EsXC268q5CK3LnTg2fK0PK3lHfpTFmtpEj6c5fTJc_5v5LDr8rjDMgcFDM-kd9Gj
  TYIbzJgbAjzG7lNMhNmFur7WCXOIwmJS3dbBonR1wW3JdI8s6nyL8uFGqIBOaMVwg
  yuBJ1_9fK0cITWqk0R_G_bE5NJO8Gxql5I0DEv7BZtqOXSfeoL0kaEoscC8VuIp5p
  873rjl4u5mRvyU3Q8i2Tcp39VFmixQIkSNuQpYjY5gAmGRFZmK5eTcGAbOxTocQVr
  1ASmRdUMTOSWTEw_fBtssp3FoXi9-agRb702SmlKdXv5wVn6yQGN2rKSzIphR-YMT
  tUimNVoGEd5qSnvIztrCMuDYJnwq0H9tqQ3B0TBNas58faIg5rQ82LO8lYyEuQTBW
  KwH_xcC3JRE2uI5ruIPIGXEGWcip0vbQIvKnaB2MmBkBudnY7_TzhTw3r0X27QzZO
  6xEfFgbhyfSzMlrXVTW2No20UND-dsEXrQwMv91ERP4OcEP5bWaPtcH54aWtL0i3o
  T5Jv116lOQp1AqoB0SlSKIl1DCvaiasUMNo3NNJtrHduO9PH6jdDn2IerEnS1Kdk0
  ASDuc2IToEybod4lC4MlL5M9y1o1WAox_4GGmj4HG_gVAIDCq3k2a61uu4PLWajQB
  05ZCqsXVwPLUkipy1J63Me00ngnU2_yU7jRJoSRwYlzbORpwVtykfMjZQH9qhz1bn
  h9jYc4C5yu8FfeItkNbgdsfH0Ul_3miGWOQEXxiaPw_sOWQbgQZROKjMwQVuZYyEX
  N05vuLBXkHHj7sOvz1cGxJg-IZ1JAhUA0eBtzYScfDRJHUnd7p1gyTh4Yf14PMC3Q
  H2kYh0Z9lcMA7bXQAoHPwbf4UgqjHu542gqUMWqg0Qd-naQ0rfs66A2Jz7sXFECnQ
  v0fDCpkoEc2l6jwDZvnfhQ4CRQ2USLfQvoB_RRvlQ6CPJbajg7FfQnlydfDojosnK
  eab9lVykZXBaouGGv8f40X5JisN_P8dPBDtxcVerCxk_SmWnDKOvGlyB6a88m76RL
  4YVpx-yWLoB9oBA2oSMDtdLGKG3Y3SZqqj1WEeEqA5qS-XVwA9CSBN53qJCC-R4vg
  c2C0bemj9LC_YqhQaGaOzGi9lT4E4XPBVqOMqPgb6MrT2A"
        ]
      ]}}

Note that the inbound and outbound server configuration does not specify the access credentials to be used to access the service. These are specified in the Credential catalog.¶

Future: The mail application should support automated means of credentialling the public key including obtaining an X.509v3 certificate or uploading the key to a key service.¶

4.2.2. SSH

SSH configuration profiles are described by entries in multiple catalogs¶

CatalogedApplicationSsh entries in the Applications catalog.: Specify an SSH client credential or certificate signing credential¶
CatalogedCredential entries in the Credential catalog.: Specify SSH host keys (i.e. contents of the known hosts file)¶
CatalogedContact entries in the Contacts catalog.: Specify SSH client keys (i.e. material from which an authorized_key file entry might be constructed).¶

Future: Client and Host certificates are not currently supported. This is clearly desirable but requires additional implementation considerations.¶

Future: Provisioning of SSH host private keys is currently out of scope. This is best considered as part of the device provisioning and authorization flow and will lead to entries being created/updated in the device catalog.¶

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

{
  "CatalogedApplicationSsh":{
    "ClientKey":{
      "Udf":"MBR3-LM6K-JRW2-JWYF-JK3C-SIA4-HG77",
      "PublicParameters":{
        "PublicKeyRSA":{
          "n":"6WSR_7MjW1hqpyLC45ZTZRWNKF0MFXN_GNuZw7wHhmZgTQwiAc
  Wa48OTj6hsj30-4Vkt-ze42q0kqlpeghveJiZA89QEWE2rO3nPuE7Og0yPp8kJEpK
  XPuwjOWD6hTNcG4jiWc7oX-pvNZCqD1ej2qh9CZVnXa7idGK1GXOWICXZhUnTN15o
  5Ou5tZDK73vvmAaIVldARiAW-ywLL4OAYQGN47RIKDUNkO8Tvhi3WZ7VR1GCduEZ2
  7k3SxyskGlgTuRTj4rRM60IWF3Pk9-j_-B3oGsMjNdvrUbnngJ_VpfDU9GLRtR4SG
  ufIrYqiw6Pbm8RIHRVco_koVSfG26N0Q",
          "e":"AQAB",
          "kid":"MBR3-LM6K-JRW2-JWYF-JK3C-SIA4-HG77"}}},
    "Key":"MBR3-LM6K-JRW2-JWYF-JK3C-SIA4-HG77",
    "Grant":["web",
      "threshold"
      ],
    "EnvelopedEscrow":[[{
          "enc":"A256CBC",
          "kid":"EBQO-W5DT-FEGY-CLWB-KZX6-TTGF-JB4S",
          "Salt":"n8FIgDGkJ6x9w3zu3ZTKLg",
          "recipients":[{
              "kid":"MCKD-3MR6-P2TE-M6U4-4LIO-ZTRG-DZVS",
              "epk":{
                "PublicKeyECDH":{
                  "crv":"X448",
                  "Public":"VYUaDmhYI6cy3ltzeLXy5iAiYxDRjzXYlEbIw
  PIMcjaZJD998DURwMcqig6cEPAYjQGDfeJ90FWA"}},
              "wmk":"xROBIN5zTCSppVnv0eASxxMZ-bOtAx9qy0O7rxL4C9J-
  bUX-D_9J1w"}
            ]},
        "-16c2DKJU7Ib5lE4p8mtpMgBPuM114w6Vj16PdvrtrMLsRt_WRSeu7i4
  uTcrW4rh2S6133gol_An1ZPT9kWCmUu1rsZMF0RgAm-d4B_X3CZ8P_HfN1zZTRaMt
  IobZuk_cZoTamrgldNdmlcy_U_JsrHsFGbv0sAXoIRHXK_bUuCCe0Xb1A5ILWukyG
  2H8-4Pcccld9r8bdoYZbBWiwXfK103BQm9gc89BO2GNXi4ncbyRO0w4SWF75-Ir_u
  ynihwi1acQcesV8XRhG3dn7x9ol0UESLY1WbkwFD2_5JRmRqiXPryKnyyuEABxji9
  nz57s90MMTXS9pHcN9axvPGEccK8svM0N5ba8_CjAV_zar8kk2t26yLi55Sead1QG
  6jjXzoQMb1-BrN6wwYrMR7zdESYJD_fShIr8o9ual909PUOnCKi-LWMtth7LQVXzv
  LUsHyMvGtFrN-qmnSfrubWiY2lx9CI1rM7cn_lu2Hrf6jnR7x6ty8czXQfw1zuBry
  XpEWaL6gdLa2PqIfJ100QPecFcJCK7DqzUWQGaH6jpVWgw_Ub3fnCJlzbA4K06Z1X
  TwfEOcHiCfKVisgCVth3br70HG6GGCJhO6EYAu2KZxeV2c6p4cWBntTkA1fTJvDeI
  0tJwgb8a69AL9FWHs3AGZaC-bwbg1cMC3yw2gCAEtVNvlAuDxgzV9hoXuI6N9wOt4
  p-H0BmgB0hdOqTaaWjlkrDcHPbPqDkosxr7Xgo2BKXVtg_nDcQ9EEyrfNaNGtvLlT
  kfpcE6ra5qbeDLZHR7iw-HrD_X1rzfnXa5syXiTNmdU6yQpDPojAAzynPJM1dZXCX
  fHD4aXc3Ow3oCUgGFYektdQHc0avKBLP_JjZMlaeOdAt6SW4hqIaFyjwYJABE3juf
  0s8IrBZEqa8rT-2OUDc0WJlsN4OPBZBfPrj4UeXtZe58eS2j-oxdf5SlWpBZzHwt3
  uqvU2h8PIa3dTL2ZXLr1SpL-bsWvtxD3ZUYfECs4JvIdayWJJpSJv99dBd3aYyWob
  vGdo9lg7v9KG0_8c7X-sXKcQuhPu8lRQTLU1KzORTcZf5AyuLb_VdmDLSXcPoEkyP
  mCkMgebpyA_l17DVKLesSzxHiKsAI0qlpdjhYECDvQ6nGZ0slrfRBQ_nWGzFUZeiE
  k-Ogu2ti2QJMvsLaXO7SHfZbk-eB4pyuy9tx8XBjCzpuanWn1LquYR7bXmdiBXGnz
  6M711qCEXtAEpaq75SZpq_T7aIojwTTlrumCxfOnn3ZCX1yw6KuM1l9DM_h2n269J
  tFEdAzRYLQtfNzxpkppN04rs3ZHSZnqRcEqieSLroSlM55iSi8Yso7HXyxpOGIJxj
  NiOj-9KYj9cvlkUzsIF2LHP5O6vxoA7gKy1tbE4H2U9gIPzMF-bwX-dsEFwcYTQ8l
  -eI_EHF9SAfnwJekjY2NcMqwNVzr7QCpgJenxkSNBl_jNoIMzdZqAuHJ5GAFcQfVF
  eRMpVARZrIq6aPxB-RzNeXSeQ_w1FwOPqJnm2y9RZCvKsj4em1WMQiZjCvzssnWv9
  tZlldDpGL4TjTfTU2G0JgJoMr8qW8fFMHWj2twfvGF18L4GptZZL3JE7dR-qDnljY
  tns_8xm_PIgvTGMGCMmPaJwEGIhwugd6lL-kxQMEDUY-QECGJPZBOeVhI0NAsfsBY
  T7AVip4cmBxBOXEK3lVTw9LcP1mL8Z48TPebNljIqlvlIryFnF6p4kadDH3UZzHTs
  V0Aq5Ic8FkRz-TIXBE6gZPN8RCZiR1Pnn6Ti2yCkKbpUUvbADVCOJhoJIu75ANvy1
  nNaGw-a4qL2aW81xV_2BjoFBUyH77TDT7ndzXifJr5T2q1LtUoDOwREhuuOCAIt1f
  nx-BAWHg_7VipCPNy7U2umRgL0ND-IGk2BMKYSPXqdZ7bSulzcMKI_rCb7rGt4hTh
  NXLfGJ_CH4H5gyaWNBAzADNvpAHX-ZfLBA5AW9KPOU_WE5goxwymKZuyBiFneNbNN
  7-AZ6goaNcrPV3m0LpnavYBGbpJafu-zu8ygY6RryIUgVEAaPR6xC6ARe45BVcv_D
  RQw4CQkNV_u7arIGFshLuZlp5FVmSy9D-p7wOTQ4MmTCK9kiHkYNezjBTL_x2DPjR
  ru9gExOzBmRS6hKX8g4fRGA0gG3F-aylo3smC8OELJCm4eLiw9o27Rj0LLlggwEw4
  W4RSiefol0jQvSv4p0SqE8Nx1X5JmGLIdQHTbyLOWyHzwJ3AiuigWv7MbpM88-vBw
  OKlVrrjzcNSH214OFxQThYXBDdQkj5494eE-QXXsvJ0AI5PcKrQzf0QdJmahhhtFV
  LjqoSplAfDC0q2UWoN9Ij6nl6_Ir7tuaWrB9Q4zoEAuVgjpZ0Y4fOImzPeCZSYnad
  eMe3YsZchJBbFOIML6xGT03EPg1kphU2a0oU9DFfAE1WNyh2p4Nqs9wRJnsRdJqVF
  Esc-7pgnDWCMqFCYm4Wu3q99ORalZRZIFmQfZNGGf__kf08YS4nEsXfNumTvLv-mD
  pr9KtkGGiwMUuDzu78dMoo-sFXxAAJB2lI8Z1XEzblgqDffNsYX2J4IlEIytUqCmP
  E0vreMDPOSI23f-Il5uWCsinsQOIyd7nKcnhHX9UznPmGb39huu5SHs7K-HlGWpTq
  RnE70x7ynQMNkrbquXHSzyx3EUJNpay1O4z33idUf24oaleer7RAZ8aalsfDaYNoP
  aSJzGG1m1q2kPwBVh-xSUGJFr4Eve1NcqutQxbDW-GyHOeczYEsuDaeI_klx9baOK
  H-DLAd9xv0l3xTn5Qu-GS4MxgBMBLCD03Peh6H9lRg3iOZmmSEuh-D-AV3dDQiHx2
  7Kqub00u7YAHxLDECczJiyO5L2C4cpHDkc2U3Ts6MGaCc7RMe1bVqo1Mgl0Cwu273
  _AIxnhLEWfOFSSFVpdbSaTfIzzeSkjPDU9Tr8OAFbQiATsdbtZVQNM8nV8GAMAWfI
  aHg5NUPuQTnglgVI6el50fEHv4YrqzLILWnBYFaXh6ZG8ZIuw7_X06qKlIw7J9mC5
  g23qWmbXHzHoqH4yw3GHAJ6u45rcSkbZwC9DamyYSX6GN7LBi_1OsovLMMiGHte8d
  nifVZoPZjNcyVzGSeRsAOAALVfA8yFTcTz66dMO_zVHt5gcW11o9SEsgLXlVfBjFe
  FPboAGNDEbGYxAFDbcXxX7dhHJtt9KAFtctPq6FaRvQW4Q"
        ]
      ],
    "LocalName":"ssh"}}

4.3. Bookmark

The bookmark catalog mmm_bookmark 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://www.example.com",
    "Title":"site1",
    "Uid":"NAXG-NNHG-MK3R-SZ73-3TQS-LS6M-M2W3",
    "LocalName":"Sites-1"}}

4.4. Contact

The contact catalog mmm_contact contains CatalogEntryContact entries which describe the person, organization or location described.¶

The fields of the contact catalog provide a superset of the capabilities of vCard [RFC2426].¶

{
  "CatalogedContact":{
    "Key":"MBQC-7OHA-RNBA-FRDL-R4GI-YQHA-DL36",
    "Self":true,
    "Contact":{
      "ContactPerson":{
        "CommonNames":[{}
          ],
        "Id":"MBQC-7OHA-RNBA-FRDL-R4GI-YQHA-DL36",
        "Anchors":[{
            "Udf":"MBQC-7OHA-RNBA-FRDL-R4GI-YQHA-DL36",
            "Validation":"Self"}
          ],
        "NetworkAddresses":[{
            "NetworkProfile":{
              "EnvelopedProfileAccount":[{
                  "EnvelopeId":"MBQC-7OHA-RNBA-FRDL-R4GI-YQHA-DL36",
                  "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJNQlFD
  LTdPSEEtUk5CQS1GUkRMLVI0R0ktWVFIQS1ETDM2IiwKICAiTWVzc2FnZVR5cGUiO
  iAiUHJvZmlsZVVzZXIiLAogICJjdHkiOiAiYXBwbGljYXRpb24vbW1tL29iamVjdC
  IsCiAgIkNyZWF0ZWQiOiAiMjAyNC0xMC0xNFQxMzoxMDo0NVoifQ",
                  "dig":"S512"},
                "ewogICJQcm9maWxlVXNlciI6IHsKICAgICJDb21tb25TaWdu
  YXR1cmUiOiB7CiAgICAgICJVZGYiOiAiTUROVC1XVDNHLTM0NkctNEk1VC1ZVjdGL
  UxUUVgtUFNOVCIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgIC
  JQdWJsaWNLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6ICJFZDQ0OCIsCiAgICA
  gICAgICAiUHVibGljIjogIklNeU1vN2ZFeTJ2SHA4c3lRMFZVNFhpdnBKRWhnUVFT
  WDNqOG12YTRIQ19UMDVVbmhRWXEKICBWWnl1dklRRVZvMmR5TUNSbTYwUTNFMEEif
  X19LAogICAgIkFjY291bnRBZGRyZXNzIjogImFsaWNlQGV4YW1wbGUuY29tIiwKIC
  AgICJTZXJ2aWNlVWRmIjogIk1CUUQtRVRYVS1IWlJXLUEyNk8tV0RUUi1LN0dJLVg
  2SkQiLAogICAgIkVzY3Jvd0VuY3J5cHRpb24iOiB7CiAgICAgICJVZGYiOiAiTUNL
  RC0zTVI2LVAyVEUtTTZVNC00TElPLVpUUkctRFpWUyIsCiAgICAgICJQdWJsaWNQY
  XJhbWV0ZXJzIjogewogICAgICAgICJQdWJsaWNLZXlFQ0RIIjogewogICAgICAgIC
  AgImNydiI6ICJYNDQ4IiwKICAgICAgICAgICJQdWJsaWMiOiAiMXZOVUFBcDNyc3p
  JcGhHOEVzZm9hTzVZNnNaQ24wSGM4ekNnZFFpdllwSkFjRHRta1NzQwogIGVJMmdt
  RFRDSzZTclMxVWdQdHVZbVR3QSJ9fX0sCiAgICAiQWRtaW5pc3RyYXRvclNpZ25hd
  HVyZSI6IHsKICAgICAgIlVkZiI6ICJNRDJMLTZNN0MtWjNaMy1RM0FMLUpGWUktWk
  lVQy1CS1VSIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB
  1YmxpY0tleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIkVkNDQ4IiwKICAgICAg
  ICAgICJQdWJsaWMiOiAiYkhvS2IwYzEyRjdjaWJNXzNnWmNKWE16T09YNHNuSGdQV
  ndPZlJZazZBUkpPc0dQZW1zZAogIDJCbTBXZm1Ba1JZTzNFUTZmajhfTnpTQSJ9fX
  0sCiAgICAiQ29tbW9uRW5jcnlwdGlvbiI6IHsKICAgICAgIlVkZiI6ICJNQVlGLUQ
  3TEotNUlNUC1FVUNHLUhTR0gtN0xTUi1BQVBaIiwKICAgICAgIlB1YmxpY1BhcmFt
  ZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICAgICAiY
  3J2IjogIlg0NDgiLAogICAgICAgICAgIlB1YmxpYyI6ICJjN29vcko4MDhzYzlkND
  BLWERoSUhnQ1RGejM5TUszSmpPMFE3S191ZkRFR0RLaXdWS2hkCiAgM29QUTQ0UEV
  xR2p3a3BwN09mYmNCYlNBIn19fSwKICAgICJDb21tb25BdXRoZW50aWNhdGlvbiI6
  IHsKICAgICAgIlVkZiI6ICJNQUZULVNJTkEtU0ZYSS1QQkRZLVdSSEUtTlhZTC1EW
  FZUIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0
  tleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIlg0NDgiLAogICAgICAgICAgIlB
  1YmxpYyI6ICJYY2dFejl5MmNxc3g0WmViR0VSVGpyTi14ek44M0QtcGN4MDY1MXgt
  V1VDcVlOcnNuelRICiAgNDBDcG9NeHVOLUZucFQ1bV9iME15dUtBIn19fSwKICAgI
  CJSb290VWRmcyI6IFsiWUJKUjNqUjJQbGpkWWs1cXhiV2RIWTByVFlFYUZBa0hZM0
  1tc1I4enZOMURyMzNSbkwKICBVTDNUaHJHOURNV0JaM1AtOFp5R3p5S2FRWXdlY28
  yWlV0Y0t3Il19fQ",
                {
                  "signatures":[{
                      "alg":"ED448",
                      "kid":"MAJF-DXRU-OY7F-RXLC-JZVM-LNM5-DWGS",
                      "SignatureKey":{
                        "PublicKeyECDH":{
                          "crv":"Ed448",
                          "Public":"9sZGEfYSIoTvVSL0Q5c_Oip_Hi2iO
  Tsl4L3iLwhfOv9bA-5nd7PyRooKEsQx-lA7PMAYBewSOmIA"}},
                      "signature":"6x3k8AC2jkUQv0jzlUVWJDqP7zcNkK
  AqvPcAs7Ci2jXULjbIFAFCct8GC8Nb8KiD5ljoLAsVHr-AnYcjklyXSHN6Gn_BIZi
  LiW3Yu5_ChXHspywX-ZGMD6soXJIilOzreauR-_aiUE7Gx0eh3Fje2wEA"}
                    ],
                  "PayloadDigest":"tXPfbmg_SRmARF_7HLPq-bM6NMO1h1
  Oa30f_Ag_TIRzGKMrmTKtV7XH-h3NIBFGxOQYuD0BproKNEg6uhtG0Mw"}
                ],
              "Address":"[email protected]"}}
          ],
        "Sources":[{
            "Validation":"Self",
            "EnvelopedSource":[{
                "ContentMetaData":"ewogICJNZXNzYWdlVHlwZSI6ICJDb2
  50YWN0UGVyc29uIiwKICAiY3R5IjogImFwcGxpY2F0aW9uL21tbS9vYmplY3QiLAo
  gICJDcmVhdGVkIjogIjIwMjQtMTAtMTRUMTM6MTA6NDVaIn0",
                "dig":"S512"},
              "ewogICJDb250YWN0UGVyc29uIjogewogICAgIkNvbW1vbk5hbW
  VzIjogW251bGxdLAogICAgIkFuY2hvcnMiOiBbewogICAgICAgICJVZGYiOiAiTUJ
  RQy03T0hBLVJOQkEtRlJETC1SNEdJLVlRSEEtREwzNiIsCiAgICAgICAgIlZhbGlk
  YXRpb24iOiAiU2VsZiJ9XSwKICAgICJOZXR3b3JrQWRkcmVzc2VzIjogW3sKICAgI
  CAgICAiTmV0d29ya1Byb2ZpbGUiOiB7CiAgICAgICAgICAiRW52ZWxvcGVkUHJvZm
  lsZUFjY291bnQiOiBbewogICAgICAgICAgICAgICJFbnZlbG9wZUlkIjogIk1CUUM
  tN09IQS1STkJBLUZSREwtUjRHSS1ZUUhBLURMMzYiLAogICAgICAgICAgICAgICJD
  b250ZW50TWV0YURhdGEiOiAiZXdvZ0lDSlZibWx4ZFdWSlpDSTZJQ0pOUWxGRExUZ
  FBTRUV0VWs1Q1FTMQogIEdVa1JNTFZJMFIwa3RXVkZJUVMxRVRETTJJaXdLSUNBaV
  RXVnpjMkZuWlZSNWNHVWlPaUFpVUhKdlptbHNaCiAgVlZ6WlhJaUxBb2dJQ0pqZEh
  raU9pQWlZWEJ3YkdsallYUnBiMjR2YlcxdEwyOWlhbVZqZENJc0NpQWdJa04KICB5
  WldGMFpXUWlPaUFpTWpBeU5DMHhNQzB4TkZReE16b3hNRG8wTlZvaWZRIiwKICAgI
  CAgICAgICAgICAiZGlnIjogIlM1MTIifSwKICAgICAgICAgICAgImV3b2dJQ0pRY2
  05bWFXeGxWWE5sY2lJNklIc0tJQ0FnSUNKRGIyMXRiMjVUYVdkdVlYUjFjbVUKICB
  pT2lCN0NpQWdJQ0FnSUNKVlpHWWlPaUFpVFVST1ZDMVhWRE5ITFRNME5rY3RORWsx
  VkMxWlZqZEdMVXhVVQogIFZndFVGTk9WQ0lzQ2lBZ0lDQWdJQ0pRZFdKc2FXTlFZW
  EpoYldWMFpYSnpJam9nZXdvZ0lDQWdJQ0FnSUNKCiAgUWRXSnNhV05MWlhsRlEwUk
  lJam9nZXdvZ0lDQWdJQ0FnSUNBZ0ltTnlkaUk2SUNKRlpEUTBPQ0lzQ2lBZ0kKICB
  DQWdJQ0FnSUNBaVVIVmliR2xqSWpvZ0lrbE5lVTF2TjJaRmVUSjJTSEE0YzNsUk1G
  WlZORmhwZG5CS1JXaAogIG5VVkZUV0ROcU9HMTJZVFJJUTE5VU1EVlZibWhSV1hFS
  0lDQldXbmwxZGtsUlJWWnZNbVI1VFVOU2JUWXdVCiAgVE5GTUVFaWZYMTlMQW9nSU
  NBZ0lrRmpZMjkxYm5SQlpHUnlaWE56SWpvZ0ltRnNhV05sUUdWNFlXMXdiR1UKICB
  1WTI5dElpd0tJQ0FnSUNKVFpYSjJhV05sVldSbUlqb2dJazFDVVVRdFJWUllWUzFJ
  V2xKWExVRXlOazh0VgogIDBSVVVpMUxOMGRKTFZnMlNrUWlMQW9nSUNBZ0lrVnpZM
  0p2ZDBWdVkzSjVjSFJwYjI0aU9pQjdDaUFnSUNBCiAgZ0lDSlZaR1lpT2lBaVRVTk
  xSQzB6VFZJMkxWQXlWRVV0VFRaVk5DMDBURWxQTFZwVVVrY3RSRnBXVXlJc0MKICB
  pQWdJQ0FnSUNKUWRXSnNhV05RWVhKaGJXVjBaWEp6SWpvZ2V3b2dJQ0FnSUNBZ0lD
  SlFkV0pzYVdOTFpYbAogIEZRMFJJSWpvZ2V3b2dJQ0FnSUNBZ0lDQWdJbU55ZGlJN
  klDSllORFE0SWl3S0lDQWdJQ0FnSUNBZ0lDSlFkCiAgV0pzYVdNaU9pQWlNWFpPVl
  VGQmNETnljM3BKY0doSE9FVnpabTloVHpWWk5uTmFRMjR3U0dNNGVrTm5aRkYKICB
  wZGxsd1NrRmpSSFJ0YTFOelF3b2dJR1ZKTW1kdFJGUkRTelpUY2xNeFZXZFFkSFZa
  YlZSM1FTSjlmWDBzQwogIGlBZ0lDQWlRV1J0YVc1cGMzUnlZWFJ2Y2xOcFoyNWhkS
  FZ5WlNJNklIc0tJQ0FnSUNBZ0lsVmtaaUk2SUNKCiAgTlJESk1MVFpOTjBNdFdqTm
  FNeTFSTTBGTUxVcEdXVWt0V2tsVlF5MUNTMVZTSWl3S0lDQWdJQ0FnSWxCMVkKICB
  teHBZMUJoY21GdFpYUmxjbk1pT2lCN0NpQWdJQ0FnSUNBZ0lsQjFZbXhwWTB0bGVV
  VkRSRWdpT2lCN0NpQQogIGdJQ0FnSUNBZ0lDQWlZM0oySWpvZ0lrVmtORFE0SWl3S
  0lDQWdJQ0FnSUNBZ0lDSlFkV0pzYVdNaU9pQWlZCiAga2h2UzJJd1l6RXlSamRqYV
  dKTlh6Tm5XbU5LV0UxNlQwOVlOSE51U0dkUVZuZFBabEpaYXpaQlVrcFBjMGQKICB
  RWlcxelpBb2dJREpDYlRCWFptMUJhMUpaVHpORlVUWm1hamhmVG5wVFFTSjlmWDBz
  Q2lBZ0lDQWlRMjl0YgogIFc5dVJXNWpjbmx3ZEdsdmJpSTZJSHNLSUNBZ0lDQWdJb
  FZrWmlJNklDSk5RVmxHTFVRM1RFb3ROVWxOVUMxCiAgRlZVTkhMVWhUUjBndE4weF
  RVaTFCUVZCYUlpd0tJQ0FnSUNBZ0lsQjFZbXhwWTFCaGNtRnRaWFJsY25NaU8KICB
  pQjdDaUFnSUNBZ0lDQWdJbEIxWW14cFkwdGxlVVZEUkVnaU9pQjdDaUFnSUNBZ0lD
  QWdJQ0FpWTNKMklqbwogIGdJbGcwTkRnaUxBb2dJQ0FnSUNBZ0lDQWdJbEIxWW14c
  Fl5STZJQ0pqTjI5dmNrbzRNRGh6WXpsa05EQkxXCiAgRVJvU1VoblExUkdlak01VF
  VzelNtcFBNRkUzUzE5MVprUkZSMFJMYVhkV1MyaGtDaUFnTTI5UVVUUTBVRVYKICB
  4UjJwM2EzQndOMDltWW1OQ1lsTkJJbjE5ZlN3S0lDQWdJQ0pEYjIxdGIyNUJkWFJv
  Wlc1MGFXTmhkR2x2YgogIGlJNklIc0tJQ0FnSUNBZ0lsVmtaaUk2SUNKTlFVWlVMV
  k5KVGtFdFUwWllTUzFRUWtSWkxWZFNTRVV0VGxoCiAgWlRDMUVXRlpVSWl3S0lDQW
  dJQ0FnSWxCMVlteHBZMUJoY21GdFpYUmxjbk1pT2lCN0NpQWdJQ0FnSUNBZ0kKICB
  sQjFZbXhwWTB0bGVVVkRSRWdpT2lCN0NpQWdJQ0FnSUNBZ0lDQWlZM0oySWpvZ0ls
  ZzBORGdpTEFvZ0lDQQogIGdJQ0FnSUNBZ0lsQjFZbXhwWXlJNklDSllZMmRGZWpsN
  U1tTnhjM2cwV21WaVIwVlNWR3B5VGkxNGVrNDRNCiAgMFF0Y0dONE1EWTFNWGd0Vj
  FWRGNWbE9jbk51ZWxSSUNpQWdOREJEY0c5TmVIVk9MVVp1Y0ZRMWJWOWlNRTEKICA
  1ZFV0QkluMTlmU3dLSUNBZ0lDSlNiMjkwVldSbWN5STZJRnNpV1VKS1VqTnFVakpR
  Ykdwa1dXczFjWGhpVgogIDJSSVdUQnlWRmxGWVVaQmEwaFpNMDF0YzFJNGVuWk9NV
  VJ5TXpOU2Jrd0tJQ0JWVEROVWFISkhPVVJOVjBKCiAgYU0xQXRPRnA1UjNwNVMyRl
  JXWGRsWTI4eVdsVjBZMHQzSWwxOWZRIiwKICAgICAgICAgICAgewogICAgICAgICA
  gICAgICJzaWduYXR1cmVzIjogW3sKICAgICAgICAgICAgICAgICAgImFsZyI6ICJF
  RDQ0OCIsCiAgICAgICAgICAgICAgICAgICJraWQiOiAiTUFKRi1EWFJVLU9ZN0YtU
  lhMQy1KWlZNLUxOTTUtRFdHUyIsCiAgICAgICAgICAgICAgICAgICJTaWduYXR1cm
  VLZXkiOiB7CiAgICAgICAgICAgICAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiA
  gICAgICAgICAgICAgICAgICAgICAiY3J2IjogIkVkNDQ4IiwKICAgICAgICAgICAg
  ICAgICAgICAgICJQdWJsaWMiOiAiOXNaR0VmWVNJb1R2VlNMMFE1Y19PaXBfSGkya
  U9Uc2w0TDNpTHdoZk92OWJBLTVuZDdQeQogIFJvb0tFc1F4LWxBN1BNQVlCZXdTT2
  1JQSJ9fSwKICAgICAgICAgICAgICAgICAgInNpZ25hdHVyZSI6ICI2eDNrOEFDMmp
  rVVF2MGp6bFVWV0pEcVA3emNOa0tBcXZQY0FzN0NpMmpYVUxqYklGCiAgQUZDY3Q4
  R0M4TmI4S2lENWxqb0xBc1ZIci1BblljamtseVhTSE42R25fQklaaUxpVzNZdTVfQ
  2hYSHNweXcKICBYLVpHTUQ2c29YSklpbE96cmVhdVItX2FpVUU3R3gwZWgzRmplMn
  dFQSJ9XSwKICAgICAgICAgICAgICAiUGF5bG9hZERpZ2VzdCI6ICJ0WFBmYm1nX1N
  SbUFSRl83SExQcS1iTTZOTU8xaDFPYTMwZl9BZ19USVJ6R0sKICBNcm1US3RWN1hI
  LWgzTklCRkd4T1FZdUQwQnByb0tORWc2dWh0RzBNdyJ9XSwKICAgICAgICAgICJBZ
  GRyZXNzIjogImFsaWNlQGV4YW1wbGUuY29tIn19XX19",
              {
                "signatures":[{
                    "alg":"ED448",
                    "kid":"MDNT-WT3G-346G-4I5T-YV7F-LTQX-PSNT",
                    "signature":"XNiZFxlGpuRctoAwDE2M8-E9H1T2YEYj
  vvtA3-7IauLyRUyXUmdd84apRaYEtCmjgVZWlurG1ywAAOj9MfFdDkucJ-QGefgtg
  mhN5YUI4K6s7p9LjjAheFt3YYRY9TNrcBFgStXVT01OL9NdO4VPyhwA"}
                  ],
                "PayloadDigest":"O_emyhwHRf9e38XKr7utUgB-gKMyo6qi
  v-Hd03Xui8KhZUCyw3LsdqG4OP5vgzJ7RM4uxJei5hOwd6-fn9MISQ"}
              ]}
          ]}}}}

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

4.5. Credential

The credential catalog mmm_credential contains CatalogEntryCredential entries which describe credentials used to access network resources.¶

{
  "CatalogedCredential":{
    "Service":"ftp.example.com",
    "Username":"alice1",
    "Password":"password"}}

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

4.6. Device

The device catalog mmm_Device contains CatalogEntryDevice entries which describe the devices connected to the account and the permissions assigned to them.¶

Each device connected to a Mesh Account has an associated CatalogEntryDevice entry that includes the activation and connection records for the account. These records are described in further detail in section ???.¶

4.7. Network

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

{
  "CatalogedNetwork":{
    "Service":"myWiFi",
    "Password":"securePassword"}}

4.8. Publication

[Note, this catalog is obsolete, the functions provided by this catalog are being merged with the Access catalog]¶

The publication catalog mmm_Publication contains CatalogEntryPublication entries which describe content published through the account.¶

If the data being published is small, it MAY be specified in the CatalogEntryPublication entry itself as enveloped data. Otherwise a link to the external content is required.¶

The Publication catalog is currently used to publish two types of data:¶

Contact: Used in the Static QR Code Contact Exchange interaction.¶
Profile Device: Used in the Preconfigured Device Connection interaction.¶

The interactions using this published data are described in [draft-hallambaker-mesh-protocol].¶

>>>> Unfinished SchemaEntryPublication¶

Missing example 13

4.9. Task

The Task catalog mmm_Task contains CatalogEntryTask entries which describe tasks assigned to the user including calendar entries and to do lists.¶

The fields of the task catalog currently reflect those offered by the iCalendar specification [RFC5545]. Specification of additional fields to allow task triggering on geographic location and/or completion of other tasks is a work in progress.¶

{
  "CatalogedTask":{
    "Title":"SomeItem",
    "Uid":"NDQD-6QT7-56MN-ONAG-2NUJ-DADI-BPOA"}}

8. 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 a device to an account.¶

Figure 1: Profiles And Connections

8.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-callsign] 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.¶

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

8.3. Mesh Connections

A Mesh connection is an assertion describing the connection of a device or a member to an account.¶

Mesh connections provide similar functionality to 'end-entity' certificates in PKIX but with the important proviso that they are only used to provide trust between a device connected to an account and the service to which that account is bound and between the devices connected to an account.¶

A connection is valid with respect to an account with profile P if and only if:¶

The profile P is valid¶
The AuthorityUdf field of the connection is consistent with the UDF of P¶
The profile is signed under the key specified in the AdministrationKey field of P.¶
Any conditions specified in the profile are met¶

A connection has the status current with respect to an account with profile if and only if:¶

The connection is valid with respect to the account with profile P.¶
The profile P is current.¶

A device is authenticated with respect to an account with profile P if and only if:¶

The connection is valid with respect to the account with profile P.¶
The device has presented an appropriate proof of knowledge of the DeviceAuthentication key specified in the connection.¶

8.4. Device Pre-configuration

The DevicePreconfiguration record provides a means of bundling all the information used to preconfigure a device for use in the Mesh. This comprises:¶

The Enveloped ProfileDevice.¶
A ConnectionDevice assertion credentialing the device to the configuration provider Mesh Service.¶
A ConnectionService assertion credentialing the device to the configuration provider Mesh Service.¶
The secret seed used to create the ProfileDevice data.¶

The DevicePreconfiguration record MAY be used as the means of preconfiguring devices to allow connection to a user's account profile using the Preconfigured/Static QR Code device connection interaction.¶

For example, Alice's coffee pot was preconfigured for connection to a Mesh account at the factory and the following DevicePreconfiguration record created:¶

{
  "DevicePreconfigurationPrivate":{
    "EnvelopedConnectionDevice":[{
        "ContentMetaData":"ewogICJNZXNzYWdlVHlwZSI6ICJDb25uZWN0aW
  9uRGV2aWNlIiwKICAiY3R5IjogImFwcGxpY2F0aW9uL21tbS9vYmplY3QiLAogICJ
  DcmVhdGVkIjogIjIwMjQtMTAtMTRUMTM6MTA6NThaIn0",
        "dig":"S512"},
      "ewogICJDb25uZWN0aW9uRGV2aWNlIjogewogICAgIlNpZ25hdHVyZSI6IH
  sKICAgICAgIlVkZiI6ICJNRFY1LUVJQ0ktSk5GVi0zNUs3LUlQREctNkNWNy1OU1Y
  1IiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tl
  eUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIkVkNDQ4IiwKICAgICAgICAgICJQd
  WJsaWMiOiAiQVVPMUIyR1RLNGZjSk9rUFlNN0RJa3VDT2s0SWNJbHFzTGZuQVlnQS
  1BQ0dhZmNvUFZCdQogIEJDSGYzR2JDMEx2bHBiS2cwNmliREh5QSJ9fX0sCiAgICA
  iRW5jcnlwdGlvbiI6IHsKICAgICAgIlVkZiI6ICJNQkZGLUVTUDMtVk5YWS1EWUhM
  LTVNSkktVjRLNy1WN1dOIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgI
  CAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIlg0NDgiLA
  ogICAgICAgICAgIlB1YmxpYyI6ICJMd2oxNlE3QmNraWU3ZU9jMG85NXJYbGZ6enh
  rSDFFTGVCMGxlLURJdklxemVpeHlocjZhCiAgTjRTSV94Vzh6eGwxSGVSclRKN1lh
  Uy1BIn19fSwKICAgICJBdXRoZW50aWNhdGlvbiI6IHsKICAgICAgIlVkZiI6ICJNQ
  kZGLUVTUDMtVk5YWS1EWUhMLTVNSkktVjRLNy1WN1dOIiwKICAgICAgIlB1YmxpY1
  BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICA
  gICAiY3J2IjogIlg0NDgiLAogICAgICAgICAgIlB1YmxpYyI6ICJMd2oxNlE3QmNr
  aWU3ZU9jMG85NXJYbGZ6enhrSDFFTGVCMGxlLURJdklxemVpeHlocjZhCiAgTjRTS
  V94Vzh6eGwxSGVSclRKN1lhUy1BIn19fX19",
      {
        "signatures":[{
            "alg":"ED448",
            "kid":"MD66-B7Q7-HWEB-UAF6-PWNM-YVBH-HXE7",
            "signature":"T5q8Ygyj3aM5tDzUmjoFMAVdGasi0PF1SZlgFYCl
  3kCT5_NZrd5iuGcJetwaq0bINEJHDjUppQuAdbpe8eZPlJBtTo8EBksurd04sqf1U
  NIokTq5HA-eXh45bjPkOGjwZmBBO46LlyQDG_kq-6roUw0A"}
          ],
        "PayloadDigest":"CQupHrY2ASmhF8QOcXCnjid4nC6wlVlUk9cxmIUc
  MGC1_YLhJwc7wpE-EfoDCcmkTtRCPmwq1tmdX88VClLkSw"}
      ],
    "EnvelopedConnectionService":[{
        "ContentMetaData":"ewogICJNZXNzYWdlVHlwZSI6ICJDb25uZWN0aW
  9uU2VydmljZSIsCiAgImN0eSI6ICJhcHBsaWNhdGlvbi9tbW0vb2JqZWN0IiwKICA
  iQ3JlYXRlZCI6ICIyMDI0LTEwLTE0VDEzOjEwOjU4WiJ9",
        "dig":"S512"},
      "ewogICJDb25uZWN0aW9uU2VydmljZSI6IHsKICAgICJBdXRoZW50aWNhdG
  lvbiI6IHsKICAgICAgIlVkZiI6ICJNQkZGLUVTUDMtVk5YWS1EWUhMLTVNSkktVjR
  LNy1WN1dOIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1
  YmxpY0tleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIlg0NDgiLAogICAgICAgI
  CAgIlB1YmxpYyI6ICJMd2oxNlE3QmNraWU3ZU9jMG85NXJYbGZ6enhrSDFFTGVCMG
  xlLURJdklxemVpeHlocjZhCiAgTjRTSV94Vzh6eGwxSGVSclRKN1lhUy1BIn19fX1
  9",
      {
        "signatures":[{
            "alg":"ED448",
            "kid":"MD66-B7Q7-HWEB-UAF6-PWNM-YVBH-HXE7",
            "signature":"4FkfmdMX6sWMQ5zskF7V_1UsoBTBKVVQtYigF41m
  MGOx1_yTQtpDs1lnqxmBt6yAtjfUvv1NsG2AdYx425rJ5-lryqyud6m-MNoTCUeWW
  wuO0jGMpaw2PyjFUFh62_k5fGDzZVgqx-larLbwVf6vFQsA"}
          ],
        "PayloadDigest":"z4aP8rSa_WxiufLZcZmhBbJd-3OCz70GX4gIkH0y
  U4LCO8QdoX-4iAbwfwylksQDTtNbKmVfxQam4MCT-2oKZw"}
      ],
    "PrivateKey":{
      "PrivateKeyUDF":{
        "PrivateValue":"ZAAQ-AUKH-YPXV-5NTI-ZVIK-4Q2D-EFAP-UR7Y-5XX
N-EDXE-HX3O-LYFS-BJOU-CMQE",
        "KeyType":"MeshProfileDevice",
        "RootSignAlgorithms":["ED448"
          ]}},
    "ConnectUri":"mcd://[email protected]/EBH3-DT6M-G2WA-EF7E-DA42-
DN55-7E",
    "EnvelopedProfileDevice":[{
        "EnvelopeId":"MBQK-36BF-K7RS-UDWD-PVC3-CVMR-BJCP",
        "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJNQlFLLTM2QkYtSz
  dSUy1VRFdELVBWQzMtQ1ZNUi1CSkNQIiwKICAiTWVzc2FnZVR5cGUiOiAiUHJvZml
  sZURldmljZSIsCiAgImN0eSI6ICJhcHBsaWNhdGlvbi9tbW0vb2JqZWN0IiwKICAi
  Q3JlYXRlZCI6ICIyMDI0LTEwLTE0VDEzOjEwOjU4WiJ9",
        "dig":"S512"},
      "ewogICJQcm9maWxlRGV2aWNlIjogewogICAgIkVuY3J5cHRpb24iOiB7Ci
  AgICAgICJVZGYiOiAiTUJGRi1FU1AzLVZOWFktRFlITC01TUpJLVY0SzctVjdXTiI
  sCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdWJsaWNLZXlF
  Q0RIIjogewogICAgICAgICAgImNydiI6ICJYNDQ4IiwKICAgICAgICAgICJQdWJsa
  WMiOiAiTHdqMTZRN0Jja2llN2VPYzBvOTVyWGxmenp4a0gxRUxlQjBsZS1ESXZJcX
  plaXh5aHI2YQogIE40U0lfeFc4enhsMUhlUnJUSjdZYVMtQSJ9fX0sCiAgICAiU2l
  nbmF0dXJlIjogewogICAgICAiVWRmIjogIk1EVjUtRUlDSS1KTkZWLTM1SzctSVBE
  Ry02Q1Y3LU5TVjUiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgI
  CAiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogIC
  AgICAgICAgIlB1YmxpYyI6ICJBVU8xQjJHVEs0ZmNKT2tQWU03RElrdUNPazRJY0l
  scXNMZm5BWWdBLUFDR2FmY29QVkJ1CiAgQkNIZjNHYkMwTHZscGJLZzA2aWJESHlB
  In19fSwKICAgICJBdXRoZW50aWNhdGlvbiI6IHsKICAgICAgIlVkZiI6ICJNQVZHL
  VlXWVYtMlVXNy1MU1QzLUFQQkctUkw3SC1ONTMzIiwKICAgICAgIlB1YmxpY1Bhcm
  FtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICAgICA
  iY3J2IjogIlg0NDgiLAogICAgICAgICAgIlB1YmxpYyI6ICJyRlZGUi1jTDZjdWNU
  U3JmRm4xNDZYVE9kMWgzSkdBM0hrQ0VlYkNzaUEzT3dWQXBkN2ZsCiAgZ0Z4Zlh0d
  lkzVXRpNmlRd1RTdmVFWmtBIn19fSwKICAgICJSb290VWRmcyI6IFsiWU5lVGVBYk
  l4NVdSdEN4Q3llbnBqYWJKVlJuOERUbGF1SFBUZFFUYnRJOEFHblY1bk8KICBWM1l
  PWENlRFlRZTk5VnFIcWZwYi10MFZxSjI5blZKRW1yUEpNIl19fQ",
      {
        "signatures":[{
            "alg":"ED448",
            "kid":"MDLZ-G6AG-ZDDZ-LENU-FRBM-T2PJ-RWTM",
            "SignatureKey":{
              "PublicKeyECDH":{
                "crv":"Ed448",
                "Public":"WPX0CBEOzgJWHVJqiyTAr4MrieFJQYzdutZML5-
  MnHsfF7KfRmGxsUR9eppBIKTFhzLaRhd06XmA"}},
            "signature":"s1AVL-omThJqK3LTFXtg58xvRBZoeansc39u4rqT
  iKRHKrCQx-11PG9b0Vq-VC_MRWxbCwZenawAo4fBnNnpNvtbNGUaALlFVvLK5nPZV
  O6nY6gA_i3ID9ZrUTxYJz0lbj-ZTIt6NZOGxTJX4yxJiC8A"}
          ],
        "PayloadDigest":"OrZNsRzLz7olETFljSpKbdG1bNjj5MBr-ireuPK6
  Sn9-ARWs4E3Xk2_HvrHA7cySavkX6anRBSGzQ5uYty0_Ow"}
      ]}}

The use of the publication mechanism in device connection is discussed further in [draft-hallambaker-mesh-protocol].¶

9. Architecture

The Mesh architecture has four principal components:¶

Mesh Account: A collection of information (contacts, calendar entries, inbound and outbound messages, etc.) belonging to a user who uses the Mesh to management.¶
Mesh Device Management: The various functions that manage binding of devices to a Mesh to grant access to information and services bound to that account.¶
Mesh Service: Provides network services through which devices and other Mesh users may interact with a Mesh Account.¶
Mesh Messaging: An end-to-end secure messaging service that allows short messages (less than 32KB) to be exchanged between Mesh Accounts and between the Mesh devices connected to a particular account.¶

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 Mesh Service Provider which the user may change at any time of their choosing.¶

A Mesh Account May be active or inactive. By definition, an active Mesh account is serviced by exactly one Mesh Service, an inactive Mesh account is not serviced by a Mesh Service. A Mesh Service Provider MAY offer a backup service for accounts hosted by other providers. In this case the backup provider is connected to the account as a Mesh device, thus allowing the backup provider to maintain a copy of the stores contained in the account and facilitating a rapid transfer of responsibility for servicing the account should that be desired. The use of backup providers is described further in [draft-hallambaker-mesh-discovery].¶

9.1. Mesh Account

Mesh Accounts contains all the stateful information (contacts, calendar entries, inbound and outbound messages, etc.) related to a particular persona used by the owner.¶

By definition a Mesh Account is active if it is serviced by a Mesh Service and inactive otherwise. A Mesh user MAY change their service provider at any time. An active Mesh Account is serviced by exactly one Mesh Service at once but a user MAY register a 'backup' service provider to their account in the same manner as adding an advice. This ensures that the backup service is pre-populated with all the information required to allow the user to switch to the new provider without interruption of service.¶

Each Mesh account is described by an Account Profile. Currently separate profile Account Profile are defined for user accounts and group accounts. It is not clear if this distinction is a useful one.¶

9.1.1. Account Profile

A Mesh account 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.¶

An Account Profile MUST specify an EscrowEncryption key. This key MAY be used to escrow private keys used for encryption of stored data. 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 account profile unless they intend to establish a separate identity. To minimize the risk of disclosure, the Profile Signature Key is only ever used to sign updates to the account profile itself. This allows the user to secure their Profile 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.¶

9.1.1.1. Creating a ProfileMaster

Creating a ProfileMaster comprises the steps of:¶

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

9.1.1.2. Updating a ProfileMaster

Updating a ProfileMaster comprises the steps of:¶

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

9.2. Device Management

Device management allows a collection of devices belonging to a user to function as a single personal Mesh. Two catalogs are used to manage this process:¶

The Access catalog is used to instruct the Mesh Service how to respond to requests from the device.¶
The Device catalog records information for use by administration devices managing the device.¶

9.2.1. The Device Catalog

Each Mesh Account 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.¶

9.2.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. When bound to an account, the base keys specified in the Device Profile are combined with the key data provided in the Activation device to construct the keys the device will use in the context of the account.¶

Figure 2: Mapping of Device Profile and Device Private to Device Connection Keys.

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

9.2.2.1. Creating a ProfileDevice

Creating a ProfileDevice comprises the steps of:¶

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

9.2.2.2. Connection to a Meh Account

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

Generating the PrivateDevice keys.¶
Creating the ConnectionDevice data from the public components of the ProfileDevice and PrivateDevice keys and signing it using the administration key.¶
Creating the Activations for the device and signing them using the administration key.¶
Creating the CatalogEntryDevice for the device and adding it to the CatalogDevice of the account.¶
Creating an AccessCapability granting the necessary access rights for the device and adding that to the CatalogAccess of the account.¶

These steps are usually performed through use of the Mesh Protocol Connection mechanism. However, Mesh clients MAY support additional mechanisms as circumstances require provided that the appropriate authentication and private key protection controls are provided.¶

9.3. Mesh Services

A Mesh Service provides one or more Mesh Hosts that support Mesh Accounts through the Mesh Web Service Protocol.¶

Mesh Services and Hosts are described by Service Profiles and Host Profiles. The means by which services manage the hosts through which they provide service is outside the scope of this document.¶

As with a Device connected to a Mesh Account, a the binding of a Host to the service it supports is described by a connection record:¶

Figure 3: Service Profile and Delegated Host Assertion.

The credentials provided by the ProfileService and ProfileHost are distinct from those provided by the WebPKI that typically services TLS requests. WebPKI credentials provide service introduction and authentication while a Mesh ProfileHost only provides authentication.¶

Unless exceptional circumstances require, a service should not need to revise its Service Profile unless it is intended to change its identity. Service Profiles MAY be countersigned by Trusted Third Parties to establish accountability.¶

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

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

9.4.1. Message Status

As previously described in section ###, every message stored in a spool has a specified state. The range of allowable states is defined by the message type. New message states MAY be defined for new message types as they are defined.¶

By default, messages are appended to a spool in the Initial state, but a spool entry MAY specify any state that is valid for that message type.¶

The state of a message is changed by appending a completion message to the spool as described in [draft-hallambaker-mesh-protocol].¶

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 message will be removed if the sequence is subsequently purged.¶

9.4.2. Four Corner Model

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¶

Figure 4: Four Corner Messaging Model

The outbound Mesh Service checks to see that the request to send a message 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. Services that fail to implement appropriate controls are likely to be subject to sanctions from either their users or from other services.¶

Figure 5: Performing Access Control on Outbound Messages

The inbound Mesh Service also checks to see that messages received are consistent with the service Acceptable Use Policy and the user's personal access control settings.¶

Mesh Services that fail to police abuse by their account holders SHOULD be subject to consequences in the same fashion as account holders.¶

Figure 6: Performing Access Control on Inbound Messages

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

11. Schema

11.1. Shared Classes

The following classes are used as common elements in Mesh profile specifications.¶

11.1.1. Classes describing keys

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

11.1.3. Structure: KeyShare

Inherits: Key
ServiceId: String (Optional): The identifier used to claim the capability from the service.[Only present for a partial key.]¶
ServiceAddress: String (Optional): The service account that supports a serviced capability. [Only present for a partial key.]¶

11.1.4. Structure: CompositePrivate

Inherits: Key
DeviceKeyUdf: String (Optional): UDF fingerprint of the bound device key (if used).¶

11.2. Assertion classes

Classes that are derived from an assertion.¶

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

11.2.2. Structure: Condition

Parent class from which all condition classes are derived.¶

[No fields]¶

11.2.3. Base Classes

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

11.2.4. Structure: Activation

Inherits: Assertion

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

ActivationKey: String (Optional): Secret seed used to derive keys that are not explicitly specified.¶
Entries: ActivationEntry [0..Many]: Activation of named account resource activations. These are separate from Application activations which are¶

11.2.5. Structure: ActivationEntry

Resource: String (Optional): Name of the activated resource¶
Key: KeyData (Optional): The activation key or key share¶
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.]¶

11.2.6. Mesh Profile Classes

Classes describing Mesh Profiles. All Profiles are Assertions derrived from Assertion.¶

11.2.7. Structure: Profile

Inherits: Assertion

Parent class from which all profile classes are derived¶

Description: String (Optional): Description of the profile¶
RootUdfs: Binary [0..Many]: A list of binary UDF fingerprints of accepted root signature keys for the profile. The profile finderprint is calculated over the concatenation of the fingerprint URIs.¶

11.2.8. Structure: ProfileDevice

Inherits: Profile

Describes a mesh device.¶

Encryption: KeyData (Optional): Base key contribution for encryption keys. Also used to decrypt activation data sent to the device during connection to an account.¶
Signature: KeyData (Optional): Base key contribution for signature keys.¶
Authentication: KeyData (Optional): Base key contribution for authentication keys. Also used to authenticate the device during connection to an account.¶

11.2.9. Structure: ProfileAccount

Base class for the account profiles ProfileUser and ProfileGroup. These subclasses may be merged at some future date.¶

Inherits: Profile
AccountAddress: String (Optional): The account address. This is either a DNS service address (e.g. [email protected]) or a Mesh Name (@alice).¶
ServiceUdf: String (Optional): The fingerprint of the service profile to which the account is currently bound.¶
EscrowEncryption: KeyData (Optional): Escrow key associated with the account.¶
AdministratorSignature: KeyData (Optional): Key used to sign connection assertions to the account.¶
CommonEncryption: KeyData (Optional): Key currently used to encrypt data under this profile¶
CommonAuthentication: KeyData (Optional): Key used to authenticate requests made under this user account. This key SHOULD NOT be provisioned to any device except for the purpose of enabling account recovery.¶

11.2.10. Structure: ProfileUser

Inherits: ProfileAccount

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

CommonSignature: KeyData (Optional): Key used to sign data under the account.¶

11.2.11. Structure: ProfileGroup

Inherits: ProfileAccount

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

Cover: Binary (Optional): HTML document containing cover text to be presented if a document encrypted under the group key cannot be decrypted.¶

11.2.12. Structure: ProfileService

Inherits: Profile

Profile of a Mesh Service¶

ServiceAuthentication: KeyData (Optional): Key used to authenticate service connections.¶
ServiceEncryption: KeyData (Optional): Key used to encrypt data under this profile¶
ServiceSignature: KeyData (Optional): Key used to sign data under the account.¶

11.2.13. Structure: ProfileMeshService

Inherits: ProfileService

Profile of a Mesh Service¶

[No fields]¶

11.2.14. Structure: ProfileHost

Inherits: ProfileDevice

Profile of a Mesh Host providing one or more Mesh Services.¶

[No fields]¶

11.2.15. Connection Assertions

Connection assertions are used to authenticate and authorize interactions between devices and the service currently servicing the account. They SHOULD NOT be visible to external parties.¶

11.2.16. Structure: Connection

Inherits: Assertion
Subject: String (Optional): UDF of the connection target.¶
Authority: String (Optional): UDF of the connection source.¶
Authentication: KeyData (Optional): The authentication key for use of the device under the profile¶

11.2.17. Structure: CallsignBinding

Inherits: Assertion
Canonical: String (Optional): The canonical form of the callsign.¶
Display: String (Optional): The display form of the callsign. This MAY include characters such as whitespace, trademark signifiers, etc. that are omitted of trranslated in the canonical form.¶
CharacterPage: String (Optional): Specifies the page to which the Description"CharacterPageLatin"¶
ProfileUdf: String (Optional): The profile to which the name is bound.¶
TransferUdf: String (Optional): The profile to which the name has been transfered.¶
Services: NamedService [0..Many]: List of named services. If multiple service providers are specified for a given service, these are listed in order of priority, most preferred first.¶
ServiceAddress: String (Optional): The Mesh service address.¶
CommonEncryption: KeyData (Optional): Key currently used to encrypt data under this profile¶

11.2.18. Structure: Accreditation

Registration of a trusted third party accreditation of a callsign/profile binding.¶

Callsign: String (Optional): The callsign to which the accreditation applies¶
ProfileUdf: String (Optional): The profile to which the accreditation applies.¶
SubjectNames: String [0..Many]: The validated names of the subject¶
SubjectLogos: String [0..Many]: Mesh strong URIs from which a validated logo belonging to the subject MAY be retreived and validated.¶
Issued: DateTime (Optional): The time the assertion was issued.¶
Expires: DateTime (Optional): The time the assertion is due to expire¶
Policy: String (Optional): The issuing policy under which the validation was performed.¶
Practice: String (Optional): The issuing practices under which the validation was performed.¶

11.2.19. Structure: ConnectionStripped

Asserts that a profile is connected to an account address.¶

Inherits: Connection

Stripped down connection assertion¶

Account: String (Optional): To be removed¶

11.2.20. Structure: ConnectionService

Inherits: Connection

Asserts that a device is connected to an account profile¶

ProfileUdf: String (Optional): The account address¶

11.2.21. Structure: ConnectionDevice

Inherits: ConnectionService

Asserts that a device is connected to an account profile¶

Roles: String [0..Many]
Signature: KeyData (Optional): The signature key for use of the device under the profile¶
Encryption: KeyData (Optional): The encryption key for use of the device under the profile¶

11.2.22. Structure: ConnectionApplication

Inherits: Connection

Connection assertion stating that a particular device is¶

[No fields]¶

11.2.23. Structure: ConnectionGroup

Describes the connection of a member to a group.¶

Inherits: Connection

[No fields]¶

11.2.24. Structure: AccountHostAssignment

Inherits: Assertion
AccountAddess: String (Optional): The account being bound¶
HostAddresses: String [0..Many]: Host address in Callsign, DNS or IP format in order of preference.¶
AccessEncrypt: KeyData (Optional): Encryption key to be used to encrypt data for the service to use.¶
CallsignServiceProfile: ProfileAccount (Optional): Profile of the callsign registry used by the service.¶
EnvelopedProfileService: Enveloped (Optional): Profile of the service.¶

11.2.25. Structure: ConnectionHost

Inherits: Connection

[No fields]¶

11.2.26. Activation Assertions

11.2.27. Structure: ActivationAccount

Contains activation data for device specific keys used in the context of a Mesh account.¶

Inherits: Activation
AccountUdf: String (Optional): The UDF of the account¶

11.2.28. Structure: ActivationHost

Contains activation data for device specific keys used in the context of a Mesh host¶

Inherits: ActivationAccount

[No fields]¶

11.2.29. Structure: ActivationCommon

Inherits: Activation
ProfileSignatures: KeyData [0..Many]: Grant access to profile online signing key used to sign updates to the profile.¶
AdministratorSignature: KeyData (Optional): Grant access to Profile administration key used to make changes to administrator catalogs.¶
Encryption: KeyData (Optional): Grant access to ProfileUser account encryption key¶
Authentication: KeyData (Optional): Grant access to ProfileUser account authentication key¶
Signature: KeyData (Optional): Grant access to ProfileUser account signature key¶

11.2.30. Structure: ActivationApplication

Inherits: Activation

[No fields]¶

11.2.31. Structure: ActivationApplicationSsh

Inherits: ActivationApplication
ClientKey: KeyData (Optional): The SSH client key.¶

11.2.32. Structure: ActivationApplicationMail

Inherits: ActivationApplication
SmimeSign: KeyData (Optional): The S/Mime signature key¶
SmimeEncrypt: KeyData (Optional): The S/Mime encryption key¶
OpenpgpSign: KeyData (Optional): The OpenPGP signature key¶
OpenpgpEncrypt: KeyData (Optional): The OpenPGP encryption key¶

11.2.33. Structure: ActivationApplicationGroup

Inherits: ActivationApplication
AccountEncryption: KeyData (Optional): Key or capability allowing account encryption keys to be created for new members.¶
AdministratorSignature: KeyData (Optional): Key or capability allowing account updates, connection assertions etc to be signed.¶
AccountAuthentication: KeyData (Optional): Key or capability allowing administration of the group.¶
EnvelopedConnectionService: Enveloped (Optional): Signed connection service delegation allowing the device to access the account.¶

11.3. Application Data

11.3.1. Structure: ApplicationEntry

Identifier: String (Optional)

11.3.2. Structure: ApplicationEntrySsh

Inherits: ApplicationEntry
EnvelopedActivation: Enveloped (Optional)

11.3.3. Structure: ApplicationEntryGroup

Inherits: ApplicationEntry
EnvelopedActivation: Enveloped (Optional)

11.3.4. Structure: ApplicationEntryMail

Inherits: ApplicationEntry
EnvelopedActivation: Enveloped (Optional)

11.4. Data Structures

Classes describing data used in cataloged data.¶

11.4.1. Structure: Contact

Inherits: Assertion

Base class for contact entries.¶

Id: String (Optional): The globally unique contact identifier.¶
Local: String (Optional): The local name.¶
Anchors: Anchor [0..Many]: Mesh fingerprints associated with the contact.¶
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.¶

11.4.2. Structure: Anchor

Trust anchor¶

Udf: String (Optional): The trust anchor.¶
Validation: String (Optional): The means of validation.¶

11.4.3. Structure: TaggedSource

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: Enveloped (Optional): The contact data in enveloped form. If present, the BinarySource property is ignored.¶

11.4.4. Structure: ContactGroup

Inherits: Contact

Contact for a group, including encryption groups.¶

[No fields]¶

11.4.5. Structure: ContactPerson

Inherits: Contact
CommonNames: PersonName [0..Many]: List of person names in order of preference¶

11.4.6. Structure: ContactOrganization

Inherits: Contact
CommonNames: OrganizationName [0..Many]: List of person names in order of preference¶

11.4.7. Structure: OrganizationName

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

11.4.8. Structure: PersonName

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

11.4.9. Structure: NetworkAddress

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. [email protected]¶
Protocol: String (Optional): The IANA protocol|identifier of the network protocols by which the contact may be reached using the specified Address.¶

11.4.10. Structure: NetworkCredential

Inherits: NetworkAddress
Type: String (Optional): The IANA credential type¶
Credential: Binary (Optional): The credential¶

11.4.11. Structure: NetworkProfile

Inherits: NetworkAddress
EnvelopedProfileAccount: Enveloped (Optional): The account profile¶

11.4.12. Structure: NetworkCapability

Inherits: NetworkProfile

[No fields]¶

11.4.13. Structure: NetworkProtocol

Protocol: String (Optional): The IANA protocol|identifier of the network protocols by which the contact may be reached using the specified Address.¶

11.4.14. Structure: Role

OrganizationName: String (Optional): The organization at which the role is held¶
Titles: String [0..Many]: The titles held with respect to that organization.¶
Locations: Location [0..Many]: Postal or physical addresses associated with the role.¶

11.4.15. Structure: Location

Appartment: String (Optional)
Street: String (Optional)
District: String (Optional)
Locality: String (Optional)
County: String (Optional)
Postcode: String (Optional)
Country: String (Optional)

11.4.16. Structure: Bookmark

Uri: String (Optional)
Title: String (Optional)
Role: String [0..Many]

11.4.17. Structure: Reference

MessageId: String (Optional): The received message to which this is a response¶
ResponseId: String (Optional): Message that was generated in response to the original (optional).¶
Relationship: String (Optional): The relationship type. This can be Read, Unread, Accept, Reject.¶

11.4.18. Structure: Engagement

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)

11.4.19. Structure: WorkTask

Inherits: Engagement
Dependency: String [0..Many]

11.5. Catalog Entries

11.5.1. Structure: CatalogedEntry

Base class for cataloged Mesh data.¶

Uid: String (Optional): Globaly unique identifier¶
LocalName: String (Optional): User specified identifier.¶
Path: String (Optional): The set of labels describing the entry¶
Description: String (Optional): Description¶

11.5.2. Structure: CatalogedDevice

Inherits: CatalogedEntry

Public device entry, indexed under the device ID Hello¶

Updated: DateTime (Optional): Timestamp, allows¶
Udf: String (Optional): UDF of the signature key of the device in the Mesh¶
Platform: String (Optional): Device Platform¶
DeviceUdf: String (Optional): UDF of the offline signature key of the device¶
SignatureUdf: String (Optional): UDF of the account online signature key¶
EnvelopedProfileUser: Enveloped (Optional): The Mesh profile. Why is this still here? This is not specific to the device.¶
EnvelopedProfileDevice: Enveloped (Optional): The device profile¶
DeviceDescription: DeviceDescription (Optional): Description of the device¶
EnvelopedConnectionService: Enveloped (Optional): Slim version of ConnectionDevice used by the presentation layer¶
EnvelopedConnectionDevice: Enveloped (Optional): The public assertion demonstrating connection of the Device to the Mesh¶
EnvelopedActivationAccount: Enveloped (Optional): The activation of the device within the Mesh account¶
EnvelopedActivationCommon: Enveloped (Optional): The activation of the device within the Mesh account¶

11.5.3. Structure: DeviceDescription

Idiom: String (Optional): The device form factor, valid values are Desktop, Phone, Tablet, TV, Watch¶
Manufacturer: String (Optional): Manufacturer name¶
Model: String (Optional): Manufacturer defined model¶
Name: String (Optional): Name of the device as specified by the user¶
Platform: String (Optional): The device platform or operating system: Android / iOS / macOS / Tizen / watchOS / Windows¶
Version: String (Optional): Platform version in format Major.Minor.Build.Revision¶
ImageLocator: String (Optional): EARL specifying an image of the device.¶

11.5.4. Structure: CatalogedSignature

Inherits: CatalogedEntry

Cataloged Signature¶

[No fields]¶

11.5.5. Structure: CatalogedDocument

A document stored on a service somewhere.¶

Inherits: CatalogedEntry
Udf: String (Optional): Document fingerprint.¶
Filename: String (Optional)
Title: String (Optional)
Version: String (Optional)
URI: String (Optional): Locator to be used to retrieve the data.¶
ContentType: String (Optional): IANA content type of the encoded content.¶
Encoding: String (Optional): Content encoding, typically DARE envelope.¶
Created: DateTime (Optional)
Updated: DateTime (Optional)
Length: Integer (Optional): Encoded document length in bytes.¶

11.5.6. Structure: CatalogedPublication

Inherits: CatalogedEntry

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. The data type is specified by the envelope metadata.¶
NotOnOrAfter: DateTime (Optional): Epiration time (inclusive)¶

11.5.7. Structure: CatalogedCredential

Inherits: CatalogedEntry
Protocol: String (Optional)
Service: String (Optional)
Username: String (Optional)
Password: String (Optional)
ClientAuthentication: KeyData [0..Many]: Specifies the client identification key¶
HostAuthentication: KeyData [0..Many]: Means of authenticating the host key¶

11.5.8. Structure: CatalogedNetwork

Inherits: CatalogedEntry
Protocol: String (Optional)
Service: String (Optional)
Username: String (Optional)
Password: String (Optional)

11.5.9. Structure: CatalogedContact

Inherits: CatalogedEntry
Key: String (Optional): Unique key.¶
Self: Boolean (Optional): If true, this catalog entry is for the user who created the catalog.¶

11.5.10. Structure: CatalogedAccess

Inherits: CatalogedEntry

[No fields]¶

11.5.11. Structure: Capability

Id: String (Optional): The identifier of the capability. If this is a cryptographic capability, this is the KeyIdentifier of the primary key that was shared. If this is an access capability, this is the KeyIdentifier of the authentication key being authorized for access.¶
Active: Boolean (Optional)
Issued: Integer (Optional)
Mode: String (Optional): The authentication mode: Device, Account, PIN¶
Udf: String (Optional): Identifies the authentication credential. For a device, this is the authentication key identifier, for an account, the profile identifier, for a PIN, the locator value of the PIN.¶
Witness: String (Optional): The verification value used to perform proof of knowledge of the secret.¶

11.5.12. Structure: NullCapability

Inherits: Capability

[No fields]¶

11.5.13. Structure: AccessCapability

Inherits: Capability
Rights: String [0..Many]: Access rights associated with the key¶
EnvelopedCatalogedDevice: Enveloped (Optional)
CatalogedDeviceDigest: String (Optional): Digest value used to signal updates to envelope¶

11.5.14. Structure: PublicationCapability

Inherits: Capability
Identifier: String (Optional): Selector allowing a specific document to be requested.¶
Digest: String (Optional): Document digest, this allows a status/claim request to request an update to be returned only if the document has changed.¶
Data: Binary (Optional): The published document.¶

11.5.15. Structure: CryptographicCapability

Inherits: Capability
KeyData: KeyData (Optional): The key that enables the capability¶
GranteeAccount: String (Optional)
GranteeUdf: String (Optional)
EnvelopedKeyShare: Enveloped (Optional): One or more enveloped key shares.¶

11.5.16. Structure: CapabilityDecrypt

Inherits: CryptographicCapability

The corresponding key is a decryption key¶

[No fields]¶

11.5.17. Structure: CapabilityDecryptPartial

Inherits: CapabilityDecrypt

The corresponding key is an encryption key¶

[No fields]¶

11.5.18. Structure: CapabilityDecryptServiced

Inherits: CapabilityDecrypt

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

11.5.19. Structure: CapabilitySign

Inherits: CryptographicCapability

The corresponding key is an administration key¶

[No fields]¶

11.5.20. Structure: CapabilityKeyGenerate

Inherits: CryptographicCapability

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

[No fields]¶

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

11.5.22. Structure: NamedService

Prefix: String (Optional): The IANA service name (e.g. dns)¶
Mapping: String (Optional): Optional name mapping, (e.g. [email protected] -> alice.mesh)¶
Endpoints: String [0..Many]: The service endpoints. This MAY be specified as a callsign (@alice), a DNS address (example.com), an IP address (10.0.0.1) or a fully qualified URI.¶

11.5.23. Structure: ServiceAccessToken

Inherits: NamedService
Token: Binary (Optional): Session initiation token¶
SharedSecret: Binary (Optional): Session shared secret¶

11.5.24. Structure: CatalogedBookmark

Inherits: CatalogedEntry
Uri: String (Optional)
Title: String (Optional)
Comments: String [0..Many]: User comments on bookmark entry¶

11.5.25. Structure: CatalogedTask

Inherits: CatalogedEntry
Title: String (Optional)
EnvelopedTask: Enveloped (Optional)

11.5.26. Structure: CatalogedApplication

Inherits: CatalogedEntry
Default: Integer (Optional)
Key: String (Optional)
Grant: String [0..Many]
Deny: String [0..Many]
EnvelopedCapabilities: DareEnvelope [0..Many]: Enveloped keys for use with Application¶
EnvelopedEscrow: Enveloped [0..Many]: Escrow entries for the application.¶

11.5.27. Structure: CatalogedMember

ContactAddress: String (Optional)
MemberCapabilityId: String (Optional)
ServiceCapabilityId: String (Optional)
Inherits: CatalogedEntry

11.5.28. Structure: CatalogedGroup

Inherits: CatalogedApplication
EnvelopedConnectionAddress: Enveloped (Optional): The connection allowing control of the group.¶
EnvelopedProfileGroup: Enveloped (Optional): The Mesh profile¶
EnvelopedActivationCommon: Enveloped (Optional): The activation of the device within the Mesh account¶

11.5.29. Structure: CatalogedFeed

Inherits: CatalogedBookmark
Protocol: String (Optional)

11.5.30. Structure: CatalogedApplicationMail

Inherits: CatalogedApplication
AccountAddress: String (Optional)
InboundConnect: String (Optional)
OutboundConnect: String (Optional)
SmimeSign: KeyData (Optional): The S/Mime signature key¶
SmimeEncrypt: KeyData (Optional): The S/Mime encryption key¶
OpenpgpSign: KeyData (Optional): The OpenPGP signature key¶
OpenpgpEncrypt: KeyData (Optional): The OpenPGP encryption key¶

11.5.31. Structure: CatalogedApplicationPkix

Inherits: CatalogedApplication

[No fields]¶

11.5.32. Structure: CatalogedApplicationOpenPgp

Inherits: CatalogedApplication

[No fields]¶

11.5.33. Structure: CatalogedApplicationSsh

Inherits: CatalogedApplication
ClientKey: KeyData (Optional): The S/Mime encryption key¶

11.5.34. Structure: CatalogedApplicationGit

Inherits: CatalogedApplication

[No fields]¶

11.5.35. Structure: CatalogedApplicationDeveloper

Inherits: CatalogedApplication

[No fields]¶

11.5.36. Structure: MessageInvoice

Inherits: Message

[No fields]¶

11.5.37. Structure: CatalogedReceipt

Inherits: CatalogedEntry

[No fields]¶

11.5.38. Structure: CatalogedTicket

Inherits: CatalogedEntry

[No fields]¶

11.6. Publications

11.6.1. Structure: DevicePreconfigurationPublic

EnvelopedProfileDevice: Enveloped (Optional): The device profile¶
Hailing: String [0..Many]: A list of URIs specifying hailing transports that may be used to initiate a connection to the device. This allows a device to specify that it can be reached by WiFi transport to a particular private SSID, or by Bluetooth, IR etc. etc.¶

11.6.2. Structure: DevicePreconfigurationPrivate

Inherits: DevicePreconfigurationPublic

A data structure that is passed¶

EnvelopedConnectionDevice: Enveloped (Optional): The device connection¶
EnvelopedConnectionService: Enveloped (Optional): The device connection¶
ConnectUri: String (Optional): The connection URI. This would normally be printed on the device as a QR code.¶

11.7. Messages

11.7.1. Structure: Message

MessageId: String (Optional): Unique per-message ID. When encapsulating a Mesh Message in a DARE envelope, the envelope EnvelopeID field MUST be a UDF fingerprint of the MessageId value.¶
Sender: String (Optional)
Recipient: String (Optional)

11.7.2. Structure: MessageError

Inherits: Message
ErrorCode: String (Optional)

11.7.3. Structure: MessageComplete

Inherits: Message
References: Reference [0..Many]

11.7.4. Structure: MessageValidated

Inherits: Message
AuthenticatedData: DareEnvelope (Optional): Enveloped data that is authenticated by means of the PIN¶
ClientNonce: Binary (Optional): Nonce provided by the client to validate the PIN¶
PinId: String (Optional): Pin identifier value calculated from the PIN code, action and account address.¶
PinWitness: Binary (Optional): Witness value calculated as KDF (Device.Udf + AccountAddress, ClientNonce)¶

11.7.5. Structure: MessagePin

Account: String (Optional)
Inherits: Message
Expires: DateTime (Optional)
Automatic: Boolean (Optional): If true, authentication against the PIN code is sufficient to complete the associated action without further authorization.¶
SaltedPin: String (Optional): PIN code bound to the specified action.¶
Action: String (Optional): The action to which this PIN code is bound.¶
Roles: String [0..Many]: The set of rights bound to the PIN grant.¶

11.7.6. Structure: RequestConnection

Connection request message. This message contains the information¶

Inherits: MessageValidated
AccountAddress: String (Optional)

11.7.7. Structure: AcknowledgeConnection

Connection request message generated by a service on receipt of a valid MessageConnectionRequestClient¶

Inherits: Message
EnvelopedRequestConnection: Enveloped (Optional): The client connection request.¶
ServerNonce: Binary (Optional)
Witness: String (Optional)

11.7.8. Structure: RespondConnection

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

11.7.9. Structure: MessageContact

Inherits: MessageValidated
Reply: Boolean (Optional): If true, requests that the recipient return their own contact information in reply.¶
Subject: String (Optional): Optional explanation of the reason for the request.¶
PIN: String (Optional): One time authentication code supplied to a recipient to allow authentication of the response.¶