[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02 03 04 05 06 07
Network Working Group P. M. Hallam-Baker
Internet-Draft ThresholdSecrets.com
Intended status: Informational 13 January 2021
Expires: 17 July 2021
Mathematical Mesh 3.0 Part IV: Schema Reference
draft-hallambaker-mesh-schema-07
Abstract
The Mathematical Mesh 'The Mesh' is an end-to-end secure
infrastructure that facilitates the exchange of configuration and
credential data between multiple user devices. The core protocols of
the Mesh are described with examples of common use cases and
reference data.
[Note to Readers]
Discussion of this draft takes place on the MATHMESH mailing list
(mathmesh@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/search/?email_list=mathmesh.
This document is also available online at
http://mathmesh.com/Documents/draft-hallambaker-mesh-schema.html.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 17 July 2021.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
Hallam-Baker Expires 17 July 2021 [Page 1]
Internet-Draft Mesh Schema Reference January 2021
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 6
2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Related Specifications . . . . . . . . . . . . . . . . . 6
2.4. Implementation Status . . . . . . . . . . . . . . . . . . 6
3. Actors . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Accounts . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Device . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.1. Activation . . . . . . . . . . . . . . . . . . . . . 10
3.3. Service . . . . . . . . . . . . . . . . . . . . . . . . . 12
4. Catalogs . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Access . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2. Application . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.1. Mesh Account . . . . . . . . . . . . . . . . . . . . 15
4.2.2. SSH . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.3. Mail . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3. Bookmark . . . . . . . . . . . . . . . . . . . . . . . . 16
4.4. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.5. Credential . . . . . . . . . . . . . . . . . . . . . . . 20
4.6. Device . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.7. Network . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.8. Publication . . . . . . . . . . . . . . . . . . . . . . . 20
4.9. Task . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5. Spools . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.1. Outbound . . . . . . . . . . . . . . . . . . . . . . . . 22
5.2. Inbound . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.3. Local . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6. Cryptographic Operations . . . . . . . . . . . . . . . . . . 23
6.1. Key Derivation from Seed . . . . . . . . . . . . . . . . 23
6.2. Message Envelope and Response Identifiers. . . . . . . . 23
6.3. Proof of Knowledge of PIN . . . . . . . . . . . . . . . . 24
6.4. EARL . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.5. Key Agreement . . . . . . . . . . . . . . . . . . . . . . 27
6.6. Service Cryptographic Operations . . . . . . . . . . . . 27
7. Mesh Assertions . . . . . . . . . . . . . . . . . . . . . . . 28
7.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 28
7.2. Mesh Profiles . . . . . . . . . . . . . . . . . . . . . . 29
7.3. Mesh Connections . . . . . . . . . . . . . . . . . . . . 30
8. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 31
Hallam-Baker Expires 17 July 2021 [Page 2]
Internet-Draft Mesh Schema Reference January 2021
8.1. Mesh Account . . . . . . . . . . . . . . . . . . . . . . 32
8.1.1. Account Profile . . . . . . . . . . . . . . . . . . . 32
8.2. Device Management . . . . . . . . . . . . . . . . . . . . 33
8.2.1. The Device Catalog . . . . . . . . . . . . . . . . . 34
8.2.2. Mesh Devices . . . . . . . . . . . . . . . . . . . . 34
8.3. Mesh Services . . . . . . . . . . . . . . . . . . . . . . 36
8.4. Mesh Messaging . . . . . . . . . . . . . . . . . . . . . 37
8.4.1. Message Status . . . . . . . . . . . . . . . . . . . 37
8.4.2. Four Corner Model . . . . . . . . . . . . . . . . . . 38
8.4.3. Traffic Analysis . . . . . . . . . . . . . . . . . . 38
9. Publications . . . . . . . . . . . . . . . . . . . . . . . . 39
9.1. Contact Exchange . . . . . . . . . . . . . . . . . . . . 39
9.2. Device Preconfiguration . . . . . . . . . . . . . . . . . 39
9.3. Device Description . . . . . . . . . . . . . . . . . . . 41
10. Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
10.1. Shared Classes . . . . . . . . . . . . . . . . . . . . . 42
10.1.1. Classes describing keys . . . . . . . . . . . . . . 42
10.1.2. Structure: KeyData . . . . . . . . . . . . . . . . . 42
10.1.3. Structure: CompositePrivate . . . . . . . . . . . . 42
10.2. Assertion classes . . . . . . . . . . . . . . . . . . . 42
10.2.1. Structure: Assertion . . . . . . . . . . . . . . . . 42
10.2.2. Structure: Condition . . . . . . . . . . . . . . . . 43
10.2.3. Base Classes . . . . . . . . . . . . . . . . . . . . 43
10.2.4. Structure: Connection . . . . . . . . . . . . . . . 43
10.2.5. Structure: Activation . . . . . . . . . . . . . . . 43
10.2.6. Structure: ActivationEntry . . . . . . . . . . . . . 43
10.2.7. Mesh Profile Classes . . . . . . . . . . . . . . . . 43
10.2.8. Structure: Profile . . . . . . . . . . . . . . . . . 44
10.2.9. Structure: ProfileDevice . . . . . . . . . . . . . . 44
10.2.10. Structure: ProfileAccount . . . . . . . . . . . . . 44
10.2.11. Structure: ProfileUser . . . . . . . . . . . . . . . 45
10.2.12. Structure: ProfileGroup . . . . . . . . . . . . . . 45
10.2.13. Structure: ProfileService . . . . . . . . . . . . . 45
10.2.14. Structure: ProfileHost . . . . . . . . . . . . . . . 45
10.2.15. Connection Assertions . . . . . . . . . . . . . . . 46
10.2.16. Structure: ConnectionDevice . . . . . . . . . . . . 46
10.2.17. Structure: ConnectionApplication . . . . . . . . . . 46
10.2.18. Structure: ConnectionGroup . . . . . . . . . . . . . 46
10.2.19. Structure: ConnectionService . . . . . . . . . . . . 47
10.2.20. Structure: ConnectionHost . . . . . . . . . . . . . 47
10.2.21. Activation Assertions . . . . . . . . . . . . . . . 47
10.2.22. Structure: ActivationDevice . . . . . . . . . . . . 47
10.2.23. Structure: ActivationAccount . . . . . . . . . . . . 47
10.2.24. Structure: ActivationApplication . . . . . . . . . . 47
10.3. Data Structures . . . . . . . . . . . . . . . . . . . . 48
10.3.1. Structure: Contact . . . . . . . . . . . . . . . . . 48
10.3.2. Structure: Anchor . . . . . . . . . . . . . . . . . 48
10.3.3. Structure: TaggedSource . . . . . . . . . . . . . . 48
Hallam-Baker Expires 17 July 2021 [Page 3]
Internet-Draft Mesh Schema Reference January 2021
10.3.4. Structure: ContactGroup . . . . . . . . . . . . . . 49
10.3.5. Structure: ContactPerson . . . . . . . . . . . . . . 49
10.3.6. Structure: ContactOrganization . . . . . . . . . . . 49
10.3.7. Structure: OrganizationName . . . . . . . . . . . . 49
10.3.8. Structure: PersonName . . . . . . . . . . . . . . . 49
10.3.9. Structure: NetworkAddress . . . . . . . . . . . . . 50
10.3.10. Structure: NetworkProtocol . . . . . . . . . . . . . 50
10.3.11. Structure: Role . . . . . . . . . . . . . . . . . . 50
10.3.12. Structure: Location . . . . . . . . . . . . . . . . 50
10.3.13. Structure: Bookmark . . . . . . . . . . . . . . . . 51
10.3.14. Structure: Reference . . . . . . . . . . . . . . . . 51
10.3.15. Structure: Task . . . . . . . . . . . . . . . . . . 51
10.4. Catalog Entries . . . . . . . . . . . . . . . . . . . . 52
10.4.1. Structure: CatalogedEntry . . . . . . . . . . . . . 52
10.4.2. Structure: CatalogedDevice . . . . . . . . . . . . . 52
10.4.3. Structure: CatalogedPublication . . . . . . . . . . 53
10.4.4. Structure: CatalogedCredential . . . . . . . . . . . 53
10.4.5. Structure: CatalogedNetwork . . . . . . . . . . . . 53
10.4.6. Structure: CatalogedContact . . . . . . . . . . . . 53
10.4.7. Structure: CatalogedAccess . . . . . . . . . . . . . 54
10.4.8. Structure: CryptographicCapability . . . . . . . . . 54
10.4.9. Structure: CapabilityDecrypt . . . . . . . . . . . . 54
10.4.10. Structure: CapabilityDecryptPartial . . . . . . . . 54
10.4.11. Structure: CapabilityDecryptServiced . . . . . . . . 55
10.4.12. Structure: CapabilitySign . . . . . . . . . . . . . 55
10.4.13. Structure: CapabilityKeyGenerate . . . . . . . . . . 55
10.4.14. Structure: CapabilityFairExchange . . . . . . . . . 55
10.4.15. Structure: CatalogedBookmark . . . . . . . . . . . . 55
10.4.16. Structure: CatalogedTask . . . . . . . . . . . . . . 56
10.4.17. Structure: CatalogedApplication . . . . . . . . . . 56
10.4.18. Structure: CatalogedMember . . . . . . . . . . . . . 56
10.4.19. Structure: CatalogedGroup . . . . . . . . . . . . . 56
10.4.20. Structure: CatalogedApplicationSSH . . . . . . . . . 56
10.4.21. Structure: CatalogedApplicationMail . . . . . . . . 56
10.4.22. Structure: CatalogedApplicationNetwork . . . . . . . 57
10.5. Publications . . . . . . . . . . . . . . . . . . . . . . 57
10.5.1. Structure: DevicePreconfiguration . . . . . . . . . 57
10.6. Messages . . . . . . . . . . . . . . . . . . . . . . . . 57
10.6.1. Structure: Message . . . . . . . . . . . . . . . . . 57
10.6.2. Structure: MessageError . . . . . . . . . . . . . . 57
10.6.3. Structure: MessageComplete . . . . . . . . . . . . . 57
10.6.4. Structure: MessagePinValidated . . . . . . . . . . . 58
10.6.5. Structure: MessagePin . . . . . . . . . . . . . . . 58
10.6.6. Structure: RequestConnection . . . . . . . . . . . . 58
10.6.7. Structure: AcknowledgeConnection . . . . . . . . . . 58
10.6.8. Structure: RespondConnection . . . . . . . . . . . . 59
10.6.9. Structure: MessageContact . . . . . . . . . . . . . 59
10.6.10. Structure: GroupInvitation . . . . . . . . . . . . . 59
Hallam-Baker Expires 17 July 2021 [Page 4]
Internet-Draft Mesh Schema Reference January 2021
10.6.11. Structure: RequestConfirmation . . . . . . . . . . . 59
10.6.12. Structure: ResponseConfirmation . . . . . . . . . . 60
10.6.13. Structure: RequestTask . . . . . . . . . . . . . . . 60
10.6.14. Structure: MessageClaim . . . . . . . . . . . . . . 60
10.6.15. Structure: ProcessResult . . . . . . . . . . . . . . 60
11. Security Considerations . . . . . . . . . . . . . . . . . . . 60
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 61
14. Appendix A: Example Container Organization (not normative) . 61
14.1. Device . . . . . . . . . . . . . . . . . . . . . . . . . 61
14.1.1. Creating a new Mesh . . . . . . . . . . . . . . . . 61
14.1.2. Adding an Account . . . . . . . . . . . . . . . . . 61
14.1.3. Adding a Device . . . . . . . . . . . . . . . . . . 61
14.2. Service . . . . . . . . . . . . . . . . . . . . . . . . 62
14.2.1. Creating a Service . . . . . . . . . . . . . . . . . 62
14.2.2. Adding an Account . . . . . . . . . . . . . . . . . 62
15. Appendix B: Collected Authentication and Encryption
Requirements . . . . . . . . . . . . . . . . . . . . . . . . 62
15.1. Mesh Messaging . . . . . . . . . . . . . . . . . . . . . 62
16. Normative References . . . . . . . . . . . . . . . . . . . . 63
17. Informative References . . . . . . . . . . . . . . . . . . . 64
1. Introduction
This document describes the data structures of the Mathematical Mesh
with illustrative examples. For an overview of the Mesh objectives
and architecture, consult the accompanying _Architecture Guide_
[draft-hallambaker-mesh-architecture]. For information on the
implementation of the Mesh Service protocol, consult the accompanying
_Protocol Reference_ [draft-hallambaker-mesh-protocol]
This document has two main sections. The first section presents
examples of the Mesh assertions, catalog entry and messages in use.
The second section contains the schema reference. All the material
in both sections is generated from the Mesh reference implementation
[draft-hallambaker-mesh-developer].
Although some of the services described in this document could be
used to replace existing Internet protocols including FTP and SMTP,
the principal value of any communication protocol lies in the size of
the audience it allows them to communicate with. Thus, while the
Mesh Messaging service is designed to support efficient and reliable
transfer of messages ranging in size from a few bytes to multiple
terabytes, the near-term applications of these services will be to
applications that are not adequately supported by existing protocols
if at all.
Hallam-Baker Expires 17 July 2021 [Page 5]
Internet-Draft Mesh Schema Reference January 2021
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. Actors
The Mesh mediates interactions between three principal actors:
*Accounts*, *Devices*, and *Services*.
Currently two account types are specified, *user accounts* which
belong to an individual user and *group accounts* that are used to
share access to confidential information between a group of users.
It may prove useful to define new types of account over time or to
eliminate the distinction entirely. When active a Mesh account is
bound to a Mesh Service. The service to which an account is bound
MAY be changed over time but an account can only be bound to a single
service at a time.
Hallam-Baker Expires 17 July 2021 [Page 6]
Internet-Draft Mesh Schema Reference January 2021
A Mesh account is an abstract construct that (when active) is
instantiated across one or more physical machines called a device.
Each device that is connected to an account has a separate set of
cryptographic keys that are used to interact with other devices
connected to the account and MAY be provisioned with access to the
account private keys which MAY or MAY NOT be mediated by the current
Mesh Service.
A Mesh Service is an abstract construct that is provided by one or
more physical machines called Hosts. A Mesh Host is a device that is
attached to a service rather than an account.
3.1. Accounts
A Mesh Account is described by a Profile descended from Profile
Account and contains a set of Mesh stores. Currently two account
profiles are defined:
ProfileUser Describes a user account.
ProfileGroup Describes a group account used to share confidential
information between a group of users.
Both types of profile specify the following fields:
ProfileSignature The public signature key used to authenticate the
profile itself
AccountAddress The account name to which the account is currently
bound. (e.g. "alice@example.com", "@alice").
ServiceUdf If the account is active, specifies the fingerprint of
the service profile to which the account is currently bound.
AdministratorSignature The public signature key used to verify
administrative actions on the account. In particular addition of
devices to a user account or members to a group account.
AccountEncryption The public encryption key for the account. All
messages sent to the account MUST be encrypted under this key. By
definition, all data encrypted under this account is encrypted
under this key.
User accounts specify two additional public keys, "AccountSignature"
and "AccountAuthentication" which allow signature and authentication
operations under the account context.
Hallam-Baker Expires 17 July 2021 [Page 7]
Internet-Draft Mesh Schema Reference January 2021
Every account contains a set of catalogs and spools that are managed
by the service as directed by the contents of the associated "Access"
catalog.
For example, the personal account profile Alice created is:
{
"ProfileUser":{
"ProfileSignature":{
"Udf":"MAMU-5QXP-TWCD-7PKI-S4FC-IB76-XASH",
"PublicParameters":{
"PublicKeyECDH":{
"crv":"Ed448",
"Public":"c3l96hFNVbXzQa7dohgp_X9YIIzaR4U0dPCfyocquFWnZ
uiFdu9vl9UIgtYv-tjFVpmk6qRDj7mA"}}},
"AccountAddress":"alice@example.com",
"ServiceUdf":"MA36-TUJL-QRZJ-3M3L-SRBQ-BRYQ-W2YM",
"AccountEncryption":{
"Udf":"MDLO-JJ4B-RBY5-VYD7-LJZY-S3RK-DBM2",
"PublicParameters":{
"PublicKeyECDH":{
"crv":"X448",
"Public":"4Mi9X8mXI9mGh_7sjGZP0aFPRXJNSFexPBnIAK1BN__SX
RxtWQTsXsgz1fl5Jc38ZYx7MVe2X9wA"}}},
"AdministratorSignature":{
"Udf":"MCCK-F2WZ-QAAC-C3NA-EVAW-SBL7-IHEQ",
"PublicParameters":{
"PublicKeyECDH":{
"crv":"Ed448",
"Public":"8TSZ7DNTM7FugJqAFft4FJD4WdjA9omHUDa7tntnJBkQ4
kNW_tyS6QMGMYly4wHR1WFnUZvI5QmA"}}},
"AccountAuthentication":{
"Udf":"MBB3-723K-DJKQ-G4HH-7PTN-5JXK-ZV6A",
"PublicParameters":{
"PublicKeyECDH":{
"crv":"X448",
"Public":"l674_n9ihg91rjgPisb3XuA78E_8hWzsHtYfoFQvGB2kZ
3O1xSBFE2ppFjhS4hslA45yz7WpBzgA"}}},
"AccountSignature":{
"Udf":"MDA6-ELE2-T2AM-52RT-AN3R-LUDS-GJGX",
"PublicParameters":{
"PublicKeyECDH":{
"crv":"Ed448",
"Public":"AHStW8KGpbroZt5ez-wvbC_FMr9AjqI8gLigC5p3whHcE
Q4jP9dW1xDwZ34j77qXNIfFEvOEWJMA"}}}}}
Hallam-Baker Expires 17 July 2021 [Page 8]
Internet-Draft Mesh Schema Reference January 2021
3.2. Device
Every Mesh device has a set of private keys that are unique to that
device. These keys MAY be installed during manufacture, installed
from an external source after manufacture or generated on the device.
If the platform capabilities allow, device private keys SHOULD be
bound to the device so that they cannot be extracted or exported
without substantial effort.
The public keys corresponding to the device private keys are
specified in a ProfileDevice. This MUST contain at least the
following fields:
ProfileSignature The public signature key used to authenticate the
profile itself.
BaseEncryption Public encryption key used as a share contribution to
generation of device encryption keys to be used in the context of
an account and to decrypt data during the process of connecting to
an account.
BaseAuthentication Public authentication key used as a share
contribution to generation of device authentication keys to be
used in the context of an account and to authenticate the device
to a service during the process of connecting to an account.
BaseSignature Public signature key used as a share contribution to
generation of device authentication keys to be used in the context
of an account.
For example, the device profile corresponding to Alice's coffee pot
device is:
Hallam-Baker Expires 17 July 2021 [Page 9]
Internet-Draft Mesh Schema Reference January 2021
{
"ProfileDevice":{
"ProfileSignature":{
"Udf":"MAQO-2SJC-PGX4-KVHC-TEQ3-I2NP-GYBA",
"PublicParameters":{
"PublicKeyECDH":{
"crv":"Ed448",
"Public":"s9IdDH2a_dArdBA8thg41Ctwc0qVo6w67bRrEI1LZgSlG
pUSlXWZN8W-VY7hm40Xoq7TU5KEsQSA"}}},
"BaseEncryption":{
"Udf":"MD5F-Q3O6-KRGL-IS4V-IWVC-5SIN-S63R",
"PublicParameters":{
"PublicKeyECDH":{
"crv":"X448",
"Public":"aJSPUdraCO0yv2YXVKkQ4i1XUKVau-Apb7-OxXNb06Y-w
9I420kkRzXhSfsifKPegX7kJMHDKZkA"}}},
"BaseAuthentication":{
"Udf":"MDQC-JYXP-KZ3I-ETIO-KMWA-XIAP-3JRD",
"PublicParameters":{
"PublicKeyECDH":{
"crv":"X448",
"Public":"KABXGv_VuvLPRhfVpHd5qykjJDUNRiwhh5u3CJpwuAZXf
vmeM0KXit5b6wNvYYsSoLeNfKy337IA"}}},
"BaseSignature":{
"Udf":"MDL3-Q7RU-USJR-QF3O-CJEF-6TPW-EVAN",
"PublicParameters":{
"PublicKeyECDH":{
"crv":"Ed448",
"Public":"2wXyHGACnTq5ee8mgXM_jADlpeRV7gcN3jTQc9LP3LP1Y
zii2iSkUMgUTP8yF_KmibXs5pXvv0oA"}}}}}
3.2.1. Activation
The device private keys are only used to perform cryptographic
operations during the process of connecting a device to an account.
During that connection process, a threshold key generation scheme is
used to generate a second set of device keys bound to the account by
combining the base key held by the device with a second device
private key provided by the administration device approving the
connection of the device to the account. The resulting key is
referred to as the device key. The process of combining the base
keys with the contributions to form the device keys is called
Activation.
The activation record for Alice's coffee pot device is:
Hallam-Baker Expires 17 July 2021 [Page 10]
Internet-Draft Mesh Schema Reference January 2021
{
"ActivationDevice":{
"ActivationKey":"ZAAQ-HHIF-DKIU-F5UI-VEFB-G4XO-SZY6-JF4J-7QLL-2
RFQ-QGUO-AJI7-I2FQ-CXO6",
"AccountUdf":"MAQO-2SJC-PGX4-KVHC-TEQ3-I2NP-GYBA"}}
The Mesh protocols are designed so that there is never a need to
export or escrow private keys of any type associated with a device,
neither the base key, nor the device key nor the contribution from
the administration device.
This approach to device configuration ensures that the keys that are
used by the device when operating within the context of the account
are entirely separate from those originally provided by the device
manufacturer or generated on the device, provided only that the key
contributions from the administration device are sufficiently random
and unguessable.
The public keys corresponding to the composite keys generated during
the connection process are described in a "ConnectionUser" assertion
signed by the administration key of the corresponding account.
The connection record for Alice's coffee pot device is:
{
"ConnectionDevice":{
"DeviceSignature":{
"Udf":"MCEL-HWST-PNFX-ENF4-ROL5-INQF-P2TK",
"PublicParameters":{
"PublicKeyECDH":{
"crv":"Ed448",
"Public":"4DHBHjQ8X2CadyazPhOx_kSM1IFwgkZEWwW6BK18UBsrr
wURQg5QVOGbZl4hvQqu7dULB4tDjAIA"}}},
"DeviceEncryption":{
"Udf":"MDPR-ZBW2-AERR-PQIZ-2J3Z-5DLN-ALBM",
"PublicParameters":{
"PublicKeyECDH":{
"crv":"X448",
"Public":"Q7UKXQoRCr4eqDLi1WgyyO9JNtDmZ4AaFl6iaGB5IRGrF
eMpv7LanAKnTNZUQP0fbnmpdoGvjG-A"}}},
"DeviceAuthentication":{
"Udf":"MDS4-XJNU-HVTT-VR27-I4W3-DYDC-AFEK",
"PublicParameters":{
"PublicKeyECDH":{
"crv":"X448",
"Public":"F2Bv14NA0Qw_f2B1ktqMGUzAMKbiUNF8etfElLVN-FGYw
V0PN9PMdE55ELOt0Y0YkKxP3CR0Kp4A"}}}}}
Hallam-Baker Expires 17 July 2021 [Page 11]
Internet-Draft Mesh Schema Reference January 2021
The "ConnectionUser" assertion MAY be used in the same fashion as an
X.509v3/PKIX certificate to mediate interactions between devices
connected to the same account without the need for interaction with
the Mesh service. Thus, a coffee pot device connected to the account
can receive and authenticate instructions issued by a voice
recognition device connected to that account.
While the "ConnectionUser" assertion MAY be used to mediate external
interactions, this approach is typically undesirable as it provides
the external parties with visibility to the internal configuration of
the account, in particular which connected devices are being used on
which occasions. Furthermore, the lack of the need to interact with
the service means that the service is necessarily unable to mediate
the exchange and enforce authorization policy on the interactions.
Device keys are intended to be used to secure communications between
devices connected to the same account. All communication between
Mesh accounts SHOULD be mediated by a Mesh service. This enables
abuse mitigation by applying access control to every outbound and
every inbound message.
Since Alice's coffee pot does not require the external communication
right, the activation record for the coffee pot does not provide
access to the account keys required to perform external
communications. Alice's watch device does require access to the
account keys so it can receive messages and task updates. But since
it is a device that Alice has to carry on her person to use, it is a
device that might easily be lost or stolen. Accordingly, the
activation record for Alice's watch provides access to the account
decryption and signature keys but in the form of threshold key shares
mediated by the Mesh service. Thus, Alice's watch can sign and read
message sent to the account but only under the control of the Mesh
service.
3.3. Service
Mesh services are described by a "ProfileService". This specifies
the encryption, and signature authentication keys used to interact
with the abstract service.
Since Mesh accounts and services are both abstract constructs, they
cannot interact directly. A device connected to an account can only
interact with a service by interacted with a device authorized to
provide services on behalf of one or more accounts connected to the
service. Such a device is called a Mesh Host.
Hallam-Baker Expires 17 July 2021 [Page 12]
Internet-Draft Mesh Schema Reference January 2021
Mesh hosts MAY be managed using the same ProfileDevice and device
connection mechanism provided for management of user devices or by
whatever other management protocols prove convenient. The only part
of the Service/Host interaction that is visible to devices connected
to a profile and to hosts connected to other services is the
ConnectionHost structure that describes the set of device keys to use
in interactions with that specific host.
4. Catalogs
Catalogs track sets of persistent objects associated with a Mesh
Service Account. The Mesh Service has no access to the entries in
any Mesh catalog except for the Device and Contacts catalog which are
used in device authentication and authorization of inbound messages.
Each Mesh Catalog managed by a Mesh Account has a name of the form:
"<prefix>_<name>"
Where "<prefix>" is the IANA assigned service name. The assigned
service name for the Mathematical Mesh is mmm. Thus, all catalogs
specified by the Mesh schema have names prefixed with the sequence
"mmm_".
The following catalogs are currently specified within the
Mathematical Mesh.
Access: mmm_Access Describes access control policy for performing
operations on the account. The Access catalog is the only Mesh
catalog whose contents are readable by the Mesh Service under
normal circumstances.
Application: "mmm_Application" Describes configuration information
for applications including mail (SMTP, IMAP, OpenPGP, S/MIME, etc)
and SSH and for the MeshAccount application itself.
Bookmark: "mmm_Bookmark" Describes Web bookmarks and other citations
allowing them to be shared between devices connected to the
profile.
Contact: "mmm_Contact" Describes logical and physical contact
information for people and organizations.
Credential: "mmm_Credential" Describes credentials used to access
network resources.
Device: "mmm_Device" Describes the set of devices connected to the
account and the permissions assigned to them
Hallam-Baker Expires 17 July 2021 [Page 13]
Internet-Draft Mesh Schema Reference January 2021
Network: "mmm_Network" Describes network settings such as WiFi
access points, IPSEC and TLS VPN configurations, etc.
Member: mmm_Member Describes the set of members connected to a group
account.
Publication: mmm_Publication Describes data published under the
account context. The data MAY be stored in the publication
catalog itself or on a separate service (e.g. a Web server).
Task: "mmm_CatalogTask" Describes tasks assigned to the user
including calendar entries and to do lists.
The Access, Publication, Device and Member catalogs are involved in
Mesh Service Protocol interactions. These interactions are further
described in the Protocol Reference
[draft-hallambaker-mesh-protocol].
In many cases, the Mesh Catalog offers capabilities that represent a
superset of the capabilities of an existing application. For
example, the task catalog supports the appointment tracking functions
of a traditional calendar application and the task tracking function
of the traditional 'to do list' application. Combining these
functions allows tasks to be triggered by other events other than the
passage of time such as completion of other tasks, geographical
presence, etc.
In such cases, the Mesh Catalog entries are designed to provide a
superset of the data representation capabilities of the legacy
formats and (where available) recent extensions. Where a catalog
entry is derived from input presented in a legacy format, the
original data representation MAY be attached verbatim to facilitate
interoperability.
4.1. Access
The access catalog "mmm_Access" contains a list of access control
entries granting a party authenticated using a particular
cryptographic credential a specific privilege such as:
* Accept Mesh Messages of particular types
* Perform an operation on a private key known to the service.
Hallam-Baker Expires 17 July 2021 [Page 14]
Internet-Draft Mesh Schema Reference January 2021
As with the publication catalog, the access catalog provides
information that is necessary for the Mesh Service to act on behalf
of the user. It is therefore necessary to grant a decryption
capability for this catalog during the process of binding the account
to a service.
4.2. Application
The application catalog "mmm"_"Application" contains
"CatalogEntryApplication" entries which describe the use of specific
applications under the Mesh Service Account. Multiple application
accounts for a single application MAY be connected to a single Mesh
Service Account. Each account being specified in a separate entry.
The "CatalogEntryApplication" entries only contain configuration
information for the application as it applies to the account as a
whole. If the application requires separate configuration for
individual devices, this is specified in separate activation records
specified in the corresponding "ConnectionDevice".
4.2.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.
4.2.2. SSH
SSH configuration profiles are described by
"CatalogEntryApplicationSSH" entries. The corresponding activation
records for the connected devices contain the contributions used to
derive the private keys.
A user may have separate SSH configurations for separate purposes
within a single Mesh Account. This allows a system administrator
servicing multiple clients to maintain separate SSH profiles for each
of her customers allowing credentials to be easily (and verifiably)
revoked at contract termination.
The SSH profile contains the information that is stored in the
"known_hosts" and "authorized_keys" files of SSH clients and servers.
Hallam-Baker Expires 17 July 2021 [Page 15]
Internet-Draft Mesh Schema Reference January 2021
4.2.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.
4.3. Bookmark
The bookmark catalog "mmm_bookmark" contains "CatalogEntryBookmark"
entries which describe Web bookmarks and other citations allowing
them to be shared between devices connected to the profile.
The fields currently supported by the Bookmarks catalog are currently
limited to the fields required for tracking Web bookmarks.
Specification of additional fields to track full academic citations
is a work in progress.
{
"CatalogedBookmark":{
"Uri":"http://www.site1.com",
"Title":"site1",
"Path":"Sites.1"}}
4.4. Contact
The contact catalog "mmm_contact" contains "CatalogEntryContact"
entries which describe
{
"CatalogedContact":{
"Key":"MAMU-5QXP-TWCD-7PKI-S4FC-IB76-XASH",
"Self":true,
"Contact":{
"ContactPerson":{
"Id":"MAMU-5QXP-TWCD-7PKI-S4FC-IB76-XASH",
"Anchors":[{
"Udf":"MAMU-5QXP-TWCD-7PKI-S4FC-IB76-XASH",
"Validation":"Self"}
],
"NetworkAddresses":[{
"Address":"alice@example.com",
"EnvelopedProfileAccount":[{
Hallam-Baker Expires 17 July 2021 [Page 16]
Internet-Draft Mesh Schema Reference January 2021
"EnvelopeId":"MAMU-5QXP-TWCD-7PKI-S4FC-IB76-XASH",
"dig":"S512",
"ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJNQU1VLT
VRWFAtVFdDRC03UEtJLVM0RkMtSUI3Ni1YQVNIIiwKICAiTWVzc2FnZVR5cGUiOiA
iUHJvZmlsZVVzZXIiLAogICJjdHkiOiAiYXBwbGljYXRpb24vbW1tL29iamVjdCIs
CiAgIkNyZWF0ZWQiOiAiMjAyMS0wMS0xM1QxNjozODoxOVoifQ"},
"ewogICJQcm9maWxlVXNlciI6IHsKICAgICJQcm9maWxlU2lnbm
F0dXJlIjogewogICAgICAiVWRmIjogIk1BTVUtNVFYUC1UV0NELTdQS0ktUzRGQy1
JQjc2LVhBU0giLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgICAi
UHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgI
CAgICAgIlB1YmxpYyI6ICJjM2w5NmhGTlZiWHpRYTdkb2hncF9YOVlJSXphUjRVMG
RQQ2Z5b2NxdUZXblp1aUZkdTl2CiAgbDlVSWd0WXYtdGpGVnBtazZxUkRqN21BIn1
9fSwKICAgICJBY2NvdW50QWRkcmVzcyI6ICJhbGljZUBleGFtcGxlLmNvbSIsCiAg
ICAiU2VydmljZVVkZiI6ICJNQTM2LVRVSkwtUVJaSi0zTTNMLVNSQlEtQlJZUS1XM
llNIiwKICAgICJBY2NvdW50RW5jcnlwdGlvbiI6IHsKICAgICAgIlVkZiI6ICJNRE
xPLUpKNEItUkJZNS1WWUQ3LUxKWlktUzNSSy1EQk0yIiwKICAgICAgIlB1YmxpY1B
hcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICAg
ICAiY3J2IjogIlg0NDgiLAogICAgICAgICAgIlB1YmxpYyI6ICI0TWk5WDhtWEk5b
UdoXzdzakdaUDBhRlBSWEpOU0ZleFBCbklBSzFCTl9fU1hSeHRXUVRzCiAgWHNnej
FmbDVKYzM4Wll4N01WZTJYOXdBIn19fSwKICAgICJBZG1pbmlzdHJhdG9yU2lnbmF
0dXJlIjogewogICAgICAiVWRmIjogIk1DQ0stRjJXWi1RQUFDLUMzTkEtRVZBVy1T
Qkw3LUlIRVEiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgICAiU
HVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgIC
AgICAgIlB1YmxpYyI6ICI4VFNaN0ROVE03RnVnSnFBRmZ0NEZKRDRXZGpBOW9tSFV
EYTd0bnRuSkJrUTRrTldfdHlTCiAgNlFNR01ZbHk0d0hSMVdGblVadkk1UW1BIn19
fSwKICAgICJBY2NvdW50QXV0aGVudGljYXRpb24iOiB7CiAgICAgICJVZGYiOiAiT
UJCMy03MjNLLURKS1EtRzRISC03UFROLTVKWEstWlY2QSIsCiAgICAgICJQdWJsaW
NQYXJhbWV0ZXJzIjogewogICAgICAgICJQdWJsaWNLZXlFQ0RIIjogewogICAgICA
gICAgImNydiI6ICJYNDQ4IiwKICAgICAgICAgICJQdWJsaWMiOiAibDY3NF9uOWlo
ZzkxcmpnUGlzYjNYdUE3OEVfOGhXenNIdFlmb0ZRdkdCMmtaM08xeFNCRgogIEUyc
HBGamhTNGhzbEE0NXl6N1dwQnpnQSJ9fX0sCiAgICAiQWNjb3VudFNpZ25hdHVyZS
I6IHsKICAgICAgIlVkZiI6ICJNREE2LUVMRTItVDJBTS01MlJULUFOM1ItTFVEUy1
HSkdYIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1Ymxp
Y0tleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIkVkNDQ4IiwKICAgICAgICAgI
CJQdWJsaWMiOiAiQUhTdFc4S0dwYnJvWnQ1ZXotd3ZiQ19GTXI5QWpxSThnTGlnQz
VwM3doSGNFUTRqUDlkVwogIDF4RHdaMzRqNzdxWE5JZkZFdk9FV0pNQSJ9fX19fQ",
{
"signatures":[{
"alg":"S512",
"kid":"MAMU-5QXP-TWCD-7PKI-S4FC-IB76-XASH",
"signature":"_9tIDk5KvjeIuasHaXDawBB1VTw2YIzx
BUxpLn78a0qfO9CjuWh7auyUMHrCGvpuQRjjQrDR_OeATnhDzrIG5xcQbFwvfge_r
fqvUjqQc-CZqvT8lLDQ2clW6THP1Z0GcIZmxNEpYVkyyR-9AACDQAcA"}
],
"PayloadDigest":"fb_iksIe0dM4IWIWZjmKlYQSF-XttjIA
g8Bww4tJjpOE0P9bxX42pkNorLfHQ8XyD8x9IHT-FKh-_lhLJNAUzA"}
],
"Protocols":[{
Hallam-Baker Expires 17 July 2021 [Page 17]
Internet-Draft Mesh Schema Reference January 2021
"Protocol":"mmm"}
]}
],
"Sources":[{
"Validation":"Self",
"EnvelopedSource":[{
"dig":"S512",
"ContentMetaData":"ewogICJNZXNzYWdlVHlwZSI6ICJDb2
50YWN0UGVyc29uIiwKICAiY3R5IjogImFwcGxpY2F0aW9uL21tbS9vYmplY3QiLAo
gICJDcmVhdGVkIjogIjIwMjEtMDEtMTNUMTY6Mzg6MTlaIn0"},
"ewogICJDb250YWN0UGVyc29uIjogewogICAgIkFuY2hvcnMiOi
BbewogICAgICAgICJVZGYiOiAiTUFNVS01UVhQLVRXQ0QtN1BLSS1TNEZDLUlCNzY
tWEFTSCIsCiAgICAgICAgIlZhbGlkYXRpb24iOiAiU2VsZiJ9XSwKICAgICJOZXR3
b3JrQWRkcmVzc2VzIjogW3sKICAgICAgICAiQWRkcmVzcyI6ICJhbGljZUBleGFtc
GxlLmNvbSIsCiAgICAgICAgIkVudmVsb3BlZFByb2ZpbGVBY2NvdW50IjogW3sKIC
AgICAgICAgICAgIkVudmVsb3BlSWQiOiAiTUFNVS01UVhQLVRXQ0QtN1BLSS1TNEZ
DLUlCNzYtWEFTSCIsCiAgICAgICAgICAgICJkaWciOiAiUzUxMiIsCiAgICAgICAg
ICAgICJDb250ZW50TWV0YURhdGEiOiAiZXdvZ0lDSlZibWx4ZFdWSlpDSTZJQ0pOU
VUxVkxUVlJXRkF0VkZkRFJDMAogIDNVRXRKTFZNMFJrTXRTVUkzTmkxWVFWTklJaX
dLSUNBaVRXVnpjMkZuWlZSNWNHVWlPaUFpVUhKdlptbHNaCiAgVlZ6WlhJaUxBb2d
JQ0pqZEhraU9pQWlZWEJ3YkdsallYUnBiMjR2YlcxdEwyOWlhbVZqZENJc0NpQWdJ
a04KICB5WldGMFpXUWlPaUFpTWpBeU1TMHdNUzB4TTFReE5qb3pPRG94T1ZvaWZRI
n0sCiAgICAgICAgICAiZXdvZ0lDSlFjbTltYVd4bFZYTmxjaUk2SUhzS0lDQWdJQ0
pRY205bWFXeAogIGxVMmxuYm1GMGRYSmxJam9nZXdvZ0lDQWdJQ0FpVldSbUlqb2d
JazFCVFZVdE5WRllVQzFVVjBORUxUZFFTCiAgMGt0VXpSR1F5MUpRamMyTFZoQlUw
Z2lMQW9nSUNBZ0lDQWlVSFZpYkdsalVHRnlZVzFsZEdWeWN5STZJSHMKICBLSUNBZ
0lDQWdJQ0FpVUhWaWJHbGpTMlY1UlVORVNDSTZJSHNLSUNBZ0lDQWdJQ0FnSUNKam
NuWWlPaUFpUgogIFdRME5EZ2lMQW9nSUNBZ0lDQWdJQ0FnSWxCMVlteHBZeUk2SUN
Kak0ydzVObWhHVGxaaVdIcFJZVGRrYjJoCiAgbmNGOVlPVmxKU1hwaFVqUlZNR1JR
UTJaNWIyTnhkVVpYYmxwMWFVWmtkVGwyQ2lBZ2JEbFZTV2QwV1hZdGQKICBHcEdWb
kJ0YXpaeFVrUnFOMjFCSW4xOWZTd0tJQ0FnSUNKQlkyTnZkVzUwUVdSa2NtVnpjeU
k2SUNKaGJHbAogIGpaVUJsZUdGdGNHeGxMbU52YlNJc0NpQWdJQ0FpVTJWeWRtbGp
aVlZrWmlJNklDSk5RVE0yTFZSVlNrd3RVCiAgVkphU2kwelRUTk1MVk5TUWxFdFFs
SlpVUzFYTWxsTklpd0tJQ0FnSUNKQlkyTnZkVzUwUlc1amNubHdkR2wKICB2YmlJN
klIc0tJQ0FnSUNBZ0lsVmtaaUk2SUNKTlJFeFBMVXBLTkVJdFVrSlpOUzFXV1VRM0
xVeEtXbGt0VQogIHpOU1N5MUVRazB5SWl3S0lDQWdJQ0FnSWxCMVlteHBZMUJoY21
GdFpYUmxjbk1pT2lCN0NpQWdJQ0FnSUNBCiAgZ0lsQjFZbXhwWTB0bGVVVkRSRWdp
T2lCN0NpQWdJQ0FnSUNBZ0lDQWlZM0oySWpvZ0lsZzBORGdpTEFvZ0kKICBDQWdJQ
0FnSUNBZ0lsQjFZbXhwWXlJNklDSTBUV2s1V0RodFdFazViVWRvWHpkemFrZGFVRE
JoUmxCU1dFcAogIE9VMFpsZUZCQ2JrbEJTekZDVGw5ZlUxaFNlSFJYVVZSekNpQWd
XSE5uZWpGbWJEVktZek00V2xsNE4wMVdaCiAgVEpZT1hkQkluMTlmU3dLSUNBZ0lD
SkJaRzFwYm1semRISmhkRzl5VTJsbmJtRjBkWEpsSWpvZ2V3b2dJQ0EKICBnSUNBa
VZXUm1Jam9nSWsxRFEwc3RSakpYV2kxUlFVRkRMVU16VGtFdFJWWkJWeTFUUWt3M0
xVbElSVkVpTAogIEFvZ0lDQWdJQ0FpVUhWaWJHbGpVR0Z5WVcxbGRHVnljeUk2SUh
zS0lDQWdJQ0FnSUNBaVVIVmliR2xqUzJWCiAgNVJVTkVTQ0k2SUhzS0lDQWdJQ0Fn
SUNBZ0lDSmpjbllpT2lBaVJXUTBORGdpTEFvZ0lDQWdJQ0FnSUNBZ0kKICBsQjFZb
XhwWXlJNklDSTRWRk5hTjBST1ZFMDNSblZuU25GQlJtWjBORVpLUkRSWFpHcEJPVz
l0U0ZWRVlUZAogIDBiblJ1U2tKclVUUnJUbGRmZEhsVENpQWdObEZOUjAxWmJIazB
Hallam-Baker Expires 17 July 2021 [Page 18]
Internet-Draft Mesh Schema Reference January 2021
kMGhTTVZkR2JsVmFka2sxVVcxQkluMTlmCiAgU3dLSUNBZ0lDSkJZMk52ZFc1MFFY
VjBhR1Z1ZEdsallYUnBiMjRpT2lCN0NpQWdJQ0FnSUNKVlpHWWlPaUEKICBpVFVKQ
015MDNNak5MTFVSS1MxRXRSelJJU0MwM1VGUk9MVFZLV0VzdFdsWTJRU0lzQ2lBZ0
lDQWdJQ0pRZAogIFdKc2FXTlFZWEpoYldWMFpYSnpJam9nZXdvZ0lDQWdJQ0FnSUN
KUWRXSnNhV05MWlhsRlEwUklJam9nZXdvCiAgZ0lDQWdJQ0FnSUNBZ0ltTnlkaUk2
SUNKWU5EUTRJaXdLSUNBZ0lDQWdJQ0FnSUNKUWRXSnNhV01pT2lBaWIKICBEWTNOR
jl1T1dsb1p6a3hjbXBuVUdsellqTllkVUUzT0VWZk9HaFhlbk5JZEZsbWIwWlJka2
RDTW10YU0wOAogIHhlRk5DUmdvZ0lFVXljSEJHYW1oVE5HaHpiRUUwTlhsNk4xZHd
RbnBuUVNKOWZYMHNDaUFnSUNBaVFXTmpiCiAgM1Z1ZEZOcFoyNWhkSFZ5WlNJNklI
c0tJQ0FnSUNBZ0lsVmtaaUk2SUNKTlJFRTJMVVZNUlRJdFZESkJUUzAKICAxTWxKV
UxVRk9NMUl0VEZWRVV5MUhTa2RZSWl3S0lDQWdJQ0FnSWxCMVlteHBZMUJoY21GdF
pYUmxjbk1pTwogIGlCN0NpQWdJQ0FnSUNBZ0lsQjFZbXhwWTB0bGVVVkRSRWdpT2l
CN0NpQWdJQ0FnSUNBZ0lDQWlZM0oySWpvCiAgZ0lrVmtORFE0SWl3S0lDQWdJQ0Fn
SUNBZ0lDSlFkV0pzYVdNaU9pQWlRVWhUZEZjNFMwZHdZbkp2V25RMVoKICBYb3RkM
1ppUTE5R1RYSTVRV3B4U1RoblRHbG5RelZ3TTNkb1NHTkZVVFJxVURsa1Z3b2dJRE
Y0UkhkYU16UgogIHFOemR4V0U1SlprWkZkazlGVjBwTlFTSjlmWDE5ZlEiLAogICA
gICAgICAgewogICAgICAgICAgICAic2lnbmF0dXJlcyI6IFt7CiAgICAgICAgICAg
ICAgICAiYWxnIjogIlM1MTIiLAogICAgICAgICAgICAgICAgImtpZCI6ICJNQU1VL
TVRWFAtVFdDRC03UEtJLVM0RkMtSUI3Ni1YQVNIIiwKICAgICAgICAgICAgICAgIC
JzaWduYXR1cmUiOiAiXzl0SURrNUt2amVJdWFzSGFYRGF3QkIxVlR3MllJenhCVXh
wTG43OGEwcWZPOUNqdQogIFdoN2F1eVVNSHJDR3ZwdVFSampRckRSX09lQVRuaER6
cklHNXhjUWJGd3ZmZ2VfcmZxdlVqcVFjLUNacXZUCiAgOGxMRFEyY2xXNlRIUDFaM
EdjSVpteE5FcFlWa3l5Ui05QUFDRFFBY0EifV0sCiAgICAgICAgICAgICJQYXlsb2
FkRGlnZXN0IjogImZiX2lrc0llMGRNNElXSVdaam1LbFlRU0YtWHR0aklBZzhCd3c
0dEpqcE9FMAogIFA5YnhYNDJwa05vckxmSFE4WHlEOHg5SUhULUZLaC1fbGhMSk5B
VXpBIn1dLAogICAgICAgICJQcm90b2NvbHMiOiBbewogICAgICAgICAgICAiUHJvd
G9jb2wiOiAibW1tIn1dfV19fQ",
{
"signatures":[{
"alg":"S512",
"kid":"MDA6-ELE2-T2AM-52RT-AN3R-LUDS-GJGX",
"signature":"TNxwW6yniJfw_8hNE_6bssF6HiT_Ian7
y755E1N-X9t88aU2FzbsOHvILoehWLnSUYd8FSWnRw4AwOkXeNnSOC0vP_ORtgCVF
tNjqyjvTSVqlH2qUa5u_ad8cTe9iEEc8Kw34jIjJ3vGG5T-zoEhpCcA"}
],
"PayloadDigest":"unXsJJuUAUZ6Sd8nfRYOnUvFQjsevfU9
8Dj6NJn3ul30f6mwwaHcsWojEr2F1lfeHbkA4vksAX2seekIjNH7Ww"}
]}
]}}}}
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 17 July 2021 [Page 19]
Internet-Draft Mesh Schema Reference January 2021
4.5. Credential
The credential catalog "mmm_credential" contains
"CatalogEntryCredential" entries which describe credentials used to
access network resources.
{
"CatalogedCredential":{
"Service":"ftp.example.com",
"Username":"alice1",
"Password":"password"}}
Only username/password credentials are stored in the credential
catalog. If public key credentials are to be used, these SHOULD be
managed as an application profile allowing separate credentials to be
created for each device.
4.6. Device
The device catalog "mmm_Device" contains "CatalogEntryDevice" entries
which describe the devices connected to the account and the
permissions assigned to them.
Each device connected to a Mesh Account has an associated
CatalogEntryDevice entry that includes the activation and connection
records for the account. These records are described in further
detail in section REF _Ref54628559 \r \h 0.
4.7. Network
The network catalog contains "CatalogEntryNetwork" entries which
describe network settings, IPSEC and TLS VPN configurations, etc.
{
"CatalogedNetwork":{
"Service":"myWiFi",
"Password":"securePassword"}}
4.8. Publication
The publication catalog "mmm_Publication" contains
"CatalogEntryPublication" entries which describe content published
through the account.
Hallam-Baker Expires 17 July 2021 [Page 20]
Internet-Draft Mesh Schema Reference January 2021
4.9. Task
The Task catalog "mmm_Task" contains "CatalogEntryTask" entries which
describe tasks assigned to the user including calendar entries and to
do lists.
The fields of the task catalog currently reflect those offered by the
iCalendar specification [RFC5545]. Specification of additional
fields to allow task triggering on geographic location and/or
completion of other tasks is a work in progress.
{
"CatalogedTask":{
"Title":"SomeItem",
"Key":"NC44-73RX-SL65-EFN4-E6ZD-JL47-CZ3A"}}
5. Spools
Spools are DARE Containers containing an append only list of messages
sent or received by an account. Three spools are currently defined:
Inbound Messages sent to the account. These are encrypted under the
account encryption keys of the sender and receiver that were
current at the time the message was sent.
Outbound Messages sent from the account. These are encrypted under
the account encryption keys of the sender and receiver that were
current at the time the message was sent.
Local Messages sent from the account for internal use. These are
encrypted under the encryption key of the intended recipient
alone. This is either the account administration encryption key
or a device encryption key.
Every Mesh Message has a unique message identifier. Messages created
at the beginning of a new messaging protocol interaction are assigned
a random message identifier. Responses to previous messages are
assigned message identifiers formed from the message identifier to
which they respond by means of a message digest function.
Every Mesh Message stored in a spool is encapsulated in an envelope
which bears a unique identifier that is formed by applying a message
digest function to the message identifier. Each stored message has
an associated state which is initially set to the state "Initial" and
MAY be subsequently altered by one or more "MessageComplete" messages
subsequently appended to the spool. The allowable message states
depending upon the spool in question.
Hallam-Baker Expires 17 July 2021 [Page 21]
Internet-Draft Mesh Schema Reference January 2021
5.1. Outbound
The outbound spool stores messages that are to be or have been sent
and "MessageComplete" messages reporting changes to the status of the
messages stored on the spool.
Messages posted to the outbound spool have the state Initial, Sent,
Received or Refused:
Initial The initial state of a message posted to the spool.
Sent The Mesh Service of the sender has delivered the message to the
Mesh Service of the recipient which accepted it.
Received The Mesh Service of the sender has delivered the message to
the Mesh Service of the recipient and the recipient has
acknowledged receipt.
Refused The Mesh Service of the sender has delivered the message to
the Mesh Service of the recipient which refused to accept it.
"MessageComplete" messages are only valid when posted to the spool by
the service.
5.2. Inbound
The inbound spool stores messages that have been received by the Mesh
service servicing the account and MessageComplete messages reporting
changes to the status of the messages stored on the spool.
Messages posted to the outbound spool have the state Initial, Read:
Initial The initial state of a message posted to the spool.
Read The message has been read.
A message previously marked as read MAY be returned to the unread
state by marking it as being in the Initial state.
5.3. Local
The local spool stores messages that are used for administrative
functions. In normal circumstances, only administrator devices and
the Mesh Service require access to the local spool.
Hallam-Baker Expires 17 July 2021 [Page 22]
Internet-Draft Mesh Schema Reference January 2021
The local spool is used to store MessagePin messages used to notify
administration devices that a PIN code has been registered for some
purpose and RespondConnection messages used to inform a device of the
result of a connection request.
The local spool is used in a device connection operation to provide a
device with the activation and connection records required to access
the service as an authorized client. Servicing these requests
requires that the service be able to access messages stored in the
spool by envelope id.
Messages posted to the outbound spool have the states Initial,
Closed:
Initial The initial state of a message posted to the spool.
Closed The action associated with the message has been completed.
6. Cryptographic Operations
The Mesh makes use of various cryptographic operations including
threshold operations. For convenience, these are gathered here and
specified as functions that are referenced by other parts of the
specification.
6.1. Key Derivation from Seed
Mesh Keys that derived from a seed value use the mechanism described
in [draft-hallambaker-mesh-udf]. Use of the "keyname" parameter
allows multiple keys for different uses to be derived from a single
key. Thus escrow of a single seed value permits recovery of all the
private keys associated with the profile.
The keyname parameter is a string formed by concatenating identifiers
specifying the key type, the actor that will use the key and the key
operation:
6.2. Message Envelope and Response Identifiers.
Every Mesh message has a unique Message Identifier "MessageId". The
"MakeID()" function is used to calculate the value of Envelope
Identifier and Response identifier from the message identifier as
follows:
Hallam-Baker Expires 17 July 2021 [Page 23]
Internet-Draft Mesh Schema Reference January 2021
static string MakeID(string udf, string content) {
var (code, bds) = UDF.Parse(udf);
return code switch
{
UdfTypeIdentifier.Digest_SHA_3_512 =>
UDF.ContentDigestOfDataString(
bds, content, cryptoAlgorithmId:
CryptoAlgorithmId.SHA_3_512),
_ => UDF.ContentDigestOfDataString(
bds, content, cryptoAlgorithmId:
CryptoAlgorithmId.SHA_2_512),
};
Where the values of content are given as follows:
String String
For example:
MessageID
= NBPS-TE2K-5BQZ-3HWA-PJNU-WYOX-DAMW
EnvelopeID
= MAD4-DQE5-PU4Y-QCTJ-D5U2-ZZVS-WBYC
ResponseID
= MDDB-CUZ4-QYCA-BEZB-3BPQ-PYOM-GPUM
6.3. Proof of Knowledge of PIN
Mesh Message classes that are subclasses of "MessagePinValidated" MAY
be authenticated by means of a PIN. Currently two such messages are
defined: "MessageContact" used in contact exchange and
"RequestConnection" message used in device connection.
The PIN codes used to authenticate "MessagePinValidated" messages are
UDF Authenticator strings. The type code of the identifier specifies
the algorithm to be used to authenticate the PIN code and the Binary
Data Sequence value specifies the key.
The inputs to the PIN proof of knowledge functions are:
PIN: string A UDF Authenticator. The type code of the identifier
specifies the algorithm to be used to authenticate the PIN code
and the Binary Data Sequence value specifies the key.
Action: string A code determining the specific action that the PIN
Hallam-Baker Expires 17 July 2021 [Page 24]
Internet-Draft Mesh Schema Reference January 2021
code MAY be used to authenticate. By convention this is the name
of the Mesh message type used to perform the action.
Account: string The account for which the PIN code is issued.
ClientNonce: binary Nonce value generated by the client using the
PIN code to authenticate its message.
PayloadDigest: binary The PayloadDigest of a DARE Envelope that
contains the message to be authenticated. Note that if the
envelope is encrypted, this value is calculated over the
ciphertext and does not provide proof of knowledge of the
plaintext.
The following values of Action are currently defined:
String String
These inputs are used to derive values as follows:
alg = UdfAlg (PIN)
pinData = UdfBDS (PIN)
saltedPINData = MAC (Action, pinData)
saltedPIN = UDFPresent (HMAC_SHA_2_512 + saltedPINData)
PinId = UDFPresent (MAC (Account, saltedPINData))
The issuer of the PIN code stores the value saltedPIN for retrieval
using the key PinId.
The witness value for a Dare Envelope with payload digest
PayloadDigest authenticated by a PIN code whose salted value is
saltedPINData, issued by account Account is given by PinWitness() as
follows:
witnessData = Account.ToUTF8() + ClientNonce + PayloadDigest
witnessValue = MAC (witnessData , saltedPINData)
For example, to generate saltedPIN for the pin AB23-ZBOI-CEIZ-MTD4-VQ
used to authenticate a an action of type Device:
Hallam-Baker Expires 17 July 2021 [Page 25]
Internet-Draft Mesh Schema Reference January 2021
pin = AB23-ZBOI-CEIZ-MTD4-VQ
action = message.
alg = UdfAlg (PIN)
= Authenticator_HMAC_SHA_2_512
hashalg = default (alg, HMAC_SHA_2_512)
pinData = UdfBDS (PIN)
= System.Byte[]
saltedPINData
= hashalg(pinData, hashalg);
= System.Byte[]
saltedPIN = UDFPresent (hashalg + saltedPINData)
= AANT-HAQW-KDUY-GUMW-YFY2-YWB5-23YC
The PinId binding the pin to the account alice@example.com is
Account = alice@example.com
PinId = UDFPresent (MAC (Account, saltedPINData))
= ABVQ-HJHJ-UUIJ-SLQE-KMK4-XUVP-DTVG
Where "MAC(data, key)" is the message authentication code algorithm
specified by the value of "alg".
When an administrative device issues a PIN code, a Message PIN is
appended to the local spool. This has the MessageId PinId and
specifies the value "saltedPIN" in the field of that name.
When PIN code authentication is used, a message of type
"MessagePinValidated" specifies the values "ClientNonce",
"PinWitness" and "PinId" in the fields of those names. These values
are used to authenticate the inner message data specified by the
"AuthenticatedData" field.
6.4. EARL
The UDF Encrypted Authenticated Resource Locator mechanism is used to
publish data and provide means of authentication and access through a
static identifier such as a QR code.
This mechanism is used to allow contact exchange by means of a QR
code printed on a business card and to connect a device to an account
using a static identifier printed on the device in the form of a QR
code.
Hallam-Baker Expires 17 July 2021 [Page 26]
Internet-Draft Mesh Schema Reference January 2021
In both cases, the information is passed using the EARL format
described in [draft-hallambaker-mesh-udf].
6.5. Key Agreement
All Mesh Protocol requests except for the HelloRequest and every
response MUST be authenticated under the device key of the host or
device making the request.
Initial authentication is achieved by performing a Key agreement
under the "DeviceAuthentication" key of each of the hosts and
combining the result with nonce values provided by the requestor and
respondent using a KDF function as follows:
Two bindings are currently planned.
DARE Envelope over HTTPS The request or response is encapsulated in
a DARE Envelope that is exchanged by means of a HTTP POST method
over a TLS transport. The shared secret is used as the key on
Message Authentication Code that authenticates the request
payload.
UDP Transport Presents the same information as for the DARE Envelope
over HTTPS case but in a compact encoding using the shared secret
and an authenticated encryption scheme to pass the required
information.
Once authentication has been performed, the same pair of devices MAY
re-authenticate using the previously agreed key. To facilitate
stateless implementation, a host specifies an opaque identifier to be
used to identify the shared secret on subsequent uses which MAY be
used to recover the shared secret from the opaque identifier.
[To be specified]
6.6. Service Cryptographic Operations
A Mesh Service acts as the counterparty for threshold operations
allowing mitigation of the risk of compromise of an individual device
connected to a user account or an insider threat from an individual
member of a group account.
When acting in this role, the Mesh service controls the use of the
cryptographic function but does not have the ability to perform the
action either by itself or by collaborating with other services to
which the account has been bound in the past.
Hallam-Baker Expires 17 July 2021 [Page 27]
Internet-Draft Mesh Schema Reference January 2021
Note that this approach limits rather than eliminates trust in the
service. As with services presenting themselves as 'zero trust', a
Mesh service becomes a trusted service after a sufficient number of
breaches in other parts of the system have occurred. And the user
trusts the service to provide availability of the service.
Three service cryptographic operations are currently specified:
Threshold Key Share A private key share _s_, held by the service is
split into key shares _x_, _y_ such that _a_ = _x_ + _y_. One key
share is encrypted under a decryption key held by the service.
The other is encrypted under a public key specified by the party
making the request.
Threshold Key Agreement A private key share s, held by the service
is used to calculate the value (_sl_+ _c_)._P_ where _l_, _c_ are
integers specified by the requestor and _P_ is a point on the
curve.
Threshold Signature A private key share s, held by the service is
used to calculate a contribution to a threshold signature scheme.
The implementation of the cryptographic operations described above is
described in [draft-hallambaker-threshold] and
[draft-hallambaker-threshold-sigs].
7. Mesh Assertions
Mesh Assertions are signed DARE Envelopes that contain one of more
claims. Mesh Assertions provide the basis for trust in the
Mathematical Mesh.
Mesh Assertions are divided into two classes. Mesh Profiles are
self-signed assertions. Assertions that are not self-signed are
called declarations. The only type of declaration currently defined
is a Connection Declaration describing the connection of a device to
an account.
(Artwork only available as svg: No external link available, see
draft-hallambaker-mesh-schema-07.html for artwork.)
Figure 1: Profiles And Connections
7.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:
Hallam-Baker Expires 17 July 2021 [Page 28]
Internet-Draft Mesh Schema Reference January 2021
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.
7.2. Mesh Profiles
Mesh Profiles perform a similar role to X.509v3 certificates but with
important differences:
* Profiles describe credentials, they do not make identity
statements
* Profiles do not expire, there is therefore no need to support
renewal processing.
* Profiles may be modified over time, the current and past status of
a profile being recorded in an append only log.
Hallam-Baker Expires 17 July 2021 [Page 29]
Internet-Draft Mesh Schema Reference January 2021
Profiles provide the axioms of trust for the Mesh PKI. Unlike in the
PKIX model in which all trust flows from axioms of trust held by a
small number of Certificate Authorities, every part in the Mesh
contributes their own axiom of trust.
It should be noted however that the role of Certificate Authorities
is redefined rather than eliminated. Rather than making assertions
whose subject is represented by identities which are inherently
mutable and subjective, Certificate Authorities can now make
assertions about immutable cryptographic keys.
Every Profile MUST contain a "SignatureKey" field and MUST be signed
by the key specified in that field.
A Profile is valid if and only if:
* There is a "SignatureKey" field.
* The profile is signed under the key specified in the
"SignatureKey" field.
A profile has the status "current" if and only if:
* The Profile is valid
* Every Conditions clause in the profile is understood by the
relying party and evaluates to "true".
7.3. Mesh Connections
A Mesh connection is an assertion describing the connection of a
device or a member to an account.
Mesh connections provide similar functionality to 'end-entity'
certificates in PKIX but with the important proviso that they are
only used to provide trust between a device connected to an account
and the service to which that account is bound and between the
devices connected to an account.
A connection is valid with respect to an account with profile _P_ if
and only if:
* The profile _P_ is valid
* The "AuthorityUdf" field of the connection is consistent with the
UDF of _P_
Hallam-Baker Expires 17 July 2021 [Page 30]
Internet-Draft Mesh Schema Reference January 2021
* The profile is signed under the key specified in the
"AdministrationKey" field of _P_.
* Any conditions specified in the profile are met
A connection has the status current with respect to an account with
profile if and only if:
* The connection is valid with respect to the account with profile
_P_.
* The profile "P" is current.
A device is authenticated with respect to an account with profile P
if and only if:
* The connection is valid with respect to the account with profile
_P_.
* The device has presented an appropriate proof of knowledge of the
"DeviceAuthentication" key specified in the connection.
8. Architecture
The Mesh architecture has four principal components:
Mesh Account A collection of information (contacts, calendar
entries, inbound and outbound messages, etc.) belonging to a user
who uses the Mesh to management.
Mesh Device Management The various functions that manage binding of
devices to a Mesh to grant access to information and services
bound to that account.
Mesh Service Provides network services through which devices and
other Mesh users may interact with a Mesh Account.
Mesh Messaging An end to end secure messaging service that allows
short messages (less than 32KB) to be exchanged between Mesh
Accounts and between the Mesh devices connected to a particular
account.
The separation of accounts and services as separate components is a
key distinction between the Mesh and earlier Internet applications.
A Mesh account belongs to the owner of the Mesh and not the Mesh
Service Provider which the user may change at any time of their
choosing.
Hallam-Baker Expires 17 July 2021 [Page 31]
Internet-Draft Mesh Schema Reference January 2021
A Mesh Account May be active or inactive. By definition, an active
Mesh account is serviced by exactly one Mesh Service, an inactive
Mesh account is not serviced by a Mesh Service. A Mesh Service
Provider MAY offer a backup service for accounts hosted by other
providers. In this case the backup provider is connected to the
account as a Mesh device, thus allowing the backup provider to
maintain a copy of the stores contained in the account and
facilitating a rapid transfer of responsibility for servicing the
account should that be desired. The use of backup providers is
described further in [draft-hallambaker-mesh-discovery].
8.1. Mesh Account
Mesh Accounts contains all the stateful information (contacts,
calendar entries, inbound and outbound messages, etc.) related to a
particular persona used by the owner.
By definition a Mesh Account is active if it is serviced by a Mesh
Service and inactive otherwise. A Mesh user MAY change their service
provider at any time. An active Mesh Account is serviced by exactly
one Mesh Service at once but a user MAY register a 'backup' service
provider to their account in the same manner as adding an advice.
This ensures that the backup service is pre-populated with all the
information required to allow the user to switch to the new provider
without interruption of service.
Each Mesh account is described by an Account Profile. Currently
separate profile Account Profile are defined for user accounts and
group accounts. It is not clear if this distinction is a useful one.
8.1.1. Account Profile
A Mesh account profile provides the axiom of trust for a mesh user.
It contains a Master Signature Key and one or more Administration
Signature Keys. The unique identifier of the master profile is the
UDF of the Master Signature Key.
An Account Profile MUST specify an "EscrowEncryption" key. This key
MAY be used to escrow private keys used for encryption of stored
data. They SHOULD NOT be used to escrow authentication keys and MUST
NOT be used to escrow signature keys.
Hallam-Baker Expires 17 July 2021 [Page 32]
Internet-Draft Mesh Schema Reference January 2021
A user should not need to replace their account profile unless they
intend to establish a separate identity. To minimize the risk of
disclosure, the Profile Signature Key is only ever used to sign
updates to the account profile itself. This allows the user to
secure their Profile Signature Key by either keeping it on hardware
token or device dedicated to that purpose or by using the escrow
mechanism and paper recovery keys as described in this document.
8.1.1.1. Creating a ProfileMaster
Creating a "ProfileMaster" comprises the steps of:
0. Creating a Master Signature key.
1. Creating an Online Signing Key
2. Signing the "ProfileMaster" using the Master Signature Key
3. Persisting the "ProfileMaster" on the administration device to
the "CatalogHost".
4. (Optional) Connecting at least one Administration Device and
granting it the "ActivationAdministration" activation.
8.1.1.2. Updating a ProfileMaster
Updating a "ProfileMaster" comprises the steps of:
0. Making the necessary changes.
1. Signing the ProfileMaster using the Master Signature Key
2. Persisting the ProfileMaster on the administration device to the
CatalogHost.
8.2. Device Management
Device management allows a collection of devices belonging to a user
to function as a single personal Mesh.
The device management functions are principally concerned with the
catalog containing the entries describing the connected devices.
Hallam-Baker Expires 17 July 2021 [Page 33]
Internet-Draft Mesh Schema Reference January 2021
8.2.1. The Device Catalog
Each Mesh Account has a Device Catalog "CatalogDevice" associated
with it. The Device Catalog is used to manage the connection of
devices to the Personal Mesh and has a "CatalogEntryDevice" for each
device currently connected to the catalog.
Each Administration Device MUST have access to an up-to-date copy of
the Device Catalog in order to manage the devices connected to the
Mesh. The Mesh Service protocol MAY be used to synchronize the
Device Catalog between administration devices in the case that there
is more than one administration device.
The "CatalogEntryDevice" contains fields for the device profile,
device private and device connection.
8.2.2. Mesh Devices
The principle of radical distrust requires us to consider the
possibility that a device might be compromised during manufacture.
Once consequence of this possibility is that when an administration
device connects a new device to a user's personal Mesh, we cannot put
our full trust in either the device being connected or the
administration device connecting it.
This concern is resolved by (at minimum) combining keying material
generated from both sources to create the keys to be used in the
context of the user's personal Mesh with the process being fully
verified by both parties.
Additional keying material sources could be added if protection
against the possibility of compromise at both devices was required
but this is not supported by the current specifications.
A device profile provides the axiom of trust and the key
contributions of the device. When bound to an account, the base keys
specified in the Device Profile are combined with the key data
provided in the Activation device to construct the keys the device
will use in the context of the account.
(Artwork only available as svg: No external link available, see
draft-hallambaker-mesh-schema-07.html for artwork.)
Figure 2: Mapping of Device Profile and Device Private to Device
Connection Keys.
Hallam-Baker Expires 17 July 2021 [Page 34]
Internet-Draft Mesh Schema Reference January 2021
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.
{
"ProfileDevice":{
"ProfileSignature":{
"Udf":"MAQO-2SJC-PGX4-KVHC-TEQ3-I2NP-GYBA",
"PublicParameters":{
"PublicKeyECDH":{
"crv":"Ed448",
"Public":"s9IdDH2a_dArdBA8thg41Ctwc0qVo6w67bRrEI1LZgSlG
pUSlXWZN8W-VY7hm40Xoq7TU5KEsQSA"}}},
"BaseEncryption":{
"Udf":"MD5F-Q3O6-KRGL-IS4V-IWVC-5SIN-S63R",
"PublicParameters":{
"PublicKeyECDH":{
"crv":"X448",
"Public":"aJSPUdraCO0yv2YXVKkQ4i1XUKVau-Apb7-OxXNb06Y-w
9I420kkRzXhSfsifKPegX7kJMHDKZkA"}}},
"BaseAuthentication":{
"Udf":"MDQC-JYXP-KZ3I-ETIO-KMWA-XIAP-3JRD",
"PublicParameters":{
"PublicKeyECDH":{
"crv":"X448",
"Public":"KABXGv_VuvLPRhfVpHd5qykjJDUNRiwhh5u3CJpwuAZXf
vmeM0KXit5b6wNvYYsSoLeNfKy337IA"}}},
"BaseSignature":{
"Udf":"MDL3-Q7RU-USJR-QF3O-CJEF-6TPW-EVAN",
"PublicParameters":{
"PublicKeyECDH":{
"crv":"Ed448",
"Public":"2wXyHGACnTq5ee8mgXM_jADlpeRV7gcN3jTQc9LP3LP1Y
zii2iSkUMgUTP8yF_KmibXs5pXvv0oA"}}}}}
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].
8.2.2.1. Creating a ProfileDevice
Creating a "ProfileDevice" comprises the steps of:
0. Creating the necessary key
1. Signing the "ProfileDevice" using the Master Signature Key
Hallam-Baker Expires 17 July 2021 [Page 35]
Internet-Draft Mesh Schema Reference January 2021
2. Once created, a "ProfileDevice" is never changed. In the
unlikely event that any modification is required, a completely
new "ProfileDevice" MUST be created.
8.2.2.2. Connection to a Personal Mesh
Devices are only connected to a personal Mesh by an administration
device. This comprises the steps of:
0. Generating the PrivateDevice keys.
1. Creating the ConnectionDevice data from the public components of
the ProfileDevice and PrivateDevice keys and signing it using the
administration key.
2. Creating the Activations for the device and signing them using
the administration key.
3. Creating the "CatalogEntryDevice" for the device and adding it to
the "CatalogDevice" of the Personal Mesh.
4. If the Personal Mesh has accounts that are connected to a Mesh
Service, synchronizing the "CatalogEntryDevice" to those
services.
These steps are usually performed through use of the Mesh Protocol
Connection mechanism. However, Mesh clients MAY support additional
mechanisms as circumstances require provided that the appropriate
authentication and private key protection controls are provided.
8.3. Mesh Services
A Mesh Service provides one or more Mesh Hosts that support Mesh
Accounts through the Mesh Web Service Protocol.
Mesh Services and Hosts are described by Service Profiles and Host
Profiles. The means by which services manage the hosts through which
they provide service is outside the scope of this document.
As with a Device connected to a Mesh Account, a the binding of a Host
to the service it supports is described by a connection record:
(Artwork only available as svg: No external link available, see
draft-hallambaker-mesh-schema-07.html for artwork.)
Figure 3: Service Profile and Delegated Host Assertion.
Hallam-Baker Expires 17 July 2021 [Page 36]
Internet-Draft Mesh Schema Reference January 2021
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.
8.4. Mesh Messaging
Mesh Messaging is an end-to-end secure messaging system used to
exchange short (32KB) messages between Mesh devices and services. In
cases where exchange of longer messages is required, Mesh Messaging
MAY be used to provide a control plane to advise the intended message
recipient(s) of the type of data being offered and the means of
retrieval (e.g an EARL).
All communications between Mesh accounts takes the form of a Mesh
Message carried in a Dare Envelope. Mesh Messages are stored in two
spools associated with the account, the SpoolOutbound and the
SpoolInbound containing the messages sent and received respectively.
This document only describes the representation of the messages
within the message spool. The Mesh Service protocol by which the
messages are exchanged between devices and services and between
services is described in [draft-hallambaker-mesh-protocol].
8.4.1. Message Status
As previously described in section ###, every message stored in a
spool has a specified state. The range of allowable states is
defined by the message type. New message states MAY be defined for
new message types as they are defined.
By default, messages are appended to a spool in the "Initial" state,
but a spool entry MAY specify any state that is valid for that
message type.
The state of a message is changed by appending a completion message
to the spool as described in [draft-hallambaker-mesh-protocol].
Services MAY erase or redact messages in accordance with local site
policy. Since messages are not removed from the spool on being
marked deleted, they may be undeleted by marking them as read or
unread. Marking a message deleted MAY make it more likely that the
message will be removed if the sequence is subsequently purged.
Hallam-Baker Expires 17 July 2021 [Page 37]
Internet-Draft Mesh Schema Reference January 2021
8.4.2. Four Corner Model
A four-corner messaging model is enforced. Mesh Services only accept
outbound messages from devices connected to accounts that it
services. Inbound messages are only accepted from other Mesh
Services. This model enables access control at both the outbound and
inbound services
(Artwork only available as svg: No external link available, see
draft-hallambaker-mesh-schema-07.html for artwork.)
Figure 4: Four Corner Messaging Model
The outbound Mesh Service checks to see that the request to send a
message does not violate its acceptable use policy. Accounts that
make a large number of message requests that result in complaints
SHOULD be subject to consequences ranging from restriction of the
number and type of messages sent to suspending or terminating
messaging privileges. Services that fail to implement appropriate
controls are likely to be subject to sanctions from either their
users or from other services.
(Artwork only available as svg: No external link available, see
draft-hallambaker-mesh-schema-07.html for artwork.)
Figure 5: Performing Access Control on Outbound Messages
The inbound Mesh Service also checks to see that messages received
are consistent with the service Acceptable Use Policy and the user's
personal access control settings.
Mesh Services that fail to police abuse by their account holders
SHOULD be subject to consequences in the same fashion as account
holders.
(Artwork only available as svg: No external link available, see
draft-hallambaker-mesh-schema-07.html for artwork.)
Figure 6: Performing Access Control on Inbound Messages
8.4.3. Traffic Analysis
The Mesh Messaging protocol as currently specified provides only
limited protection against traffic analysis attacks. The use of TLS
to encrypt communication between Mesh Services limits the
effectiveness of na?ve traffic analysis mechanisms but does not
prevent timing attacks unless dummy traffic is introduced to
obfuscate traffic flows.
Hallam-Baker Expires 17 July 2021 [Page 38]
Internet-Draft Mesh Schema Reference January 2021
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.
9. Publications
Static QR codes MAY be used to allow contact exchange or device
connection. In either case, the QR code contains an EARL providing
the means of locating, decrypting and authenticating the published
data.
The use of EARLs as a means of publishing encrypted data and the use
of EARLs for location, decryption and authentication is discussed in
[draft-hallambaker-mesh-dare] .
9.1. Contact Exchange
When used for contact exchange, the envelope payload is a
CatalogedContact record.
Besides allowing for exchange of contact information on a business
card, a user might have their contact information printed on personal
property to facilitate return of lost property.
9.2. Device Preconfiguration
The static QR code device connection interaction allows a device with
no keyboard, display or other user affordances to be connected to a
Mesh account.
The information necessary to establish communication with the device
and to complete a device connection workflow is provided by means of
a DevicePreconfiguration record accessed by means of an EARL.
For example, Alice's coffee pot was preconfigured for connection to a
Mesh account at the factory and the following DevicePreconfiguration
record created:
{
"DevicePreconfiguration":{
"EnvelopedProfileDevice":[{
"EnvelopeId":"MAQO-2SJC-PGX4-KVHC-TEQ3-I2NP-GYBA",
"dig":"S512",
"ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJNQVFPLTJTSkMtUE
dYNC1LVkhDLVRFUTMtSTJOUC1HWUJBIiwKICAiTWVzc2FnZVR5cGUiOiAiUHJvZml
sZURldmljZSIsCiAgImN0eSI6ICJhcHBsaWNhdGlvbi9tbW0vb2JqZWN0IiwKICAi
Hallam-Baker Expires 17 July 2021 [Page 39]
Internet-Draft Mesh Schema Reference January 2021
Q3JlYXRlZCI6ICIyMDIxLTAxLTEzVDE2OjM4OjM5WiJ9"},
"ewogICJQcm9maWxlRGV2aWNlIjogewogICAgIlByb2ZpbGVTaWduYXR1cm
UiOiB7CiAgICAgICJVZGYiOiAiTUFRTy0yU0pDLVBHWDQtS1ZIQy1URVEzLUkyTlA
tR1lCQSIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdWJs
aWNLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6ICJFZDQ0OCIsCiAgICAgICAgI
CAiUHVibGljIjogInM5SWRESDJhX2RBcmRCQTh0aGc0MUN0d2MwcVZvNnc2N2JSck
VJMUxaZ1NsR3BVU2xYV1oKICBOOFctVlk3aG00MFhvcTdUVTVLRXNRU0EifX19LAo
gICAgIkJhc2VFbmNyeXB0aW9uIjogewogICAgICAiVWRmIjogIk1ENUYtUTNPNi1L
UkdMLUlTNFYtSVdWQy01U0lOLVM2M1IiLAogICAgICAiUHVibGljUGFyYW1ldGVyc
yI6IHsKICAgICAgICAiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOi
AiWDQ0OCIsCiAgICAgICAgICAiUHVibGljIjogImFKU1BVZHJhQ08weXYyWVhWS2t
RNGkxWFVLVmF1LUFwYjctT3hYTmIwNlktdzlJNDIwa2sKICBSelhoU2ZzaWZLUGVn
WDdrSk1IREtaa0EifX19LAogICAgIkJhc2VBdXRoZW50aWNhdGlvbiI6IHsKICAgI
CAgIlVkZiI6ICJNRFFDLUpZWFAtS1ozSS1FVElPLUtNV0EtWElBUC0zSlJEIiwKIC
AgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUVDREg
iOiB7CiAgICAgICAgICAiY3J2IjogIlg0NDgiLAogICAgICAgICAgIlB1YmxpYyI6
ICJLQUJYR3ZfVnV2TFBSaGZWcEhkNXF5a2pKRFVOUml3aGg1dTNDSnB3dUFaWGZ2b
WVNMEtYCiAgaXQ1YjZ3TnZZWXNTb0xlTmZLeTMzN0lBIn19fSwKICAgICJCYXNlU2
lnbmF0dXJlIjogewogICAgICAiVWRmIjogIk1ETDMtUTdSVS1VU0pSLVFGM08tQ0p
FRi02VFBXLUVWQU4iLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAg
ICAiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogI
CAgICAgICAgIlB1YmxpYyI6ICIyd1h5SEdBQ25UcTVlZThtZ1hNX2pBRGxwZVJWN2
djTjNqVFFjOUxQM0xQMVl6aWkyaVNrCiAgVU1nVVRQOHlGX0ttaWJYczVwWHZ2MG9
BIn19fX19",
{
"signatures":[{
"alg":"S512",
"kid":"MAQO-2SJC-PGX4-KVHC-TEQ3-I2NP-GYBA",
"signature":"Rk-jBj3zvSUIYSTkVcq1BL134IBOKSFw0exQnv1Y
26U42dKutmhV5HahY40oJ3qlnaj6ZNuW0OSAKeoNbCJH--_3IggojgroQT_YHR3xe
G2nr5QcKNdrM9MenLukm4vj9Kk-CiQIsr4LE8rXnx-ICAIA"}
],
"PayloadDigest":"cdJ8Gs61LhDMaKD_H4s-4BLas3GVu5ktraeMhbgZ
AcKpYK-WOslevSZZ1B73P_gwHsMoltGo8hIL6CBQydwyuw"}
],
"EnvelopedConnectionDevice":[{
"dig":"S512",
"ContentMetaData":"ewogICJNZXNzYWdlVHlwZSI6ICJDb25uZWN0aW
9uRGV2aWNlIiwKICAiY3R5IjogImFwcGxpY2F0aW9uL21tbS9vYmplY3QiLAogICJ
DcmVhdGVkIjogIjIwMjEtMDEtMTNUMTY6Mzg6NDBaIn0"},
"ewogICJDb25uZWN0aW9uRGV2aWNlIjogewogICAgIkRldmljZVNpZ25hdH
VyZSI6IHsKICAgICAgIlVkZiI6ICJNREwzLVE3UlUtVVNKUi1RRjNPLUNKRUYtNlR
QVy1FVkFOIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1
YmxpY0tleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIkVkNDQ4IiwKICAgICAgI
CAgICJQdWJsaWMiOiAiMndYeUhHQUNuVHE1ZWU4bWdYTV9qQURscGVSVjdnY04zal
RRYzlMUDNMUDFZemlpMmlTawogIFVNZ1VUUDh5Rl9LbWliWHM1cFh2djBvQSJ9fX0
sCiAgICAiRGV2aWNlRW5jcnlwdGlvbiI6IHsKICAgICAgIlVkZiI6ICJNRDVGLVEz
TzYtS1JHTC1JUzRWLUlXVkMtNVNJTi1TNjNSIiwKICAgICAgIlB1YmxpY1BhcmFtZ
Hallam-Baker Expires 17 July 2021 [Page 40]
Internet-Draft Mesh Schema Reference January 2021
XRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICAgICAiY3
J2IjogIlg0NDgiLAogICAgICAgICAgIlB1YmxpYyI6ICJhSlNQVWRyYUNPMHl2Mll
YVktrUTRpMVhVS1ZhdS1BcGI3LU94WE5iMDZZLXc5STQyMGtrCiAgUnpYaFNmc2lm
S1BlZ1g3a0pNSERLWmtBIn19fSwKICAgICJEZXZpY2VBdXRoZW50aWNhdGlvbiI6I
HsKICAgICAgIlVkZiI6ICJNRDVGLVEzTzYtS1JHTC1JUzRWLUlXVkMtNVNJTi1TNj
NSIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0t
leUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIlg0NDgiLAogICAgICAgICAgIlB1
YmxpYyI6ICJhSlNQVWRyYUNPMHl2MllYVktrUTRpMVhVS1ZhdS1BcGI3LU94WE5iM
DZZLXc5STQyMGtrCiAgUnpYaFNmc2lmS1BlZ1g3a0pNSERLWmtBIn19fX19",
{
"signatures":[{
"alg":"S512",
"kid":"MC3W-C4WT-J4SR-F6W7-HOZN-ATJT-DNJZ",
"signature":"7PK0VTzj2A-WQsV2rJB13o4GERF2RsAS0lvE_dEo
gSU9ntXlphGKq2_HG1mRl_ST384i_850aeMASEBUeNmpAC7Int1Dhd6SIWIlPV0ro
xGnfqWQz-0Q44yxoyb10peN8sXApzotLOIcub3tN4q5vS8A"}
],
"PayloadDigest":"kDW0uaxyl9h89xhwA62Yj0SNOCfdpScINyvRrehg
-kFMn6NCEA69AFtawZ2gwKPRZfV30dAi-cQ47ACH0b3V-g"}
],
"PrivateKey":{
"PrivateKeyUDF":{
"PrivateValue":"ZAAQ-AQWW-7FV6-RK7V-XWUH-5LCF-DMRU-GHAT-5FD
P-PABH-3SD5-3UNJ-I6NO-BYFB",
"KeyType":"MeshProfileDevice"}},
"ConnectUri":"mcu://maker@example.com/EAQN-I5LT-6YG6-RR5F-57CG-
B755-RFUR-JVQQ-IW5N-X5FR-57BA-SJS6-X2PF-A"}}
To connect to the coffee pot, Alice first scans the QR code with her
administrative device which uses the PIN code and service to
retrieve, decrypt and authenticate the DevicePreconfiguration record.
Future versions of the specification will allow this record to
specify means by which the administration device can establish direct
peer-to-peer communication to complete the connection process by any
communication modality supported by both devices (e.g. IR,
Bluetooth, WiFi-Direct, etc.)
The use of the publication mechanism in device connection is
discussed further in [draft-hallambaker-mesh-protocol].
9.3. Device Description
The device description publication is a JSON Record that describes a
device that is available for connection.
[Not yet implemented.]
Hallam-Baker Expires 17 July 2021 [Page 41]
Internet-Draft Mesh Schema Reference January 2021
10. Schema
10.1. Shared Classes
The following classes are used as common elements in Mesh profile
specifications.
10.1.1. Classes describing keys
10.1.2. Structure: KeyData
The KeyData class is used to describe public key pairs and trust
assertions associated with a public key.
Udf: String (Optional) UDF fingerprint of the public key parameters
X509Certificate: Binary (Optional) List of X.509 Certificates
X509Chain: Binary [0..Many] X.509 Certificate chain.
X509CSR: Binary (Optional) X.509 Certificate Signing Request.
NotBefore: DateTime (Optional) If present specifies a time instant
that use of the private key is not valid before.
NotOnOrAfter: DateTime (Optional) If present specifies a time
instant that use of the private key is not valid on or after.
10.1.3. Structure: CompositePrivate
Inherits: Key
DeviceKeyUdf: String (Optional) UDF fingerprint of the bound device
key (if used).
10.2. Assertion classes
Classes that are derived from an assertion.
10.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.
Hallam-Baker Expires 17 July 2021 [Page 42]
Internet-Draft Mesh Schema Reference January 2021
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.
10.2.2. Structure: Condition
Parent class from which all condition classes are derived.
[No fields]
10.2.3. Base Classes
Abstract classes from which the Profile, Activation and Connection
classes are derrived.
10.2.4. Structure: Connection
Inherits: Assertion
SubjectUdf: String (Optional) UDF of the connection target.
AuthorityUdf: String (Optional) UDF of the connection source.
10.2.5. Structure: Activation
Inherits: Assertion
Contains the private activation information for a Mesh application
running on a specific device
ActivationKey: String (Optional) Secret seed used to derive keys
that are not explicitly specified.
Entries: ActivationEntry [0..Many] Activation of named resources.
10.2.6. Structure: ActivationEntry
Resource: String (Optional) Name of the activated resource
Key: KeyData (Optional) The activation key or key share
10.2.7. Mesh Profile Classes
Classes describing Mesh Profiles. All Profiles are Assertions
derrived from Assertion.
Hallam-Baker Expires 17 July 2021 [Page 43]
Internet-Draft Mesh Schema Reference January 2021
10.2.8. Structure: Profile
Inherits: Assertion
Parent class from which all profile classes are derived
ProfileSignature: KeyData (Optional) The permanent signature key
used to sign the profile itself. The UDF of the key is used as
the permanent object identifier of the profile. Thus, by
definition, the KeySignature value of a Profile does not change
under any circumstance.
10.2.9. Structure: ProfileDevice
Inherits: Profile
Describes a mesh device.
Description: String (Optional) Description of the device
BaseEncryption: KeyData (Optional) Base key contribution for
encryption keys. Also used to decrypt activation data sent to the
device during connection to an account.
BaseAuthentication: KeyData (Optional) Base key contribution for
authentication keys. Also used to authenticate the device during
connection to an account.
BaseSignature: KeyData (Optional) Base key contribution for
signature keys.
10.2.10. Structure: ProfileAccount
Base class for the account profiles ProfileUser and ProfileGroup.
These subclasses may be merged at some future date.
Inherits: Profile
AccountAddress: String (Optional) The account address. This is
either a DNS service address (e.g. alice@example.com) or a Mesh
Name (@alice).
ServiceUdf: String (Optional) The fingerprint of the service profile
to which the account is currently bound.
EscrowEncryption: KeyData (Optional) Escrow key associated with the
account.
Hallam-Baker Expires 17 July 2021 [Page 44]
Internet-Draft Mesh Schema Reference January 2021
AccountEncryption: KeyData (Optional) Key currently used to encrypt
data under this profile
AdministratorSignature: KeyData (Optional) Key used to sign
connection assertions to the account.
10.2.11. Structure: ProfileUser
Inherits: ProfileAccount
Account assertion. This is signed by the service hosting the
account.
AccountAuthentication: KeyData (Optional) Key used to authenticate
requests made under this user account.
AccountSignature: KeyData (Optional) Key used to sign data under the
account.
10.2.12. Structure: ProfileGroup
Inherits: ProfileAccount
Describes a group. Note that while a group is created by one person
who becomes its first administrator, control of the group may pass to
other administrators over time.
[No fields]
10.2.13. Structure: ProfileService
Inherits: Profile
Profile of a Mesh Service
ServiceAuthentication: KeyData (Optional) Key used to authenticate
service connections.
ServiceEncryption: KeyData (Optional) Key used to encrypt data under
this profile
ServiceSignature: KeyData (Optional) Key used to sign data under the
account.
10.2.14. Structure: ProfileHost
Inherits: Profile
Hallam-Baker Expires 17 July 2021 [Page 45]
Internet-Draft Mesh Schema Reference January 2021
KeyAuthentication: KeyData (Optional) Key used to authenticate
service connections.
KeyEncryption: KeyData (Optional) Key used to pass encrypted data to
the device such as a
10.2.15. Connection Assertions
Connection assertions are used to authenticate and authorize
interactions between devices and the service currently servicing the
account. They SHOULD NOT be visible to external parties.
10.2.16. Structure: ConnectionDevice
Inherits: Connection
Connection assertion used to authenticate service requests made by a
device.
AccountAddress: String (Optional) The account address
DeviceSignature: KeyData (Optional) The signature key for use of the
device under the profile
DeviceEncryption: KeyData (Optional) The encryption key for use of
the device under the profile
DeviceAuthentication: KeyData (Optional) The authentication key for
use of the device under the profile
10.2.17. Structure: ConnectionApplication
Inherits: Connection
Connection assertion stating that a particular device is
[No fields]
10.2.18. Structure: ConnectionGroup
Describes the connection of a member to a group.
Inherits: Connection
[No fields]
Hallam-Baker Expires 17 July 2021 [Page 46]
Internet-Draft Mesh Schema Reference January 2021
10.2.19. Structure: ConnectionService
Inherits: Connection
[No fields]
10.2.20. Structure: ConnectionHost
Inherits: Connection
[No fields]
10.2.21. Activation Assertions
10.2.22. Structure: ActivationDevice
Contains activation data for device specific keys used in the context
of a Mesh account.
Inherits: Activation
AccountUdf: String (Optional) The UDF of the account
10.2.23. Structure: ActivationAccount
Inherits: Activation
ProfileSignature: KeyData (Optional) Grant access to profile online
signing key used to sign updates to the profile.
AdministratorSignature: KeyData (Optional) Grant access to Profile
administration key used to make changes to administrator catalogs.
AccountEncryption: KeyData (Optional) Grant access to ProfileUser
account encryption key
AccountAuthentication: KeyData (Optional) Grant access to
ProfileUser account authentication key
AccountSignature: KeyData (Optional) Grant access to ProfileUser
account signature key
10.2.24. Structure: ActivationApplication
Inherits: Activation
[No fields]
Hallam-Baker Expires 17 July 2021 [Page 47]
Internet-Draft Mesh Schema Reference January 2021
10.3. Data Structures
Classes describing data used in cataloged data.
10.3.1. Structure: Contact
Inherits: Assertion
Base class for contact entries.
Id: String (Optional) The globally unique contact identifier.
Anchors: Anchor [0..Many] Mesh fingerprints associated with the
contact.
NetworkAddresses: NetworkAddress [0..Many] Network address entries
Locations: Location [0..Many] The physical locations the contact is
associated with.
Roles: Role [0..Many] The roles of the contact
Bookmark: Bookmark [0..Many] The Web sites and other online
presences of the contact
Sources: TaggedSource [0..Many] Source(s) from which this contact
was constructed.
10.3.2. Structure: Anchor
Trust anchor
Udf: String (Optional) The trust anchor.
Validation: String (Optional) The means of validation.
10.3.3. Structure: TaggedSource
Source from which contact information was obtained.
LocalName: String (Optional) Short name for the contact information.
Validation: String (Optional) The means of validation.
BinarySource: Binary (Optional) The contact data in binary form.
EnvelopedSource: Enveloped (Optional) The contact data in enveloped
form. If present, the BinarySource property is ignored.
Hallam-Baker Expires 17 July 2021 [Page 48]
Internet-Draft Mesh Schema Reference January 2021
10.3.4. Structure: ContactGroup
Inherits: Contact
Contact for a group, including encryption groups.
[No fields]
10.3.5. Structure: ContactPerson
Inherits: Contact
CommonNames: PersonName [0..Many] List of person names in order of
preference
10.3.6. Structure: ContactOrganization
Inherits: Contact
CommonNames: OrganizationName [0..Many] List of person names in
order of preference
10.3.7. Structure: OrganizationName
The name of an organization
Inactive: Boolean (Optional) If true, the name is not in current
use.
RegisteredName: String (Optional) The registered name.
DBA: String (Optional) Names that the organization uses including
trading names and doing business as names.
10.3.8. Structure: PersonName
The name of a natural person
Inactive: Boolean (Optional) If true, the name is not in current
use.
FullName: String (Optional) The preferred presentation of the full
name.
Prefix: String (Optional) Honorific or title, E.g. Sir, Lord, Dr.,
Mr.
First: String (Optional) First name.
Hallam-Baker Expires 17 July 2021 [Page 49]
Internet-Draft Mesh Schema Reference January 2021
Middle: String [0..Many] Middle names or initials.
Last: String (Optional) Last name.
Suffix: String (Optional) Nominal suffix, e.g. Jr., III, etc.
PostNominal: String (Optional) Post nominal letters (if used).
10.3.9. Structure: NetworkAddress
Provides all means of contacting the individual according to a
particular network address
Inactive: Boolean (Optional) If true, the name is not in current
use.
Address: String (Optional) The network address, e.g.
alice@example.com
NetworkCapability: String [0..Many] The capabilities bound to this
address.
EnvelopedProfileAccount: Enveloped (Optional) The account profile
Protocols: NetworkProtocol [0..Many] Public keys associated with the
network address
10.3.10. Structure: NetworkProtocol
Protocol: String (Optional) The IANA protocol|identifier of the
network protocols by which the contact may be reached using the
specified Address.
10.3.11. Structure: Role
OrganizationName: String (Optional) The organization at which the
role is held
Titles: String [0..Many] The titles held with respect to that
organization.
Locations: Location [0..Many] Postal or physical addresses
associated with the role.
10.3.12. Structure: Location
Appartment: String (Optional)
Hallam-Baker Expires 17 July 2021 [Page 50]
Internet-Draft Mesh Schema Reference January 2021
Street: String (Optional)
District: String (Optional)
Locality: String (Optional)
County: String (Optional)
Postcode: String (Optional)
Country: String (Optional)
10.3.13. Structure: Bookmark
Uri: String (Optional)
Title: String (Optional)
Role: String [0..Many]
10.3.14. 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.
10.3.15. Structure: Task
Key: String (Optional) Unique key.
Start: DateTime (Optional)
Finish: DateTime (Optional)
StartTravel: String (Optional)
FinishTravel: String (Optional)
TimeZone: String (Optional)
Title: String (Optional)
Description: String (Optional)
Hallam-Baker Expires 17 July 2021 [Page 51]
Internet-Draft Mesh Schema Reference January 2021
Location: String (Optional)
Trigger: String [0..Many]
Conference: String [0..Many]
Repeat: String (Optional)
Busy: Boolean (Optional)
10.4. Catalog Entries
10.4.1. Structure: CatalogedEntry
Base class for cataloged Mesh data.
Labels: String [0..Many] The set of labels describing the entry
10.4.2. Structure: CatalogedDevice
Inherits: CatalogedEntry
Public device entry, indexed under the device ID Hello
Udf: String (Optional) UDF of the signature key of the device in the
Mesh
DeviceUdf: String (Optional) UDF of the offline signature key of the
device
SignatureUdf: String (Optional) UDF of the account online signature
key
EnvelopedProfileUser: Enveloped (Optional) The Mesh profile
EnvelopedProfileDevice: Enveloped (Optional) The device profile
EnvelopedConnectionUser: Enveloped (Optional) The public assertion
demonstrating connection of the Device to the Mesh
EnvelopedActivationDevice: Enveloped (Optional) The activation of
the device within the Mesh account
EnvelopedActivationAccount: Enveloped (Optional) The activation of
the device within the Mesh account
EnvelopedActivationApplication: Enveloped [0..Many] Application
activations granted to the device.
Hallam-Baker Expires 17 July 2021 [Page 52]
Internet-Draft Mesh Schema Reference January 2021
10.4.3. Structure: CatalogedPublication
Inherits: CatalogedEntry
A publication.
Id: String (Optional) Unique identifier code
Authenticator: String (Optional) The witness key value to use to
request access to the record.
EnvelopedData: DareEnvelope (Optional) Dare Envelope containing the
entry data. The data type is specified by the envelope metadata.
NotOnOrAfter: DateTime (Optional) Epiration time (inclusive)
10.4.4. Structure: CatalogedCredential
Inherits: CatalogedEntry
Protocol: String (Optional)
Service: String (Optional)
Username: String (Optional)
Password: String (Optional)
10.4.5. Structure: CatalogedNetwork
Inherits: CatalogedEntry
Protocol: String (Optional)
Service: String (Optional)
Username: String (Optional)
Password: String (Optional)
10.4.6. Structure: CatalogedContact
Inherits: CatalogedEntry
Key: String (Optional) Unique key.
Self: Boolean (Optional) If true, this catalog entry is for the user
who created the catalog.
Hallam-Baker Expires 17 July 2021 [Page 53]
Internet-Draft Mesh Schema Reference January 2021
10.4.7. Structure: CatalogedAccess
Inherits: CatalogedEntry
[No fields]
10.4.8. Structure: CryptographicCapability
Id: String (Optional) The identifier of the capability. If this is
a user capability, MUST match the KeyData identifier. If this is
a serviced capability, MUST match the value of ServiceId on the
corresponding service capability.
KeyData: KeyData (Optional) The key that enables the capability
EnvelopedKeyShares: Enveloped [0..Many] One or more enveloped key
shares.
SubjectId: String (Optional) The identifier of the resource that is
controlled using the key.
SubjectAddress: String (Optional) The address of the resource that
is controlled using the key.
10.4.9. Structure: CapabilityDecrypt
Inherits: CryptographicCapability
The corresponding key is a decryption key
[No fields]
10.4.10. Structure: CapabilityDecryptPartial
Inherits: CapabilityDecrypt
The corresponding key is an encryption key
ServiceId: String (Optional) The identifier used to claim the
capability from the service.[Only present for a partial
capability.]
ServiceAddress: String (Optional) The service account that supports
a serviced capability. [Only present for a partial capability.]
Hallam-Baker Expires 17 July 2021 [Page 54]
Internet-Draft Mesh Schema Reference January 2021
10.4.11. Structure: CapabilityDecryptServiced
Inherits: CapabilityDecrypt
The corresponding key is an encryption key
AuthenticationId: String (Optional) UDF of trust root under which
request to use a serviced capability must be authorized. [Only
present for a serviced capability]
10.4.12. Structure: CapabilitySign
Inherits: CryptographicCapability
The corresponding key is an administration key
[No fields]
10.4.13. Structure: CapabilityKeyGenerate
Inherits: CryptographicCapability
The corresponding key is a key that may be used to generate key
shares.
[No fields]
10.4.14. Structure: CapabilityFairExchange
Inherits: CryptographicCapability
The corresponding key is a decryption key to be used in accordance
with the Micali Fair Electronic Exchange with Invisible Trusted
Parties protocol.
[No fields]
10.4.15. Structure: CatalogedBookmark
Inherits: CatalogedEntry
Uri: String (Optional)
Title: String (Optional)
Path: String (Optional)
Hallam-Baker Expires 17 July 2021 [Page 55]
Internet-Draft Mesh Schema Reference January 2021
10.4.16. Structure: CatalogedTask
Inherits: CatalogedEntry
EnvelopedTask: Enveloped (Optional)
Title: String (Optional)
Key: String (Optional) Unique key.
10.4.17. Structure: CatalogedApplication
Inherits: CatalogedEntry
Key: String (Optional)
EnvelopedCapabilities: DareEnvelope [0..Many] Enveloped keys for use
with Application
10.4.18. Structure: CatalogedMember
ContactAddress: String (Optional)
MemberCapabilityId: String (Optional)
ServiceCapabilityId: String (Optional)
Inherits: CatalogedEntry
10.4.19. Structure: CatalogedGroup
Inherits: CatalogedApplication
EnvelopedProfileGroup: Enveloped (Optional) The Mesh profile
EnvelopedActivationAccount: Enveloped (Optional) The activation of
the device within the Mesh account
10.4.20. Structure: CatalogedApplicationSSH
Inherits: CatalogedApplication
[No fields]
10.4.21. Structure: CatalogedApplicationMail
Inherits: CatalogedApplication
Hallam-Baker Expires 17 July 2021 [Page 56]
Internet-Draft Mesh Schema Reference January 2021
[No fields]
10.4.22. Structure: CatalogedApplicationNetwork
Inherits: CatalogedApplication
[No fields]
10.5. Publications
10.5.1. Structure: DevicePreconfiguration
A data structure that is passed
EnvelopedProfileDevice: Enveloped (Optional) The device profile
EnvelopedConnectionDevice: Enveloped (Optional) The device
connection
ConnectUri: String (Optional) The connection URI. This would
normally be printed on the device as a QR code.
10.6. Messages
10.6.1. Structure: Message
MessageId: String (Optional) Unique per-message ID. When
encapsulating a Mesh Message in a DARE envelope, the envelope
EnvelopeID field MUST be a UDF fingerprint of the MessageId value.
Sender: String (Optional)
Recipient: String (Optional)
10.6.2. Structure: MessageError
Inherits: Message
ErrorCode: String (Optional)
10.6.3. Structure: MessageComplete
Inherits: Message
References: Reference [0..Many]
Hallam-Baker Expires 17 July 2021 [Page 57]
Internet-Draft Mesh Schema Reference January 2021
10.6.4. Structure: MessagePinValidated
Inherits: Message
AuthenticatedData: DareEnvelope (Optional) Enveloped data that is
authenticated by means of the PIN
ClientNonce: Binary (Optional) Nonce provided by the client to
validate the PIN
PinId: String (Optional) Pin identifier value calculated from the
PIN code, action and account address.
PinWitness: Binary (Optional) Witness value calculated as KDF
(Device.Udf + AccountAddress, ClientNonce)
10.6.5. Structure: MessagePin
Account: String (Optional)
Inherits: Message
Expires: DateTime (Optional)
Automatic: Boolean (Optional) If true, authentication against the
PIN code is sufficient to complete the associated action without
further authorization.
SaltedPin: String (Optional) PIN code bound to the specified action.
Action: String (Optional) The action to which this PIN code is
bound.
10.6.6. Structure: RequestConnection
Connection request message. This message contains the information
Inherits: MessagePinValidated
AccountAddress: String (Optional)
10.6.7. Structure: AcknowledgeConnection
Connection request message generated by a service on receipt of a
valid MessageConnectionRequestClient
Inherits: Message
Hallam-Baker Expires 17 July 2021 [Page 58]
Internet-Draft Mesh Schema Reference January 2021
EnvelopedRequestConnection: Enveloped (Optional) The client
connection request.
ServerNonce: Binary (Optional)
Witness: String (Optional)
10.6.8. Structure: RespondConnection
Respond to RequestConnection message to grant or refuse the
connection request.
Inherits: Message
Result: String (Optional) The response to the request. One of
"Accept", "Reject" or "Pending".
CatalogedDevice: CatalogedDevice (Optional) The device information.
MUST be present if the value of Result is "Accept". MUST be
absent or null otherwise.
10.6.9. Structure: MessageContact
Inherits: MessagePinValidated
Reply: Boolean (Optional) If true, requests that the recipient
return their own contact information in reply.
Subject: String (Optional) Optional explanation of the reason for
the request.
PIN: String (Optional) One time authentication code supplied to a
recipient to allow authentication of the response.
10.6.10. Structure: GroupInvitation
Inherits: Message
Text: String (Optional)
10.6.11. Structure: RequestConfirmation
Inherits: Message
Text: String (Optional)
Hallam-Baker Expires 17 July 2021 [Page 59]
Internet-Draft Mesh Schema Reference January 2021
10.6.12. Structure: ResponseConfirmation
Inherits: Message
Request: Enveloped (Optional)
Accept: Boolean (Optional)
10.6.13. Structure: RequestTask
Inherits: Message
[No fields]
10.6.14. Structure: MessageClaim
Inherits: Message
PublicationId: String (Optional)
ServiceAuthenticate: String (Optional)
DeviceAuthenticate: String (Optional)
Expires: DateTime (Optional)
10.6.15. Structure: ProcessResult
For future use, allows logging of operations and results
Inherits: Message
Success: Boolean (Optional)
ErrorReport: String (Optional) The error report code.
11. 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].
12. IANA Considerations
All the IANA considerations for the Mesh documents are specified in
this document
Hallam-Baker Expires 17 July 2021 [Page 60]
Internet-Draft Mesh Schema Reference January 2021
13. Acknowledgements
A list of people who have contributed to the design of the Mesh is
presented in [draft-hallambaker-mesh-architecture].
14. Appendix A: Example Container Organization (not normative)
The means by which profiles are stored on devices is outside the
scope of the specification. Only catalogs that are required to be
shared between machines by means of accounts need to be standardized.
14.1. Device
Host Catalog: Host.dare Catalog of all the Mesh Profiles that the
user has registered with the device and the latest version of the
device profile for this device.
MeshCatalog: [UDF-Mesh].dcat Catalog containing the Account Entries
for the Mesh [UDF-Mesh].
Account Catalogs: [UDF-Account]/mmm_Device.dcat The device catalog
associated with the specified account
Account Catalogs: [UDF-Account]/[Catalog name].dcat The set of
account catalogs that are shared verbatim between the devices
connected to the account.
14.1.1. Creating a new Mesh
Create new Mesh Profile, Device Profile, Add to Host Catalog
Create MeshCatalog
14.1.2. Adding an Account
Create new Account Profile, Add to MeshCatalog
Create new Account Device Catalog
For each device to be added to the account: Create Account Connection
Assertion, add to Account Device Catalog.
14.1.3. Adding a Device
Create a Device Connection Assertion.
For each account the device is to be added to: Create Account
Connection Assertion, add to Account Device Catalog.
Hallam-Baker Expires 17 July 2021 [Page 61]
Internet-Draft Mesh Schema Reference January 2021
14.2. Service
Master Catalog Catalog of all services on machine
Service Catalog Catalog of accounts in the service.
14.2.1. Creating a Service
Create a Service Description, add to Master Catalog
14.2.2. Adding an Account
Create the account entry, add to Service Catalog
Create the Account Directory
15. Appendix B: Collected Authentication and Encryption Requirements
15.1. Mesh Messaging
+=======================+=========+==================+
| 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 |
+-----------------------+---------+------------------+
Table 1
Hallam-Baker Expires 17 July 2021 [Page 62]
Internet-Draft Mesh Schema Reference January 2021
16. Normative References
[draft-hallambaker-mesh-architecture]
Hallam-Baker, P., "Mathematical Mesh 3.0 Part I:
Architecture Guide", Work in Progress, Internet-Draft,
draft-hallambaker-mesh-architecture-15, 2 November 2020,
<https://tools.ietf.org/html/draft-hallambaker-mesh-
architecture-15>.
[draft-hallambaker-mesh-cryptography]
Hallam-Baker, P., "Mathematical Mesh 3.0 Part VIII:
Cryptographic Algorithms", Work in Progress, Internet-
Draft, draft-hallambaker-mesh-cryptography-07, 2 November
2020, <https://tools.ietf.org/html/draft-hallambaker-mesh-
cryptography-07>.
[draft-hallambaker-mesh-dare]
Hallam-Baker, P., "Mathematical Mesh 3.0 Part III : Data
At Rest Encryption (DARE)", Work in Progress, Internet-
Draft, draft-hallambaker-mesh-dare-10, 2 November 2020,
<https://tools.ietf.org/html/draft-hallambaker-mesh-dare-
10>.
[draft-hallambaker-mesh-discovery]
Hallam-Baker, P., "Mathematical Mesh 3.0 Part VI: Mesh
Discovery Service", Work in Progress, Internet-Draft,
draft-hallambaker-mesh-discovery-00, 2 November 2020,
<https://tools.ietf.org/html/draft-hallambaker-mesh-
discovery-00>.
[draft-hallambaker-mesh-notary]
"[Reference Not Found!]".
[draft-hallambaker-mesh-protocol]
Hallam-Baker, P., "Mathematical Mesh 3.0 Part V: Protocol
Reference", Work in Progress, Internet-Draft, draft-
hallambaker-mesh-protocol-07, 2 November 2020,
<https://tools.ietf.org/html/draft-hallambaker-mesh-
protocol-07>.
[draft-hallambaker-mesh-security]
Hallam-Baker, P., "Mathematical Mesh 3.0 Part VII:
Security Considerations", Work in Progress, Internet-
Draft, draft-hallambaker-mesh-security-06, 2 November
2020, <https://tools.ietf.org/html/draft-hallambaker-mesh-
security-06>.
Hallam-Baker Expires 17 July 2021 [Page 63]
Internet-Draft Mesh Schema Reference January 2021
[draft-hallambaker-mesh-udf]
Hallam-Baker, P., "Mathematical Mesh 3.0 Part II: Uniform
Data Fingerprint.", Work in Progress, Internet-Draft,
draft-hallambaker-mesh-udf-11, 2 November 2020,
<https://tools.ietf.org/html/draft-hallambaker-mesh-udf-
11>.
[draft-hallambaker-threshold]
Hallam-Baker, P., "Threshold Modes in Elliptic Curves",
Work in Progress, Internet-Draft, draft-hallambaker-
threshold-04, 2 November 2020,
<https://tools.ietf.org/html/draft-hallambaker-threshold-
04>.
[draft-hallambaker-threshold-sigs]
Hallam-Baker, P., "Threshold Signatures in Elliptic
Curves", Work in Progress, Internet-Draft, draft-
hallambaker-threshold-sigs-05, 2 November 2020,
<https://tools.ietf.org/html/draft-hallambaker-threshold-
sigs-05>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
17. Informative References
[draft-hallambaker-mesh-developer]
Hallam-Baker, P., "Mathematical Mesh: Reference
Implementation", Work in Progress, Internet-Draft, draft-
hallambaker-mesh-developer-10, 27 July 2020,
<https://tools.ietf.org/html/draft-hallambaker-mesh-
developer-10>.
[RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile",
RFC 2426, DOI 10.17487/RFC2426, September 1998,
<https://www.rfc-editor.org/rfc/rfc2426>.
[RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling
Core Object Specification (iCalendar)", RFC 5545,
DOI 10.17487/RFC5545, September 2009,
<https://www.rfc-editor.org/rfc/rfc5545>.
Hallam-Baker Expires 17 July 2021 [Page 64]
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/