Mathematical Mesh 3.0 Part IV: Schema Reference
draft-hallambaker-mesh-schema-03
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Phillip Hallam-Baker | ||
| Last updated | 2019-08-13 (Latest revision 2019-07-08) | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-hallambaker-mesh-schema-03
Network Working Group P. Hallam-Baker
Internet-Draft August 13, 2019
Intended status: Informational
Expires: February 14, 2020
Mathematical Mesh 3.0 Part IV: Schema Reference
draft-hallambaker-mesh-schema-03
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.
This document is also available online at
http://mathmesh.com/Documents/draft-hallambaker-mesh-schema.html [1]
.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 14, 2020.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Hallam-Baker Expires February 14, 2020 [Page 1]
Internet-Draft Mesh Schema Reference August 2019
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Related Specifications . . . . . . . . . . . . . . . . . 5
2.4. Implementation Status . . . . . . . . . . . . . . . . . . 5
3. Mesh Assertions . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Mesh Profiles . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Mesh Connections . . . . . . . . . . . . . . . . . . . . 7
3.4. Mesh Private Declarations . . . . . . . . . . . . . . . . 7
4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Device Management . . . . . . . . . . . . . . . . . . . . 8
4.1.1. Master Profile . . . . . . . . . . . . . . . . . . . 9
4.1.2. Mesh Devices . . . . . . . . . . . . . . . . . . . . 11
4.2. Mesh Accounts . . . . . . . . . . . . . . . . . . . . . . 17
4.2.1. Creating a ProfileAccount . . . . . . . . . . . . . . 19
4.2.2. Connecting a Device to an Account . . . . . . . . . . 19
4.2.3. Binding and Account to a Service . . . . . . . . . . 20
4.3. Mesh Services . . . . . . . . . . . . . . . . . . . . . . 20
4.3.1. Creating a ProfileService . . . . . . . . . . . . . . 21
4.3.2. Creating a ProfileHost . . . . . . . . . . . . . . . 22
4.3.3. Creating a ConnectionHost . . . . . . . . . . . . . . 22
4.4. Mesh Messaging . . . . . . . . . . . . . . . . . . . . . 22
4.4.1. Traffic Analysis . . . . . . . . . . . . . . . . . . 23
5. Mesh Catalogs . . . . . . . . . . . . . . . . . . . . . . . . 24
5.1. Application . . . . . . . . . . . . . . . . . . . . . . . 25
5.1.1. Mesh Account . . . . . . . . . . . . . . . . . . . . 25
5.1.2. SSH . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.1.3. Mail . . . . . . . . . . . . . . . . . . . . . . . . 26
5.2. Device . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.3. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.4. Credential . . . . . . . . . . . . . . . . . . . . . . . 27
5.5. Bookmark . . . . . . . . . . . . . . . . . . . . . . . . 27
5.6. Task . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.7. Network . . . . . . . . . . . . . . . . . . . . . . . . . 28
6. Mesh Messages . . . . . . . . . . . . . . . . . . . . . . . . 28
6.1. Completion . . . . . . . . . . . . . . . . . . . . . . . 28
6.2. Connection . . . . . . . . . . . . . . . . . . . . . . . 28
6.3. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.4. Confirmation . . . . . . . . . . . . . . . . . . . . . . 30
Hallam-Baker Expires February 14, 2020 [Page 2]
Internet-Draft Mesh Schema Reference August 2019
7. Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.1. Shared Classes . . . . . . . . . . . . . . . . . . . . . 31
7.1.1. Classes describing keys . . . . . . . . . . . . . . . 31
7.1.2. Structure: PublicKey . . . . . . . . . . . . . . . . 31
7.1.3. Structure: KeyComposite . . . . . . . . . . . . . . . 31
7.1.4. Structure: KeyOverlay . . . . . . . . . . . . . . . . 31
7.1.5. Structure: EscrowedKeySet . . . . . . . . . . . . . . 31
7.1.6. Structure: DeviceRecryptionKey . . . . . . . . . . . 32
7.2. Assertion classes . . . . . . . . . . . . . . . . . . . . 32
7.2.1. Structure: Assertion . . . . . . . . . . . . . . . . 32
7.2.2. Structure: Condition . . . . . . . . . . . . . . . . 32
7.2.3. Profile Classes . . . . . . . . . . . . . . . . . . . 32
7.2.4. Structure: Profile . . . . . . . . . . . . . . . . . 32
7.2.5. Structure: ProfilePersonal . . . . . . . . . . . . . 33
7.2.6. Structure: ProfileDevice . . . . . . . . . . . . . . 33
7.2.7. Structure: ProfileService . . . . . . . . . . . . . . 33
7.2.8. Structure: ProfileAccount . . . . . . . . . . . . . . 34
7.2.9. Structure: ProfileGroup . . . . . . . . . . . . . . . 34
7.2.10. Structure: ProfileHost . . . . . . . . . . . . . . . 34
7.2.11. Connection Classes . . . . . . . . . . . . . . . . . 34
7.2.12. Structure: Connection . . . . . . . . . . . . . . . . 34
7.2.13. Structure: Permission . . . . . . . . . . . . . . . . 35
7.2.14. Structure: ConnectionDevice . . . . . . . . . . . . . 35
7.2.15. Structure: ConnectionAccount . . . . . . . . . . . . 35
7.2.16. Structure: ConnectionService . . . . . . . . . . . . 36
7.2.17. Structure: ConnectionHost . . . . . . . . . . . . . . 36
7.2.18. Structure: ConnectionApplication . . . . . . . . . . 36
7.2.19. Activation Classes . . . . . . . . . . . . . . . . . 36
7.2.20. Structure: Activation . . . . . . . . . . . . . . . . 36
7.2.21. Structure: ActivationDevice . . . . . . . . . . . . . 36
7.2.22. Structure: ActivationAccount . . . . . . . . . . . . 37
7.3. Cataloged items . . . . . . . . . . . . . . . . . . . . . 37
7.3.1. Data Structures . . . . . . . . . . . . . . . . . . . 37
7.3.2. Structure: Contact . . . . . . . . . . . . . . . . . 37
7.3.3. Structure: Role . . . . . . . . . . . . . . . . . . . 38
7.3.4. Structure: Address . . . . . . . . . . . . . . . . . 39
7.3.5. Structure: Location . . . . . . . . . . . . . . . . . 39
7.3.6. Structure: Reference . . . . . . . . . . . . . . . . 39
7.3.7. Structure: Task . . . . . . . . . . . . . . . . . . . 40
7.4. Catalog Entries . . . . . . . . . . . . . . . . . . . . . 41
7.4.1. Structure: CatalogedEntry . . . . . . . . . . . . . . 41
7.4.2. Structure: CatalogedDevice . . . . . . . . . . . . . 41
7.4.3. Structure: CatalogedCredential . . . . . . . . . . . 41
7.4.4. Structure: CatalogedNetwork . . . . . . . . . . . . . 42
7.4.5. Structure: CatalogedContact . . . . . . . . . . . . . 42
7.4.6. Structure: CatalogedContactRecryption . . . . . . . . 42
7.4.7. Structure: CatalogedBookmark . . . . . . . . . . . . 43
7.4.8. Structure: CatalogedTask . . . . . . . . . . . . . . 43
Hallam-Baker Expires February 14, 2020 [Page 3]
Internet-Draft Mesh Schema Reference August 2019
7.4.9. Structure: CatalogedApplication . . . . . . . . . . . 43
7.4.10. Structure: CatalogedApplicationAccount . . . . . . . 43
7.4.11. Structure: CatalogedMember . . . . . . . . . . . . . 44
7.4.12. Structure: CatalogedGroup . . . . . . . . . . . . . . 44
7.4.13. Structure: CatalogedApplicationSSH . . . . . . . . . 44
7.4.14. Structure: CatalogedApplicationMail . . . . . . . . . 44
7.4.15. Structure: CatalogedApplicationNetwork . . . . . . . 44
7.5. Messages . . . . . . . . . . . . . . . . . . . . . . . . 44
7.5.1. Structure: Message . . . . . . . . . . . . . . . . . 44
7.5.2. Structure: MessageComplete . . . . . . . . . . . . . 45
7.5.3. Structure: MessagePIN . . . . . . . . . . . . . . . . 45
7.5.4. Structure: RequestConnection . . . . . . . . . . . . 45
7.5.5. Structure: AcknowledgeConnection . . . . . . . . . . 46
7.5.6. Structure: RequestContact . . . . . . . . . . . . . . 46
7.5.7. Structure: RequestConfirmation . . . . . . . . . . . 46
7.5.8. Structure: ResponseConfirmation . . . . . . . . . . . 46
7.5.9. Structure: RequestTask . . . . . . . . . . . . . . . 47
8. Security Considerations . . . . . . . . . . . . . . . . . . . 47
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 47
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 47
11.1. Normative References . . . . . . . . . . . . . . . . . . 47
11.2. Informative References . . . . . . . . . . . . . . . . . 48
11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 49
1. Introduction
This document describes the data structures of the Mathematical Mesh
with illustrative examples. For an overview of the Mesh objectives
and architecture, consult the accompanying Architecture Guide
[draft-hallambaker-mesh-architecture] . For information on the
implementation of the Mesh Service protocol, consult the accompanying
Protocol Reference [draft-hallambaker-mesh-protocol]
This document has two main sections. The first section presents
examples of the Mesh assertions, catalog entry and messages in use.
The second section contains the schema reference. All the material
in both sections is generated from the Mesh reference implementation
[draft-hallambaker-mesh-developer] .
Although some of the services described in this document could be
used to replace existing Internet protocols including FTP and SMTP,
the principal value of any communication protocol lies in the size of
the audience it allows them to communicate with. Thus, while the
Mesh Messaging service is designed to support efficient and reliable
transfer of messages ranging in size from a few bytes to multiple
terabytes, the near-term applications of these services will be to
Hallam-Baker Expires February 14, 2020 [Page 4]
Internet-Draft Mesh Schema Reference August 2019
applications that are not adequately supported by existing protocols
if at all.
2. Definitions
This section presents the related specifications and standard, the
terms that are used as terms of art within the documents and the
terms used as requirements language.
2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] .
2.2. Defined Terms
The terms of art used in this document are described in the Mesh
Architecture Guide [draft-hallambaker-mesh-architecture] .
2.3. Related Specifications
The architecture of the Mathematical Mesh is described in the Mesh
Architecture Guide [draft-hallambaker-mesh-architecture] . The Mesh
documentation set and related specifications are described in this
document.
2.4. Implementation Status
The implementation status of the reference code base is described in
the companion document [draft-hallambaker-mesh-developer] .
3. Mesh Assertions
Mesh Assertions are signed DARE Envelopes that contain one of more
claims. Mesh Assertions provide the basis for trust in the
Mathematical Mesh.
Mesh Assertions are divided into two classes. Mesh Profiles are
self-signed assertions. Assertions that are not self-signed are
called declarations. The only type of declaration currently defined
is a Connection Declaration describing the connection of one profile
to another. Currently, five profile and four connection types are
defined:
Hallam-Baker Expires February 14, 2020 [Page 5]
Internet-Draft Mesh Schema Reference August 2019
[[This figure is not viewable in this format. The figure is
available at http://mathmesh.com/Documents/draft-hallambaker-mesh-
schema.html [2].]]
Profiles And Connections
3.1. Encoding
The payload of a Mesh Assertion is a JSON encoded object that is a
subclass of the Assertion class which defines the following fields:
Identifier An identifier for the assertion.
Updated The date and time at which the assertion was issued or last
updated
NotaryToken An assertion may optionally contain one or more notary
tokens issued by a Mesh Notary service. These establish a proof
that the assertion was signed after the date the notary token was
created.
Conditions A list of conditions that MAY be used to verify the
status of the assertion if the relying party requires.
The implementation of the NotaryToken and Conditions mechanisms is to
be specified in [draft-hallambaker-mesh-notary] at a future date.
Note that the implementation of Conditions differs significantly from
that of SAML. Relying parties are required to process condition
clauses in a SAML assertion to determine validity. Mesh Relying
parties MAY verify the conditions clauses or rely on the
trustworthiness of the provider.
The reason for weakening the processing of conditions clauses in the
Mesh is that it is only ever possible to validate a conditions clause
of any type relative to a ground truth. In SAML applications, the
relying party almost invariably has access to an independent source
of ground truth. A Mesh device connected to a Mesh Service does not.
Thus the types of verification that can be achieved in practice are
limited to verifying the consistency of current and previous
statements from the Mesh Service.
3.2. Mesh Profiles
Mesh Profiles perform a similar role to X.509v3 certificates but with
important differences:
Hallam-Baker Expires February 14, 2020 [Page 6]
Internet-Draft Mesh Schema Reference August 2019
o Profiles describe credentials, they do not make identity
statements
o Profiles do not expire, there is therefore no need to support
renewal processing.
o Profiles may be modified over time, the current and past status of
a profile being recorded in an append only log.
Profiles provide the axioms of trust for the Mesh PKI. Unlike in the
PKIX model in which all trust flows from axioms of trust held by a
small number of Certificate Authorities, every part in the Mesh
contributes their own axiom of trust.
It should be noted however that the role of Certificate Authorities
is redefined rather than eliminated. Rather than making assertions
whose subject is represented by identities which are inherently
mutable and subjective, Certificate Authorities can now make
assertions about immutable cryptographic keys.
Every Profile MUST contain a SignatureKey field and MUST be signed by
the key specified in that field.
A Profile is valid if and only if:
o There is a SignatureKey field.
o The profile is signed under the key specified in the SignatureKey
field.
A profile has the status current if and only if:
o The Profile is valid
o Every Conditions clause in the profile is understood by the
relying party and evaluates to true.
3.3. Mesh Connections
3.4. Mesh Private Declarations
4. Architecture
The Mesh architecture has four principal components:
Mesh Device Management Binds a collection of devices that the owner
of the Mesh uses together to function as a single personal Mesh.
Hallam-Baker Expires February 14, 2020 [Page 7]
Internet-Draft Mesh Schema Reference August 2019
Mesh Account Contains all the information (contacts, calendar
entries, inbound and outbound messages, etc.) related to a
particular persona used by the owner.
Mesh Service Provides a service identifier (e.g. alice@example.com)
through which devices and other Mesh users may interact with a
Mesh Account.
Mesh Messaging
Allows short messages (less than 32KB) to be exchanged between Mesh
devices connected to an account and between Mesh Accounts.
Device management and Accounts components are defined by a data
schema alone. The Service and Messaging components are defined by a
data schema and a service protocol.
The separation of accounts and services as separate components is a
key distinction between the Mesh and earlier Internet applications.
A Mesh account belongs to the owner of the Mesh and not the account
service provider which the user may change at any time of their
choosing. A Mesh account may be connected to multiple service
providers to provide backup capability or to none.
For example, Alice's personal Mesh has one Master Profile, multiple
device profiles (two of which are shown here) and two Account
Profiles. Her Personal account is connected to two Mesh services
while her Business account is not currently connected to any service:
[[This figure is not viewable in this format. The figure is
available at http://mathmesh.com/Documents/draft-hallambaker-mesh-
schema.html [3].]]
Alice's Personal Mesh
In normal circumstances, a user will create a personal Mesh and add
their first device, account and service at once. These are shown
here as separate operations to illustrate the separation of the Mesh
components.
4.1. Device Management
Device Management provides the foundation for all Mesh functions
allowing a collection of devices belonging to a user to function as a
single personal Mesh.
Hallam-Baker Expires February 14, 2020 [Page 8]
Internet-Draft Mesh Schema Reference August 2019
The device management layer of a personal Mesh consists of exactly
one Master Profile and a catalog containing the entries describing
the connected devices.
4.1.1. Master Profile
A Mesh master profile provides the axiom of trust for a mesh user.
It contains a Master Signature Key and one or more Administration
Signature Keys. The unique identifier of the master profile is the
UDF of the Master Signature Key.
A Master Profile MAY contain one or more MasterEscrowKeys. These MAY
be used to escrow private keys used for encryption. They SHOULD NOT
be used to escrow authentication keys and MUST NOT be used to escrow
signature keys.
[[This figure is not viewable in this format. The figure is
available at http://mathmesh.com/Documents/draft-hallambaker-mesh-
schema.html [4].]]
Master Profile and Associated Device and Account Connection
Assertions.
A user should not need to replace their master profile unless they
intend to establish a separate identity. To minimize the risk of
disclosure, the Master Signature Key is only ever used to sign
updates to the master profile itself. This allows the user to secure
their Master Signature Key by either keeping it on hardware token or
device dedicated to that purpose or by using the escrow mechanism and
paper recovery keys as described in this document.
Alice creates a ProfileMaster with one administration key and one
master escrow key:
Hallam-Baker Expires February 14, 2020 [Page 9]
Internet-Draft Mesh Schema Reference August 2019
{
"ProfilePersonal":{
"KeyOfflineSignature":{
"UDF":"MAOZ-3MVE-G5EN-64BI-I3RM-ODFJ-H5W4",
"PublicParameters":{
"PublicKeyECDH":{
"crv":"Ed448",
"Public":"0Vxq105QJ4y0IJu_pE2iBm6y7NTruQQkZhUIJGYu-6mBhNJ
CTKjnSIkkb6SK6aLRlzpwv-UWCzMA"}}},
"KeysOnlineSignature":[{
"UDF":"MBE7-UCJF-ZAZ2-MLGP-LB55-HZBT-XMHV",
"PublicParameters":{
"PublicKeyECDH":{
"crv":"Ed448",
"Public":"Rd3snDZ-iOOYA1BSphd7H9J1C5xfSR2ojBEGK1SljRUD0
8MR4tFsWo0Y2cGCOYLbHIi6aT6HffAA"}}}
],
"KeyEncryption":{
"UDF":"MBGA-C2UQ-QFVG-5HNA-2WTZ-IKNK-EWHT",
"PublicParameters":{
"PublicKeyECDH":{
"crv":"Ed448",
"Public":"42IyVJWg4W1J9-F0itPADd00yAYQwB8kWP0UkYWLqJuR6g0
wnkYQCF8Zr4zTe2lNhDPUf8BR8VSA"}}}}}
4.1.1.1. Creating a ProfileMaster
Creating a ProfileMaster comprises the steps of:
1. Creating a Master Signature key.
2. Creating an Online Signing Key
3. Signing the ProfileMaster using the Master Signature Key
4. Persisting the ProfileMaster on the administration device to the
CatalogHost.
5. (Optional) Connecting at least one Administration Device and
granting it the ActivationAdministration activation.
4.1.1.2. Updating a ProfileMaster
Updating a ProfileMaster comprises the steps of:
1. Making the necessary changes.
2. Signing the ProfileMaster using the Master Signature Key
Hallam-Baker Expires February 14, 2020 [Page 10]
Internet-Draft Mesh Schema Reference August 2019
3. Persisting the ProfileMaster on the administration device to the
CatalogHost.
4.1.1.3. The Device Catalog
Each personal Mesh has a Device Catalog CatalogDevice associated with
it. The Device Catalog is used to manage the connection of devices
to the Personal Mesh and has a CatalogEntryDevice for each device
currently connected to the catalog.
Each Administration Device MUST have access to an up to date copy of
the Device Catalog in order to manage the devices connected to the
Mesh. The Mesh Service protocol MAY be used to synchronize the
Device Catalog between administration devices in the case that there
is more than one administration device.
The CatalogEntryDevice contains fields for the device profile, device
private and device connection.
4.1.2. Mesh Devices
The principle of radical distrust requires us to consider the
possibility that a device might be compromised during manufacture.
Once consequence of this possibility is that when an administration
device connects a new device to a user's personal Mesh, we cannot put
our full trust in either the device being connected or the
administration device connecting it.
This concern is resolved by (at minimum) combining keying material
generated from both sources to create the keys to be used in the
context of the user's personal Mesh with the process being fully
verified by both parties.
Additional keying material sources could be added if protection
against the possibility of compromise at both devices was required
but this is not supported by the current specifications.
A device profile provides the axiom of trust and the key
contributions of the device:
[[This figure is not viewable in this format. The figure is
available at http://mathmesh.com/Documents/draft-hallambaker-mesh-
schema.html [5].]]
Mapping of Device Profile and Device Private to Device Connection
Keys.
Hallam-Baker Expires February 14, 2020 [Page 11]
Internet-Draft Mesh Schema Reference August 2019
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":"MABG-6ZLL-I2FM-KUKX-TM7E-OVAJ-M5QP",
"PublicParameters":{
"PublicKeyECDH":{
"crv":"Ed448",
"Public":"9Fot0c6ztURHkCY0pLew5-9cjGvP72EztCSx0xwh0IstC-I
kb7fdzwv_vcEA6f6eyJF4HD-mGSeA"}}},
"KeyEncryption":{
"UDF":"MB3L-TNWX-HNZI-FFHN-IJRZ-HSOF-NKZL",
"PublicParameters":{
"PublicKeyECDH":{
"crv":"Ed448",
"Public":"CUG3q5c8uFglVWyGeMnxybLprQAKHvqb-V9UbRQ5OS3LB9J
j1H7k8i9HQpiyhNvCZ5mcb5Rti_6A"}}},
"KeyAuthentication":{
"UDF":"MD6N-VQ4H-6EQO-DT3S-IUMN-C5OJ-CDXR",
"PublicParameters":{
"PublicKeyECDH":{
"crv":"Ed448",
"Public":"IodXkMxsyg6kUsKFSlS8mDvxe5ZKSuSU0r-lXoY2Tvp0CMo
F34NAloV1RpAjTaPhVPJLdgaLspYA"}}}}}
Since the Device Profile keys are ultimately under the control of the
device and/or software provider, these are considered insufficiently
trustworthy and the administration device creates key contributions
to be added to the device keys to establish the key set to be used in
the context of the user's personal Mesh:
Hallam-Baker Expires February 14, 2020 [Page 12]
Internet-Draft Mesh Schema Reference August 2019
{
"ActivationDevice":{
"KeySignature":{
"UDF":"MDAA-75W5-HOD4-LSSU-JNYG-WHML-34DU",
"BaseUDF":"MABG-6ZLL-I2FM-KUKX-TM7E-OVAJ-M5QP",
"Overlay":{
"PrivateKeyECDH":{
"crv":"Ed448",
"Private":"hchEs5Is89D_B89_04Y24dau12P7hVvGlIY5JJVRevREwG
LZsuRaDnsJTDaW7yEbKwQMTdhky5k"}}},
"KeyEncryption":{
"UDF":"MDBS-VUEM-T4LN-V6SG-OLAZ-DBXD-BEKR",
"BaseUDF":"MB3L-TNWX-HNZI-FFHN-IJRZ-HSOF-NKZL",
"Overlay":{
"PrivateKeyECDH":{
"crv":"Ed448",
"Private":"idvk3TtbV_tE1P0jEFyMZAnrOWrODow6TnvsuNpGUIrqte
QaRHLM35tA53Nca7Fyl2_8NpA85Ps"}}},
"KeyAuthentication":{
"UDF":"MC2O-YPA4-NZYJ-4XYX-LV7S-TVCV-ODIH",
"BaseUDF":"MD6N-VQ4H-6EQO-DT3S-IUMN-C5OJ-CDXR",
"Overlay":{
"PrivateKeyECDH":{
"crv":"Ed448",
"Private":"Sq5L14DMmsCG0WC4gBzc3RGMq4QSrl1DBautaEDSNQFLQP
RFD4CR2h1Iq057HKuNk5IDViidsyA"}}}}}
The resulting key set is specified in the device connection:
Hallam-Baker Expires February 14, 2020 [Page 13]
Internet-Draft Mesh Schema Reference August 2019
{
"ConnectionDevice":{
"KeySignature":{
"UDF":"MDAA-75W5-HOD4-LSSU-JNYG-WHML-34DU",
"PublicParameters":{
"PublicKeyECDH":{
"crv":"Ed448",
"Public":"CHU3vyEJRMDuHnzZev5GqO-0iK-lOBxowBEUsOUaWN-KUe0
RZHa5d-a3xBEQtG-0o0rq5LwKvJwA"}}},
"KeyEncryption":{
"UDF":"MDBS-VUEM-T4LN-V6SG-OLAZ-DBXD-BEKR",
"PublicParameters":{
"PublicKeyECDH":{
"crv":"Ed448",
"Public":"VW2pEXUUgHkvV7e4DhsX8qjLr4Z5-qGkyBsfCRUdmtyGqdq
RGYXA8qeGvP4GcrMlhlmtJ_tEQBcA"}}},
"KeyAuthentication":{
"UDF":"MC2O-YPA4-NZYJ-4XYX-LV7S-TVCV-ODIH",
"PublicParameters":{
"PublicKeyECDH":{
"crv":"Ed448",
"Public":"Yz1ljn0ykFMNussK778qoua202kBugeeCRj35OL7VqBxYOw
8nG4BcmHTH3cIKdJohQB4H3T1ikOA"}}}}}
All the above are combined to form the CatalogedDevice entry:
{
"CatalogedDevice":{
"UDF":"MDAA-75W5-HOD4-LSSU-JNYG-WHML-34DU",
"DeviceUDF":"MABG-6ZLL-I2FM-KUKX-TM7E-OVAJ-M5QP",
"EnvelopedProfileDevice":[{
"dig":"S512",
"cty":"application/mmm"},
"ewogICJQcm9maWxlRGV2aWNlIjogewogICAgIktleU9mZmxpbmVTaWduYXR1
cmUiOiB7CiAgICAgICJVREYiOiAiTUFCRy02WkxMLUkyRk0tS1VLWC1UTTdFLU9WQ
UotTTVRUCIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdW
JsaWNLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6ICJFZDQ0OCIsCiAgICAgICA
gICAiUHVibGljIjogIjlGb3QwYzZ6dFVSSGtDWTBwTGV3NS05Y2pHdlA3MkV6dENT
eDB4d2gwSXN0Qy1Ja2I3ZmQKICB6d3ZfdmNFQTZmNmV5SkY0SEQtbUdTZUEifX19L
AogICAgIktleUVuY3J5cHRpb24iOiB7CiAgICAgICJVREYiOiAiTUIzTC1UTldYLU
hOWkktRkZITi1JSlJaLUhTT0YtTktaTCIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJ
zIjogewogICAgICAgICJQdWJsaWNLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6
ICJFZDQ0OCIsCiAgICAgICAgICAiUHVibGljIjogIkNVRzNxNWM4dUZnbFZXeUdlT
W54eWJMcHJRQUtIdnFiLVY5VWJSUTVPUzNMQjlKajFIN2sKICA4aTlIUXBpeWhOdk
NaNW1jYjVSdGlfNkEifX19LAogICAgIktleUF1dGhlbnRpY2F0aW9uIjogewogICA
gICAiVURGIjogIk1ENk4tVlE0SC02RVFPLURUM1MtSVVNTi1DNU9KLUNEWFIiLAog
ICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgICAiUHVibGljS2V5RUNES
CI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICAgICAgIlB1YmxpYy
Hallam-Baker Expires February 14, 2020 [Page 14]
Internet-Draft Mesh Schema Reference August 2019
I6ICJJb2RYa014c3lnNmtVc0tGU2xTOG1EdnhlNVpLU3VTVTByLWxYb1kyVHZwMEN
Nb0YzNE5BCiAgbG9WMVJwQWpUYVBoVlBKTGRnYUxzcFlBIn19fX19",
{
"signatures":[{
"signature":"zTXCLitDmFOuBcza1RqH_DgGOhyP7WpVk3ndttT7OA
Nlxf7RQc7n6fcmfKLqeyuINT04YfPwC94Ac5Fv0Mi_jzOPdJBcipuAu-_nH6ArIcD
uxfiat7kbAfSJmv4dMJV_gzIdynf6yX6WH6SA7VVSpxAA"}
],
"PayloadDigest":"qFInJ114BiGrkbKq-TvoQ3b0ztUyVu_1qmIwUed3nj
mYeguyZov8nIQKNdnuFmGYfYKxOW2n-Usz-4PHvHAyDg"}
],
"EnvelopedConnectionDevice":[{
"dig":"S512"},
"ewogICJDb25uZWN0aW9uRGV2aWNlIjogewogICAgIktleVNpZ25hdHVyZSI6
IHsKICAgICAgIlVERiI6ICJNREFBLTc1VzUtSE9ENC1MU1NVLUpOWUctV0hNTC0zN
ERVIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0
tleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIkVkNDQ4IiwKICAgICAgICAgICJ
QdWJsaWMiOiAiQ0hVM3Z5RUpSTUR1SG56WmV2NUdxTy0waUstbE9CeG93QkVVc09V
YVdOLUtVZTBSWkhhNQogIGQtYTN4QkVRdEctMG8wcnE1THdLdkp3QSJ9fX0sCiAgI
CAiS2V5RW5jcnlwdGlvbiI6IHsKICAgICAgIlVERiI6ICJNREJTLVZVRU0tVDRMTi
1WNlNHLU9MQVotREJYRC1CRUtSIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB
7CiAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIkVk
NDQ4IiwKICAgICAgICAgICJQdWJsaWMiOiAiVlcycEVYVVVnSGt2VjdlNERoc1g4c
WpMcjRaNS1xR2t5QnNmQ1JVZG10eUdxZHFSR1lYQQogIDhxZUd2UDRHY3JNbGhsbX
RKX3RFUUJjQSJ9fX0sCiAgICAiS2V5QXV0aGVudGljYXRpb24iOiB7CiAgICAgICJ
VREYiOiAiTUMyTy1ZUEE0LU5aWUotNFhZWC1MVjdTLVRWQ1YtT0RJSCIsCiAgICAg
ICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdWJsaWNLZXlFQ0RIIjoge
wogICAgICAgICAgImNydiI6ICJFZDQ0OCIsCiAgICAgICAgICAiUHVibGljIjogIl
l6MWxqbjB5a0ZNTnVzc0s3Nzhxb3VhMjAya0J1Z2VlQ1JqMzVPTDdWcUJ4WU93OG5
HNEIKICBjbUhUSDNjSUtkSm9oUUI0SDNUMWlrT0EifX19fX0",
{
"signatures":[{
"signature":"LakNIBxHRHIWfUdZuKKt_UzGpwJPxLXSDHvS43pzFO
G8Q4FJzacaO1MsS3piW6Mjwcq8kvGZr7QArwewDVCGXsF-fO43zlk8iEeJBA8csWz
ika412bjVSvT--oNjKYtaeRLBYcM656e7ITOdjft_sR8A"}
],
"PayloadDigest":"sUSwjnOWHrs5n7CUZCr72SHFGJYYiNgxtg8fIcUEeQ
u1Mhjwz3iI-UAjJ1yRQQnmsZ_YEf_aBzSWRK077LwX2w"}
],
"EnvelopedActivationDevice":[{
"enc":"none",
"Salt":"cJK1bnGuELszHVogMXTj3Q",
"cty":"application/mmm",
"recipients":[{
"kid":"MB3L-TNWX-HNZI-FFHN-IJRZ-HSOF-NKZL",
"epk":{
"PublicKeyECDH":{
"crv":"Ed448",
Hallam-Baker Expires February 14, 2020 [Page 15]
Internet-Draft Mesh Schema Reference August 2019
"Public":"8bUnsSVeSoF5wzTXjEw4uNfXb0gTgP0_qV_utnBl3
SuIIub6LKfeLcArA8pEwnzk7-GrtJkBCCsA"}},
"wmk":"pqampqampqY"},
{
"kid":"MBGA-C2UQ-QFVG-5HNA-2WTZ-IKNK-EWHT",
"epk":{
"PublicKeyECDH":{
"crv":"Ed448",
"Public":"JqQ0Xz152usfWTlj7dITf6AUpC-IglIEXq7babkUB
WZ57lRRHegc0CIo3McqAHqp6kAR7d34alOA"}},
"wmk":"pqampqampqY"}
]},
"ewogICJBY3RpdmF0aW9uRGV2aWNlIjogewogICAgIktleVNpZ25hdHVyZSI6
IHsKICAgICAgIlVERiI6ICJNREFBLTc1VzUtSE9ENC1MU1NVLUpOWUctV0hNTC0zN
ERVIiwKICAgICAgIkJhc2VVREYiOiAiTUFCRy02WkxMLUkyRk0tS1VLWC1UTTdFLU
9WQUotTTVRUCIsCiAgICAgICJPdmVybGF5IjogewogICAgICAgICJQcml2YXRlS2V
5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICAgICAgIlBy
aXZhdGUiOiAiaGNoRXM1SXM4OURfQjg5XzA0WTI0ZGF1MTJQN2hWdkdsSVk1SkpWU
mV2UkV3R0xac3VSCiAgYURuc0pURGFXN3lFYkt3UU1UZGhreTVrIn19fSwKICAgIC
JLZXlFbmNyeXB0aW9uIjogewogICAgICAiVURGIjogIk1EQlMtVlVFTS1UNExOLVY
2U0ctT0xBWi1EQlhELUJFS1IiLAogICAgICAiQmFzZVVERiI6ICJNQjNMLVROV1gt
SE5aSS1GRkhOLUlKUlotSFNPRi1OS1pMIiwKICAgICAgIk92ZXJsYXkiOiB7CiAgI
CAgICAgIlByaXZhdGVLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6ICJFZDQ0OC
IsCiAgICAgICAgICAiUHJpdmF0ZSI6ICJpZHZrM1R0YlZfdEUxUDBqRUZ5TVpBbnJ
PV3JPRG93NlRudnN1TnBHVUlycXRlUWFSSEwKICBNMzV0QTUzTmNhN0Z5bDJfOE5w
QTg1UHMifX19LAogICAgIktleUF1dGhlbnRpY2F0aW9uIjogewogICAgICAiVURGI
jogIk1DMk8tWVBBNC1OWllKLTRYWVgtTFY3Uy1UVkNWLU9ESUgiLAogICAgICAiQm
FzZVVERiI6ICJNRDZOLVZRNEgtNkVRTy1EVDNTLUlVTU4tQzVPSi1DRFhSIiwKICA
gICAgIk92ZXJsYXkiOiB7CiAgICAgICAgIlByaXZhdGVLZXlFQ0RIIjogewogICAg
ICAgICAgImNydiI6ICJFZDQ0OCIsCiAgICAgICAgICAiUHJpdmF0ZSI6ICJTcTVMM
TRETW1zQ0cwV0M0Z0J6YzNSR01xNFFTcmwxREJhdXRhRURTTlFGTFFQUkZENEMKIC
BSMmgxSXEwNTdIS3VOazVJRFZpaWRzeUEifX19fX0"
]}}
The derivation of the Connection encryption and signature keys from
the Profile and Private contributions in this example is shown in
[draft-hallambaker-mesh-cryptography] .
4.1.2.1. Creating a ProfileDevice
Creating a ProfileDevice comprises the steps of:
1. Creating the necessary key
2. Signing the ProfileDevice using the Master Signature Key
Hallam-Baker Expires February 14, 2020 [Page 16]
Internet-Draft Mesh Schema Reference August 2019
3. Once created, a ProfileDevice is never changed. In the unlikely
event that any modification is required, a completely new
ProfileDevice MUST be created.
4.1.2.2. Connection to a Personal Mesh
Devices are only connected to a personal Mesh by administration
device. This comprises the steps of:
1. Generating the PrivateDevice keys.
2. Creating the ConnectionDevice data from the public components of
the ProfileDevice and PrivateDevice keys and signing it using the
administration key.
3. Creating the Activations for the device and signing them using
the administration key.
4. Creating the CatalogEntryDevice for the device and adding it to
the CatalogDevice of the Personal Mesh.
5. If the Personal Mesh has accounts that are connected to a Mesh
Service, synchronizing the CatalogEntryDevice to those services.
4.2. Mesh Accounts
Mesh Accounts contains all the stateful information (contacts,
calendar entries, inbound and outbound messages, etc.) related to a
particular persona used by the owner.
A Mesh Profile MAY be connected to multiple accounts at the same time
allowing the user to maintain separate personas for separate
purposes.
Unlike traditional Internet application accounts, Mesh accounts are
created by and belong to the user, not the Mesh Service provider. A
user MAY change their Mesh Service provider at any time and
disconnect the profile from all Mesh Services (e.g. to archive the
account).
Alice's personal account is connected to two Mesh services:
[[This figure is not viewable in this format. The figure is
available at http://mathmesh.com/Documents/draft-hallambaker-mesh-
schema.html [6].]]
Account Profile Connected to Devices and Services.
Hallam-Baker Expires February 14, 2020 [Page 17]
Internet-Draft Mesh Schema Reference August 2019
The account profile specifies the online and offline signature keys
used to maintain the profile and the encryption key to be used by the
account.
{
"ProfileAccount":{
"MeshProfileUDF":"MAOZ-3MVE-G5EN-64BI-I3RM-ODFJ-H5W4",
"KeyEncryption":{
"UDF":"MAFZ-VUMP-7PU3-4TP7-7MRZ-BKBQ-VMNN",
"PublicParameters":{
"PublicKeyECDH":{
"crv":"Ed448",
"Public":"1lcZUNjHGJWkPWmS9MHeGYNfDSZGUO4lGk5Xpq7XgH--SGL
QE4E_s-0b0PI8m0fjtzIMUEYDI_IA"}}}}}
Each device using the account requires an activation record:
{
"ActivationAccount":{
"AccountUDF":"MAFZ-VUMP-7PU3-4TP7-7MRZ-BKBQ-VMNN",
"EnvelopedAssertionAccountConnection":[{
"dig":"S512"},
"ewogICJDb25uZWN0aW9uQWNjb3VudCI6IHsKICAgICJLZXlTaWduYXR1cmUi
OiB7CiAgICAgICJVREYiOiAiTURZTC02RzJBLVkzRUctVTNGRy1IQVkzLVNOTE4tT
llQMiIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdWJsaW
NLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6ICJFZDQ0OCIsCiAgICAgICAgICA
iUHVibGljIjogIkkzcDFocE50YnN3dWhEaU5kdGxNVnBTMVF0amxjbkh0bmZxdE5I
WHFYVVBxT1pZbTF0WGIKICAxUDRNRWZjQXZvVHlNZ1lZdUZWdXlBV0EifX19LAogI
CAgIktleUVuY3J5cHRpb24iOiB7CiAgICAgICJVREYiOiAiTUFGWi1WVU1QLTdQVT
MtNFRQNy03TVJaLUJLQlEtVk1OTiIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjo
gewogICAgICAgICJQdWJsaWNLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6ICJF
ZDQ0OCIsCiAgICAgICAgICAiUHVibGljIjogIjFsY1pVTmpIR0pXa1BXbVM5TUhlR
1lOZkRTWkdVTzRsR2s1WHBxN1hnSC0tU0dMUUU0RV8KICBzLTBiMFBJOG0wZmp0ek
lNVUVZRElfSUEifX19LAogICAgIktleUF1dGhlbnRpY2F0aW9uIjogewogICAgICA
iVURGIjogIk1DTlctUVVSTi1XNzVFLVRIRTYtUDJSQS1RN1BOLUlNVFkiLAogICAg
ICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgICAiUHVibGljS2V5RUNESCI6I
HsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICAgICAgIlB1YmxpYyI6IC
JjRW5xYWkyWmU0NTFNVHBQSWNPNDFlcHZPTlNaOFk2d2dQMFZ1N2o4ckcwbTZHMUd
LWUplCiAgSlJEUTROMEhTUVFkUUVGMjNDaHkxWFNBIn19fX19",
{
"signatures":[{
"signature":"jm8gei5o49kwvBEbFGB9E9SpxdmIpoTzF7QXqL2IGF
e8dCsPfbDQKkO0x7v95Aw7SsOZ7p_KLysAJJg5ly8W02jwhQhLa4DCf2sthWA82yv
yHnMFysD4rAzyxi3J9b2BEXpS8e_OXKcy_Y5syjq-_gAA"}
],
"PayloadDigest":"oKJFUfV-FrLaHCbGvk_GTyUVxRPGSgUM5AuwnuHgLK
ANfb_cz0GIHDiYCpIYIbWnajerZZDNARd8R_4M5va4Ow"}
],
Hallam-Baker Expires February 14, 2020 [Page 18]
Internet-Draft Mesh Schema Reference August 2019
"KeyEncryption":{
"Public":{
"PublicKeyECDH":{
"crv":"Ed448",
"Public":"1lcZUNjHGJWkPWmS9MHeGYNfDSZGUO4lGk5Xpq7XgH--SGL
QE4E_s-0b0PI8m0fjtzIMUEYDI_IA"}},
"Part":{
"PrivateKeyECDH":{
"crv":"Ed448",
"Private":"0wzAsNH-Ft8i3GcK585BXuECOXwQCS1V_bPJxhjHURA7we
SPHfLh-ThoRkAF6Em0jtST4mG0FBI"}}},
"KeyAuthentication":{
"UDF":"MCNW-QURN-W75E-THE6-P2RA-Q7PN-IMTY",
"BaseUDF":"MD6N-VQ4H-6EQO-DT3S-IUMN-C5OJ-CDXR",
"Overlay":{
"PrivateKeyECDH":{
"crv":"Ed448",
"Private":"8E50eTfRcL9ghQUyOnSvI3wagGsYGQaKSXj09KxNRMzq5T
DaKD-E-HroSc8wJapds-bHDSoShgM"}}},
"KeySignature":{
"UDF":"MDYL-6G2A-Y3EG-U3FG-HAY3-SNLN-NYP2",
"BaseUDF":"MABG-6ZLL-I2FM-KUKX-TM7E-OVAJ-M5QP",
"Overlay":{
"PrivateKeyECDH":{
"crv":"Ed448",
"Private":"Ye28IFBvRvxKCc5r5c-cAPYjGhLFw_dCt5ScuFzAx7bAlt
WviYPsk_bD5ndt3oKReFUT30EpFOg"}}}}}
4.2.1. Creating a ProfileAccount
Creating a ProfileAccount comprises the steps of:
1. [TBS]
2. .
3. Signing the ProfileMaster using the Master Signature Key
4.2.2. Connecting a Device to an Account
Adding a device to an account comprises the steps of:
1. Creating a PrivateAccount instance for the device.
2. Creating a ConnectionAccountDevice for the device using the
public keys from the PrivateAccount instance and the
ProfileDevice.
Hallam-Baker Expires February 14, 2020 [Page 19]
Internet-Draft Mesh Schema Reference August 2019
3. Creating an ActivationAccount for the device containing the
PrivateAccount and ConnectionAccountDevice instances.
4. Adding the ActivationAccount to the CatalogEntryDevice of the
device.
5. If the Personal Mesh has accounts that are connected to a Mesh
Service, synchronizing the CatalogEntryDevice to those services.
4.2.3. Binding and Account to a Service
Binding a ProfileAccount to a Mesh Service the steps of:
1. [TBS]
2. .
3. Signing the ProfileMaster using the Master Signature Key
4.3. Mesh Services
A service profile provides the axiom of trust and cryptographic keys
for a Mesh Service. A Mesh Service Host SHOULD return a copy of its
ProfileHost and the parent ProfileService in response to a Hello
transaction request.
[[This figure is not viewable in this format. The figure is
available at http://mathmesh.com/Documents/draft-hallambaker-mesh-
schema.html [7].]]
Service Profile and Delegated Host Assertion.
The credentials provided by the ProfileService and ProfileHost are
distinct from those provided by the WebPKI that typically services
TLS requests. WebPKI credentials provide service introduction and
authentication while a Mesh ProfileHost only provides authentication.
Unless exceptional circumstances require, a service should not need
to revise its Service Profile unless it is intended to change its
identity. Service Profiles MAY be countersigned by Trusted Third
Parties to establish accountability.
The service profile
Hallam-Baker Expires February 14, 2020 [Page 20]
Internet-Draft Mesh Schema Reference August 2019
{
"ProfileService":{
"KeyOfflineSignature":{
"UDF":"MBCP-OGFY-KFAQ-6EO3-VX6S-6V4G-ENNU",
"PublicParameters":{
"PublicKeyECDH":{
"crv":"Ed448",
"Public":"mHlROSazpUTzwFNZ0qI1MbXjpthOUxple0W8NUaq8M71VT5
eNwXjcfQ-tMlLgwq_Uff1FGmmlH-A"}}}}}
The host also has a profile
{
"ProfileHost":{
"KeyOfflineSignature":{
"UDF":"MDKQ-VTTD-HQKB-YH6O-H57C-4KDH-6KWI",
"PublicParameters":{
"PublicKeyECDH":{
"crv":"Ed448",
"Public":"ouDlKyIUksS_CWUhqoWaPFP93Ka9Zg53dQCC44guaGOBB9S
12eHlz2KoX9-PctQH31567TcmMDCA"}}},
"KeyAuthentication":{
"UDF":"MC3D-ID62-L5VZ-IWLC-WRLX-7FTT-F7ST",
"PublicParameters":{
"PublicKeyECDH":{
"crv":"Ed448",
"Public":"4BfeW0WQB5O3EOrjW4LvAdkLz71BtJsls3wzw0acuH5Edup
WWT8vE3MObkkfmD_4tPZ7B6VanteA"}}}}}
And there should be a connection of the host to the service but this
isn't implemented yet:
$$$$ Empty $$$$
4.3.1. Creating a ProfileService
[TBS]
Creating a ProfileService comprises the steps of:
1. [TBS]
2. .
3. [TBS]
4.
Hallam-Baker Expires February 14, 2020 [Page 21]
Internet-Draft Mesh Schema Reference August 2019
5. Signing the ProfileMaster using the Master Signature Key
4.3.2. Creating a ProfileHost
Creating a ProfileHost comprises the steps of:
1. [TBS]
2. .
3. [TBS]
4.
5. Signing the ConnectionHost using the Master Signature Key of the
ProfileService.
4.3.3. Creating a ConnectionHost
Creating a ConnectionHost comprises the steps of:
1. [TBS]
2. .
3. Signing the ConnectionHost using the Master Signature Key of the
ProfileService.
4.4. Mesh Messaging
Mesh Messaging is an end-to-end secure messaging system used to
exchange short (32KB) messages between Mesh devices and services. In
cases where exchange of longer messages is required, Mesh Messaging
MAY be used to provide a control plane to advise the intended message
recipient(s) of the type of data being offered and the means of
retrieval (e.g an EARL).
A four-corner messaging model is enforced. Mesh Services only accept
outbound messages from devices connected to accounts that it
services. Inbound messages are only accepted from other Mesh
Services. This model enables access control at both the outbound and
inbound services
Hallam-Baker Expires February 14, 2020 [Page 22]
Internet-Draft Mesh Schema Reference August 2019
[[This figure is not viewable in this format. The figure is
available at http://mathmesh.com/Documents/draft-hallambaker-mesh-
schema.html [8].]]
Performing Access Control on Outbound Messages
The outbound Mesh Service checks to see that the message request does
not violate its acceptable use policy. Accounts that make a large
number of message requests that result in complaints SHOULD be
subject to consequences ranging from restriction of the number and
type of messages sent to suspending or terminating messaging
privileges.
[[This figure is not viewable in this format. The figure is
available at http://mathmesh.com/Documents/draft-hallambaker-mesh-
schema.html [9].]]
Performing Access Control on Outbound Messages
The inbound Mesh Service also checks to see that messages received
are consistent with the service Acceptable Use Policy and the user's
personal access control settings.
Mesh Services that fail to police abuse by their account holders
SHOULD be subject to consequences in the same fashion as account
holders.
[[This figure is not viewable in this format. The figure is
available at http://mathmesh.com/Documents/draft-hallambaker-mesh-
schema.html [10].]]
Performing Access Control on Inbound Messages
4.4.1. Traffic Analysis
The Mesh Messaging protocol as currently specified provides only
limited protection against traffic analysis attacks. The use of TLS
to encrypt communication between Mesh Services limits the
effectiveness of na?ve traffic analysis mechanisms but does not
prevent timing attacks unless dummy traffic is introduced to
obfuscate traffic flows.
The limitation of the message size is in part intended to facilitate
use of mechanisms capable of providing high levels of traffic
analysis such as mixmaster and onion routing but the current Mesh
Hallam-Baker Expires February 14, 2020 [Page 23]
Internet-Draft Mesh Schema Reference August 2019
Service Protocol does not provide support for such approaches and
there are no immediate plans to do so.
5. Mesh Catalogs
Catalogs track sets of persistent objects associated with a Mesh
Service Account. The Mesh Service has no access to the entries in
any Mesh catalog except for the Device and Contacts catalog which are
used in device authentication and authorization of inbound messages.
Each Mesh Catalog managed by a Mesh Account has a name of the form:
<<prefix>_<name>
Where <<prefix> is the IANA assigned service name. The assigned
service name for the Mathematical Mesh is mmm. Thus, all catalogs
specified by the Mesh schema have names prefixed with the sequence
mmm_.
The following catalogs are currently specified within the
Mathematical Mesh.
Application: mmm_CatalogApplication Contains configuration
information for applications including mail (SMTP, IMAP, OpenPGP,
S/MIME, etc) and SSH and for the MeshAccount application itself.
Device: mmm_CatalogDevice Contains descriptions of devices connected
to the account and the permissions assigned to them
Contact: mmm_CatalogContact Contains logical and physical contact
information for people and organizations.
Credential: mmm_CatalogCredential Contains credentials used to
access network resources.
Bookmark: mmm_CatalogBookmark Contains Web bookmarks and other
citations allowing them to be shared between devices connected to
the profile.
Task: mmm_CatalogTask Contains tasks assigned to the user including
calendar entries and to do lists.
Network: mmm_CatalogNetwork Contains network settings such as WiFi
access points, IPSEC and TLS VPN configurations, etc.
In many cases, the Mesh Catalog offers capabilities that represent a
superset of the capabilities of an existing application. For
example, the task catalog supports the appointment tracking functions
Hallam-Baker Expires February 14, 2020 [Page 24]
Internet-Draft Mesh Schema Reference August 2019
of a traditional calendar application and the task tracking function
of the traditional 'to do list' application. Combining these
functions allows tasks to be triggered by other events other than the
passage of time such as completion of other tasks, geographical
presence, etc.
In such cases, the Mesh Catalog entries are designed to provide a
superset of the data representation capabilities of the legacy
formats and (where available) recent extensions. Where a catalog
entry is derived from input presented in a legacy format, the
original data representation MAY be attached verbatim to facilitate
interoperability.
5.1. Application
The application catalog mmm_CatalogApplication contains
CatalogEntryApplication entries which describe the use of specific
applications under the Mesh Service Account. Multiple application
accounts for a single application MAY be connected to a single Mesh
Service Account. Each account being specified in a separate entry.
The CatalogEntryApplication entries only contain configuration
information for the application as it applies to the account as a
whole. If the application requires separate configuration for
individual devices, this is specified in separate activation records
specified in the corresponding ConnectionDevice.
5.1.1. Mesh Account
Mesh Accounts are described by CatalogEntryAccount entries. The
corresponding activation records for the connected devices contain
the contributions used to derive the private keys for use of the
account.
The CatalogEntryAccount entry is described in the section describing
Mesh accounts above.
5.1.2. SSH
SSH configuration profiles are described by
CatalogEntryApplicationSSH entries. The corresponding activation
records for the connected devices contain the contributions used to
derive the private keys.
A user may have separate SSH configurations for separate purposes
within a single Mesh Account. This allows a system administrator
servicing multiple clients to maintain separate SSH profiles for each
Hallam-Baker Expires February 14, 2020 [Page 25]
Internet-Draft Mesh Schema Reference August 2019
of her customers allowing credentials to be easily (and verifiably)
revoked at contract termination.
The SSH profile contains the information that is stored in the
known_hosts and authorized_keys files of SSH clients and servers.
$$$$ Empty $$$$
5.1.3. Mail
Mail configuration profiles are described by one or more
CatalogEntryApplicationMail entries, one for each email account
connected to the Mesh profile. The corresponding activation records
for the connected devices contain information used to provide the
device with the necessary decryption information.
Entries specify the email account address(es), the inbound and
outbound server configuration and the cryptographic keys to be used
for S/MIME and OpenPGP encryption.
$$$$ Empty $$$$
5.2. Device
The device catalog mmm_CatalogDevice contains CatalogEntryDevice
entries which describe the devices connected to the account and the
permissions assigned to them.
The management of the device catalog is described in the section
describing Mesh Device Management.
5.3. Contact
The contacts catalog contains CatalogEntryContact entries which
describe
$$$$ Empty $$$$
The fields of the contact catalog provide a superset of the
capabilities of vCard [RFC2426] .
The Contact catalog is typically used by the MeshService as a source
of authorization information to perform access control on inbound and
outbound message requests. For this reason, Mesh Service SHOULD be
granted read access to the contacts catalog by providing a decryption
entry for the service.
Hallam-Baker Expires February 14, 2020 [Page 26]
Internet-Draft Mesh Schema Reference August 2019
5.4. Credential
The credential catalog contains CatalogEntryCredential entries which
describe credentials used to access network resources.
Only username/password credentials are stored in the credential
catalog. If public key credentials are to be used, these SHOULD
be managed as an application profile allowing separate credentials
to be created for each device.
{
"CatalogedCredential":{
"Service":"ftp.example.com",
"Username":"alice1",
"Password":"newpassword"}}
5.5. Bookmark
The bookmark catalog contains CatalogEntryBookmark entries which
describe Web bookmarks and other citations allowing them to be shared
between devices connected to the profile.
The fields currently supported by the Bookmarks catalog are currently
limited to the fields required for tracking Web bookmarks.
Specification of additional fields to track full academic citations
is a work in progress.
{
"CatalogedBookmark":{
"Uri":"http://example.net/Bananas",
"Title":"\"Banana",
"Path":"Folder1/2"}}
5.6. Task
The Task catalog contains CatalogEntryTask entries which describe
tasks assigned to the user including calendar entries and to do
lists.
The fields of the task catalog currently reflect those offered by the
iCalendar specification [RFC5545] . Specification of additional
fields to allow task triggering on geographic location and/or
completion of other tasks is a work in progress.
{
"CatalogedTask":{
"Key":"CalID1"}}
Hallam-Baker Expires February 14, 2020 [Page 27]
Internet-Draft Mesh Schema Reference August 2019
5.7. Network
The network catalog contains CatalogEntryNetwork entries which
describe network settings, IPSEC and TLS VPN configurations, etc.
$$$$ Empty $$$$
6. Mesh Messages
All communications between Mesh accounts takes the form of a Mesh
Message carried in a Dare Envelope. Mesh Messages are stored in two
spools associated with the account, the SpoolOutbound and the
SpoolInbound containing the messages sent and received respectively.
This document only describes the representation of the messages
within the message spool. The Mesh Service protocol by which the
messages are exchanged between devices and services and between
services is described in [draft-hallambaker-mesh-protocol] .
6.1. Completion
Completion messages are dummy messages that are added to a Mesh Spool
to change the status of messages previously posted. Any message that
is in the inbound spool and has not been erased or redacted MAY be
marked as read, unread or deleted. Any message in the outbound spool
MAY be marked as sent, received or deleted.
Services MAY erase or redact messages in accordance with local site
policy. Since messages are not removed from the spool on being
marked deleted, they may be undeleted by marking them as read or
unread. Marking a message deleted MAY make it more likely that the
Service will purge the message however.
Having processed a message, a completion message is added to the
spool so that other devices can see that it has been read:
[NYI]
6.2. Connection
Connection requests are sent by a device requesting connection to a
Mesh Service Account.
The MessageConnectionRequest is originally sent by the device
requesting connection to the Mesh Service associated with the
account.
Hallam-Baker Expires February 14, 2020 [Page 28]
Internet-Draft Mesh Schema Reference August 2019
If the connection request is accepted by the Mesh Service, it creates
a MessageConnectionResponse containing the ServerNonce and Witness
values used in the authentication of the response together with a
verbatim copy of the original request. The MessageConnectionResponse
is then returned to the device that made the original request and
placed on the SpoolInbound of the account to which the request was
directed.
Further details of this mechanism are described in
[draft-hallambaker-mesh-protocol] .
The connection process begins with the assignment of a time-limited
PIN value. This is described in a Message sent by the administration
device to allow other admin devices to accept the request made.
[NYI]
The initial request is sent to the service
[NYI]
The service returns an acknowledgement giving the Witness value.
Note that this is not a 'reply' since it comes from the service, not
the user.
[NYI]
[Note, this mechanism should be revised to ensure that there is
perfect forward secrecy. The device should provide a nonce key as a
mixin]
6.3. Contact
A contact request presents a proposed contact entry and requests that
it be added to the Contacts catalog of the specified Mesh Service
Account. A contact request is usually sent by the party requesting
that their contact be added but this is not necessarily the case.
The MessageContact contains a DARE Envelope containing the Contact
information of the requester. If the request is accepted, this
information will be added to the contact catalog of the relevant
account. If the Reply field has the value 'true', this indicates
that the sender is asking for the recipient to return their own
credentials in reply.
Since the sender requires the user's contact information before the
request can be made, the MessageContact message MAY be encrypted
under either the user's account encryption key (if known) or the Mesh
Hallam-Baker Expires February 14, 2020 [Page 29]
Internet-Draft Mesh Schema Reference August 2019
Service encryption key (which may be obtained from the service on
request.
Bob asks Alice to send her contact details and sends his.
[NYI]
Alice responds with her details:
[NYI]
[Note that this exchange could be performed automatically on Alice's
behalf by the service if she delegates this action to it.]
The current protocol assumes that all contact management will be
performed end-to-end through the Mesh Services themselves. If the
number of Mesh users were to become very large, additional
infrastructure to facilitate contact management will be required.
These topics are discussed at a high level in
[draft-hallambaker-mesh-trust] .
In situations where a user is well known and has a very large number
of contacts, they are likely to make use of a tiered approach to
contact management in which they keep separate accounts for their
'public' and 'restricted' personas and delegate management of their
public account to a subordinate or to their Mesh Service provider.
6.4. Confirmation
Confirmation messages are used to provide an improved form of second
factor authentication capability.
Two confirmation messages are specified, a request and response.
A confirmation request is initiated by sending a
MessageConfirmationRequest to the Mesh Service hosting the recipient
Mesh Service Account. The request specifies the question that is to
be put to the user.
To respond to a confirmation request, a user generates a
MessageConfirmationResponse. This MUST be signed by a device
authorized to respond to confirmation requests by a Device Connection
Assertion with the Confirmation privilege.
The confirmation request
[NYI]
Hallam-Baker Expires February 14, 2020 [Page 30]
Internet-Draft Mesh Schema Reference August 2019
The confirmation response
[NYI]
7. Schema
7.1. Shared Classes
The following classes are used as common elements in Mesh profile
specifications.
7.1.1. Classes describing keys
7.1.2. Structure: PublicKey
The PublicKey class is used to describe public key pairs and trust
assertions associated with a public key.
UDF: String (Optional) UDF fingerprint of the public key parameters/
X509Certificate: Binary (Optional) List of X.509 Certificates
X509Chain: Binary [0..Many] X.509 Certificate chain.
X509CSR: Binary (Optional) X.509 Certificate Signing Request.
7.1.3. Structure: KeyComposite
Service: String (Optional) Service holding the additional
contribution
7.1.4. Structure: KeyOverlay
UDF: String (Optional) Fingerprint of the resulting composite key
(to allow verification)
BaseUDF: String (Optional) Fingerprint specifying the base key
7.1.5. Structure: EscrowedKeySet
A set of escrowed keys.
[No fields]
Hallam-Baker Expires February 14, 2020 [Page 31]
Internet-Draft Mesh Schema Reference August 2019
7.1.6. Structure: DeviceRecryptionKey
UDF: String (Optional) The fingerprint of the encryption key
RecryptionKey: PublicKey (Optional) The recryption key
EnvelopedRecryptionKeyDevice: DareEnvelope (Optional) The decryption
key encrypted under the user's device key.
7.2. Assertion classes
Classes that are derived from an assertion.
7.2.1. Structure: Assertion
Parent class from which all assertion classes are derived
Names: String [0..Many] Fingerprints of index terms for profile
retrieval. The use of the fingerprint of the name rather than the
name itself is a precaution against enumeration attacks and other
forms of abuse.
Updated: DateTime (Optional) The time instant the profile was last
modified.
NotaryToken: String (Optional) A Uniform Notary Token providing
evidence that a signature was performed after the notary token was
created.
7.2.2. Structure: Condition
Parent class from which all condition classes are derived.
[No fields]
7.2.3. Profile Classes
Profiles are self signed assertions.
7.2.4. Structure: Profile
Inherits: Assertion
Parent class from which all profile classes are derived
KeyOfflineSignature: PublicKey (Optional) The permanent signature
key used to sign the profile itself. The UDF of the key is used
as the permanent object identifier of the profile. Thus, by
Hallam-Baker Expires February 14, 2020 [Page 32]
Internet-Draft Mesh Schema Reference August 2019
definition, the KeySignature value of a Profile does not change
under any circumstance. The only case in which a
KeysOnlineSignature: PublicKey [0..Many] A Personal profile contains
at least one OSK which is used to sign device administration
application profiles.
7.2.5. Structure: ProfilePersonal
Inherits: Profile
Describes the long term parameters associated with a personal
profile.
KeysMasterEscrow: PublicKey [0..Many] A Personal Profile MAY contain
one or more PMEK keys to enable escrow of private keys used for
stored data.
KeyEncryption: PublicKey (Optional) Key used to pass encrypted data
to the device such as a DeviceUseEntry
7.2.6. Structure: ProfileDevice
Inherits: Profile
Describes a mesh device.
Description: String (Optional) Description of the device
KeyEncryption: PublicKey (Optional) Key used to pass encrypted data
to the device such as a DeviceUseEntry
KeyAuthentication: PublicKey (Optional) Key used to authenticate
requests made by the device.
7.2.7. Structure: ProfileService
Inherits: Profile
Profile of a Mesh Service
KeyAuthentication: PublicKey (Optional) Key used to authenticate
service connections.
Hallam-Baker Expires February 14, 2020 [Page 33]
Internet-Draft Mesh Schema Reference August 2019
7.2.8. Structure: ProfileAccount
Inherits: Profile
Account assertion. This is signed by the service hosting the
account.
ServiceIDs: String [0..Many] Service address(es).
MeshProfileUDF: String (Optional) Master profile of the account
being registered.
KeyEncryption: PublicKey (Optional) Key used to encrypt data under
this profile
7.2.9. Structure: ProfileGroup
Inherits: Profile
Describes a group. Note that while a group is created by one person
who becomes its first administrator, control of the group may pass to
other administrators over time.
[No fields]
7.2.10. Structure: ProfileHost
Inherits: Profile
Inherits: Profile
KeyAuthentication: PublicKey (Optional) Key used to authenticate
service connections.
7.2.11. Connection Classes
7.2.12. Structure: Connection
Inherits: Assertion
Inherits: Assertion
SubjectUDF: String (Optional) UDF of the connection target.
AuthorityUDF: String (Optional) UDF of the connection source.
Hallam-Baker Expires February 14, 2020 [Page 34]
Internet-Draft Mesh Schema Reference August 2019
7.2.13. Structure: Permission
Name: String (Optional)
Name: String (Optional)
Role: String (Optional)
Role: String (Optional)
Capabilities: DareEnvelope (Optional) Keys or key contributions
enabling the operation to be performed
7.2.14. Structure: ConnectionDevice
Inherits: Connection
Inherits: Connection
Permissions: Permission [0..Many] List of the permissions that the
device has been granted.
KeySignature: PublicKey (Optional) The signature key for use of the
device under the profile
KeyEncryption: PublicKey (Optional) The encryption key for use of
the device under the profile
KeyAuthentication: PublicKey (Optional) The authentication key for
use of the device under the profile
7.2.15. Structure: ConnectionAccount
Inherits: Connection
Inherits: Connection
Permissions: Permission [0..Many] List of the permissions that the
device has been granted.
KeySignature: PublicKey (Optional) The signature key for use of the
device under the profile
KeyEncryption: PublicKey (Optional) The encryption key for use of
the device under the profile
KeyAuthentication: PublicKey (Optional) The authentication key for
use of the device under the profile
Hallam-Baker Expires February 14, 2020 [Page 35]
Internet-Draft Mesh Schema Reference August 2019
7.2.16. Structure: ConnectionService
Inherits: Connection
[No fields]
7.2.17. Structure: ConnectionHost
Inherits: Connection
[No fields]
7.2.18. Structure: ConnectionApplication
Inherits: Connection
[No fields]
7.2.19. Activation Classes
7.2.20. Structure: Activation
Inherits: Assertion
Contains the private activation information for a Mesh application
running on a specific device
[No fields]
7.2.21. Structure: ActivationDevice
Inherits: Assertion
Inherits: Assertion
EnvelopedAssertionDeviceConnection: DareEnvelope (Optional) The
signed AssertionDeviceConnection.
KeySignature: KeyOverlay (Optional) The key overlay used to generate
the account signature key from the device signature key
KeyEncryption: KeyOverlay (Optional) The key overlay used to
generate the account encryption key from the device encryption key
KeyAuthentication: KeyOverlay (Optional) The key overlay used to
generate the account authentication key from the device
authentication key
Hallam-Baker Expires February 14, 2020 [Page 36]
Internet-Draft Mesh Schema Reference August 2019
7.2.22. Structure: ActivationAccount
Inherits: Activation
Inherits: Activation
AccountUDF: String (Optional) The UDF of the account
EnvelopedAssertionAccountConnection: DareEnvelope (Optional) The
account connection assertion
KeyEncryption: KeyComposite (Optional) The key contribution for the
decryption key for the device. NB this is NOT an overlay on the
device signature key, it is an overlay on the corresponding
recryption key.
KeyAuthentication: KeyOverlay (Optional) The key overlay used to
generate the account authentication key from the device
authentication key
KeySignature: KeyOverlay (Optional) The key overlay used to generate
the account signature key from the device signature key
7.3. Cataloged items
7.3.1. Data Structures
Classes describing data used in cataloged data.
7.3.2. Structure: Contact
Inherits: Assertion
Inherits: Assertion
Identifier: String (Optional)
Identifier: String (Optional)
FullName: String (Optional)
FullName: String (Optional)
Title: String (Optional)
Title: String (Optional)
First: String (Optional)
Hallam-Baker Expires February 14, 2020 [Page 37]
Internet-Draft Mesh Schema Reference August 2019
First: String (Optional)
Middle: String (Optional)
Middle: String (Optional)
Last: String (Optional)
Last: String (Optional)
Suffix: String (Optional)
Suffix: String (Optional)
Labels: String [0..Many]
Labels: String [0..Many]
AssertionAccounts: ProfileAccount [0..Many]
AssertionAccounts: ProfileAccount [0..Many]
Addresses: Address [0..Many]
Addresses: Address [0..Many]
Locations: Location [0..Many]
Locations: Location [0..Many]
Roles: Role [0..Many]
7.3.3. Structure: Role
CompanyName: String (Optional)
CompanyName: String (Optional)
Addresses: Address [0..Many]
Addresses: Address [0..Many]
Locations: Location [0..Many]
Hallam-Baker Expires February 14, 2020 [Page 38]
Internet-Draft Mesh Schema Reference August 2019
7.3.4. Structure: Address
URI: String (Optional)
URI: String (Optional)
Labels: String [0..Many]
7.3.5. Structure: Location
Appartment: String (Optional)
Appartment: String (Optional)
Street: String (Optional)
Street: String (Optional)
District: String (Optional)
District: String (Optional)
Locality: String (Optional)
Locality: String (Optional)
County: String (Optional)
County: String (Optional)
Postcode: String (Optional)
Postcode: String (Optional)
Country: String (Optional)
7.3.6. Structure: Reference
MessageID: String (Optional) The received message to which this is a
response
ResponseID: String (Optional) Message that was generated in response
to the original (optional).
Relationship: String (Optional) The relationship type. This can be
Read, Unread, Accept, Reject.
Hallam-Baker Expires February 14, 2020 [Page 39]
Internet-Draft Mesh Schema Reference August 2019
7.3.7. Structure: Task
Key: String (Optional) Unique key.
Start: DateTime (Optional)
Start: DateTime (Optional)
Finish: DateTime (Optional)
Finish: DateTime (Optional)
StartTravel: String (Optional)
StartTravel: String (Optional)
FinishTravel: String (Optional)
FinishTravel: String (Optional)
TimeZone: String (Optional)
TimeZone: String (Optional)
Title: String (Optional)
Title: String (Optional)
Description: String (Optional)
Description: String (Optional)
Location: String (Optional)
Location: String (Optional)
Trigger: String [0..Many]
Trigger: String [0..Many]
Conference: String [0..Many]
Conference: String [0..Many]
Repeat: String (Optional)
Repeat: String (Optional)
Hallam-Baker Expires February 14, 2020 [Page 40]
Internet-Draft Mesh Schema Reference August 2019
Busy: Boolean (Optional)
7.4. Catalog Entries
7.4.1. Structure: CatalogedEntry
Base class for cataloged Mesh data.
[No fields]
7.4.2. Structure: CatalogedDevice
Inherits: CatalogedEntry
Public device entry, indexed under the device ID
AccountUDFs: String [0..Many] The accounts to which this device is
bound.
UDF: String (Optional) UDF of the signature key of the device in the
Mesh
DeviceUDF: String (Optional) UDF of the signature key of the device
EnvelopedProfileDevice: DareEnvelope (Optional) The device profile
EnvelopedConnectionDevice: DareEnvelope (Optional) The public
assertion demonstrating connection of the Device to the Mesh
EnvelopedActivationDevice: DareEnvelope (Optional) The device
profile
7.4.3. Structure: CatalogedCredential
Inherits: CatalogedEntry
Inherits: CatalogedEntry
Protocol: String (Optional)
Protocol: String (Optional)
Service: String (Optional)
Service: String (Optional)
Username: String (Optional)
Hallam-Baker Expires February 14, 2020 [Page 41]
Internet-Draft Mesh Schema Reference August 2019
Username: String (Optional)
Password: String (Optional)
7.4.4. Structure: CatalogedNetwork
Inherits: CatalogedEntry
Inherits: CatalogedEntry
Protocol: String (Optional)
Protocol: String (Optional)
Service: String (Optional)
Service: String (Optional)
Username: String (Optional)
Username: String (Optional)
Password: String (Optional)
7.4.5. Structure: CatalogedContact
Inherits: CatalogedEntry
Inherits: CatalogedEntry
Self: Boolean (Optional) If true, this catalog entry is for the user
who created the catalog. To be valid, such an entry MUST be
signed by an administration key for the Mesh profile containing
the account to which the catalog belongs.
Key: String (Optional) Unique key.
Permissions: Permission [0..Many] List of the permissions that the
contact has been granted.
EnvelopedContact: DareEnvelope (Optional) The (signed) contact data.
7.4.6. Structure: CatalogedContactRecryption
Inherits: CatalogedContact
[No fields]
Hallam-Baker Expires February 14, 2020 [Page 42]
Internet-Draft Mesh Schema Reference August 2019
7.4.7. Structure: CatalogedBookmark
Inherits: CatalogedEntry
Inherits: CatalogedEntry
Uri: String (Optional)
Uri: String (Optional)
Title: String (Optional)
Title: String (Optional)
Path: String (Optional)
7.4.8. Structure: CatalogedTask
Inherits: CatalogedEntry
Inherits: CatalogedEntry
EnvelopedTask: DareEnvelope (Optional)
EnvelopedTask: DareEnvelope (Optional)
Key: String (Optional) Unique key.
7.4.9. Structure: CatalogedApplication
Inherits: CatalogedEntry
Inherits: CatalogedEntry
Key: String (Optional)
7.4.10. Structure: CatalogedApplicationAccount
Wrapper for a signed AccountAssertion
Inherits: CatalogedApplication
Inherits: CatalogedApplication
EnvelopedProfileAccount: DareEnvelope (Optional) The account
assertion
Hallam-Baker Expires February 14, 2020 [Page 43]
Internet-Draft Mesh Schema Reference August 2019
7.4.11. Structure: CatalogedMember
UDF: String (Optional)
UDF: String (Optional)
Inherits: CatalogedEntry
7.4.12. Structure: CatalogedGroup
Inherits: CatalogedApplication
[No fields]
7.4.13. Structure: CatalogedApplicationSSH
Inherits: CatalogedApplication
[No fields]
7.4.14. Structure: CatalogedApplicationMail
Inherits: CatalogedApplication
[No fields]
7.4.15. Structure: CatalogedApplicationNetwork
Inherits: CatalogedApplication
[No fields]
7.5. Messages
7.5.1. Structure: Message
MessageID: String (Optional)
MessageID: String (Optional)
Sender: String (Optional)
Sender: String (Optional)
Recipient: String (Optional)
Recipient: String (Optional)
Hallam-Baker Expires February 14, 2020 [Page 44]
Internet-Draft Mesh Schema Reference August 2019
References: Reference [0..Many]
7.5.2. Structure: MessageComplete
Inherits: Message
[No fields]
7.5.3. Structure: MessagePIN
Account: String (Optional)
Account: String (Optional)
Inherits: Message
Inherits: Message
Expires: DateTime (Optional)
Expires: DateTime (Optional)
PIN: String (Optional)
7.5.4. Structure: RequestConnection
Connection request message. This message contains the information
Inherits: Message
Inherits: Message
ServiceID: String (Optional)
ServiceID: String (Optional)
EnvelopedProfileDevice: DareEnvelope (Optional) Device profile of
the device making the request.
ClientNonce: Binary (Optional)
ClientNonce: Binary (Optional)
PinUDF: String (Optional) Fingerprint of the PIN value used to
authenticate the request.
Hallam-Baker Expires February 14, 2020 [Page 45]
Internet-Draft Mesh Schema Reference August 2019
7.5.5. Structure: AcknowledgeConnection
Connection request message generated by a service on receipt of a
valid MessageConnectionRequestClient
Inherits: Message
Inherits: Message
EnvelopedRequestConnection: DareEnvelope (Optional) The client
connection request.
ServerNonce: Binary (Optional)
ServerNonce: Binary (Optional)
Witness: String (Optional)
7.5.6. Structure: RequestContact
Inherits: Message
Inherits: Message
Reply: Boolean (Optional)
Reply: Boolean (Optional)
Self: DareEnvelope (Optional) The contact data.
7.5.7. Structure: RequestConfirmation
Inherits: Message
Inherits: Message
Text: String (Optional)
7.5.8. Structure: ResponseConfirmation
Inherits: Message
Inherits: Message
ResponseID: String (Optional)
ResponseID: String (Optional)
Hallam-Baker Expires February 14, 2020 [Page 46]
Internet-Draft Mesh Schema Reference August 2019
Accept: Boolean (Optional)
7.5.9. Structure: RequestTask
Inherits: Message
[No fields]
8. Security Considerations
The security considerations for use and implementation of Mesh
services and applications are described in the Mesh Security
Considerations guide [draft-hallambaker-mesh-security] .
9. IANA Considerations
All the IANA considerations for the Mesh documents are specified in
this document
10. Acknowledgements
A list of people who have contributed to the design of the Mesh is
presented in [draft-hallambaker-mesh-architecture] .
11. References
11.1. Normative References
[draft-hallambaker-mesh-architecture]
Hallam-Baker, P., "Mathematical Mesh 3.0 Part I:
Architecture Guide", draft-hallambaker-mesh-
architecture-09 (work in progress), July 2019.
[draft-hallambaker-mesh-cryptography]
Hallam-Baker, P., "Mathematical Mesh 3.0 Part VIII:
Cryptographic Algorithms", draft-hallambaker-mesh-
cryptography-02 (work in progress), July 2019.
[draft-hallambaker-mesh-notary]
"[Reference Not Found!]".
[draft-hallambaker-mesh-protocol]
Hallam-Baker, P., "Mathematical Mesh Part V: Protocol
Reference", draft-hallambaker-mesh-protocol-01 (work in
progress), July 2019.
Hallam-Baker Expires February 14, 2020 [Page 47]
Internet-Draft Mesh Schema Reference August 2019
[draft-hallambaker-mesh-security]
Hallam-Baker, P., "Mathematical Mesh Part VII: Security
Considerations", draft-hallambaker-mesh-security-01 (work
in progress), July 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997.
11.2. Informative References
[draft-hallambaker-mesh-developer]
Hallam-Baker, P., "Mathematical Mesh: Reference
Implementation", draft-hallambaker-mesh-developer-08 (work
in progress), April 2019.
[draft-hallambaker-mesh-trust]
Hallam-Baker, P., "Mathematical Mesh Part VI: The Trust
Mesh", draft-hallambaker-mesh-trust-02 (work in progress),
July 2019.
[RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile",
RFC 2426, DOI 10.17487/RFC2426, September 1998.
[RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling
Core Object Specification (iCalendar)", RFC 5545,
DOI 10.17487/RFC5545, September 2009.
11.3. URIs
[1] http://mathmesh.com/Documents/draft-hallambaker-mesh-schema.html
[2] http://mathmesh.com/Documents/draft-hallambaker-mesh-schema.html
[3] http://mathmesh.com/Documents/draft-hallambaker-mesh-schema.html
[4] http://mathmesh.com/Documents/draft-hallambaker-mesh-schema.html
[5] http://mathmesh.com/Documents/draft-hallambaker-mesh-schema.html
[6] http://mathmesh.com/Documents/draft-hallambaker-mesh-schema.html
[7] http://mathmesh.com/Documents/draft-hallambaker-mesh-schema.html
[8] http://mathmesh.com/Documents/draft-hallambaker-mesh-schema.html
[9] http://mathmesh.com/Documents/draft-hallambaker-mesh-schema.html
Hallam-Baker Expires February 14, 2020 [Page 48]
Internet-Draft Mesh Schema Reference August 2019
[10] http://mathmesh.com/Documents/draft-hallambaker-mesh-schema.html
Author's Address
Phillip Hallam-Baker
Email: phill@hallambaker.com
Hallam-Baker Expires February 14, 2020 [Page 49]