Network Working Group P. Hallam-Baker
Internet-Draft Comodo Group Inc.
Intended status: Informational August 31, 2018
Expires: March 4, 2019
Mathematical Mesh Part II: Reference
draft-hallambaker-mesh-reference-10
Abstract
The Mathematical Mesh ?The Mesh? is an end-to-end secure
infrastructure that facilitates the exchange of configuration and
credential data between multiple user devices. The core protocols of
the Mesh are described with examples of common use cases and
reference data.
This document is also available online at
http://mathmesh.com/Documents/draft-hallambaker-mesh-reference.html
[1] .
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 4, 2019.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Hallam-Baker Expires March 4, 2019 [Page 1]
Internet-Draft Mathematical Mesh Reference August 2018
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Related Specifications . . . . . . . . . . . . . . . . . 5
2.4. Implementation Status . . . . . . . . . . . . . . . . . . 5
3. Mesh Profiles . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Mesh Master Profile . . . . . . . . . . . . . . . . . . . 6
3.2. Mesh Device Profile . . . . . . . . . . . . . . . . . . . 7
3.3. Mesh Personal Profile . . . . . . . . . . . . . . . . . . 7
3.4. Mesh Application Profile . . . . . . . . . . . . . . . . 8
4. Mesh Portal Service . . . . . . . . . . . . . . . . . . . . . 8
4.1. Creating a Mesh Service Account . . . . . . . . . . . . . 8
4.2. Using Recovery Records . . . . . . . . . . . . . . . . . 9
4.2.1. Creating a Recovery Record . . . . . . . . . . . . . 9
4.2.2. Recovering a Profile. . . . . . . . . . . . . . . . . 11
4.3. Connecting a Device to a Portal Account . . . . . . . . . 11
4.3.1. Deleting a Portal Account . . . . . . . . . . . . . . 13
5. Mesh Catalogs . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Synchronizing a Device to a Catalog . . . . . . . . . . . 14
6. Mesh Catalog Services . . . . . . . . . . . . . . . . . . . . 16
6.1. The Contacts Catalog . . . . . . . . . . . . . . . . . . 16
6.2. Credential Catalog . . . . . . . . . . . . . . . . . . . 16
6.3. Tasks Catalog . . . . . . . . . . . . . . . . . . . . . . 16
6.4. Mail Catalog . . . . . . . . . . . . . . . . . . . . . . 17
6.5. SSH Catalog . . . . . . . . . . . . . . . . . . . . . . . 17
6.6. Recryption Catalog . . . . . . . . . . . . . . . . . . . 17
7. Mesh Messaging . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. Message Origination . . . . . . . . . . . . . . . . . . . 18
7.2. Message Transit . . . . . . . . . . . . . . . . . . . . . 19
7.3. Receiving Messages . . . . . . . . . . . . . . . . . . . 20
7.3.1. Responding to Messages . . . . . . . . . . . . . . . 21
8. Messaging Services . . . . . . . . . . . . . . . . . . . . . 21
8.1. Contact Messaging Service . . . . . . . . . . . . . . . . 21
8.2. Confirmation Messaging Service . . . . . . . . . . . . . 21
8.3. Asynchronous Messaging Service . . . . . . . . . . . . . 21
8.4. Synchronous Messaging Service . . . . . . . . . . . . . . 21
9. Shared Classes . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Cryptographic Data Classes . . . . . . . . . . . . . . . 21
9.1.1. Structure: PublicKey . . . . . . . . . . . . . . . . 22
9.1.2. Structure: SignedData . . . . . . . . . . . . . . . . 22
Hallam-Baker Expires March 4, 2019 [Page 2]
Internet-Draft Mathematical Mesh Reference August 2018
9.1.3. Structure: EncryptedData . . . . . . . . . . . . . . 22
9.2. Common Application Classes . . . . . . . . . . . . . . . 22
9.2.1. Structure: Connection . . . . . . . . . . . . . . . . 22
10. Mesh Profile Objects . . . . . . . . . . . . . . . . . . . . 23
10.1. Base Profile Objects . . . . . . . . . . . . . . . . . . 23
10.1.1. Structure: Entry . . . . . . . . . . . . . . . . . . 23
10.1.2. Structure: SignedProfile . . . . . . . . . . . . . . 23
10.1.3. Structure: Advice . . . . . . . . . . . . . . . . . 23
10.1.4. Structure: PortalAdvice . . . . . . . . . . . . . . 24
10.1.5. Structure: Profile . . . . . . . . . . . . . . . . . 24
10.2. Device Profile Classes . . . . . . . . . . . . . . . . . 24
10.2.1. Structure: SignedDeviceProfile . . . . . . . . . . . 24
10.2.2. Structure: DeviceProfile . . . . . . . . . . . . . . 24
10.2.3. Structure: DevicePrivateProfile . . . . . . . . . . 25
10.3. Master Profile Objects . . . . . . . . . . . . . . . . . 25
10.3.1. Structure: SignedMasterProfile . . . . . . . . . . . 25
10.3.2. Structure: MasterProfile . . . . . . . . . . . . . . 25
10.4. Personal Profile Objects . . . . . . . . . . . . . . . . 26
10.4.1. Structure: SignedPersonalProfile . . . . . . . . . . 26
10.4.2. Structure: PersonalProfile . . . . . . . . . . . . . 26
10.4.3. Structure: ApplicationProfileEntry . . . . . . . . . 26
10.5. Application Profile Objects . . . . . . . . . . . . . . 27
10.5.1. Structure: SignedApplicationProfile . . . . . . . . 27
10.5.2. Structure: ApplicationProfile . . . . . . . . . . . 27
10.5.3. Structure: ApplicationProfilePrivate . . . . . . . . 27
10.5.4. Structure: ApplicationDevicePublic . . . . . . . . . 27
10.5.5. Structure: ApplicationDevicePrivate . . . . . . . . 28
10.6. Key Escrow Objects . . . . . . . . . . . . . . . . . . . 28
10.6.1. Structure: EscrowEntry . . . . . . . . . . . . . . . 28
10.6.2. Structure: OfflineEscrowEntry . . . . . . . . . . . 28
10.6.3. Structure: OnlineEscrowEntry . . . . . . . . . . . . 28
10.6.4. Structure: EscrowedKeySet . . . . . . . . . . . . . 28
11. Portal Connection . . . . . . . . . . . . . . . . . . . . . . 28
11.1. Connection Request and Response Structures . . . . . . . 28
11.1.1. Structure: ConnectionRequest . . . . . . . . . . . . 29
11.1.2. Structure: SignedConnectionRequest . . . . . . . . . 29
11.1.3. Structure: ConnectionResult . . . . . . . . . . . . 29
11.1.4. Structure: SignedConnectionResult . . . . . . . . . 29
12. Mesh Portal Service Reference . . . . . . . . . . . . . . . . 29
12.1. Request Messages . . . . . . . . . . . . . . . . . . . . 30
12.1.1. Message: MeshRequest . . . . . . . . . . . . . . . . 30
12.2. Response Messages . . . . . . . . . . . . . . . . . . . 30
12.2.1. Message: MeshResponse . . . . . . . . . . . . . . . 30
12.3. Imported Objects . . . . . . . . . . . . . . . . . . . . 30
12.4. Common Structures . . . . . . . . . . . . . . . . . . . 30
12.4.1. Structure: KeyValue . . . . . . . . . . . . . . . . 30
12.4.2. Structure: SearchConstraints . . . . . . . . . . . . 31
12.5. Transaction: Hello . . . . . . . . . . . . . . . . . . . 31
Hallam-Baker Expires March 4, 2019 [Page 3]
Internet-Draft Mathematical Mesh Reference August 2018
12.6. Transaction: ValidateAccount . . . . . . . . . . . . . . 31
12.6.1. Message: ValidateRequest . . . . . . . . . . . . . . 32
12.6.2. Message: ValidateResponse . . . . . . . . . . . . . 32
12.7. Transaction: CreateAccount . . . . . . . . . . . . . . . 33
12.7.1. Message: CreateRequest . . . . . . . . . . . . . . . 33
12.7.2. Message: CreateResponse . . . . . . . . . . . . . . 33
12.8. Transaction: DeleteAccount . . . . . . . . . . . . . . . 33
12.8.1. Message: DeleteRequest . . . . . . . . . . . . . . . 34
12.8.2. Message: DeleteResponse . . . . . . . . . . . . . . 34
12.9. Transaction: Get . . . . . . . . . . . . . . . . . . . . 34
12.9.1. Message: GetRequest . . . . . . . . . . . . . . . . 34
12.9.2. Message: GetResponse . . . . . . . . . . . . . . . . 35
12.10. Transaction: Publish . . . . . . . . . . . . . . . . . . 35
12.10.1. Message: PublishRequest . . . . . . . . . . . . . . 35
12.10.2. Message: PublishResponse . . . . . . . . . . . . . 36
12.11. Transaction: Status . . . . . . . . . . . . . . . . . . 36
12.11.1. Message: StatusRequest . . . . . . . . . . . . . . 36
12.11.2. Message: StatusResponse . . . . . . . . . . . . . . 36
12.12. Transaction: ConnectStart . . . . . . . . . . . . . . . 37
12.12.1. Message: ConnectStartRequest . . . . . . . . . . . 37
12.12.2. Message: ConnectStartResponse . . . . . . . . . . . 37
12.13. Transaction: ConnectStatus . . . . . . . . . . . . . . . 37
12.13.1. Message: ConnectStatusRequest . . . . . . . . . . . 38
12.13.2. Message: ConnectStatusResponse . . . . . . . . . . 38
12.14. Transaction: ConnectPending . . . . . . . . . . . . . . 38
12.14.1. Message: ConnectPendingRequest . . . . . . . . . . 38
12.14.2. Message: ConnectPendingResponse . . . . . . . . . . 39
12.15. Transaction: ConnectComplete . . . . . . . . . . . . . . 39
12.15.1. Message: ConnectCompleteRequest . . . . . . . . . . 39
12.15.2. Message: ConnectCompleteResponse . . . . . . . . . 39
12.16. Transaction: Transfer . . . . . . . . . . . . . . . . . 40
12.16.1. Message: TransferRequest . . . . . . . . . . . . . 40
12.16.2. Message: TransferResponse . . . . . . . . . . . . . 40
13. Security Considerations . . . . . . . . . . . . . . . . . . . 40
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
16.1. Normative References . . . . . . . . . . . . . . . . . . 41
16.2. Informative References . . . . . . . . . . . . . . . . . 41
16.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction
This document describes the data structures and network protocols of
the Mathematical Mesh illustrated with illustrative examples. For an
overview of the Mesh objectives and architecture, consult the
accompanying Architecture Guide [draft-hallambaker-mesh-architecture]
Hallam-Baker Expires March 4, 2019 [Page 4]
Internet-Draft Mathematical Mesh Reference August 2018
This document has two main sections. The first section presents
examples of using the Mesh to address common use cases. The second
section contains the Mesh profile and service schemas. All the
material in both sections is generated from the Mesh reference
implementation [draft-hallambaker-mesh-developer] .
Although some of the services described in this document could be
used to replace existing Internet protocols including FTP and SMTP,
the principal value of any communication protocol lies in the size of
the audience it allows them to communicate with. Thus, while the
Mesh Messaging service is designed to support efficient and reliable
transfer of messages ranging in size from a few bytes to multiple
terabytes, the near term applications of these services will be to
applications that are not adequately supported by existing protocols
if at all.
2. Definitions
This section presents the related specifications and standard, the
terms that are used as terms of art within the documents and the
terms used as requirements language.
2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] .
2.2. Defined Terms
The terms of art used in this document are described in the Mesh
Architecture Guide [draft-hallambaker-mesh-architecture] .
2.3. Related Specifications
The architecture of the Mathematical Mesh is described in the Mesh
Architecture Guide [draft-hallambaker-mesh-architecture] . The Mesh
documentation set and related specifications are described in this
document.
2.4. Implementation Status
The implementation status of the reference code base is described in
the companion document [draft-hallambaker-mesh-developer] .
Hallam-Baker Expires March 4, 2019 [Page 5]
Internet-Draft Mathematical Mesh Reference August 2018
3. Mesh Profiles
Every Mesh user has a Mesh profile which contains all the
configuration information for all their devices and all their network
services. For convenience, the mesh profile is divided into four
separate parts, the Master profile, the Personal Profile, Device
Profiles and Application Profiles as follows:
3.1. Mesh Master Profile
The Mesh Master Profile describes the criteria for validating an
owner's personal profile. In particular, the master profile
specifies the Master Signature Key that is used as the root of trust
under which the master profile is validated and a set of
Administration Signature Keys under which the personal profile is
validated.
Master Signature Key is immutable. By definition, it is not possible
to change the Master Signature Key without creating a new master
profile.
The UDF fingerprint of the Master Signature Key is the fingerprint of
the Master Profile and the Personal Profile created underneath it.
For example, Alice creates the following Master Profile, it has a
Master Signature Key and a Master Recovery Key. There is one
administration device specified, the correcponding device profile is
described in the next section.
{AliceMasterProfile}
Figure 1
The UDF fingerprint of Alice's Master signature key is:
{AliceFingerprint}
Figure 2
A Master Profile MAY be revoked but never expires. It is the
intended that a user should not normally need to change their master
profile.
The only means of expiring a master profile that is currently
supported is to sign a 'suicide note' for the profile. This is an
assertion that the master profile is invalid that has been signed by
the user. An application MAY generate such a suicide note at the
Hallam-Baker Expires March 4, 2019 [Page 6]
Internet-Draft Mathematical Mesh Reference August 2018
time that the master profile is created and archive it so that the
profile owner's executors can revoke the profile after death.
{AliceMasterProfileSuicide}
Figure 3
Since a Master Signature Key is immutable, no provision is made for
modifying a Master Signature Key, nor is such provision possible.
Should a user lose control of the private keys listed in their master
profile, the only remediation possible is to create a new Master
Signature Key and master profile and then persuade parties relying on
the original that it is the successor.
3.2. Mesh Device Profile
To make use of the Mesh Profile, Alice needs to connect at least one
device. Every device profile has an encryption, signature and
authentication key.
Alice decides to use her desktop personal computer as her first
administration device. Her device profile is:
{AliceDeviceProfile}
Figure 4
Note that each of the keys is a Diffie-Hellman Key. This enables the
use of distributed key generation techniques as described in part
III. These will be transitioned to Elliptic Curve Diffie Hellman
keys for production use.
3.3. Mesh Personal Profile
Alice's personal profile contains her master profile and a list of
device profiles. It is signed by her administration device using its
signature key.
Alice's personal profile specifies her master profile and the device
profile of her personal computer:
{AlicePersonalProfile}
Figure 5
A personal profile instance MUST specify the device profile of the
administration profile that signed that instance.
Hallam-Baker Expires March 4, 2019 [Page 7]
Internet-Draft Mathematical Mesh Reference August 2018
3.4. Mesh Application Profile
Alice also creates one or more application profiles, each of which
are signed by her administration key.
Alice creates a credential catalog to allow her to create strong
passwords with a work factor of 2^128 and use them on multiple
devices, in this case, her administration device and her
{AliceApplicationProfile}
Figure 6
4. Mesh Portal Service
The Mesh Portal Service is the subset of Mesh Service operations that
manage Mesh profiles. A Mesh Service MUST support the Mesh Portal
Service but is not required to support any other service.
4.1. Creating a Mesh Service Account
Having created a personal profile, Alice requests creation of an
account at a Mesh Service. The first step in this process is
choosing a Mesh Service account address 'Mesh address'
A Mesh address has the format user@domain where domain is the DNS
name of the Mesh service and user is the name of their account at
that service.
Services MAY support the use of any unicode character sequence
permitted for use as an SMTP email address by RFC6530. Matching of
Mesh addresses is case insensitive for latin characters (a-z, A-Z)
but no similar mappings are supported for other character sets.
Alice selects the Mesh Service 'example.com' and the name 'alice'.
Her Mesh client first checks to see if the name is available:
Request {Verify alice@example.com}
Figure 7
The Mesh service responds stating that the address is available.
The ValidateRequest message contains the requested account identifier
and an optional language parameter to allow the service to provide
informative error messages in a language the user understands. The
Language field contains a list of ISO language identifier codes in
order of preference, most preferred first.
Hallam-Baker Expires March 4, 2019 [Page 8]
Internet-Draft Mathematical Mesh Reference August 2018
Response {Verify alice@example.com}
Figure 8
The ValidateResponse message returns the result of the validation
request in the Valid field. Note that even if the value true is
returned, a subsequent account creation request MAY still fail.
[Note that for the sake of concise presentation, the HTTP binding
information is omitted from future examples.]
The Mesh client requests that the account be created and bound to the
(provided) personal profile:
Request {Account Create alice@example.com}
Figure 9
The Mesh service responds stating that the address is available:
Response {Account Create alice@example.com}
Figure 10
4.2. Using Recovery Records
Before using her newly created profile, Alice makes sure that she can
recover it in the case of a catastrophe. She also wants to make sure
that her master profile won't be compromised if the machine she
created it on is compromised by deleting the key information from the
machine. To do this, she creates a Recovery Record.
A recovery record contains the private keys associated with her
master profile encrypted using a strong symmetric cipher (AES 256 in
this case). Recovery records are indexed by means of the UDF
fingerprint derrived from the decryption key. Thus, knowledge of the
decryption key is sufficient to locate the recovery record in a
collection of recovery records and knowledge of the index is evidence
that a requestor knows the decryption key.
4.2.1. Creating a Recovery Record
The plaintext of the recovery record specifies the private keys
associated with the Master Signature Key and Master Escrow Key:
{Recovery RecordPlaintext}
Figure 11
Hallam-Baker Expires March 4, 2019 [Page 9]
Internet-Draft Mathematical Mesh Reference August 2018
A Master Recovery Key is created. In this case, Alice is using a
Master Recovery Key of 128 bits so that the recovery key shares are
as compact as possible.
{MasterRecoveryKey}
Figure 12
The HKDF function is used to derrive the Encryption Key for the
Recovery Record and the Recovery index:
{RecoveryEncryptionKey}
{RecoveryIndex}
Figure 13
The Recovery record is encrypted using the DARE Message Format
{Recovery RecordDARE}
Figure 14
The Mesh client then creates an authenticated request to post the
recovery record to the profile:
{AuthenticatedRecoveryRequest}
Figure 15
The Mesh Service returns its response:
{AuthenticatedRecoveryResponse}
Figure 16
[Note that for the sake of concise presentation, the request and
response authentication information is omitted from future examples.]
Having successfully posted the recovery data to the service, the
client presents Alice with a list of recovery shares that can be used
to recover the data. The calculation of the recovery shares is
described in part III.
{Recovery shares 2 of 3}
Figure 17
Hallam-Baker Expires March 4, 2019 [Page 10]
Internet-Draft Mathematical Mesh Reference August 2018
4.2.2. Recovering a Profile.
To test her ability to recover her master profile, Alice deletes her
master profile from her administration device=. To recover her
profile, Alice reconstructs the recovery secret from two of her
shares and uses this information to request recovery:
{RecoveryRecordRequest}
Figure 18
Note that this request is not authenticated.
The Mesh Service locates the requested data and responds:
{RecoveryRecordResponse}
Figure 19
The client recovers the Master profile information and verifies it,
then uses the data to reactivate the
4.3. Connecting a Device to a Portal Account
Connecting a device to a profile requires the client on the new
device to interact with a client on a device that has administration
capabilities, i.e. it has access to an Online Signing Key. Since
clients cannot interact directly with other clients, a service is
required to mediate the connection. This service is provided by a
Mesh portal provider.
All service transactions are initiated by the clients. First the
connecting device posts ConnectStart, after which it may poll for the
outcome of the connection request using ConnectStatus.
Periodically, the Administration Device polls for a list of pending
connection requests using ConnectPending. After posting a request,
the administration device posts the result using ConnectComplete:
Hallam-Baker Expires March 4, 2019 [Page 11]
Internet-Draft Mathematical Mesh Reference August 2018
Connecting Mesh Administration
Device Service Device
| | |
| ConnectStart | |
| ----------------------> | |
| | ConnectPending |
| | <---------------------- |
| | |
| | ConnectComplete |
| | <---------------------- |
| ConnectStatus | |
| ----------------------> | |
Figure 20
The Device connection flow is actually an example of the Messaging
flow in that it is initiated by an untrusted device making a
connection request to the Mesh Service which the user's
administration device collects and responds to in the same fashion as
any other messaging flow.
The process is initiated by a request from the device to post a
connection request.
Request {ConnectStart alice@example.com}
Figure 21
The request is accepted. Note that if abuse is a concern, we may
have required the use of a one time passcode to validate the request.
The service responds with the personal profile bound to the account.
Response {ConnectStart alice@example.com}
Figure 22
The fingerprint of the device profile and the fingerprint of the
personal profile are combined to create a request verification code.
This is displayed on Alice's device
{Verification code.}
Figure 23
To authorize the request, the administration device begins by
synchronizing the connect message spool:
Hallam-Baker Expires March 4, 2019 [Page 12]
Internet-Draft Mathematical Mesh Reference August 2018
Request {SyncPending Connect alice@example.com}
Figure 24
The service responds with a list of pending requests optionally
filtered according to criteria provided by Alice:
Response {SyncPending Connect alice@example.com}
Figure 25
Alice Accepts the request. Her administration device creates and
signs a Device Authorization and posts it to the Mesh Service where
it is added to the Device Catalog:
Request {ConnectPost alice@example.com}
Figure 26
The request is successful:
Response {ConnectPost alice@example.com}
Figure 27
Finally, the device polls the service and recieves notice that the
request has been accepted:
Request {ConnectStatus alice@example.com}
Figure 28
The acceptance includes a copy of the Device Authorization(s).
Response {ConnectStatus alice@example.com}
Figure 29
4.3.1. Deleting a Portal Account
Should she ever decide to stop using the Mesh Service, Alice can
request that her account be deleted. Note that this only affects her
account on the service and not on her local machine.
{DeleteRequest}
Figure 30
Hallam-Baker Expires March 4, 2019 [Page 13]
Internet-Draft Mathematical Mesh Reference August 2018
The Mesh Service returns its response:
{DeleteResponse}
Figure 31
Once a Mesh address has been deleted, reuse of the address by a new
profile is entirely a matter for site policy. A Mesh Service MAY
refuse to allow any request to create an account with a previously
used address under any circumstances or MAY allow any party to reuse
the address.
Mesh addresses are inherently transient. If a permanent and
immutable address is required for some purpose, the Strong Internet
Name of the Mesh Address SHOULD be used instead. This name binds the
Mesh profile fingerprint to the Mesh Address, thus creating a name
that can be regarded as unambiguously identifying the profile owner
and means of contact.
5. Mesh Catalogs
A Mesh Catalog Service contains a set of entries that are created by
the user for their own use.
A catalog entry MUST be signed by the signature key of a device that
is specified in the user's Personal Profile.
Each entry in a Mesh catalog has a unique identifier that acts as its
primary key.
Mesh catalogs are typically compact and updated infrequently. Given
current storage costs and typical network bandwidth, it is to be
expected that most users will be best served by a model in which
every device contains a complete copy of the user's catalog(s) that
are of interest to it rather than support a model in which connected
devices hunt an peck for the desired records on the server. Such an
approach is in any case likely to be impossible for the majority of
Mesh applications in which the server content is end-to-end
encrypted.
5.1. Synchronizing a Device to a Catalog
Synchronization of the catalog data stored on a device with that
stored by the Mesh service is bidirectional. Catalog updates stored
on the device are merged with those stored on the service and any
conflicts reported to the user.
Hallam-Baker Expires March 4, 2019 [Page 14]
Internet-Draft Mathematical Mesh Reference August 2018
Each device that has the access privilege to update catalog entries
thus has two separate queues, one containing a (possibly incomplete)
copy of the append-only log held by the service, the other containing
updates that have been made on the device but have not yet been
accepted by the service.
When a device synchronizes, it:
o Downloads relevant updates from the service to the device.
Devices MAY perform these operations in either order or
simultaneously (if the service permits). But regardless of the order
in which these are performed by a particular device, there is only
one catalog and it is maintaind by the service. Thus all updates
that are accepted SHALL be applied to the catalog after all the
previous updates.
Since every object has a distinct and independent lifecycle in the
Mesh persistence model, detecting a conflict early on in the
synchronization process does not invalidate updates to other objects
which are independent.
For example, consider the scenario in which Alice synchronizes two
devices to her credential catalog.
Alice is already using the password management features of her
browser but this service does not provide end-to-end encryption.
Alice's Mesh client provides a feature that allows her to export the
usernames and passwords from her browser and store them in a Mesh
catalog.
Alice's first device creates two credential entries.
{AliceCredential1}
Figure 32
When multiple catalog entries are being encrypted at the same time,
these MAY be encrypted under a single key agreement or under a
separate key agreement for each entry. Here, a single key agreement
is shared:
{AliceCredential1Request}
Figure 33
Hallam-Baker Expires March 4, 2019 [Page 15]
Internet-Draft Mathematical Mesh Reference August 2018
Since the catalog is empty, the service accepts the update entries
and responds with the catalog index before and after the items were
accepted.
{AliceCredential1Response}
Figure 34
Alice then attempts to syncrhonize a second device. The browser on
the second device has two entries, one of which maches an entry in
the first and the other of which is different:
{AliceCredential2}
Figure 35
When the service responds to the second request, the first entry is
rejected as a possible conflict and the second is accepted. Note
that even though the username/password values are identical, the
service does not know this because they are end-to-end encrypted and
the service does not have a decryption key. The service responds
with a list of the frame numbers of the rejected entries.
{AliceCredential1Response}
Figure 36
Entries are deleted from a catalog with the delete method. The
request specifies the catalog to be updated and the list of entries
to be deleted:
{AliceDeleteCredential}
Figure 37
6. Mesh Catalog Services
6.1. The Contacts Catalog
{includes recryption membership notifications}
6.2. Credential Catalog
6.3. Tasks Catalog
Hallam-Baker Expires March 4, 2019 [Page 16]
Internet-Draft Mathematical Mesh Reference August 2018
6.4. Mail Catalog
6.5. SSH Catalog
6.6. Recryption Catalog
The recryption catalog is unique in that it is the only Mesh Service
that contains entries that are to be decrypted by the Mesh Service
itself
Recryption Group Administrator entries Contain the information that
an administrator requires to administer a recryption group. These
are encrypted such that only the administrators can decrypt them.
Recryption Group Member entries Contain the information that the
Recryption Service requires to respond to recryption requests
encrypted under the server key.
7. Mesh Messaging
Mesh messaging services are very similar to Mesh catalog services but
with one important difference: Requests to append or update message
entries come from a third party that may prove untrustworthy. It is
therefore necessary to apply access control to inbound message
requests.
The persistence store for a messaging service is called a spool. As
with the catalog store of a catalog service, the DARE Container
format is designed to support the requirements of managing a
messaging service spool but Mesh Services MAY use any persistence
technology that meets their needs.
Some Mesh messaging services are standalone while others are closely
related to a catalog service.
o Accepting a recryption membership notification SHOULD result in an
entry being added to the recipient's credential catalog.
o Accepting a device connection request MUST result in an entry
being added to the user's devices catalog.
The PostUpdate method allows a Mesh client to reply to an inbound
request and post an entry to the accompanying catalog at the same
time.
Mesh messaging services adopt a four corner communication mode in
which the sender of a message forwards the request to their own Mesh
Service which in turn contacts the recipient's Mesh service to
Hallam-Baker Expires March 4, 2019 [Page 17]
Internet-Draft Mathematical Mesh Reference August 2018
organize delivery. As with any other four Mesh Service MAY act for
both the sender and receiver
The only circumstance in which the sender and recipient communicate
directly is in a two phase synchronous protocol in which a four
corner first phase is used to negotiate parameters for a direct
connection in the second phase.
7.1. Message Origination
Messages are posted to the senders outbound Mesh Service using the
Post method.
Alice meets Bob and they 'bump' phones performing a QR code exchange.
To begin this exchange, Alice's device generates a random one-time
use passcode. Note that since this passcode is only used to
authenticate the exchange to mitigate abuse, a work factor of 2^64 is
more than sufficient.
lYFAVLNJLkC
Figure 38
The QR code is:
[QR code image]
The decoded URI is:
mmm:alice@example.com.mmm-wekjhwkjehrkjwher:c:lYFAVLNJLkC
Figure 39
Bob's phone reads the QR code and creates a contact request message
containing Bob's information. The contact request asks to be able to
send various types of message.
{BobContactPostRequest}
Figure 40
Messages are subject to access control by both the inbound and
outbound services.
Bob's Mesh Service checks to see if the rate of contact requests he
has made in the past is excessive. Finding that it is not, the
contact request is accepted and placed in the outbound messages
queue.
Hallam-Baker Expires March 4, 2019 [Page 18]
Internet-Draft Mathematical Mesh Reference August 2018
Bob's service responds with a unique identifier that MAY be used to
check on the status of the message:
{BobContactPostRequest}
Figure 41
A short while later, Bob's phone asks for a status update on the
request.
{BobContactStatusRequest}
Figure 42
Alice has not responded yet (she is talking to Bob in person).
{BobContactStatusRequest}
Figure 43
If Bob decides not to connect after all, he can cancel the request.
7.2. Message Transit
Passing of messages between Mesh Services is called transit.
To begin a message transfer, the outbound service makes a PostRequest
to the inbound service which contains the message headers and the
maximum size of the payload.
{OutboundPostRequest}
Figure 44
The inbound service performs access control on the PostRequest
according to site policy which MAY include use any resources the
inbound service chooses to use, including:
o Valid one time use authorization code issued by the recipient to
the sender
o Credentials provided by the inbound service.
o The sender's entry in the recipient's contact catalog.
o The type of access requested.
Hallam-Baker Expires March 4, 2019 [Page 19]
Internet-Draft Mathematical Mesh Reference August 2018
The access control policy is set by the Mesh Service and the user.
When setting an access control policy, both should consider the
likelihood that the recipient would wish to accept the message and
the risk of harm resulting.
Different users will naturally require different access policies. A
celebrity receiving hundreds of contacts a day is likely to require
closer access control criteria than a person receiving one request a
week. A request to send email messages presents a lower degree of
risk than a request to send invoices or program code.
In this case, the request has been pre-approved by means of a one
time use authentication code provided by Alice's device. The inbound
service has no means of verifying the authentication code at this
stage but accepts the request knowing that it will be rejected by
Alice's client if it proves to be bogus.
{OutboundPostResponse}
Figure 45
Since the contact request message is short, the inbound service
authorizes the outbound service to send the message body immediately.
If the message was longer, the inbound service might tell the
outbound to defer delivery of the message body which might be
completed by means of an incremental transfer (e.g. in chunks of 4MB
at a time).
This mechanism allows the same messaging protocol to be used to
transfer messages of a few bytes to multiple terabytes. A Mesh
Service is not required to support such messages however and
particularly in the case of very large messages, may delgate
collection of the message payload to the destination device.
7.3. Receiving Messages
Pending messages are received by synchronizing the message spool of
the device with the message spool of the messaging service. This
process is identical to synchonizing a catalog.
{SyncRequest}
Figure 46
There is only one message in the contact request spool to be
synchronized:
Hallam-Baker Expires March 4, 2019 [Page 20]
Internet-Draft Mathematical Mesh Reference August 2018
{SyncResponse}
Figure 47
A device MAY improve the user experience by requesting the service
provide just the headers of the queued messages or to filter messages
of a particular type or which have particular characteristics.
7.3.1. Responding to Messages
As previously noted, the response to a message request frequently
entails an update to the user's corresponding catalog. Otherwise,
posting a response is the same as a request.
Alice's phone verifies the authentication code on Bob's request and
automatically approves it for the level of access Alice specified
when they bumped phones. A new contact entry is created together
with a contact request message to be returned to Bob notifying him
that his request was approved by Alice and providing him with her
details for his contact catalog.
{ContactAddResponse}
Figure 48
8. Messaging Services
8.1. Contact Messaging Service
8.2. Confirmation Messaging Service
8.3. Asynchronous Messaging Service
8.4. Synchronous Messaging Service
9. Shared Classes
The following classes are used as common elements in Mesh profile
specifications.a
9.1. Cryptographic Data Classes
Most Mesh objects are signed and/or encrypted. For consistency all
Mesh classes make use of the cryptographic data classes described in
this section.
Hallam-Baker Expires March 4, 2019 [Page 21]
Internet-Draft Mathematical Mesh Reference August 2018
9.1.1. Structure: PublicKey
The PublicKey class is used to describe public key pairs and trust
assertions associated with a public key.
UDF: String (Optional) UDF fingerprint of the public key parameters/
X509Certificate: Binary (Optional) List of X.509 Certificates
X509Chain: Binary [0..Many] X.509 Certificate chain.
X509CSR: Binary (Optional) X.509 Certificate Signing Request.
9.1.2. Structure: SignedData
Container for JOSE signed data and related attributes.
Data: Binary (Optional) The signed data
9.1.3. Structure: EncryptedData
Container for JOSE encrypted data and related attributes.
Data: Binary (Optional) The encrypted data
9.2. Common Application Classes
9.2.1. Structure: Connection
Describes network connection parameters for an application
ServiceName: String (Optional) DNS address of the server
Port: Integer (Optional) TCP/UDP Port number
Prefix: String (Optional) DNS service prefix as described in
[!RFC6335]
Security: String [0..Many] Describes the security mode to use.
Valid choices are Direct/Upgrade/None
UserName: String (Optional) Username to present to the service for
authentication
Password: String (Optional) Password to present to the service for
authentication
URI: String (Optional) Service connection parameters in URI format
Hallam-Baker Expires March 4, 2019 [Page 22]
Internet-Draft Mathematical Mesh Reference August 2018
Authentication: String (Optional) List of the supported/acceptable
authentication mechanisms, preferred mechanism first.
TimeOut: Integer (Optional) Service timeout in seconds.
Polling: Boolean (Optional) If set, the client should poll the
specified service intermittently for updates.
10. Mesh Profile Objects
10.1. Base Profile Objects
10.1.1. Structure: Entry
Base class for all Mesh Profile objects.
Identifier: String (Optional) Globally unique identifier that
remains constant for the lifetime of the entry.
10.1.2. Structure: SignedProfile
Inherits: Entry
Contains a signed profile entry
SignedData: JoseWebSignature (Optional) The signed profile.
Note that each child of SignedProfile requires that the Payload
field of the SignedData object contain an object of a specific
type. For example, a SignedDeviceProfile object MUST contain a
Payload field that contains a DeviceProfile object.
Unauthenticated: Advice (Optional) Additional data that is not
authenticated.
10.1.3. Structure: Advice
Additional data bound to a signed profile that is not authenticated.
Default: DateTime (Optional) If specified, the profile was the
default profile at the specified date and time. The current
default for that type of profile is the profile with the most
recent Default timestamp.
Hallam-Baker Expires March 4, 2019 [Page 23]
Internet-Draft Mathematical Mesh Reference August 2018
10.1.4. Structure: PortalAdvice
Describes the portal(s) at which the profile is registered.
Inherits: Advice
Inherits: Advice
PortalAddress: String [0..Many] A portal address at which this
profile is registered.
10.1.5. Structure: Profile
Inherits: Entry
Parent class from which all profile types are derived
Names: String [0..Many] Fingerprints of index terms for profile
retrieval. The use of the fingerprint of the name rather than the
name itself is a precaution against enumeration attacks and other
forms of abuse.
Updated: DateTime (Optional) The time instant the profile was last
modified.
NotaryToken: String (Optional) A Uniform Notary Token providing
evidence that a signature was performed after the notary token was
created.
10.2. Device Profile Classes
10.2.1. Structure: SignedDeviceProfile
Inherits: SignedProfile
Contains a signed device profile
[No fields]
10.2.2. Structure: DeviceProfile
Inherits: Profile
Describes a mesh device.
Description: String (Optional) Description of the device
Hallam-Baker Expires March 4, 2019 [Page 24]
Internet-Draft Mathematical Mesh Reference August 2018
DeviceSignatureKey: PublicKey (Optional) Key used to sign
certificates for the DAK and DEK. The fingerprint of the DSK is
the UniqueID of the Device Profile
DeviceAuthenticationKey: PublicKey (Optional) Key used to
authenticate requests made by the device.
DeviceEncryptiontionKey: PublicKey (Optional) Key used to pass
encrypted data to the device such as a DeviceUseEntry
10.2.3. Structure: DevicePrivateProfile
Private portion of device encryption profile.
DeviceSignatureKey: Key (Optional) Private portion of the
DeviceSignatureKey
DeviceAuthenticationKey: Key (Optional) Private portion of the
DeviceAuthenticationKey
DeviceEncryptiontionKey: Key (Optional) Private portion of the
DeviceEncryptiontionKey
10.3. Master Profile Objects
10.3.1. Structure: SignedMasterProfile
Inherits: SignedProfile
Contains a signed Personal master profile
[No fields]
10.3.2. Structure: MasterProfile
Inherits: Profile
Describes the long term parameters associated with a personal
profile.
MasterSignatureKey: PublicKey (Optional) The root of trust for the
Personal PKI, the public key of the PMSK is presented as a self-
signed X.509v3 certificate with Certificate Signing use enabled.
The PMSK is used to sign certificates for the PMEK, POSK and PKEK
keys.
Hallam-Baker Expires March 4, 2019 [Page 25]
Internet-Draft Mathematical Mesh Reference August 2018
MasterEscrowKeys: PublicKey [0..Many] A Personal Profile MAY contain
one or more PMEK keys to enable escrow of private keys used for
stored data.
OnlineSignatureKeys: PublicKey [0..Many] A Personal profile contains
at least one POSK which is used to sign device administration
application profiles.
10.4. Personal Profile Objects
10.4.1. Structure: SignedPersonalProfile
Inherits: SignedProfile
Contains a signed Personal current profile
[No fields]
10.4.2. Structure: PersonalProfile
Inherits: Profile
Describes the current applications and devices connected to a
personal master profile.
SignedMasterProfile: SignedMasterProfile (Optional) The
corresponding master profile. The profile MUST be signed by the
PMSK.
Devices: SignedDeviceProfile [0..Many] The set of device profiles
connected to the profile. The profile MUST be signed by the DSK
in the profile.
Applications: ApplicationProfileEntry [0..Many] Application profiles
connected to this profile.
10.4.3. Structure: ApplicationProfileEntry
Personal profile entry describing the privileges of specific devices.
Identifier: String (Optional) The unique identifier of the
application
Type: String (Optional) The application type
Friendly: String (Optional) Optional friendly name identifying the
application.
Hallam-Baker Expires March 4, 2019 [Page 26]
Internet-Draft Mathematical Mesh Reference August 2018
AdminDeviceUDF: String [0..Many] List of devices authorized to sign
application profiles
DecryptDeviceUDF: String [0..Many] List of devices authorized to
read private parts of application profiles.
AccountID: String (Optional) The account at which the profile is
located.
10.5. Application Profile Objects
10.5.1. Structure: SignedApplicationProfile
Inherits: SignedProfile
Contains a signed device profile
[No fields]
10.5.2. Structure: ApplicationProfile
Inherits: Profile
Parent class from which all application profiles inherit.
[No fields]
10.5.3. Structure: ApplicationProfilePrivate
Inherits: Entry
The base class for all private profiles.
[No fields]
10.5.4. Structure: ApplicationDevicePublic
Inherits: Entry
Describes the public per device data
DeviceDescription: String (Optional) Description of the device for
convenience of the user.
DeviceUDF: String (Optional) Fingerprint of device that this key
corresponds to.
Hallam-Baker Expires March 4, 2019 [Page 27]
Internet-Draft Mathematical Mesh Reference August 2018
10.5.5. Structure: ApplicationDevicePrivate
Inherits: Entry
Describes the private per device data
[No fields]
10.6. Key Escrow Objects
10.6.1. Structure: EscrowEntry
Inherits: Entry
Contains escrowed data
EncryptedData: JoseWebEncryption (Optional) The encrypted escrow
data
10.6.2. Structure: OfflineEscrowEntry
Inherits: EscrowEntry
Contains data escrowed using the offline escrow mechanism.
[No fields]
10.6.3. Structure: OnlineEscrowEntry
Inherits: EscrowEntry
Contains data escrowed using the online escrow mechanism.
[No fields]
10.6.4. Structure: EscrowedKeySet
A set of escrowed keys.
[No fields]
11. Portal Connection
11.1. Connection Request and Response Structures
Hallam-Baker Expires March 4, 2019 [Page 28]
Internet-Draft Mathematical Mesh Reference August 2018
11.1.1. Structure: ConnectionRequest
Describes a connection request.
ParentUDF: String (Optional) UDF of Mesh Profile to which connection
is requested.
Device: SignedDeviceProfile (Optional) The Device profile to be
connected
11.1.2. Structure: SignedConnectionRequest
Inherits: SignedProfile
Contains a ConnectionRequest signed by the corresponding device
signature key.
[No fields]
11.1.3. Structure: ConnectionResult
Describes the result of a connection request.
Inherits: ConnectionRequest
Inherits: ConnectionRequest
Result: String (Optional) The result of the connection request.
Valid responses are: Accepted, Refused, Query.
11.1.4. Structure: SignedConnectionResult
Inherits: SignedProfile
Contains a signed connection result
[No fields]
12. Mesh Portal Service Reference
HTTP Well Known Service Prefix: /.well-known/mmm
Every Mesh Portal Service transaction consists of exactly one request
followed by exactly one response. Mesh Service transactions MAY
cause modification of the data stored in the Mesh Portal or the Mesh
itself but do not cause changes to the connection state. The
protocol itself is thus idempotent. There is no set sequence in
which operations are required to be performed. It is not necessary
Hallam-Baker Expires March 4, 2019 [Page 29]
Internet-Draft Mathematical Mesh Reference August 2018
to perform a Hello transaction prior to a ValidateAccount, Publish or
any other transaction.
12.1. Request Messages
A Mesh Portal Service request consists of a payload object that
inherits from the MeshRequest class. When using the HTTP binding,
the request MUST specify the portal DNS address in the HTTP Host
field.
12.1.1. Message: MeshRequest
Base class for all request messages.
Portal: String (Optional) Name of the Mesh Portal Service to which
the request is directed.
12.2. Response Messages
A Mesh Portal Service response consists of a payload object that
inherits from the MeshResponse class. When using the HTTP binding,
the response SHOULD report the Status response code in the HTTP
response message. However the response code returned in the payload
object MUST always be considered authoritative.
12.2.1. Message: MeshResponse
Base class for all response messages. Contains only the status code
and status description fields.
[No fields]
12.3. Imported Objects
The Mesh Service protocol makes use of JSON objects defined in the
JOSE Signatgure and Encryption specifications.
12.4. Common Structures
The following common structures are used in the protocol messages:
12.4.1. Structure: KeyValue
Describes a Key/Value structure used to make queries for records
matching one or more selection criteria.
Key: String (Optional) The data retrieval key.
Hallam-Baker Expires March 4, 2019 [Page 30]
Internet-Draft Mathematical Mesh Reference August 2018
Value: String (Optional) The data value to match.
12.4.2. Structure: SearchConstraints
Specifies constraints to be applied to a search result. These allow
a client to limit the number of records returned, the quantity of
data returned, the earliest and latest data returned, etc.
NotBefore: DateTime (Optional) Only data published on or after the
specified time instant is requested.
Before: DateTime (Optional) Only data published before the specified
time instant is requested. This excludes data published at the
specified time instant.
MaxEntries: Integer (Optional) Maximum number of data entries to
return.
MaxBytes: Integer (Optional) Maximum number of data bytes to return.
PageKey: String (Optional) Specifies a page key returned in a
previous search operation in which the number of responses
exceeded the specified bounds.
When a page key is specified, all the other search parameters
except for MaxEntries and MaxBytes are ignored and the service
returns the next set of data responding to the earlier query.
12.5. Transaction: Hello
Request: HelloRequest
Request: HelloRequest
Response: HelloResponse
Report service and version information.
The Hello transaction provides a means of determining which protocol
versions, message encodings and transport protocols are supported by
the service.
12.6. Transaction: ValidateAccount
Request: ValidateRequest
Request: ValidateRequest
Hallam-Baker Expires March 4, 2019 [Page 31]
Internet-Draft Mathematical Mesh Reference August 2018
Response: ValidateResponse
Request validation of a proposed name for a new account.
For validation of a user's account name during profile creation.
12.6.1. Message: ValidateRequest
Inherits: MeshRequest
Describes the proposed account properties. Currently, these are
limited to the account name but could be extended in future versions
of the protocol.
Account: String (Optional) Account name requested
Reserve: Boolean (Optional) If true, request a reservation for the
specified account name. Note that the service is not obliged to
honor reservation requests.
Language: String [0..Many] List of ISO language codes in order of
preference. For creating explanatory text.
12.6.2. Message: ValidateResponse
Inherits: MeshResponse
States whether the proposed account properties are acceptable and
(optional) returns an indication of what properties are valid.
Note that receiving a 'Valid' responseto a Validate Request does not
guarantee creation of the account. In addition to the possibility
that the account namecould be requested by another user between the
Validate and Create transactions, a portal service MAY perform more
stringent validation criteria when an account is actually being
created. For example, checking with the authoritative list of
current accounts rather than a cached copy.
Valid: Boolean (Optional) If true, the specified account identifier
is acceptable. If false, the account identifier is rejected.
Minimum: Integer (Optional) Specifies the minimum length of an
account name.
Maximum: Integer (Optional) Specifies the maximum length of an
account name.
Hallam-Baker Expires March 4, 2019 [Page 32]
Internet-Draft Mathematical Mesh Reference August 2018
InvalidCharacters: String (Optional) A list of characters that the
service does not accept in account names. The list of characters
MAY not be exhaustive but SHOULD include any illegal characters in
the proposed account name.
Reason: String (Optional) Text explaining the reason an account name
was rejected.
12.7. Transaction: CreateAccount
Request: CreateRequest
Request: CreateRequest
Response: CreateResponse
Request creation of a new portal account.
Unlike a profile, a mesh account is specific to a particular Mesh
portal. A mesh account must be created and accepted before a profile
can be published.
12.7.1. Message: CreateRequest
Request creation of a new portal account. The request specifies the
requested account identifier and the Mesh profile to be associated
with the account.
Inherits: MeshRequest
Inherits: MeshRequest
Account: String (Optional) Account identifier requested.
12.7.2. Message: CreateResponse
Inherits: MeshResponse
Reports the success or failure of a Create transaction.
[No fields]
12.8. Transaction: DeleteAccount
Request: DeleteRequest
Request: DeleteRequest
Hallam-Baker Expires March 4, 2019 [Page 33]
Internet-Draft Mathematical Mesh Reference August 2018
Response: DeleteResponse
Request deletion of a portal account.
Deletes a portal account but not the underlying profile. Once
registered, profiles are permanent.
12.8.1. Message: DeleteRequest
Request deletion of a new portal account. The request specifies the
requested account identifier.
Inherits: MeshRequest
Inherits: MeshRequest
Account: String (Optional) Account identifier to be deleted.
12.8.2. Message: DeleteResponse
Inherits: MeshResponse
Reports the success or failure of a Delete transaction.
[No fields]
12.9. Transaction: Get
Request: GetRequest
Request: GetRequest
Response: GetResponse
Search for data in the mesh that matches a set of properties
described by a sequence of key/value pairs.
12.9.1. Message: GetRequest
Describes the Portal or Mesh data to be retreived.
Inherits: MeshRequest
Inherits: MeshRequest
Identifier: String (Optional) Lookup by profile ID
Account: String (Optional) Lookup by Account ID
Hallam-Baker Expires March 4, 2019 [Page 34]
Internet-Draft Mathematical Mesh Reference August 2018
KeyValues: KeyValue [0..Many] List of KeyValue pairs specifying the
conditions to be met
SearchConstraints: SearchConstraints (Optional) Constrain the search
to a specific time interval and/or limit the number and/or total
size of data records returned.
Multiple: Boolean (Optional) If true return multiple responses if
available
Full: Boolean (Optional) If true, the client requests that the full
Mesh data record be returned containing both the Mesh entry itself
and the Mesh metadata that allows the date and time of the
publication of the Mesh entry to be verified.
12.9.2. Message: GetResponse
Reports the success or failure of a Get transaction. If a Mesh entry
matching the specified profile is found, containsthe list of entries
matching the request.
Inherits: MeshResponse
Inherits: MeshResponse
DataItems: DataItem [0..Many] List of mesh data records matching the
request.
PageKey: String (Optional) If non-null, indicates that the number
and/or size of the data records returned exceeds either the
SearchConstraints specified in the request or internal server
limits.
12.10. Transaction: Publish
Request: PublishRequest
Request: PublishRequest
Response: PublishResponse
Publish a profile or key escrow entry to the mesh.
12.10.1. Message: PublishRequest
Requests publication of the specified Mesh entry.
Inherits: MeshRequest
Hallam-Baker Expires March 4, 2019 [Page 35]
Internet-Draft Mathematical Mesh Reference August 2018
[No fields]
12.10.2. Message: PublishResponse
Reports the success or failure of a Publish transaction.
Inherits: MeshResponse
[No fields]
12.11. Transaction: Status
Request: StatusRequest
Request: StatusRequest
Response: StatusResponse
Request the current status of the mesh as seen by the portal to which
it is directed.
The response to the status request contains the last signed
checkpoint and proof chains for each of the peer portals that have
been checkpointed.
[Not currently implemented]
12.11.1. Message: StatusRequest
Inherits: MeshRequest
Initiates a status transaction.
[No fields]
12.11.2. Message: StatusResponse
Reports the success or failure of a Status transaction.
Inherits: MeshResponse
Inherits: MeshResponse
LastWriteTime: DateTime (Optional) Time that the last write update
was made to the Mesh
LastCheckpointTime: DateTime (Optional) Time that the last Mesh
checkpoint was calculated.
Hallam-Baker Expires March 4, 2019 [Page 36]
Internet-Draft Mathematical Mesh Reference August 2018
NextCheckpointTime: DateTime (Optional) Time at which the next Mesh
checkpoint should be calculated.
CheckpointValue: String (Optional) Last checkpoint value.
12.12. Transaction: ConnectStart
Request: ConnectStartRequest
Request: ConnectStartRequest
Response: ConnectStartResponse
Request connection of a new device to a mesh profile
12.12.1. Message: ConnectStartRequest
Inherits: MeshRequest
Initial device connection request.
SignedRequest: SignedConnectionRequest (Optional) Device connection
request signed by thesignature key of the device requesting
connection.
AccountID: String (Optional) Account identifier of account to which
the device is requesting connection.
12.12.2. Message: ConnectStartResponse
Reports the success or failure of a ConnectStart transaction.
Inherits: MeshRequest
[No fields]
12.13. Transaction: ConnectStatus
Request: ConnectStatusRequest
Request: ConnectStatusRequest
Response: ConnectStatusResponse
Request status of pending connection request of a new device to a
mesh profile
Hallam-Baker Expires March 4, 2019 [Page 37]
Internet-Draft Mathematical Mesh Reference August 2018
12.13.1. Message: ConnectStatusRequest
Inherits: MeshRequest
Request status information for a pending request posted previously.
AccountID: String (Optional) Account identifier for which pending
connection information is requested.
DeviceID: String (Optional) Device identifier of device requesting
status information.
12.13.2. Message: ConnectStatusResponse
Reports the success or failure of a ConnectStatus transaction.
Inherits: MeshRequest
Inherits: MeshRequest
Result: SignedConnectionResult (Optional) The signed
ConnectionResult object.
12.14. Transaction: ConnectPending
Request: ConnectPendingRequest
Request: ConnectPendingRequest
Response: ConnectPendingResponse
Request a list of pending requests for an administration profile.
12.14.1. Message: ConnectPendingRequest
Inherits: MeshRequest
Specify the criteria for pending requests.
AccountID: String (Optional) The account identifier of the account
for which pending connection requests are requested.
SearchConstraints: SearchConstraints (Optional) Constrain the search
to a specific time interval and/or limit the number and/or total
size of data records returned.
Hallam-Baker Expires March 4, 2019 [Page 38]
Internet-Draft Mathematical Mesh Reference August 2018
12.14.2. Message: ConnectPendingResponse
Reports the success or failure of a ConnectPending transaction.
Inherits: MeshRequest
Inherits: MeshRequest
Pending: SignedConnectionRequest [0..Many] A list of pending
requests satisfying the criteria set out in the request.
PageKey: String (Optional) If non-null, indicates that the number
and/or size of the data records returned exceeds either the
SearchConstraints specified in the request or internal server
limits.
12.15. Transaction: ConnectComplete
Request: ConnectCompleteRequest
Request: ConnectCompleteRequest
Response: ConnectCompleteResponse
Post response to a pending connection request.
12.15.1. Message: ConnectCompleteRequest
Reports the success or failure of a ConnectComplete transaction.
Inherits: MeshRequest
Inherits: MeshRequest
Result: SignedConnectionResult (Optional) The connection result to
be posted to the portal. The result MUST be signed by a valid
administration key for the Mesh profile.
AccountID: String (Optional) The account identifier to which the
connection result is posted.
12.15.2. Message: ConnectCompleteResponse
Inherits: MeshRequest
Reports the success or failure of a ConnectComplete transaction.
[No fields]
Hallam-Baker Expires March 4, 2019 [Page 39]
Internet-Draft Mathematical Mesh Reference August 2018
12.16. Transaction: Transfer
Request: TransferRequest
Request: TransferRequest
Response: TransferResponse
Perform a bulk transfer of the log between the specified transaction
identifiers. Requires appropriate authorization
[Not currently implemented]
12.16.1. Message: TransferRequest
Request a bulk transfer of the log between the specified transaction
identifiers. Requires appropriate authorization
Inherits: MeshRequest
Inherits: MeshRequest
SearchConstraints: SearchConstraints (Optional) Constrain the search
to a specific time interval and/or limit the number and/or total
size of data records returned.
12.16.2. Message: TransferResponse
Inherits: MeshResponse
Reports the success or failure of a Transfer transaction. If
successful, contains the list of Mesh records to be transferred.
DataItems: DataItem [0..Many] List of mesh data records matching the
request.
PageKey: String (Optional) If non-null, indicates that the number
and/or size of the data records returned exceeds either the
SearchConstraints specified in the request or internal server
limits.
13. Security Considerations
TBS
Hallam-Baker Expires March 4, 2019 [Page 40]
Internet-Draft Mathematical Mesh Reference August 2018
14. IANA Considerations
All the IANA considerations for the Mesh documents are specified in
this document
15. Acknowledgements
16. References
16.1. Normative References
[draft-hallambaker-mesh-architecture]
Hallam-Baker, P., "Mathematical Mesh: Architecture",
draft-hallambaker-mesh-architecture-05 (work in progress),
August 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165,
RFC 6335, DOI 10.17487/RFC6335, August 2011.
16.2. Informative References
[draft-hallambaker-mesh-developer]
Hallam-Baker, P., "Mathematical Mesh: Reference
Implementation", draft-hallambaker-mesh-developer-07 (work
in progress), April 2018.
16.3. URIs
[1] http://mathmesh.com/Documents/draft-hallambaker-mesh-
reference.html
Author's Address
Phillip Hallam-Baker
Comodo Group Inc.
Email: philliph@comodo.com
Hallam-Baker Expires March 4, 2019 [Page 41]