| Internet-Draft | Mesh Schema Reference | January 2020 |
| Hallam-Baker | Expires 19 July 2020 | [Page] |
The Mathematical Mesh 'The Mesh' is an end-to-end secure infrastructure that facilitates the exchange of configuration and credential data between multiple user devices. The core protocols of the Mesh are described with examples of common use cases and reference data.¶
[Note to Readers]¶
Discussion of this draft takes place on the MATHMESH mailing list (mathmesh@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=mathmesh.¶
This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh-schema.html.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 19 July 2020.¶
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
This document describes the data structures of the Mathematical Mesh with illustrative examples. For an overview of the Mesh objectives and architecture, consult the accompanying Architecture Guide [draft-hallambaker-mesh-architecture]. For information on the implementation of the Mesh Service protocol, consult the accompanying Protocol Reference [draft-hallambaker-mesh-protocol]¶
This document has two main sections. The first section presents examples of the Mesh assertions, catalog entry and messages in use. The second section contains the schema reference. All the material in both sections is generated from the Mesh reference implementation [draft-hallambaker-mesh-developer].¶
Although some of the services described in this document could be used to replace existing Internet protocols including FTP and SMTP, the principal value of any communication protocol lies in the size of the audience it allows them to communicate with. Thus, while the Mesh Messaging service is designed to support efficient and reliable transfer of messages ranging in size from a few bytes to multiple terabytes, the near-term applications of these services will be to applications that are not adequately supported by existing protocols if at all.¶
This section presents the related specifications and standard, the terms that are used as terms of art within the documents and the terms used as requirements language.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].¶
The terms of art used in this document are described in the Mesh Architecture Guide [draft-hallambaker-mesh-architecture].¶
The implementation status of the reference code base is described in the companion document [draft-hallambaker-mesh-developer].¶
Mesh Assertions are signed DARE Envelopes that contain one of more claims. Mesh Assertions provide the basis for trust in the Mathematical Mesh.¶
Mesh Assertions are divided into two classes. Mesh Profiles are self-signed assertions. Assertions that are not self-signed are called declarations. The only type of declaration currently defined is a Connection Declaration describing the connection of one profile to another. Currently, five profile and four connection types are defined:¶
The payload of a Mesh Assertion is a JSON encoded object that is a subclass of the Assertion class which defines the following fields:¶
An identifier for the assertion.¶
The date and time at which the assertion was issued or last updated¶
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.¶
A list of conditions that MAY be used to verify the status of the assertion if the relying party requires.¶
The implementation of the NotaryToken and Conditions mechanisms is to be specified in [draft-hallambaker-mesh-notary] at a future date.¶
Note that the implementation of Conditions differs significantly from that of SAML. Relying parties are required to process condition clauses in a SAML assertion to determine validity. Mesh Relying parties MAY verify the conditions clauses or rely on the trustworthiness of the provider.¶
The reason for weakening the processing of conditions clauses in the Mesh is that it is only ever possible to validate a conditions clause of any type relative to a ground truth. In SAML applications, the relying party almost invariably has access to an independent source of ground truth. A Mesh device connected to a Mesh Service does not. Thus the types of verification that can be achieved in practice are limited to verifying the consistency of current and previous statements from the Mesh Service.¶
Mesh Profiles perform a similar role to X.509v3 certificates but with important differences:¶
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:¶
SignatureKey field.¶
SignatureKey field.¶
A profile has the status current if and only if:¶
The Mesh architecture has four principal components:¶
Binds a collection of devices that the owner of the Mesh uses together to function as a single personal Mesh.¶
Contains all the information (contacts, calendar entries, inbound and outbound messages, etc.) related to a particular persona used by the owner.¶
Provides a service identifier (e.g. alice@example.com) through which devices and other Mesh users may interact with a Mesh Account.¶
Allows short messages (less than 32KB) to be exchanged between Mesh devices connected to an account and between Mesh Accounts.¶
Device management and Accounts components are defined by a data schema alone. The Service and Messaging components are defined by a data schema and a service protocol.¶
The separation of accounts and services as separate components is a key distinction between the Mesh and earlier Internet applications. A Mesh account belongs to the owner of the Mesh and not the account service provider which the user may change at any time of their choosing. A Mesh account may be connected to multiple service providers to provide backup capability or to none.¶
For example, Alice's personal Mesh has one Master Profile, multiple device profiles (two of which are shown here) and two Account Profiles. Her Personal account is connected to two Mesh services while her Business account is not currently connected to any service:¶
In normal circumstances, a user will create a personal Mesh and add their first device, account and service at once. These are shown here as separate operations to illustrate the separation of the Mesh components.¶
Device Management provides the foundation for all Mesh functions allowing a collection of devices belonging to a user to function as a single personal Mesh.¶
The device management layer of a personal Mesh consists of exactly one Master Profile and a catalog containing the entries describing the connected devices.¶
A Mesh master profile provides the axiom of trust for a mesh user. It contains a Master Signature Key and one or more Administration Signature Keys. The unique identifier of the master profile is the UDF of the Master Signature Key.¶
A Master Profile MAY contain one or more MasterEscrowKeys. These MAY be used to escrow private keys used for encryption. They SHOULD NOT be used to escrow authentication keys and MUST NOT be used to escrow signature keys.¶
A user should not need to replace their master profile unless they intend to establish a separate identity. To minimize the risk of disclosure, the Master Signature Key is only ever used to sign updates to the master profile itself. This allows the user to secure their Master Signature Key by either keeping it on hardware token or device dedicated to that purpose or by using the escrow mechanism and paper recovery keys as described in this document.¶
Alice creates a ProfileMaster with one administration key and one master escrow key:¶
{
"ProfileMesh":{
"KeyOfflineSignature":{
"UDF":"MCSC-2POG-PH7T-ODJX-HOCA-B4XY-AFSK",
"PublicParameters":{
"PublicKeyECDH":{
"crv":"Ed448",
"Public":"AqOm-eLsUPySPkemMvVIJctXUSTa6EC5c_w0kLHZCh4xLlF
ow4SJzsDj2xSX5ofUl1XcuCBj9qaA"}}},
"KeysOnlineSignature":[{
"UDF":"MDI7-LMMT-LTJE-6C5Z-AFZN-6OXW-YLW3",
"PublicParameters":{
"PublicKeyECDH":{
"crv":"Ed448",
"Public":"tQhM2lUiBnKgk9PASigebdZH18nDC4qFSZIJgmwTPYrpd
AKsSnuZPH7UPu3AtYjFF8aGMyyF8UuA"}}}
],
"KeyEncryption":{
"UDF":"MATS-37J5-26DG-MYUR-7BMU-PPJJ-UUO4",
"PublicParameters":{
"PublicKeyECDH":{
"crv":"Ed448",
"Public":"SUJNzpDLHT9dxOyYdzfuhPL0mkR1tw-JTjuIVgU7X-bFqi2
z66efQv1cwSeVL-oZn2COpIHN-lKA"}}}}}¶
Creating a ProfileMaster comprises the steps of:¶
ProfileMaster using the Master Signature Key¶
ProfileMaster on the administration device to the CatalogHost.¶
ActivationAdministration activation.¶
Updating a ProfileMaster comprises the steps of:¶
Each personal Mesh has a Device Catalog CatalogDevice associated with it. The Device Catalog is used to manage the connection of devices to the Personal Mesh and has a CatalogEntryDevice for each device currently connected to the catalog.¶
Each Administration Device MUST have access to an up to date copy of the Device Catalog in order to manage the devices connected to the Mesh. The Mesh Service protocol MAY be used to synchronize the Device Catalog between administration devices in the case that there is more than one administration device.¶
The CatalogEntryDevice contains fields for the device profile, device private and device connection.¶
The principle of radical distrust requires us to consider the possibility that a device might be compromised during manufacture. Once consequence of this possibility is that when an administration device connects a new device to a user's personal Mesh, we cannot put our full trust in either the device being connected or the administration device connecting it.¶
This concern is resolved by (at minimum) combining keying material generated from both sources to create the keys to be used in the context of the user's personal Mesh with the process being fully verified by both parties.¶
Additional keying material sources could be added if protection against the possibility of compromise at both devices was required but this is not supported by the current specifications.¶
A device profile provides the axiom of trust and the key contributions of the device:¶
Unless exceptional circumstances require, a device should not require more than one Device profile even if the device supports use by multiple users under different accounts. But a device MAY have multiple profiles if this approach is more convenient for implementation.¶
Alice's Device Profile specifies keys for encryption, signature and exchange:¶
{
"ProfileDevice":{
"KeyOfflineSignature":{
"UDF":"MCYS-TOQJ-CDAX-EDU7-6EZ3-OLPG-KMLG",
"PublicParameters":{
"PublicKeyECDH":{
"crv":"Ed448",
"Public":"m54L_jENmDdwE9vFeDZgBuJHbV3HTZxWr6Ep-tVdQhudcpw
25rOBvp6l5OhKbNUfoKRWFKTS93qA"}}},
"KeyEncryption":{
"UDF":"MCZP-AMNO-JHWY-ZQ22-N3ZP-V2KW-52JE",
"PublicParameters":{
"PublicKeyECDH":{
"crv":"Ed448",
"Public":"W-E1XmOgjze4ozrhkkft5nV_Zcr90En9vT6WswBe3VBCrxW
RKGI48Ud9EWSDlJfEqQWRbhMyZp0A"}}},
"KeyAuthentication":{
"UDF":"MDYO-XAHJ-RXT6-YO4J-X7WV-L3IW-5NEP",
"PublicParameters":{
"PublicKeyECDH":{
"crv":"Ed448",
"Public":"OlJMs9_Dcm7XuFzvbypI5WC3xLLgPOjohsg5dkqA61gCfsF
9J4syqcZnOFrAsk-pFWFDm0DESoAA"}}}}}¶
Since the Device Profile keys are ultimately under the control of the device and/or software provider, these are considered insufficiently trustworthy and the administration device creates key contributions to be added to the device keys to establish the key set to be used in the context of the user's personal Mesh:¶
$$$$ Empty $$$$¶
The resulting key set is specified in the device connection:¶
{
"ConnectionDevice":{
"KeySignature":{
"UDF":"MBPL-MIIT-KOHN-FC6P-6V5Y-ZQ4R-3NKY",
"PublicParameters":{
"PublicKeyECDH":{
"crv":"Ed448",
"Public":"D-g5vilsBjZ_6BKRG9O3cl30IrN3hCGNzVO_C6YT5OkOkVC
IO47FRho9xdoJ8zCcH938WlTDBLeA"}}},
"KeyEncryption":{
"UDF":"MBLY-KNQG-YT6V-ENLJ-KMIT-MRYT-YOHQ",
"PublicParameters":{
"PublicKeyECDH":{
"crv":"Ed448",
"Public":"aEe3u24gwMh-ygY0HqjVbBxzFEYJyPVhB_h1-Ma3F_nz6Ae
vA0fSMaJKprA-qv-JpHSsMCbA74iA"}}},
"KeyAuthentication":{
"UDF":"MDVV-QJE7-UYR4-24TQ-JK54-QDTU-BZF3",
"PublicParameters":{
"PublicKeyECDH":{
"crv":"Ed448",
"Public":"kV_ODrLu4jWdT0hJibnEcujjxu-E4ofRlI7o2eyy3eSbGaA
EES0KYv5N8BaawmWP67athBZZDjeA"}}}}}¶
All the above are combined to form the CatalogedDevice entry:¶
{
"CatalogedDevice":{
"UDF":"MBPL-MIIT-KOHN-FC6P-6V5Y-ZQ4R-3NKY",
"DeviceUDF":"MCYS-TOQJ-CDAX-EDU7-6EZ3-OLPG-KMLG",
"EnvelopedProfileDevice":[{
"dig":"SHA2"},
"ewogICJQcm9maWxlRGV2aWNlIjogewogICAgIktleU9mZmxpbmVTaWduYXR1
cmUiOiB7CiAgICAgICJVREYiOiAiTUNZUy1UT1FKLUNEQVgtRURVNy02RVozLU9MU
EctS01MRyIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdW
JsaWNLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6ICJFZDQ0OCIsCiAgICAgICA
gICAiUHVibGljIjogIm01NExfakVObURkd0U5dkZlRFpnQnVKSGJWM0hUWnhXcjZF
cC10VmRRaHVkY3B3MjVyT0IKICB2cDZsNU9oS2JOVWZvS1JXRktUUzkzcUEifX19L
AogICAgIktleUVuY3J5cHRpb24iOiB7CiAgICAgICJVREYiOiAiTUNaUC1BTU5PLU
pIV1ktWlEyMi1OM1pQLVYyS1ctNTJKRSIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJ
zIjogewogICAgICAgICJQdWJsaWNLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6
ICJFZDQ0OCIsCiAgICAgICAgICAiUHVibGljIjogIlctRTFYbU9nanplNG96cmhra
2Z0NW5WX1pjcjkwRW45dlQ2V3N3QmUzVkJDcnhXUktHSTQKICA4VWQ5RVdTRGxKZk
VxUVdSYmhNeVpwMEEifX19LAogICAgIktleUF1dGhlbnRpY2F0aW9uIjogewogICA
gICAiVURGIjogIk1EWU8tWEFISi1SWFQ2LVlPNEotWDdXVi1MM0lXLTVORVAiLAog
ICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgICAiUHVibGljS2V5RUNES
CI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICAgICAgIlB1YmxpYy
I6ICJPbEpNczlfRGNtN1h1Rnp2YnlwSTVXQzN4TExnUE9qb2hzZzVka3FBNjFnQ2Z
zRjlKNHN5CiAgcWNabk9GckFzay1wRldGRG0wREVTb0FBIn19fX19",
{
"signatures":[{
"alg":"SHA2",
"kid":"MCYS-TOQJ-CDAX-EDU7-6EZ3-OLPG-KMLG",
"signature":"9uexE_-IFBMWisUSR9xLXgJskkYDoYnbXVONBUR0NV
P5vC5_N2-m4uXUkpN1ClBKcDPhQmX0tk0AjY-xZhrTpdB9GjQmiBSyCGsl5I0VBAh
y9ogTegiNXyYznYw6cukAHrcRH7_h2dFsv2_WFT8OWTEA"}
],
"PayloadDigest":"Eo6k0vBBU9dfLJA0MTEt87qdGpzCMJi4PEFOxE9w5a
2AaC3izRZYoobWz0fJ5vjwLEfte-_ggv9wKc8GcITekw"}
],
"EnvelopedConnectionDevice":[{
"dig":"SHA2"},
"ewogICJDb25uZWN0aW9uRGV2aWNlIjogewogICAgIktleVNpZ25hdHVyZSI6
IHsKICAgICAgIlVERiI6ICJNQlBMLU1JSVQtS09ITi1GQzZQLTZWNVktWlE0Ui0zT
ktZIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0
tleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIkVkNDQ4IiwKICAgICAgICAgICJ
QdWJsaWMiOiAiRC1nNXZpbHNCalpfNkJLUkc5TzNjbDMwSXJOM2hDR056Vk9fQzZZ
VDVPa09rVkNJTzQ3RgogIFJobzl4ZG9KOHpDY0g5MzhXbFREQkxlQSJ9fX0sCiAgI
CAiS2V5RW5jcnlwdGlvbiI6IHsKICAgICAgIlVERiI6ICJNQkxZLUtOUUctWVQ2Vi
1FTkxKLUtNSVQtTVJZVC1ZT0hRIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB
7CiAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIkVk
NDQ4IiwKICAgICAgICAgICJQdWJsaWMiOiAiYUVlM3UyNGd3TWgteWdZMEhxalZiQ
nh6RkVZSnlQVmhCX2gxLU1hM0Zfbno2QWV2QTBmUwogIE1hSktwckEtcXYtSnBIU3
NNQ2JBNzRpQSJ9fX0sCiAgICAiS2V5QXV0aGVudGljYXRpb24iOiB7CiAgICAgICJ
VREYiOiAiTURWVi1RSkU3LVVZUjQtMjRUUS1KSzU0LVFEVFUtQlpGMyIsCiAgICAg
ICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdWJsaWNLZXlFQ0RIIjoge
wogICAgICAgICAgImNydiI6ICJFZDQ0OCIsCiAgICAgICAgICAiUHVibGljIjogIm
tWX09Eckx1NGpXZFQwaEppYm5FY3Vqanh1LUU0b2ZSbEk3bzJleXkzZVNiR2FBRUV
TMEsKICBZdjVOOEJhYXdtV1A2N2F0aEJaWkRqZUEifX19fX0",
{
"signatures":[{
"alg":"SHA2",
"kid":"MDI7-LMMT-LTJE-6C5Z-AFZN-6OXW-YLW3",
"signature":"R51-7cQTb4f2nK69t77YamP7ny0i9TOw0CdXl0X3dp
vgSiZ2I1OWbxncJqqkOpj7AW5e7uiOBumAc0j3tiWXSwKIQZAtoUsGvcYFY2Yq11K
OHC9kMS4ea2Hcu0IMd8tpoIglnJC38ajl_pFBCbrJVAAA"}
],
"PayloadDigest":"Td9sSenLRJHoZ0YtbwztmpadlzOv2AVb9JtOCgnuiX
X1xwkuJ5KYAAlOoSusI6pyT1iM6TtYYh0hpCSEooizgg"}
],
"EnvelopedActivationDevice":[{
"enc":"A256CBC",
"Salt":"Wv42VzJRlBdLKIqwODqHYg",
"recipients":[{
"kid":"MCZP-AMNO-JHWY-ZQ22-N3ZP-V2KW-52JE",
"epk":{
"PublicKeyECDH":{
"crv":"Ed448",
"Public":"80ofnf812P3naGy_KG6a1IUAdQKcZ9fF5TKZ8q8yR
ZsWn870qm1QKgXYxOz82RpWKEqGHGdWEYcA"}},
"wmk":"_-0e3rNNbEIvH8zjSe1tBz84FEg71dzdhHJnfQvbteecigqM
sZaFZA"},
{
"kid":"MATS-37J5-26DG-MYUR-7BMU-PPJJ-UUO4",
"epk":{
"PublicKeyECDH":{
"crv":"Ed448",
"Public":"Y64tNqhJuEREoAm3pFqXSQqBdbmN7qPhmnKKmwOWh
VnVxVvBuRFjAwM6HuVpgLa53kK3Ucl7uCsA"}},
"wmk":"G3nEbaXRHIgdaXcx-DyKXuOA1QXKG-coa4q3urbu6L4bti4c
uI5_og"}
],
"ContentMetaData":"ewogICJjdHkiOiAiYXBwbGljYXRpb24vbW1tIn0"},
"xq7fBwbgcYBrqZgcleQhT92CfS5uLMEO2xAbhr2c4clU0i6tX67Z-sx5opqd
MrSDHGuaDUShWce9JhSwBomvs_8un_0V9vhqwV5gSP_fTsvSU2nnCBT0ziEk19B5z
57AsGwAWL9lTa9kX3M6AfF92UIog4vZGTHrJ_m1yLJc_etVBAeL4GF_M9_LSZ4zjf
eZZGSwOBwQKGSWGqCfEdWRec0OZ_q4WUg3Fh6NyrdG8kaUwkF3EYgfBhN2OyLQ7oH
ybuQs-J2w_m_ev79C-o0eUYz8TJQTLeYpQb3cFmXkD71BLqBn0nWBp4BeR73UMWoo
Nv1OkyHw9HXmreaDeCOeWWqZsfNqE47xvNX1DWbwlxBYMJLqoz3y_XUSTaQFJqa1s
uX_c7ZhtbXDVEWyDFBOayf64r68LDbAI-1yVEpcBF8h9XwBvZnGXyC5iUzFGCL0WY
MlH1oC8JU8rG3kp12pDhaGR0V8OHJ6C_AL1mk2Wm39XqZFOTjIy7KJM69EN-U4MNx
-ph8Pil78inOTcfUCNffepP5XGbeNO0pse1Og35eiGnZFLf9yRB_iZtQwJmMsEZ0p
sW8qXp7vnYd2Qk5vwAmizYqRZ7oViTVotGHHgvNRTliuJgmTGHRlYYUxlsH3lUxDv
5UHJzSBKiXK5g4a3Vf5I10qaFLi2V0Gh3P-MkEXyvrcRGZVkix8K6mLYIVzZueskl
hJ28M-WlattxnV4Kdjd_0Q85HZLoKlsJryf7VUDBzfrtpoCKH19r2BWBLCC-HlsTx
NN0CArNk_Lt7FXxuAuKnB0jAPOmZhjbP2W13gP6B3IsTZQon9EGgEEWLwThyGZmh3
DwTQscUUc0tz5Gu5KywANKqXpjbhrPS-vRPogByOLAa2u_gzeCuSq6RqTva0-dCgb
gFMkqZic25BqO9BpmTmnLKTOumhGhKA2r2aNfhMeQp12wpH3zLfNsYHwTUwQj--KJ
CRgRlYt6lVBs-9U8BEgcWI_bThDod3d-CNuU7A0IveifojNeUScA9UniJPjympL1P
Q953B46-nb8Y7LodudjuEbbmJxcTzlg6Rao66oMo0rGDeEyxb0RaYPQ41gKqAi1MM
bBc80flGgxdlN4nGPYXtyQBCZQJ0Rlk-1nWujdf6LoCBg_-dpteR54N9o_Mc-aNsP
i_FpdSVrGweQp6HpoQuwpXOncHyMG257iCxZN0Fev-nviLkXn8JA_iJ72vvJzHZMH
J33XOhFlbvwDIN5g4Drn448i0t9u_G5n--3kN9nt916fUFM6tq"
],
"Accounts":[{
"AccountUDF":"MC23-X3CT-EUNB-DR3M-QIBI-W2IJ-ATEP",
"EnvelopedProfileAccount":[{
"dig":"SHA2"},
"ewogICJQcm9maWxlQWNjb3VudCI6IHsKICAgICJLZXlPZmZsaW5lU2ln
bmF0dXJlIjogewogICAgICAiVURGIjogIk1DMjMtWDNDVC1FVU5CLURSM00tUUlCS
S1XMklKLUFURVAiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgIC
AiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICA
gICAgICAgIlB1YmxpYyI6ICI5dXBQMWlhazMwX0pyRzFwZVl3aGtUMDBEcHc4SjBq
d0dRQTBuZWhuQlZQdU9hRzloNlNzCiAgRmUwRGV6MmIzYVFwbGRBR1VLb1VCZENBI
n19fSwKICAgICJLZXlzT25saW5lU2lnbmF0dXJlIjogW3sKICAgICAgICAiVURGIj
ogIk1DUlItSkZMWi1UMkpILUlOR0QtU0JZRi1OTzZYLTU1Uk4iLAogICAgICAgICJ
QdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7
CiAgICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICAgICAgICAiUHVibGljI
jogIkZfTUpmMHc4ZFVIaVBZeTk3WEtRbXBmRlZMbk5uZHNqUUg1cDFjM3ozSGxucV
RhMmE3YkUKICBVQ09veGE0SEFpc2Y5QnFueEpFZE9tZ0EifX19XSwKICAgICJNZXN
oUHJvZmlsZVVERiI6ICJNQ1NDLTJQT0ctUEg3VC1PREpYLUhPQ0EtQjRYWS1BRlNL
IiwKICAgICJLZXlFbmNyeXB0aW9uIjogewogICAgICAiVURGIjogIk1CV1ktSUlLW
S1WT0I1LUJYSVAtRElYWC1SNFRILVpJRjIiLAogICAgICAiUHVibGljUGFyYW1ldG
VycyI6IHsKICAgICAgICAiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnY
iOiAiRWQ0NDgiLAogICAgICAgICAgIlB1YmxpYyI6ICJzd3BlNkg1eWlVNHZKb3Ri
b1hiRnd3SUVwX2xYTy1rYm05emo5UE9GTEx3ZnFlNkJVTXN1CiAgOUZCQ0w2R0hwO
TN3Y21MTTI3dEdSbjRBIn19fX19",
{
"signatures":[{
"alg":"SHA2",
"kid":"MC23-X3CT-EUNB-DR3M-QIBI-W2IJ-ATEP",
"signature":"xBUh419PqcBn2XAGToSaPRxDiUJSEABsZubx-z
OaEqZsotZceYNIj6h2axaL0ZsJAwO3vPNCgCOAbX6LLqeJk4qheJ5FLmZ53_T66gD
PqaTIE0NhFp8ulQuDE0aAvU0eH7vPV1HhqUMaQMc-lZGPQCUA"}
],
"PayloadDigest":"aXMNPb2KrzIznCZVP28IrDLCOsVirh1Oy_VRZc
sqX0Y3JMuCTXOJ8BpIMc_bjer2T8a4m0e5SzYoRe4S-gXP6w"}
],
"EnvelopedConnectionAccount":[{
"dig":"SHA2"},
"ewogICJDb25uZWN0aW9uQWNjb3VudCI6IHsKICAgICJTdWJqZWN0VURG
IjogIk1DWkwtTVFPQS1YTFlVLVJMUFctVlJSSC02VUZELUtESUUiLAogICAgIkF1d
Ghvcml0eVVERiI6ICJNQzIzLVgzQ1QtRVVOQi1EUjNNLVFJQkktVzJJSi1BVEVQIi
wKICAgICJLZXlTaWduYXR1cmUiOiB7CiAgICAgICJVREYiOiAiTUNaTC1NUU9BLVh
MWVUtUkxQVy1WUlJILTZVRkQtS0RJRSIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJz
IjogewogICAgICAgICJQdWJsaWNLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6I
CJFZDQ0OCIsCiAgICAgICAgICAiUHVibGljIjogImFDdnlmT2d1YVlBRm5XeTlfNX
JYdy1rY0U0NWtNWGsyWGRtMkt0VWVWSjhnVkpTakQwZHIKICBMUzZpQ3J4SFBWdUl
hb0lGNW84UWhnVUEifX19LAogICAgIktleUF1dGhlbnRpY2F0aW9uIjogewogICAg
ICAiVURGIjogIk1DTDQtS1JCNC1QTVROLTNDTEktVVBGWi1NVjJaLTZUVUciLAogI
CAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgICAiUHVibGljS2V5RUNESC
I6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICAgICAgIlB1YmxpYyI
6ICJpR0Y0X19vRk9PWVotVm5QZHFoQlZ4bEVpTEF4UllQRnNRLVlxclVJdTVlbXlF
cjRXUlBMCiAgLTl6M2VMMmQ5SXgwSm9raUI3RUYyRm9BIn19fX19",
{
"signatures":[{
"alg":"SHA2",
"kid":"MCRR-JFLZ-T2JH-INGD-SBYF-NO6X-55RN",
"signature":"DXZyUQa06ki6HuDtd7ooofkLlX6_d341Gq0YD8
3sLOVFcKwP-C12JWOBRcp_iVdd_tlx94nkrqWAH9ZI6__XrfavdqFWbrkl9kLCQi5
mpisnx9zxOTZ_0a_kE7KAnjl7SoSV5G7Z9MqlWhZ1OVCmyR0A"}
],
"PayloadDigest":"eKZx9Y5JQGXuaXE1o1BfwSqeDRX0h4VYUWZZIT
_wFfh391cZxAp3x5GSiex1vMw4oy_I1oKLC7QdKxthACTz2Q"}
],
"EnvelopedActivationAccount":[{
"dig":"SHA2"},
"ewogICJBY3RpdmF0aW9uQWNjb3VudCI6IHsKICAgICJBY2NvdW50VURG
IjogIk1DMjMtWDNDVC1FVU5CLURSM00tUUlCSS1XMklKLUFURVAiLAogICAgIktle
UVuY3J5cHRpb24iOiB7CiAgICAgICJVREYiOiAiTUNDQS00WTM3LU5SR0wtQkVKUy
1ENDdaLTRQSVotVlNDTiIsCiAgICAgICJCYXNlVURGIjogIk1DWlAtQU1OTy1KSFd
ZLVpRMjItTjNaUC1WMktXLTUySkUiLAogICAgICAiT3ZlcmxheSI6IHsKICAgICAg
ICAiUHJpdmF0ZUtleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIkVkNDQ4IiwKI
CAgICAgICAgICJQcml2YXRlIjogIkozX0cyYkxmcjhkRkRaSDRnYjNQc0dwVTE0T0
VjMmJib3YtdDFJOTR4WDJaQmVOWGN6TQogIFFDdGVYWDNsNnNrQm1TejA0S2VKd2p
hVSJ9fX0sCiAgICAiS2V5QXV0aGVudGljYXRpb24iOiB7CiAgICAgICJVREYiOiAi
TUNMNC1LUkI0LVBNVE4tM0NMSS1VUEZaLU1WMlotNlRVRyIsCiAgICAgICJCYXNlV
URGIjogIk1EWU8tWEFISi1SWFQ2LVlPNEotWDdXVi1MM0lXLTVORVAiLAogICAgIC
AiT3ZlcmxheSI6IHsKICAgICAgICAiUHJpdmF0ZUtleUVDREgiOiB7CiAgICAgICA
gICAiY3J2IjogIkVkNDQ4IiwKICAgICAgICAgICJQcml2YXRlIjogIk9OUE5BMlVu
SXNEYnljcGl4YXkzZ3JGenh5T241dmk4bTNnV1lxUGFsVG9YRHljUlQ2UwogIFRNN
XZETjZXR0M3VC1ncDNhbnZWT3VGayJ9fX0sCiAgICAiS2V5U2lnbmF0dXJlIjogew
ogICAgICAiVURGIjogIk1DWkwtTVFPQS1YTFlVLVJMUFctVlJSSC02VUZELUtESUU
iLAogICAgICAiQmFzZVVERiI6ICJNQ1lTLVRPUUotQ0RBWC1FRFU3LTZFWjMtT0xQ
Ry1LTUxHIiwKICAgICAgIk92ZXJsYXkiOiB7CiAgICAgICAgIlByaXZhdGVLZXlFQ
0RIIjogewogICAgICAgICAgImNydiI6ICJFZDQ0OCIsCiAgICAgICAgICAiUHJpdm
F0ZSI6ICJPZ0pSOEJZWXpKTGNqRVJrVzVYY2x0OUsyWUhhaHVVZzROQkRKWHNjVWt
LQTRIWVYzN0wKICByWE1nbDVpNmVHZTh5SG9TWVcwRlRWcFkifX19fX0",
{
"signatures":[{
"alg":"SHA2",
"kid":"MCRR-JFLZ-T2JH-INGD-SBYF-NO6X-55RN",
"signature":"DG3O45F_0CUD9TEOKgkLtRK1BZDqWey5JO3Kt6
foye8lvR13l6P6UnieF9jDNO0WQY-yPI4LjyuAVNSZWi97IF4M--zrduv7ZpjCthk
sLnlQvH-oYIfGb-dZfAOza6B7zvgU6IbxPWWWCo4zQOj6qBkA"}
],
"PayloadDigest":"4pwNPnQPWuciKHFFtXv7zXN7MN4bEsRJ78KmRG
8F3cR5pK32CcQ-aI5-qF2yL_gL8hJuU6S04mPpZEpE_acOWg"}
]}
]}}¶
The derivation of the Connection encryption and signature keys from the Profile and Private contributions in this example is shown in [draft-hallambaker-mesh-cryptography].¶
Creating a ProfileDevice comprises the steps of:¶
Devices are only connected to a personal Mesh by administration device. This comprises the steps of:¶
CatalogEntryDevice for the device and adding it to the CatalogDevice of the Personal Mesh.¶
CatalogEntryDevice to those services.¶
Mesh Accounts contains all the stateful information (contacts, calendar entries, inbound and outbound messages, etc.) related to a particular persona used by the owner.¶
A Mesh Profile MAY be connected to multiple accounts at the same time allowing the user to maintain separate personas for separate purposes.¶
Unlike traditional Internet application accounts, Mesh accounts are created by and belong to the user, not the Mesh Service provider. A user MAY change their Mesh Service provider at any time and disconnect the profile from all Mesh Services (e.g. to archive the account).¶
Alice's personal account is connected to two Mesh services:¶
The account profile specifies the online and offline signature keys used to maintain the profile and the encryption key to be used by the account.¶
{
"ProfileAccount":{
"KeyOfflineSignature":{
"UDF":"MC23-X3CT-EUNB-DR3M-QIBI-W2IJ-ATEP",
"PublicParameters":{
"PublicKeyECDH":{
"crv":"Ed448",
"Public":"9upP1iak30_JrG1peYwhkT00Dpw8J0jwGQA0nehnBVPuOaG
9h6SsFe0Dez2b3aQpldAGUKoUBdCA"}}},
"KeysOnlineSignature":[{
"UDF":"MCRR-JFLZ-T2JH-INGD-SBYF-NO6X-55RN",
"PublicParameters":{
"PublicKeyECDH":{
"crv":"Ed448",
"Public":"F_MJf0w8dUHiPYy97XKQmpfFVLnNndsjQH5p1c3z3Hlnq
Ta2a7bEUCOoxa4HAisf9BqnxJEdOmgA"}}}
],
"ServiceIDs":["alice@example.com"
],
"MeshProfileUDF":"MCSC-2POG-PH7T-ODJX-HOCA-B4XY-AFSK",
"KeyEncryption":{
"UDF":"MBWY-IIKY-VOB5-BXIP-DIXX-R4TH-ZIF2",
"PublicParameters":{
"PublicKeyECDH":{
"crv":"Ed448",
"Public":"swpe6H5yiU4vJotboXbFwwIEp_lXO-kbm9zj9POFLLwfqe6
BUMsu9FBCL6GHp93wcmLM27tGRn4A"}}}}}¶
Each device using the account requires an activation record:¶
{
"ActivationAccount":{
"AccountUDF":"MC23-X3CT-EUNB-DR3M-QIBI-W2IJ-ATEP",
"KeyEncryption":{
"UDF":"MCCA-4Y37-NRGL-BEJS-D47Z-4PIZ-VSCN",
"BaseUDF":"MCZP-AMNO-JHWY-ZQ22-N3ZP-V2KW-52JE",
"Overlay":{
"PrivateKeyECDH":{
"crv":"Ed448",
"Private":"J3_G2bLfr8dFDZH4gb3PsGpU14OEc2bbov-t1I94xX2ZBe
NXczMQCteXX3l6skBmSz04KeJwjaU"}}},
"KeyAuthentication":{
"UDF":"MCL4-KRB4-PMTN-3CLI-UPFZ-MV2Z-6TUG",
"BaseUDF":"MDYO-XAHJ-RXT6-YO4J-X7WV-L3IW-5NEP",
"Overlay":{
"PrivateKeyECDH":{
"crv":"Ed448",
"Private":"ONPNA2UnIsDbycpixay3grFzxyOn5vi8m3gWYqPalToXDy
cRT6STM5vDN6WGC7T-gp3anvVOuFk"}}},
"KeySignature":{
"UDF":"MCZL-MQOA-XLYU-RLPW-VRRH-6UFD-KDIE",
"BaseUDF":"MCYS-TOQJ-CDAX-EDU7-6EZ3-OLPG-KMLG",
"Overlay":{
"PrivateKeyECDH":{
"crv":"Ed448",
"Private":"OgJR8BYYzJLcjERkW5Xclt9K2YHahuUg4NBDJXscUkKA4H
YV37LrXMgl5i6eGe8yHoSYW0FTVpY"}}}}}¶
Creating a ProfileAccount comprises the steps of:¶
Adding a device to an account comprises the steps of:¶
CatalogEntryDevice of the device.¶
CatalogEntryDevice to those services.¶
A service profile provides the axiom of trust and cryptographic keys for a Mesh Service. A Mesh Service Host SHOULD return a copy of its ProfileHost and the parent ProfileService in response to a Hello transaction request.¶
The credentials provided by the ProfileService and ProfileHost are distinct from those provided by the WebPKI that typically services TLS requests. WebPKI credentials provide service introduction and authentication while a Mesh ProfileHost only provides authentication.¶
Unless exceptional circumstances require, a service should not need to revise its Service Profile unless it is intended to change its identity. Service Profiles MAY be countersigned by Trusted Third Parties to establish accountability.¶
The service profile¶
{
"ProfileService":{
"KeyOfflineSignature":{
"UDF":"MAZN-ABCG-4UH7-NN3H-5G7D-KP7X-HRGO",
"PublicParameters":{
"PublicKeyECDH":{
"crv":"Ed448",
"Public":"4_-7mv9dECSF5ihqS7wRP-KZbo4ExJc5JjoH4iudjymQ9Qb
HPUYWHD1YSpVypaHgyg-XkfhaqkSA"}}}}}¶
The host also has a profile¶
{
"ProfileHost":{
"KeyOfflineSignature":{
"UDF":"MDNG-3RJS-N6BJ-MU63-U7TZ-RKVB-SYZT",
"PublicParameters":{
"PublicKeyECDH":{
"crv":"Ed448",
"Public":"Bn3Yo-Hh_donsmk1AQxSd1nzR-SEzRcJudwoC174DEV-Vm4
t6Sl2jVFAq3GBG7lOUEF5HfeVqQiA"}}},
"KeyAuthentication":{
"UDF":"MDSO-WOVL-R4YG-7OUT-PB6O-2DBW-KUND",
"PublicParameters":{
"PublicKeyECDH":{
"crv":"Ed448",
"Public":"hFtmh1ErT93IUy-FJbPHt7QFIAP-ohQNLSzUwtXc2E0IH7r
XE6u92gnCUQpJVECuTNrHuwALJB4A"}}}}}¶
And there should be a connection of the host to the service but this isn't implemented yet:¶
$$$$ Empty $$$$¶
[TBS]¶
Creating a ProfileService comprises the steps of:¶
Creating a ProfileHost comprises the steps of:¶
Mesh Messaging is an end-to-end secure messaging system used to exchange short (32KB) messages between Mesh devices and services. In cases where exchange of longer messages is required, Mesh Messaging MAY be used to provide a control plane to advise the intended message recipient(s) of the type of data being offered and the means of retrieval (e.g an EARL).¶
A four-corner messaging model is enforced. Mesh Services only accept outbound messages from devices connected to accounts that it services. Inbound messages are only accepted from other Mesh Services. This model enables access control at both the outbound and inbound services¶
The outbound Mesh Service checks to see that the message request does not violate its acceptable use policy. Accounts that make a large number of message requests that result in complaints SHOULD be subject to consequences ranging from restriction of the number and type of messages sent to suspending or terminating messaging privileges.¶
The inbound Mesh Service also checks to see that messages received are consistent with the service Acceptable Use Policy and the user's personal access control settings.¶
Mesh Services that fail to police abuse by their account holders SHOULD be subject to consequences in the same fashion as account holders.¶
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.¶
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.¶
mmm_CatalogApplication
Contains configuration information for applications including mail (SMTP, IMAP, OpenPGP, S/MIME, etc) and SSH and for the MeshAccount application itself.¶
mmm_CatalogDevice
Contains descriptions of devices connected to the account and the permissions assigned to them¶
mmm_CatalogContact
Contains logical and physical contact information for people and organizations.¶
mmm_CatalogCredential
Contains credentials used to access network resources.¶
mmm_CatalogBookmark
Contains Web bookmarks and other citations allowing them to be shared between devices connected to the profile.¶
mmm_CatalogTask
Contains tasks assigned to the user including calendar entries and to do lists.¶
mmm_CatalogNetwork
Contains network settings such as WiFi access points, IPSEC and TLS VPN configurations, etc.¶
In many cases, the Mesh Catalog offers capabilities that represent a superset of the capabilities of an existing application. For example, the task catalog supports the appointment tracking functions of a traditional calendar application and the task tracking function of the traditional 'to do list' application. Combining these functions allows tasks to be triggered by other events other than the passage of time such as completion of other tasks, geographical presence, etc.¶
In such cases, the Mesh Catalog entries are designed to provide a superset of the data representation capabilities of the legacy formats and (where available) recent extensions. Where a catalog entry is derived from input presented in a legacy format, the original data representation MAY be attached verbatim to facilitate interoperability.¶
The application catalog mmm_CatalogApplication contains CatalogEntryApplication entries which describe the use of specific applications under the Mesh Service Account. Multiple application accounts for a single application MAY be connected to a single Mesh Service Account. Each account being specified in a separate entry.¶
The CatalogEntryApplication entries only contain configuration information for the application as it applies to the account as a whole. If the application requires separate configuration for individual devices, this is specified in separate activation records specified in the corresponding ConnectionDevice.¶
Mesh Accounts are described by CatalogEntryAccount entries. The corresponding activation records for the connected devices contain the contributions used to derive the private keys for use of the account.¶
The CatalogEntryAccount entry is described in the section describing Mesh accounts above.¶
SSH configuration profiles are described by CatalogEntryApplicationSSH entries. The corresponding activation records for the connected devices contain the contributions used to derive the private keys.¶
A user may have separate SSH configurations for separate purposes within a single Mesh Account. This allows a system administrator servicing multiple clients to maintain separate SSH profiles for each of her customers allowing credentials to be easily (and verifiably) revoked at contract termination.¶
The SSH profile contains the information that is stored in the known_hosts and authorized_keys files of SSH clients and servers.¶
$$$$ Empty $$$$¶
Mail configuration profiles are described by one or more CatalogEntryApplicationMail entries, one for each email account connected to the Mesh profile. The corresponding activation records for the connected devices contain information used to provide the device with the necessary decryption information.¶
Entries specify the email account address(es), the inbound and outbound server configuration and the cryptographic keys to be used for S/MIME and OpenPGP encryption.¶
$$$$ Empty $$$$¶
The device catalog mmm_CatalogDevice contains CatalogEntryDevice entries which describe the devices connected to the account and the permissions assigned to them.¶
The management of the device catalog is described in the section describing Mesh Device Management.¶
The contacts catalog contains CatalogEntryContact entries which describe¶
$$$$ Empty $$$$¶
The fields of the contact catalog provide a superset of the capabilities of vCard [RFC2426].¶
The Contact catalog is typically used by the MeshService as a source of authorization information to perform access control on inbound and outbound message requests. For this reason, Mesh Service SHOULD be granted read access to the contacts catalog by providing a decryption entry for the service.¶
The credential catalog contains CatalogEntryCredential entries which describe credentials used to access network resources.¶
Only username/password credentials are stored in the credential catalog. If public key credentials are to be used, these SHOULD be managed as an application profile allowing separate credentials to be created for each device.¶
{
"CatalogedCredential":{
"Service":"ftp.example.com",
"Username":"alice1",
"Password":"newpassword"}}¶
The bookmark catalog contains CatalogEntryBookmark entries which describe Web bookmarks and other citations allowing them to be shared between devices connected to the profile.¶
The fields currently supported by the Bookmarks catalog are currently limited to the fields required for tracking Web bookmarks. Specification of additional fields to track full academic citations is a work in progress.¶
{
"CatalogedBookmark":{
"Uri":"http://example.net/Bananas",
"Title":"\"Banana",
"Path":"Folder1/2"}}¶
The Task catalog contains CatalogEntryTask entries which describe tasks assigned to the user including calendar entries and to do lists.¶
The fields of the task catalog currently reflect those offered by the iCalendar specification [RFC5545]. Specification of additional fields to allow task triggering on geographic location and/or completion of other tasks is a work in progress.¶
$$$$ Empty $$$$¶
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].¶
Completion messages are dummy messages that are added to a Mesh Spool to change the status of messages previously posted. Any message that is in the inbound spool and has not been erased or redacted MAY be marked as read, unread or deleted. Any message in the outbound spool MAY be marked as sent, received or deleted.¶
Services MAY erase or redact messages in accordance with local site policy. Since messages are not removed from the spool on being marked deleted, they may be undeleted by marking them as read or unread. Marking a message deleted MAY make it more likely that the Service will purge the message however.¶
Having processed a message, a completion message is added to the spool so that other devices can see that it has been read:¶
[NYI]¶
Connection requests are sent by a device requesting connection to a Mesh Service Account.¶
The MessageConnectionRequest is originally sent by the device requesting connection to the Mesh Service associated with the account.¶
If the connection request is accepted by the Mesh Service, it creates a MessageConnectionResponse containing the ServerNonce and Witness values used in the authentication of the response together with a verbatim copy of the original request. The MessageConnectionResponse is then returned to the device that made the original request and placed on the SpoolInbound of the account to which the request was directed.¶
Further details of this mechanism are described in [draft-hallambaker-mesh-protocol].¶
The connection process begins with the assignment of a time-limited PIN value. This is described in a Message sent by the administration device to allow other admin devices to accept the request made.¶
[NYI]¶
The initial request is sent to the service¶
[NYI]¶
The service returns an acknowledgement giving the Witness value. Note that this is not a 'reply' since it comes from the service, not the user.¶
[NYI]¶
[Note, this mechanism should be revised to ensure that there is perfect forward secrecy. The device should provide a nonce key as a mixin]¶
A contact request presents a proposed contact entry and requests that it be added to the Contacts catalog of the specified Mesh Service Account. A contact request is usually sent by the party requesting that their contact be added but this is not necessarily the case.¶
The MessageContact contains a DARE Envelope containing the Contact information of the requester. If the request is accepted, this information will be added to the contact catalog of the relevant account. If the Reply field has the value 'true', this indicates that the sender is asking for the recipient to return their own credentials in reply.¶
Since the sender requires the user's contact information before the request can be made, the MessageContact message MAY be encrypted under either the user's account encryption key (if known) or the Mesh Service encryption key (which may be obtained from the service on request.¶
Bob asks Alice to send her contact details and sends his.¶
[NYI]¶
Alice responds with her details:¶
[NYI]¶
[Note that this exchange could be performed automatically on Alice's behalf by the service if she delegates this action to it.]¶
The current protocol assumes that all contact management will be performed end-to-end through the Mesh Services themselves. If the number of Mesh users were to become very large, additional infrastructure to facilitate contact management will be required. These topics are discussed at a high level in [draft-hallambaker-mesh-trust].¶
In situations where a user is well known and has a very large number of contacts, they are likely to make use of a tiered approach to contact management in which they keep separate accounts for their 'public' and 'restricted' personas and delegate management of their public account to a subordinate or to their Mesh Service provider.¶
Confirmation messages are used to provide an improved form of second factor authentication capability.¶
Two confirmation messages are specified, a request and response.¶
A confirmation request is initiated by sending a MessageConfirmationRequest to the Mesh Service hosting the recipient Mesh Service Account. The request specifies the question that is to be put to the user.¶
To respond to a confirmation request, a user generates a MessageConfirmationResponse. This MUST be signed by a device authorized to respond to confirmation requests by a Device Connection Assertion with the Confirmation privilege.¶
The confirmation request¶
[NYI]¶
The confirmation response¶
[NYI]¶
Classes that are derived from an assertion.¶
Parent class from which all assertion classes are derived¶
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.¶
The time instant the profile was last modified.¶
A Uniform Notary Token providing evidence that a signature was performed after the notary token was created.¶
Parent class from which all condition classes are derived.¶
[No fields]¶
Profiles are self signed assertions.¶
Parent class from which all profile classes are derived¶
The permanent signature key used to sign the profile itself. The UDF of the key is used as the permanent object identifier of the profile. Thus, by definition, the KeySignature value of a Profile does not change under any circumstance. The only case in which a¶
A Personal profile contains at least one OSK which is used to sign device administration application profiles.¶
Describes the long term parameters associated with a personal profile.¶
Describes a mesh device.¶
Profile of a Mesh Service¶
Key used to authenticate service connections.¶
Account assertion. This is signed by the service hosting the account.¶
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.¶
List of the permissions that the device has been granted.¶
The signature key for use of the device under the profile¶
The encryption key for use of the device under the profile¶
The authentication key for use of the device under the profile¶
The list of service identifiers.¶
List of the permissions that the device has been granted.¶
The signature key for use of the device under the profile¶
The encryption key for use of the device under the profile¶
The authentication key for use of the device under the profile¶
Describes the connection of a member to a group.¶
[No fields]¶
[No fields]¶
[No fields]¶
Contains the private activation information for a Mesh application running on a specific device¶
[No fields]¶
The signed AssertionDeviceConnection.¶
The key overlay used to generate the account signature key from the device signature key¶
The key overlay used to generate the account encryption key from the device encryption key¶
The key overlay used to generate the account authentication key from the device authentication key¶
The UDF of the account¶
The key contribution for the decryption key for the device. NB this is NOT an overlay on the device signature key, it is an overlay on the corresponding recryption key.¶
The key overlay used to generate the account encryption key from the device encryption key¶
The key overlay used to generate the account authentication key from the device authentication key¶
The key overlay used to generate the account signature key from the device signature key¶
Classes describing data used in cataloged data.¶
The Mesh Account Connection - the main event really¶
Unique key.¶
Base class for cataloged Mesh data.¶
[No fields]¶
Public device entry, indexed under the device ID¶
UDF of the signature key of the device in the Mesh¶
UDF of the signature key of the device¶
The device profile¶
The public assertion demonstrating connection of the Device to the Mesh¶
The activations of the device within the Mesh¶
The accounts that this device is connected to¶
UDF of the account profile¶
The account profile¶
The connection of this device to the account¶
The activation data for this device to the account¶
If true, this catalog entry is for the user who created the catalog. To be valid, such an entry MUST be signed by an administration key for the Mesh profile containing the account to which the catalog belongs.¶
Unique key.¶
List of the permissions that the contact has been granted.¶
The (signed) contact data.¶
[No fields]¶
[No fields]¶
[No fields]¶
[No fields]¶
[No fields]¶
Connection request message. This message contains the information¶
Connection request message generated by a service on receipt of a valid MessageConnectionRequestClient¶
[No fields]¶
[No fields]¶
[No fields]¶
The security considerations for use and implementation of Mesh services and applications are described in the Mesh Security Considerations guide [draft-hallambaker-mesh-security].¶
All the IANA considerations for the Mesh documents are specified in this document¶
A list of people who have contributed to the design of the Mesh is presented in [draft-hallambaker-mesh-architecture].¶
The means by which profiles are stored on devices is outside the scope of the specification. Only catalogs that are required to be shared between machines by means of accounts need to be standardized.¶
Catalog of all the Mesh Profiles that the user has registered with the device and the latest version of the device profile for this device.¶
Catalog containing the Account Entries for the Mesh [UDF-Mesh].¶
The device catalog associated with the specified account¶
The set of account catalogs that are shared verbatim between the devices connected to the account.¶
Create new Mesh Profile, Device Profile, Add to Host Catalog¶
Create MeshCatalog¶
Create new Account Profile, Add to MeshCatalog¶
Create new Account Device Catalog¶
For each device to be added to the account: Create Account Connection Assertion, add to Account Device Catalog.¶
Create a Device Connection Assertion.¶
For each account the device is to be added to: Create Account Connection Assertion, add to Account Device Catalog.¶
| Message | Signer | Recipients |
|---|---|---|
| RequestConnection | Device | Service |
| AcknowledgeConnection | Service | Device, Receiver |
| OfferGroup | Sender | Receiver |
| RequestContact | Sender | Receiver |
| ReplyContact | Sender | Receiver |
| RequestConfirmation | Sender | Receiver |
| ResponseConfirmation | Sender | Receiver |
| RequestTask | Sender | Receiver |
| ResponseTask | Sender | Receiver |