[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10

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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/