<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-hallambaker-mesh-security-09" indexInclude="false" ipr="trust200902" prepTime="2022-04-20T16:18:58Z" scripts="Common,Latin" sortRefs="true" submissionType="independent" symRefs="true" tocDepth="3" tocInclude="true" version="3" xml:lang="en"><front>
<title abbrev="Mathematical Mesh Reference">Mathematical Mesh 3.0 Part IX Security Considerations</title>
<seriesInfo name="Internet-Draft" value="draft-hallambaker-mesh-security" stream="independent"/>
<author fullname="Phillip Hallam-Baker" initials="P. M." surname="Hallam-Baker"><organization>ThresholdSecrets.com</organization>
<address>
<email>phill@hallambaker.com</email>
</address>
</author>
<date day="20" month="April" year="2022"/>
<area/>
<workgroup/>
<abstract>
<t>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.</t>
<t>[Note to Readers]</t>
<t>Discussion of this draft takes place on the MATHMESH mailing list (mathmesh@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=mathmesh.</t>
<t>This document is also available online at <eref target="http://mathmesh.com/Documents/draft-hallambaker-mesh-security.html"></eref>.</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="n-introduction"></section>
<section title="Definitions" anchor="n-definitions"><t>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.</t>
<section title="Requirements Language" anchor="n-requirements-language"><t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in <xref target="RFC2119"></xref>.</t>
</section>
<section title="Defined Terms" anchor="n-defined-terms"><t>The terms of art used in this document are described in the <em>Mesh Architecture Guide</em> <xref target="draft-hallambaker-mesh-architecture"></xref>.</t>
</section>
<section title="Related Specifications" anchor="n-related-specifications"><t>The architecture of the Mathematical Mesh is described in the <em>Mesh Architecture Guide</em> <xref target="draft-hallambaker-mesh-architecture"></xref>. The Mesh documentation set and related specifications are described in this document.</t>
</section>
<section title="Implementation Status" anchor="n-implementation-status"><t>The implementation status of the reference code base is described in the companion document <xref target="draft-hallambaker-mesh-developer"></xref>.</t>
</section>
<section title="Shared Classes" anchor="n-shared-classes-"><t>The following classes are used as common elements in Mesh profile specifications. </t>
<section title="Classes describing keys" anchor="n-classes-describing-keys-"></section>
<section title="Structure: KeyData" anchor="n-structure-keydata-"><t>The KeyData class is used to describe public key pairs and  trust assertions associated with a public key. </t>
<dl>
<dt>Udf: String (Optional) </dt>
<dd>
<t>UDF fingerprint of the public key parameters </t>
</dd>
<dt>X509Certificate: Binary (Optional) </dt>
<dd>
<t>List of X.509 Certificates </t>
</dd>
<dt>X509Chain: Binary [0..Many] </dt>
<dd>
<t>X.509 Certificate chain. </t>
</dd>
<dt>X509CSR: Binary (Optional) </dt>
<dd>
<t>X.509 Certificate Signing Request. </t>
</dd>
<dt>NotBefore: DateTime (Optional) </dt>
<dd>
<t>If present specifies a time instant that use of the private key is not valid before. </t>
</dd>
<dt>NotOnOrAfter: DateTime (Optional) </dt>
<dd>
<t>If present specifies a time instant that use of the private key is not valid on or after.  </t>
</dd>
</dl>
</section>
<section title="Structure: CompositePrivate" anchor="n-structure-compositeprivate-"><dl>
<dt>Inherits: Key  </dt>
<dd>
</dd>
<dt>DeviceKeyUdf: String (Optional) </dt>
<dd>
<t>UDF fingerprint of the bound device key (if used).  </t>
</dd>
</dl>
</section>
</section>
<section title="Assertion classes" anchor="n-assertion-classes-"><t>Classes that are derived from an assertion. </t>
<section title="Structure: Assertion" anchor="n-structure-assertion-"><t>Parent class from which all assertion classes are derived </t>
<dl>
<dt>Names: String [0..Many] </dt>
<dd>
<t>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. </t>
</dd>
<dt>Updated: DateTime (Optional) </dt>
<dd>
<t>The time instant the profile was last modified. </t>
</dd>
<dt>NotaryToken: String (Optional) </dt>
<dd>
<t>A Uniform Notary Token providing evidence that a signature was performed after the notary token was created.  </t>
</dd>
</dl>
</section>
<section title="Structure: Condition" anchor="n-structure-condition-"><t>Parent class from which all condition classes are derived. </t>
<t>[No fields] </t>
</section>
<section title="Base Classes" anchor="n-base-classes-"><t>Abstract classes from which the Profile, Activation and Connection classes are derrived. </t>
</section>
<section title="Structure: Connection" anchor="n-structure-connection-"><dl>
<dt>Inherits: Assertion  </dt>
<dd>
</dd>
<dt>SubjectUdf: String (Optional) </dt>
<dd>
<t>UDF of the connection target. </t>
</dd>
<dt>AuthorityUdf: String (Optional) </dt>
<dd>
<t>UDF of the connection source.  </t>
</dd>
</dl>
</section>
<section title="Structure: Activation" anchor="n-structure-activation-"><dl>
<dt>Inherits: Assertion  </dt>
<dd>
</dd>
</dl>
<t>Contains the private activation information for a Mesh application running on a specific device </t>
<dl>
<dt>ActivationKey: String (Optional) </dt>
<dd>
<t>Secret seed used to derive keys that are not explicitly specified. </t>
</dd>
<dt>Entries: ActivationEntry [0..Many] </dt>
<dd>
<t>Activation of named resources.  </t>
</dd>
</dl>
</section>
<section title="Structure: ActivationEntry" anchor="n-structure-activationentry-"><dl>
<dt>Resource: String (Optional) </dt>
<dd>
<t>Name of the activated resource </t>
</dd>
<dt>Key: KeyData (Optional) </dt>
<dd>
<t>The activation key or key share  </t>
</dd>
</dl>
</section>
<section title="Mesh Profile Classes" anchor="n-mesh-profile-classes-"><t>Classes describing Mesh Profiles. All Profiles are Assertions derrived from Assertion. </t>
</section>
<section title="Structure: Profile" anchor="n-structure-profile-"><dl>
<dt>Inherits: Assertion  </dt>
<dd>
</dd>
</dl>
<t>Parent class from which all profile classes are derived </t>
<dl>
<dt>ProfileSignature: KeyData (Optional) </dt>
<dd>
<t>The permanent signature key used to sign the profile itself. The UDF of the key is used as the permanent object identifier of the profile. Thus, by definition, the KeySignature value of a Profile does not change under any circumstance.  </t>
</dd>
</dl>
</section>
<section title="Structure: ProfileDevice" anchor="n-structure-profiledevice-"><dl>
<dt>Inherits: Profile  </dt>
<dd>
</dd>
</dl>
<t>Describes a mesh device. </t>
<dl>
<dt>Description: String (Optional) </dt>
<dd>
<t>Description of the device </t>
</dd>
<dt>BaseEncryption: KeyData (Optional) </dt>
<dd>
<t>Base key contribution for encryption keys.  Also used to decrypt activation data sent to the device during connection to an account. </t>
</dd>
<dt>BaseAuthentication: KeyData (Optional) </dt>
<dd>
<t>Base key contribution for authentication keys.  Also used to authenticate the device during connection to an account. </t>
</dd>
<dt>BaseSignature: KeyData (Optional) </dt>
<dd>
<t>Base key contribution for signature keys.   </t>
</dd>
</dl>
</section>
<section title="Structure: ProfileAccount" anchor="n-structure-profileaccount-"><t>Base class for the account profiles ProfileUser and ProfileGroup. These subclasses may be merged at some future date. </t>
<dl>
<dt>Inherits: Profile  </dt>
<dd>
</dd>
<dt>AccountAddress: String (Optional) </dt>
<dd>
<t>The account address. This is either a DNS service address  (e.g. alice@example.com) or a Mesh Name (@alice). </t>
</dd>
<dt>ServiceUdf: String (Optional) </dt>
<dd>
<t>The fingerprint of the service profile to which the account is currently bound. </t>
</dd>
<dt>EscrowEncryption: KeyData (Optional) </dt>
<dd>
<t>Escrow key associated with the account. </t>
</dd>
<dt>AccountEncryption: KeyData (Optional) </dt>
<dd>
<t>Key currently used to encrypt data under this profile </t>
</dd>
<dt>AdministratorSignature: KeyData (Optional) </dt>
<dd>
<t>Key used to sign connection assertions to the account.  </t>
</dd>
</dl>
</section>
<section title="Structure: ProfileUser" anchor="n-structure-profileuser-"><dl>
<dt>Inherits: ProfileAccount  </dt>
<dd>
</dd>
</dl>
<t>Account assertion. This is signed by the service hosting the account. </t>
<dl>
<dt>AccountAuthentication: KeyData (Optional) </dt>
<dd>
<t>Key used to authenticate requests made under this user account. </t>
</dd>
<dt>AccountSignature: KeyData (Optional) </dt>
<dd>
<t>Key used to sign data under the account.  </t>
</dd>
</dl>
</section>
<section title="Structure: ProfileGroup" anchor="n-structure-profilegroup-"><dl>
<dt>Inherits: ProfileAccount  </dt>
<dd>
</dd>
</dl>
<t>Describes a group. Note that while a group is created by one person who becomes its first administrator, control of the group may pass to other administrators over time. </t>
<t>[No fields] </t>
</section>
<section title="Structure: ProfileService" anchor="n-structure-profileservice-"><dl>
<dt>Inherits: Profile  </dt>
<dd>
</dd>
</dl>
<t>Profile of a Mesh Service </t>
<dl>
<dt>ServiceAuthentication: KeyData (Optional) </dt>
<dd>
<t>Key used to authenticate service connections. </t>
</dd>
<dt>ServiceEncryption: KeyData (Optional) </dt>
<dd>
<t>Key used to encrypt data under this profile </t>
</dd>
<dt>ServiceSignature: KeyData (Optional) </dt>
<dd>
<t>Key used to sign data under the account.  </t>
</dd>
</dl>
</section>
<section title="Structure: ProfileHost" anchor="n-structure-profilehost-"><dl>
<dt>Inherits: Profile  </dt>
<dd>
</dd>
<dt>KeyAuthentication: KeyData (Optional) </dt>
<dd>
<t>Key used to authenticate service connections. </t>
</dd>
<dt>KeyEncryption: KeyData (Optional) </dt>
<dd>
<t>Key used to pass encrypted data to the device such as a  </t>
</dd>
</dl>
</section>
<section title="Connection Assertions" anchor="n-connection-assertions-"><t>Connection assertions are used to authenticate and authorize interactions between devices and the service currently servicing the account. They SHOULD NOT be visible to external parties. </t>
</section>
<section title="Structure: ConnectionDevice" anchor="n-structure-connectiondevice-"><dl>
<dt>Inherits: Connection  </dt>
<dd>
</dd>
</dl>
<t>Connection assertion used to authenticate service requests made by a device. </t>
<dl>
<dt>AccountAddress: String (Optional) </dt>
<dd>
<t>The account address </t>
</dd>
<dt>DeviceSignature: KeyData (Optional) </dt>
<dd>
<t>The signature key for use of the device under the profile </t>
</dd>
<dt>DeviceEncryption: KeyData (Optional) </dt>
<dd>
<t>The encryption key for use of the device under the profile </t>
</dd>
<dt>DeviceAuthentication: KeyData (Optional) </dt>
<dd>
<t>The authentication key for use of the device under the profile  </t>
</dd>
</dl>
</section>
<section title="Structure: ConnectionApplication" anchor="n-structure-connectionapplication-"><dl>
<dt>Inherits: Connection  </dt>
<dd>
</dd>
</dl>
<t>Connection assertion stating that a particular device is  </t>
<t>[No fields] </t>
</section>
<section title="Structure: ConnectionGroup" anchor="n-structure-connectiongroup-"><t>Describes the connection of a member to a group. </t>
<dl>
<dt>Inherits: Connection  </dt>
<dd>
</dd>
</dl>
<t>[No fields] </t>
</section>
<section title="Structure: ConnectionService" anchor="n-structure-connectionservice-"><dl>
<dt>Inherits: Connection  </dt>
<dd>
</dd>
</dl>
<t>[No fields] </t>
</section>
<section title="Structure: ConnectionHost" anchor="n-structure-connectionhost-"><dl>
<dt>Inherits: Connection  </dt>
<dd>
</dd>
</dl>
<t>[No fields] </t>
</section>
<section title="Activation Assertions" anchor="n-activation-assertions-"></section>
<section title="Structure: ActivationDevice" anchor="n-structure-activationdevice-"><t>Contains activation data for device specific keys used in the context of a  Mesh account. </t>
<dl>
<dt>Inherits: Activation  </dt>
<dd>
</dd>
<dt>AccountUdf: String (Optional) </dt>
<dd>
<t>The UDF of the account  </t>
</dd>
</dl>
</section>
<section title="Structure: ActivationAccount" anchor="n-structure-activationaccount-"><dl>
<dt>Inherits: Activation  </dt>
<dd>
</dd>
<dt>ProfileSignature: KeyData (Optional) </dt>
<dd>
<t>Grant access to profile online signing key used to sign updates to the profile. </t>
</dd>
<dt>AdministratorSignature: KeyData (Optional) </dt>
<dd>
<t>Grant access to Profile administration key used to make changes to administrator catalogs. </t>
</dd>
<dt>AccountEncryption: KeyData (Optional) </dt>
<dd>
<t>Grant access to ProfileUser account encryption key </t>
</dd>
<dt>AccountAuthentication: KeyData (Optional) </dt>
<dd>
<t>Grant access to ProfileUser account authentication key </t>
</dd>
<dt>AccountSignature: KeyData (Optional) </dt>
<dd>
<t>Grant access to ProfileUser account signature key  </t>
</dd>
</dl>
</section>
<section title="Structure: ActivationApplication" anchor="n-structure-activationapplication-"><dl>
<dt>Inherits: Activation  </dt>
<dd>
</dd>
</dl>
<t>[No fields] </t>
</section>
</section>
<section title="Data Structures" anchor="n-data-structures-"><t>Classes describing data used in cataloged data.	 </t>
<section title="Structure: Contact" anchor="n-structure-contact-"><dl>
<dt>Inherits: Assertion  </dt>
<dd>
</dd>
</dl>
<t>Base class for contact entries. </t>
<dl>
<dt>Id: String (Optional) </dt>
<dd>
<t>The globally unique contact identifier. </t>
</dd>
<dt>Anchors: Anchor [0..Many] </dt>
<dd>
<t>Mesh fingerprints associated with the contact. </t>
</dd>
<dt>NetworkAddresses: NetworkAddress [0..Many] </dt>
<dd>
<t>Network address entries </t>
</dd>
<dt>Locations: Location [0..Many] </dt>
<dd>
<t>The physical locations the contact is associated with. </t>
</dd>
<dt>Roles: Role [0..Many] </dt>
<dd>
<t>The roles of the contact </t>
</dd>
<dt>Bookmark: Bookmark [0..Many] </dt>
<dd>
<t>The Web sites and other online presences of the contact </t>
</dd>
<dt>Sources: TaggedSource [0..Many] </dt>
<dd>
<t>Source(s) from which this contact was constructed.  </t>
</dd>
</dl>
</section>
<section title="Structure: Anchor" anchor="n-structure-anchor-"><t>Trust anchor </t>
<dl>
<dt>Udf: String (Optional) </dt>
<dd>
<t>The trust anchor. </t>
</dd>
<dt>Validation: String (Optional) </dt>
<dd>
<t>The means of validation.  </t>
</dd>
</dl>
</section>
<section title="Structure: TaggedSource" anchor="n-structure-taggedsource-"><t>Source from which contact information was obtained. </t>
<dl>
<dt>LocalName: String (Optional) </dt>
<dd>
<t>Short name for the contact information. </t>
</dd>
<dt>Validation: String (Optional) </dt>
<dd>
<t>The means of validation.	 </t>
</dd>
<dt>BinarySource: Binary (Optional) </dt>
<dd>
<t>The contact data in binary form. </t>
</dd>
<dt>EnvelopedSource: Enveloped (Optional) </dt>
<dd>
<t>The contact data in enveloped form. If present, the BinarySource property is ignored.  </t>
</dd>
</dl>
</section>
<section title="Structure: ContactGroup" anchor="n-structure-contactgroup-"><dl>
<dt>Inherits: Contact  </dt>
<dd>
</dd>
</dl>
<t>Contact for a group, including encryption groups. </t>
<t>[No fields] </t>
</section>
<section title="Structure: ContactPerson" anchor="n-structure-contactperson-"><dl>
<dt>Inherits: Contact  </dt>
<dd>
</dd>
<dt>CommonNames: PersonName [0..Many] </dt>
<dd>
<t>List of person names in order of preference  </t>
</dd>
</dl>
</section>
<section title="Structure: ContactOrganization" anchor="n-structure-contactorganization-"><dl>
<dt>Inherits: Contact  </dt>
<dd>
</dd>
<dt>CommonNames: OrganizationName [0..Many] </dt>
<dd>
<t>List of person names in order of preference  </t>
</dd>
</dl>
</section>
<section title="Structure: OrganizationName" anchor="n-structure-organizationname-"><t>The name of an organization </t>
<dl>
<dt>Inactive: Boolean (Optional) </dt>
<dd>
<t>If true, the name is not in current use. </t>
</dd>
<dt>RegisteredName: String (Optional) </dt>
<dd>
<t>The registered name. </t>
</dd>
<dt>DBA: String (Optional) </dt>
<dd>
<t>Names that the organization uses including trading names and doing business as names.  </t>
</dd>
</dl>
</section>
<section title="Structure: PersonName" anchor="n-structure-personname-"><t>The name of a natural person </t>
<dl>
<dt>Inactive: Boolean (Optional) </dt>
<dd>
<t>If true, the name is not in current use. </t>
</dd>
<dt>FullName: String (Optional) </dt>
<dd>
<t>The preferred presentation of the full name. </t>
</dd>
<dt>Prefix: String (Optional) </dt>
<dd>
<t>Honorific or title, E.g. Sir, Lord, Dr., Mr. </t>
</dd>
<dt>First: String (Optional) </dt>
<dd>
<t>First name. </t>
</dd>
<dt>Middle: String [0..Many] </dt>
<dd>
<t>Middle names or initials. </t>
</dd>
<dt>Last: String (Optional) </dt>
<dd>
<t>Last name. </t>
</dd>
<dt>Suffix: String (Optional) </dt>
<dd>
<t>Nominal suffix, e.g. Jr., III, etc. </t>
</dd>
<dt>PostNominal: String (Optional) </dt>
<dd>
<t>Post nominal letters (if used).  </t>
</dd>
</dl>
</section>
<section title="Structure: NetworkAddress" anchor="n-structure-networkaddress-"><t>Provides all means of contacting the individual according to a particular network address </t>
<dl>
<dt>Inactive: Boolean (Optional) </dt>
<dd>
<t>If true, the name is not in current use. </t>
</dd>
<dt>Address: String (Optional) </dt>
<dd>
<t>The network address, e.g. alice@example.com </t>
</dd>
<dt>NetworkCapability: String [0..Many] </dt>
<dd>
<t>The capabilities bound to this address. </t>
</dd>
<dt>EnvelopedProfileAccount: Enveloped (Optional) </dt>
<dd>
<t>The account profile </t>
</dd>
<dt>Protocols: NetworkProtocol [0..Many] </dt>
<dd>
<t>Public keys associated with the network address  </t>
</dd>
</dl>
</section>
<section title="Structure: NetworkProtocol" anchor="n-structure-networkprotocol-"><dl>
<dt>Protocol: String (Optional) </dt>
<dd>
<t>The IANA protocol|identifier of the network protocols by which  the contact may be reached using the specified Address.   </t>
</dd>
</dl>
</section>
<section title="Structure: Role" anchor="n-structure-role-"><dl>
<dt>OrganizationName: String (Optional) </dt>
<dd>
<t>The organization at which the role is held </t>
</dd>
<dt>Titles: String [0..Many] </dt>
<dd>
<t>The titles held with respect to that organization. </t>
</dd>
<dt>Locations: Location [0..Many] </dt>
<dd>
<t>Postal or physical addresses associated with the role.  </t>
</dd>
</dl>
</section>
<section title="Structure: Location" anchor="n-structure-location-"><dl>
<dt>Appartment: String (Optional) </dt>
<dd>
</dd>
<dt>Street: String (Optional) </dt>
<dd>
</dd>
<dt>District: String (Optional) </dt>
<dd>
</dd>
<dt>Locality: String (Optional) </dt>
<dd>
</dd>
<dt>County: String (Optional) </dt>
<dd>
</dd>
<dt>Postcode: String (Optional) </dt>
<dd>
</dd>
<dt>Country: String (Optional)  </dt>
<dd>
</dd>
</dl>
</section>
<section title="Structure: Bookmark" anchor="n-structure-bookmark-"><dl>
<dt>Uri: String (Optional) </dt>
<dd>
</dd>
<dt>Title: String (Optional) </dt>
<dd>
</dd>
<dt>Role: String [0..Many]  </dt>
<dd>
</dd>
</dl>
</section>
<section title="Structure: Reference" anchor="n-structure-reference-"><dl>
<dt>MessageId: String (Optional) </dt>
<dd>
<t>The received message to which this is a response </t>
</dd>
<dt>ResponseId: String (Optional) </dt>
<dd>
<t>Message that was generated in response to the original (optional). </t>
</dd>
<dt>Relationship: String (Optional) </dt>
<dd>
<t>The relationship type. This can be Read, Unread, Accept, Reject.  </t>
</dd>
</dl>
</section>
<section title="Structure: Task" anchor="n-structure-task-"><dl>
<dt>Key: String (Optional) </dt>
<dd>
<t>Unique key. </t>
</dd>
<dt>Start: DateTime (Optional) </dt>
<dd>
</dd>
<dt>Finish: DateTime (Optional) </dt>
<dd>
</dd>
<dt>StartTravel: String (Optional) </dt>
<dd>
</dd>
<dt>FinishTravel: String (Optional) </dt>
<dd>
</dd>
<dt>TimeZone: String (Optional) </dt>
<dd>
</dd>
<dt>Title: String (Optional) </dt>
<dd>
</dd>
<dt>Description: String (Optional) </dt>
<dd>
</dd>
<dt>Location: String (Optional) </dt>
<dd>
</dd>
<dt>Trigger: String [0..Many] </dt>
<dd>
</dd>
<dt>Conference: String [0..Many] </dt>
<dd>
</dd>
<dt>Repeat: String (Optional) </dt>
<dd>
</dd>
<dt>Busy: Boolean (Optional)  </dt>
<dd>
</dd>
</dl>
</section>
</section>
<section title="Catalog Entries" anchor="n-catalog-entries-"><section title="Structure: CatalogedEntry" anchor="n-structure-catalogedentry-"><t>Base class for cataloged Mesh data. </t>
<dl>
<dt>Labels: String [0..Many] </dt>
<dd>
<t>The set of labels describing the entry  </t>
</dd>
</dl>
</section>
<section title="Structure: CatalogedDevice" anchor="n-structure-catalogeddevice-"><dl>
<dt>Inherits: CatalogedEntry  </dt>
<dd>
</dd>
</dl>
<t>Public device entry, indexed under the device ID Hello </t>
<dl>
<dt>Udf: String (Optional) </dt>
<dd>
<t>UDF of the signature key of the device in the Mesh </t>
</dd>
<dt>DeviceUdf: String (Optional) </dt>
<dd>
<t>UDF of the offline signature key of the device </t>
</dd>
<dt>SignatureUdf: String (Optional) </dt>
<dd>
<t>UDF of the account online signature key </t>
</dd>
<dt>EnvelopedProfileUser: Enveloped (Optional) </dt>
<dd>
<t>The Mesh profile </t>
</dd>
<dt>EnvelopedProfileDevice: Enveloped (Optional) </dt>
<dd>
<t>The device profile </t>
</dd>
<dt>EnvelopedConnectionUser: Enveloped (Optional) </dt>
<dd>
<t>The public assertion demonstrating connection of the Device to the Mesh </t>
</dd>
<dt>EnvelopedActivationDevice: Enveloped (Optional) </dt>
<dd>
<t>The activation of the device within the Mesh account </t>
</dd>
<dt>EnvelopedActivationAccount: Enveloped (Optional) </dt>
<dd>
<t>The activation of the device within the Mesh account </t>
</dd>
<dt>EnvelopedActivationApplication: Enveloped [0..Many] </dt>
<dd>
<t>Application activations granted to the device.  </t>
</dd>
</dl>
</section>
<section title="Structure: CatalogedPublication" anchor="n-structure-catalogedpublication-"><dl>
<dt>Inherits: CatalogedEntry  </dt>
<dd>
</dd>
</dl>
<t>A publication. </t>
<dl>
<dt>Id: String (Optional) </dt>
<dd>
<t>Unique identifier code </t>
</dd>
<dt>Authenticator: String (Optional) </dt>
<dd>
<t>The witness key value to use to request access to the record.	 </t>
</dd>
<dt>EnvelopedData: DareEnvelope (Optional) </dt>
<dd>
<t>Dare Envelope containing the entry data. The data type is specified by the envelope metadata. </t>
</dd>
<dt>NotOnOrAfter: DateTime (Optional) </dt>
<dd>
<t>Epiration time (inclusive)  </t>
</dd>
</dl>
</section>
<section title="Structure: CatalogedCredential" anchor="n-structure-catalogedcredential-"><dl>
<dt>Inherits: CatalogedEntry  </dt>
<dd>
</dd>
<dt>Protocol: String (Optional) </dt>
<dd>
</dd>
<dt>Service: String (Optional) </dt>
<dd>
</dd>
<dt>Username: String (Optional) </dt>
<dd>
</dd>
<dt>Password: String (Optional)  </dt>
<dd>
</dd>
</dl>
</section>
<section title="Structure: CatalogedNetwork" anchor="n-structure-catalogednetwork-"><dl>
<dt>Inherits: CatalogedEntry  </dt>
<dd>
</dd>
<dt>Protocol: String (Optional) </dt>
<dd>
</dd>
<dt>Service: String (Optional) </dt>
<dd>
</dd>
<dt>Username: String (Optional) </dt>
<dd>
</dd>
<dt>Password: String (Optional)  </dt>
<dd>
</dd>
</dl>
</section>
<section title="Structure: CatalogedContact" anchor="n-structure-catalogedcontact-"><dl>
<dt>Inherits: CatalogedEntry  </dt>
<dd>
</dd>
<dt>Key: String (Optional) </dt>
<dd>
<t>Unique key.  </t>
</dd>
<dt>Self: Boolean (Optional) </dt>
<dd>
<t>If true, this catalog entry is for the user who created the catalog.  </t>
</dd>
</dl>
</section>
<section title="Structure: CatalogedAccess" anchor="n-structure-catalogedaccess-"><dl>
<dt>Inherits: CatalogedEntry  </dt>
<dd>
</dd>
</dl>
<t>[No fields] </t>
</section>
<section title="Structure: CryptographicCapability" anchor="n-structure-cryptographiccapability-"><dl>
<dt>Id: String (Optional) </dt>
<dd>
<t>The identifier of the capability. If this is a user capability, MUST match the KeyData identifier. If this is a serviced capability, MUST match the value of ServiceId on the corresponding service capability. </t>
</dd>
<dt>KeyData: KeyData (Optional) </dt>
<dd>
<t>The key that enables the capability </t>
</dd>
<dt>EnvelopedKeyShares: Enveloped [0..Many] </dt>
<dd>
<t>One or more enveloped key shares. </t>
</dd>
<dt>SubjectId: String (Optional) </dt>
<dd>
<t>The identifier of the resource that is controlled using the key. </t>
</dd>
<dt>SubjectAddress: String (Optional) </dt>
<dd>
<t>The address of the resource that is controlled using the key.  </t>
</dd>
</dl>
</section>
<section title="Structure: CapabilityDecrypt" anchor="n-structure-capabilitydecrypt-"><dl>
<dt>Inherits: CryptographicCapability  </dt>
<dd>
</dd>
</dl>
<t>The corresponding key is a decryption key </t>
<t>[No fields] </t>
</section>
<section title="Structure: CapabilityDecryptPartial" anchor="n-structure-capabilitydecryptpartial-"><dl>
<dt>Inherits: CapabilityDecrypt  </dt>
<dd>
</dd>
</dl>
<t>The corresponding key is an encryption key </t>
<dl>
<dt>ServiceId: String (Optional) </dt>
<dd>
<t>The identifier used to claim the capability from the service.[Only present for a partial capability.] </t>
</dd>
<dt>ServiceAddress: String (Optional) </dt>
<dd>
<t>The service account that supports a serviced capability. [Only present for a partial capability.]  </t>
</dd>
</dl>
</section>
<section title="Structure: CapabilityDecryptServiced" anchor="n-structure-capabilitydecryptserviced-"><dl>
<dt>Inherits: CapabilityDecrypt  </dt>
<dd>
</dd>
</dl>
<t>The corresponding key is an encryption key </t>
<dl>
<dt>AuthenticationId: String (Optional) </dt>
<dd>
<t>UDF of trust root under which request to use a serviced capability must be  authorized. [Only present for a serviced capability]  </t>
</dd>
</dl>
</section>
<section title="Structure: CapabilitySign" anchor="n-structure-capabilitysign-"><dl>
<dt>Inherits: CryptographicCapability  </dt>
<dd>
</dd>
</dl>
<t>The corresponding key is an administration key </t>
<t>[No fields] </t>
</section>
<section title="Structure: CapabilityKeyGenerate" anchor="n-structure-capabilitykeygenerate-"><dl>
<dt>Inherits: CryptographicCapability  </dt>
<dd>
</dd>
</dl>
<t>The corresponding key is a key that may be used to generate key shares. </t>
<t>[No fields] </t>
</section>
<section title="Structure: CapabilityFairExchange" anchor="n-structure-capabilityfairexchange-"><dl>
<dt>Inherits: CryptographicCapability  </dt>
<dd>
</dd>
</dl>
<t>The corresponding key is a decryption key to be used in accordance  with the Micali Fair Electronic Exchange with Invisible Trusted Parties protocol. </t>
<t>[No fields] </t>
</section>
<section title="Structure: CatalogedBookmark" anchor="n-structure-catalogedbookmark-"><dl>
<dt>Inherits: CatalogedEntry  </dt>
<dd>
</dd>
<dt>Uri: String (Optional) </dt>
<dd>
</dd>
<dt>Title: String (Optional) </dt>
<dd>
</dd>
<dt>Path: String (Optional)  </dt>
<dd>
</dd>
</dl>
</section>
<section title="Structure: CatalogedTask" anchor="n-structure-catalogedtask-"><dl>
<dt>Inherits: CatalogedEntry  </dt>
<dd>
</dd>
<dt>EnvelopedTask: Enveloped (Optional) </dt>
<dd>
</dd>
<dt>Title: String (Optional) </dt>
<dd>
</dd>
<dt>Key: String (Optional) </dt>
<dd>
<t>Unique key.  </t>
</dd>
</dl>
</section>
<section title="Structure: CatalogedApplication" anchor="n-structure-catalogedapplication-"><dl>
<dt>Inherits: CatalogedEntry  </dt>
<dd>
</dd>
<dt>Key: String (Optional) </dt>
<dd>
</dd>
<dt>EnvelopedCapabilities: DareEnvelope [0..Many] </dt>
<dd>
<t>Enveloped keys for use with Application  </t>
</dd>
</dl>
</section>
<section title="Structure: CatalogedMember" anchor="n-structure-catalogedmember-"><dl>
<dt>ContactAddress: String (Optional) </dt>
<dd>
</dd>
<dt>MemberCapabilityId: String (Optional) </dt>
<dd>
</dd>
<dt>ServiceCapabilityId: String (Optional) </dt>
<dd>
</dd>
<dt>Inherits: CatalogedEntry  </dt>
<dd>
</dd>
</dl>
</section>
<section title="Structure: CatalogedGroup" anchor="n-structure-catalogedgroup-"><dl>
<dt>Inherits: CatalogedApplication  </dt>
<dd>
</dd>
<dt>EnvelopedProfileGroup: Enveloped (Optional) </dt>
<dd>
<t>The Mesh profile </t>
</dd>
<dt>EnvelopedActivationAccount: Enveloped (Optional) </dt>
<dd>
<t>The activation of the device within the Mesh account  </t>
</dd>
</dl>
</section>
<section title="Structure: CatalogedApplicationSSH" anchor="n-structure-catalogedapplicationssh-"><dl>
<dt>Inherits: CatalogedApplication  </dt>
<dd>
</dd>
</dl>
<t>[No fields] </t>
</section>
<section title="Structure: CatalogedApplicationMail" anchor="n-structure-catalogedapplicationmail-"><dl>
<dt>Inherits: CatalogedApplication  </dt>
<dd>
</dd>
</dl>
<t>[No fields] </t>
</section>
<section title="Structure: CatalogedApplicationNetwork" anchor="n-structure-catalogedapplicationnetwork-"><dl>
<dt>Inherits: CatalogedApplication  </dt>
<dd>
</dd>
</dl>
<t>[No fields] </t>
</section>
</section>
<section title="Publications" anchor="n-publications-"><section title="Structure: DevicePreconfiguration" anchor="n-structure-devicepreconfiguration-"><t>A data structure that is passed  </t>
<dl>
<dt>EnvelopedProfileDevice: Enveloped (Optional) </dt>
<dd>
<t>The device profile </t>
</dd>
<dt>EnvelopedConnectionDevice: Enveloped (Optional) </dt>
<dd>
<t>The device connection </t>
</dd>
<dt>ConnectUri: String (Optional) </dt>
<dd>
<t>The connection URI. This would normally be printed on the device as a  QR code.  </t>
</dd>
</dl>
</section>
</section>
<section title="Messages" anchor="n-messages-"><section title="Structure: Message" anchor="n-structure-message-"><dl>
<dt>MessageId: String (Optional) </dt>
<dd>
<t>Unique per-message ID. When encapsulating a Mesh Message in a DARE envelope, the envelope EnvelopeID field MUST be a UDF fingerprint of the MessageId value.  </t>
</dd>
<dt>Sender: String (Optional) </dt>
<dd>
</dd>
<dt>Recipient: String (Optional)  </dt>
<dd>
</dd>
</dl>
</section>
<section title="Structure: MessageError" anchor="n-structure-messageerror-"><dl>
<dt>Inherits: Message  </dt>
<dd>
</dd>
<dt>ErrorCode: String (Optional)  </dt>
<dd>
</dd>
</dl>
</section>
<section title="Structure: MessageComplete" anchor="n-structure-messagecomplete-"><dl>
<dt>Inherits: Message  </dt>
<dd>
</dd>
<dt>References: Reference [0..Many]  </dt>
<dd>
</dd>
</dl>
</section>
<section title="Structure: MessagePinValidated" anchor="n-structure-messagepinvalidated-"><dl>
<dt>Inherits: Message  </dt>
<dd>
</dd>
<dt>AuthenticatedData: DareEnvelope (Optional) </dt>
<dd>
<t>Enveloped data that is authenticated by means of the PIN </t>
</dd>
<dt>ClientNonce: Binary (Optional) </dt>
<dd>
<t>Nonce provided by the client to validate the PIN </t>
</dd>
<dt>PinId: String (Optional) </dt>
<dd>
<t>Pin identifier value calculated from the PIN code, action and account address. </t>
</dd>
<dt>PinWitness: Binary (Optional) </dt>
<dd>
<t>Witness value calculated as KDF (Device.Udf + AccountAddress, ClientNonce)  </t>
</dd>
</dl>
</section>
<section title="Structure: MessagePin" anchor="n-structure-messagepin-"><dl>
<dt>Account: String (Optional) </dt>
<dd>
</dd>
<dt>Inherits: Message  </dt>
<dd>
</dd>
<dt>Expires: DateTime (Optional) </dt>
<dd>
</dd>
<dt>Automatic: Boolean (Optional) </dt>
<dd>
<t>If true, authentication against the PIN code is sufficient to complete the associated action without further authorization. </t>
</dd>
<dt>SaltedPin: String (Optional) </dt>
<dd>
<t>PIN code bound to the specified action. </t>
</dd>
<dt>Action: String (Optional) </dt>
<dd>
<t>The action to which this PIN code is bound.  </t>
</dd>
</dl>
</section>
<section title="Structure: RequestConnection" anchor="n-structure-requestconnection-"><t>Connection request message. This message contains the information </t>
<dl>
<dt>Inherits: MessagePinValidated  </dt>
<dd>
</dd>
<dt>AccountAddress: String (Optional) </dt>
<dd>
</dd>
</dl>
</section>
<section title="Structure: AcknowledgeConnection" anchor="n-structure-acknowledgeconnection-"><t>Connection request message generated by a service on receipt of a valid MessageConnectionRequestClient </t>
<dl>
<dt>Inherits: Message  </dt>
<dd>
</dd>
<dt>EnvelopedRequestConnection: Enveloped (Optional) </dt>
<dd>
<t>The client connection request. </t>
</dd>
<dt>ServerNonce: Binary (Optional) </dt>
<dd>
</dd>
<dt>Witness: String (Optional) </dt>
<dd>
</dd>
</dl>
</section>
<section title="Structure: RespondConnection" anchor="n-structure-respondconnection-"><t>Respond to RequestConnection message to grant or refuse the connection request. </t>
<dl>
<dt>Inherits: Message  </dt>
<dd>
</dd>
<dt>Result: String (Optional) </dt>
<dd>
<t>The response to the request. One of "Accept", "Reject" or "Pending". </t>
</dd>
<dt>CatalogedDevice: CatalogedDevice (Optional) </dt>
<dd>
<t>The device information. MUST be present if the value of Result is "Accept". MUST be absent or null otherwise.  </t>
</dd>
</dl>
</section>
<section title="Structure: MessageContact" anchor="n-structure-messagecontact-"><dl>
<dt>Inherits: MessagePinValidated  </dt>
<dd>
</dd>
<dt>Reply: Boolean (Optional) </dt>
<dd>
<t>If true, requests that the recipient return their own contact information in reply. </t>
</dd>
<dt>Subject: String (Optional) </dt>
<dd>
<t>Optional explanation of the reason for the request. </t>
</dd>
<dt>PIN: String (Optional) </dt>
<dd>
<t>One time authentication code supplied to a recipient to allow authentication of the response.  </t>
</dd>
</dl>
</section>
<section title="Structure: GroupInvitation" anchor="n-structure-groupinvitation-"><dl>
<dt>Inherits: Message  </dt>
<dd>
</dd>
<dt>Text: String (Optional)  </dt>
<dd>
</dd>
</dl>
</section>
<section title="Structure: RequestConfirmation" anchor="n-structure-requestconfirmation-"><dl>
<dt>Inherits: Message  </dt>
<dd>
</dd>
<dt>Text: String (Optional)  </dt>
<dd>
</dd>
</dl>
</section>
<section title="Structure: ResponseConfirmation" anchor="n-structure-responseconfirmation-"><dl>
<dt>Inherits: Message  </dt>
<dd>
</dd>
<dt>Request: Enveloped (Optional) </dt>
<dd>
</dd>
<dt>Accept: Boolean (Optional)  </dt>
<dd>
</dd>
</dl>
</section>
<section title="Structure: RequestTask" anchor="n-structure-requesttask-"><dl>
<dt>Inherits: Message  </dt>
<dd>
</dd>
</dl>
<t>[No fields] </t>
</section>
<section title="Structure: MessageClaim" anchor="n-structure-messageclaim-"><dl>
<dt>Inherits: Message  </dt>
<dd>
</dd>
<dt>PublicationId: String (Optional) </dt>
<dd>
</dd>
<dt>ServiceAuthenticate: String (Optional) </dt>
<dd>
</dd>
<dt>DeviceAuthenticate: String (Optional) </dt>
<dd>
</dd>
<dt>Expires: DateTime (Optional)  </dt>
<dd>
</dd>
</dl>
</section>
<section title="Structure: ProcessResult" anchor="n-structure-processresult-"><t>For future use, allows logging of operations and results	 </t>
<dl>
<dt>Inherits: Message  </dt>
<dd>
</dd>
<dt>Success: Boolean (Optional) </dt>
<dd>
</dd>
<dt>ErrorReport: String (Optional) </dt>
<dd>
<t>The error report code.  </t>
</dd>
</dl>
</section>
</section>
</section>
<section title="Mesh Portal Service Reference" anchor="n-mesh-portal-service-reference-"><dl>
<dt>HTTP Well Known Service Prefix: /.well-known/mmm </dt>
<dd>
</dd>
</dl>
<t>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 to perform a Hello transaction prior to a ValidateAccount, Publish or any other transaction. </t>
<section title="Request Messages" anchor="n-request-messages-"><t>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.  </t>
<section title="Message: MeshRequest" anchor="n-message-meshrequest-"><t>Base class for all request messages. </t>
<dl>
<dt>Portal: String (Optional) </dt>
<dd>
<t>Name of the Mesh Portal Service to which the request  is directed.  </t>
</dd>
</dl>
</section>
</section>
<section title="Response Messages" anchor="n-response-messages-"><t>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. </t>
<section title="Message: MeshResponse" anchor="n-message-meshresponse-"><t>Base class for all response messages. Contains only the status code and status description fields. </t>
<t>[No fields] </t>
</section>
</section>
<section title="Imported Objects" anchor="n-imported-objects-"><t>The Mesh Service protocol makes use of JSON objects defined in the JOSE Signatgure and Encryption specifications. </t>
</section>
<section title="Common Structures" anchor="n-common-structures-"><t>The following common structures are used in the protocol messages: </t>
<section title="Structure: KeyValue" anchor="n-structure-keyvalue-"><t>Describes a Key/Value structure used to make queries for records matching one or more selection criteria. </t>
<dl>
<dt>Key: String (Optional) </dt>
<dd>
<t>The data retrieval key. </t>
</dd>
<dt>Value: String (Optional) </dt>
<dd>
<t>The data value to match.  </t>
</dd>
</dl>
</section>
<section title="Structure: SearchConstraints" anchor="n-structure-searchconstraints-"><t>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. </t>
<dl>
<dt>NotBefore: DateTime (Optional) </dt>
<dd>
<t>Only data published on or after the specified time instant  is requested. </t>
</dd>
<dt>Before: DateTime (Optional) </dt>
<dd>
<t>Only data published before the specified time instant is requested. This excludes data published at the specified time instant. </t>
</dd>
<dt>MaxEntries: Integer (Optional) </dt>
<dd>
<t>Maximum number of data entries to return. </t>
</dd>
<dt>MaxBytes: Integer (Optional) </dt>
<dd>
<t>Maximum number of data bytes to return. </t>
</dd>
<dt>PageKey: String (Optional) </dt>
<dd>
<t>Specifies a page key returned in a previous search operation in which the number of responses exceeded the specified bounds. </t>
<t>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.  </t>
</dd>
</dl>
</section>
</section>
<section title="Transaction: Hello" anchor="n-transaction-hello-"><dl>
<dt>Request: HelloRequest </dt>
<dd>
</dd>
<dt>Response: HelloResponse  </dt>
<dd>
</dd>
</dl>
<t>Report service and version information.  </t>
<t>The Hello transaction provides a means of determining which protocol versions, message encodings and transport protocols are supported by the service. </t>
</section>
<section title="Transaction: ValidateAccount" anchor="n-transaction-validateaccount-"><dl>
<dt>Request: ValidateRequest </dt>
<dd>
</dd>
<dt>Response: ValidateResponse  </dt>
<dd>
</dd>
</dl>
<t>Request validation of a proposed name for a new account. </t>
<t>For validation of a user's account name during profile creation. </t>
<section title="Message: ValidateRequest" anchor="n-message-validaterequest-"><dl>
<dt>Inherits: MeshRequest  </dt>
<dd>
</dd>
</dl>
<t>Describes the proposed account properties. Currently, these are limited to the account name but could be extended in future versions of the protocol. </t>
<dl>
<dt>Account: String (Optional) </dt>
<dd>
<t>Account name requested </t>
</dd>
<dt>Reserve: Boolean (Optional) </dt>
<dd>
<t>If true, request a reservation for the specified account name. Note that the service is not obliged to honor reservation  requests. </t>
</dd>
<dt>Language: String [0..Many] </dt>
<dd>
<t>List of ISO language codes in order of preference. For creating explanatory text.  </t>
</dd>
</dl>
</section>
<section title="Message: ValidateResponse" anchor="n-message-validateresponse-"><dl>
<dt>Inherits: MeshResponse  </dt>
<dd>
</dd>
</dl>
<t>States whether the proposed account properties are acceptable and (optional) returns an indication of what properties are valid. </t>
<t>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. </t>
<dl>
<dt>Valid: Boolean (Optional) </dt>
<dd>
<t>If true, the specified account identifier is acceptable. If false, the account identifier is rejected. </t>
</dd>
<dt>Minimum: Integer (Optional) </dt>
<dd>
<t>Specifies the minimum length of an account name. </t>
</dd>
<dt>Maximum: Integer (Optional) </dt>
<dd>
<t>Specifies the maximum length of an account name. </t>
</dd>
<dt>InvalidCharacters: String (Optional) </dt>
<dd>
<t>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. </t>
</dd>
<dt>Reason: String (Optional) </dt>
<dd>
<t>Text explaining the reason an account name was rejected.  </t>
</dd>
</dl>
</section>
</section>
<section title="Transaction: CreateAccount" anchor="n-transaction-createaccount-"><dl>
<dt>Request: CreateRequest </dt>
<dd>
</dd>
<dt>Response: CreateResponse  </dt>
<dd>
</dd>
</dl>
<t>Request creation of a new portal account. </t>
<t>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. </t>
<section title="Message: CreateRequest" anchor="n-message-createrequest-"><t>Request creation of a new portal account. The request specifies the requested account identifier and the Mesh profile to be associated  with the account. </t>
<dl>
<dt>Inherits: MeshRequest  </dt>
<dd>
</dd>
<dt>Account: String (Optional) </dt>
<dd>
<t>Account identifier requested.  </t>
</dd>
</dl>
</section>
<section title="Message: CreateResponse" anchor="n-message-createresponse-"><dl>
<dt>Inherits: MeshResponse  </dt>
<dd>
</dd>
</dl>
<t>Reports the success or failure of a Create transaction. </t>
<t>[No fields] </t>
</section>
</section>
<section title="Transaction: DeleteAccount" anchor="n-transaction-deleteaccount-"><dl>
<dt>Request: DeleteRequest </dt>
<dd>
</dd>
<dt>Response: DeleteResponse  </dt>
<dd>
</dd>
</dl>
<t>Request deletion of a portal account. </t>
<t>Deletes a portal account but not the underlying profile. Once registered, profiles are permanent. </t>
<section title="Message: DeleteRequest" anchor="n-message-deleterequest-"><t>Request deletion of a new portal account. The request specifies the requested account identifier. </t>
<dl>
<dt>Inherits: MeshRequest  </dt>
<dd>
</dd>
<dt>Account: String (Optional) </dt>
<dd>
<t>Account identifier to be deleted.  </t>
</dd>
</dl>
</section>
<section title="Message: DeleteResponse" anchor="n-message-deleteresponse-"><dl>
<dt>Inherits: MeshResponse  </dt>
<dd>
</dd>
</dl>
<t>Reports the success or failure of a Delete transaction. </t>
<t>[No fields] </t>
</section>
</section>
<section title="Transaction: Get" anchor="n-transaction-get-"><dl>
<dt>Request: GetRequest </dt>
<dd>
</dd>
<dt>Response: GetResponse  </dt>
<dd>
</dd>
</dl>
<t>Search for data in the mesh that matches a set of properties described by a sequence of key/value pairs. </t>
<section title="Message: GetRequest" anchor="n-message-getrequest-"><t>Describes the Portal or Mesh data to be retreived. </t>
<dl>
<dt>Inherits: MeshRequest  </dt>
<dd>
</dd>
<dt>Identifier: String (Optional) </dt>
<dd>
<t>Lookup by profile ID </t>
</dd>
<dt>Account: String (Optional) </dt>
<dd>
<t>Lookup by Account ID </t>
</dd>
<dt>KeyValues: KeyValue [0..Many] </dt>
<dd>
<t>List of KeyValue pairs specifying the conditions to be met </t>
</dd>
<dt>SearchConstraints: SearchConstraints (Optional) </dt>
<dd>
<t>Constrain the search to a specific time interval and/or  limit the number and/or total size of data records returned. </t>
</dd>
<dt>Multiple: Boolean (Optional) </dt>
<dd>
<t>If true return multiple responses if available </t>
</dd>
<dt>Full: Boolean (Optional) </dt>
<dd>
<t>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.  </t>
</dd>
</dl>
</section>
<section title="Message: GetResponse" anchor="n-message-getresponse-"><t>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. </t>
<dl>
<dt>Inherits: MeshResponse  </dt>
<dd>
</dd>
<dt>DataItems: DataItem [0..Many] </dt>
<dd>
<t>List of mesh data records matching the request. </t>
</dd>
<dt>PageKey: String (Optional) </dt>
<dd>
<t>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.  </t>
</dd>
</dl>
</section>
</section>
<section title="Transaction: Publish" anchor="n-transaction-publish-"><dl>
<dt>Request: PublishRequest </dt>
<dd>
</dd>
<dt>Response: PublishResponse  </dt>
<dd>
</dd>
</dl>
<t>Publish a profile or key escrow entry to the mesh. </t>
<section title="Message: PublishRequest" anchor="n-message-publishrequest-"><t>Requests publication of the specified Mesh entry. </t>
<dl>
<dt>Inherits: MeshRequest  </dt>
<dd>
</dd>
</dl>
<t>[No fields] </t>
</section>
<section title="Message: PublishResponse" anchor="n-message-publishresponse-"><t>Reports the success or failure of a Publish transaction. </t>
<dl>
<dt>Inherits: MeshResponse  </dt>
<dd>
</dd>
</dl>
<t>[No fields] </t>
</section>
</section>
<section title="Transaction: Status" anchor="n-transaction-status-"><dl>
<dt>Request: StatusRequest </dt>
<dd>
</dd>
<dt>Response: StatusResponse  </dt>
<dd>
</dd>
</dl>
<t>Request the current status of the mesh as seen by the portal to which it is directed. </t>
<t>The response to the status request contains the last signed checkpoint and proof chains for each of the peer portals that have been checkpointed. </t>
<t>[Not currently implemented] </t>
<section title="Message: StatusRequest" anchor="n-message-statusrequest-"><dl>
<dt>Inherits: MeshRequest  </dt>
<dd>
</dd>
</dl>
<t>Initiates a status transaction. </t>
<t>[No fields] </t>
</section>
<section title="Message: StatusResponse" anchor="n-message-statusresponse-"><t>Reports the success or failure of a Status transaction. </t>
<dl>
<dt>Inherits: MeshResponse  </dt>
<dd>
</dd>
<dt>LastWriteTime: DateTime (Optional) </dt>
<dd>
<t>Time that the last write update was made to the Mesh </t>
</dd>
<dt>LastCheckpointTime: DateTime (Optional) </dt>
<dd>
<t>Time that the last Mesh checkpoint was calculated. </t>
</dd>
<dt>NextCheckpointTime: DateTime (Optional) </dt>
<dd>
<t>Time at which the next Mesh checkpoint should be calculated. </t>
</dd>
<dt>CheckpointValue: String (Optional) </dt>
<dd>
<t>Last checkpoint value.  </t>
</dd>
</dl>
</section>
</section>
<section title="Transaction: ConnectStart" anchor="n-transaction-connectstart-"><dl>
<dt>Request: ConnectStartRequest </dt>
<dd>
</dd>
<dt>Response: ConnectStartResponse  </dt>
<dd>
</dd>
</dl>
<t>Request connection of a new device to a mesh profile </t>
<section title="Message: ConnectStartRequest" anchor="n-message-connectstartrequest-"><dl>
<dt>Inherits: MeshRequest  </dt>
<dd>
</dd>
</dl>
<t>Initial device connection request. </t>
<dl>
<dt>SignedRequest: SignedConnectionRequest (Optional) </dt>
<dd>
<t>Device connection request signed by thesignature key of the  device requesting connection. </t>
</dd>
<dt>AccountID: String (Optional) </dt>
<dd>
<t>Account identifier of account to which the device is requesting connection.  </t>
</dd>
</dl>
</section>
<section title="Message: ConnectStartResponse" anchor="n-message-connectstartresponse-"><t>Reports the success or failure of a ConnectStart transaction. </t>
<dl>
<dt>Inherits: MeshRequest  </dt>
<dd>
</dd>
</dl>
<t>[No fields] </t>
</section>
</section>
<section title="Transaction: ConnectStatus" anchor="n-transaction-connectstatus-"><dl>
<dt>Request: ConnectStatusRequest </dt>
<dd>
</dd>
<dt>Response: ConnectStatusResponse  </dt>
<dd>
</dd>
</dl>
<t>Request status of pending connection request of a new device  to a mesh profile </t>
<section title="Message: ConnectStatusRequest" anchor="n-message-connectstatusrequest-"><dl>
<dt>Inherits: MeshRequest  </dt>
<dd>
</dd>
</dl>
<t>Request status information for a pending request posted previously. </t>
<dl>
<dt>AccountID: String (Optional) </dt>
<dd>
<t>Account identifier for which pending connection information is requested. </t>
</dd>
<dt>DeviceID: String (Optional) </dt>
<dd>
<t>Device identifier of device requesting status information.  </t>
</dd>
</dl>
</section>
<section title="Message: ConnectStatusResponse" anchor="n-message-connectstatusresponse-"><t>Reports the success or failure of a ConnectStatus transaction. </t>
<dl>
<dt>Inherits: MeshRequest  </dt>
<dd>
</dd>
<dt>Result: SignedConnectionResult (Optional) </dt>
<dd>
<t>The signed ConnectionResult object.  </t>
</dd>
</dl>
</section>
</section>
<section title="Transaction: ConnectPending" anchor="n-transaction-connectpending-"><dl>
<dt>Request: ConnectPendingRequest </dt>
<dd>
</dd>
<dt>Response: ConnectPendingResponse  </dt>
<dd>
</dd>
</dl>
<t>Request a list of pending requests for an administration profile. </t>
<section title="Message: ConnectPendingRequest" anchor="n-message-connectpendingrequest-"><dl>
<dt>Inherits: MeshRequest  </dt>
<dd>
</dd>
</dl>
<t>Specify the criteria for pending requests. </t>
<dl>
<dt>AccountID: String (Optional) </dt>
<dd>
<t>The account identifier of the account for which pending connection requests are requested. </t>
</dd>
<dt>SearchConstraints: SearchConstraints (Optional) </dt>
<dd>
<t>Constrain the search to a specific time interval and/or  limit the number and/or total size of data records returned.  </t>
</dd>
</dl>
</section>
<section title="Message: ConnectPendingResponse" anchor="n-message-connectpendingresponse-"><t>Reports the success or failure of a ConnectPending transaction. </t>
<dl>
<dt>Inherits: MeshRequest  </dt>
<dd>
</dd>
<dt>Pending: SignedConnectionRequest [0..Many] </dt>
<dd>
<t>A list of pending requests satisfying the criteria set out in the request. </t>
</dd>
<dt>PageKey: String (Optional) </dt>
<dd>
<t>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.  </t>
</dd>
</dl>
</section>
</section>
<section title="Transaction: ConnectComplete" anchor="n-transaction-connectcomplete-"><dl>
<dt>Request: ConnectCompleteRequest </dt>
<dd>
</dd>
<dt>Response: ConnectCompleteResponse  </dt>
<dd>
</dd>
</dl>
<t>Post response to a pending connection request. </t>
<section title="Message: ConnectCompleteRequest" anchor="n-message-connectcompleterequest-"><t>Reports the success or failure of a ConnectComplete transaction. </t>
<dl>
<dt>Inherits: MeshRequest  </dt>
<dd>
</dd>
<dt>Result: SignedConnectionResult (Optional) </dt>
<dd>
<t>The connection result to be posted to the portal. The result MUST be signed by a valid administration key for the Mesh profile. </t>
</dd>
<dt>AccountID: String (Optional) </dt>
<dd>
<t>The account identifier to which the connection result is posted.  </t>
</dd>
</dl>
</section>
<section title="Message: ConnectCompleteResponse" anchor="n-message-connectcompleteresponse-"><dl>
<dt>Inherits: MeshRequest  </dt>
<dd>
</dd>
</dl>
<t>Reports the success or failure of a ConnectComplete transaction. </t>
<t>[No fields] </t>
</section>
</section>
<section title="Transaction: Transfer" anchor="n-transaction-transfer-"><dl>
<dt>Request: TransferRequest </dt>
<dd>
</dd>
<dt>Response: TransferResponse  </dt>
<dd>
</dd>
</dl>
<t>Perform a bulk transfer of the log between the specified transaction identifiers. Requires appropriate authorization </t>
<t>[Not currently implemented] </t>
<section title="Message: TransferRequest" anchor="n-message-transferrequest-"><t>Request a bulk transfer of the log between the specified transaction identifiers. Requires appropriate authorization </t>
<dl>
<dt>Inherits: MeshRequest  </dt>
<dd>
</dd>
<dt>SearchConstraints: SearchConstraints (Optional) </dt>
<dd>
<t>Constrain the search to a specific time interval and/or  limit the number and/or total size of data records returned.  </t>
</dd>
</dl>
</section>
<section title="Message: TransferResponse" anchor="n-message-transferresponse-"><dl>
<dt>Inherits: MeshResponse  </dt>
<dd>
</dd>
</dl>
<t>Reports the success or failure of a Transfer transaction. If successful, contains the list of Mesh records to be transferred. </t>
<dl>
<dt>DataItems: DataItem [0..Many] </dt>
<dd>
<t>List of mesh data records matching the request. </t>
</dd>
<dt>PageKey: String (Optional) </dt>
<dd>
<t>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.  </t>
</dd>
</dl>
</section>
</section>
</section>
<section title="Assets" anchor="n-assets"><section title="Data" anchor="n-data"></section>
<section title="Credentials" anchor="n-credentials"></section>
<section title="Reputation" anchor="n-reputation"><section title="Outbound Messaging Abuse ()" anchor="n-outbound-messaging-abuse-"></section>
</section>
</section>
<section title="Risks" anchor="n-risks"><section title="Confidentiality" anchor="n-confidentiality"><t>Is a regulatory requirement GDPR/HIPPA</t>
<t></t>
<section title="Privacy" anchor="n-privacy"><t>Stronger requirement, given data but with restrictions on use</t>
<t>Unintended use within an organization may put it in default</t>
<t>GDPR</t>
<t>HIPPA</t>
</section>
</section>
<section title="Integrity" anchor="n-integrity"><t>Modification of data enables control breaches</t>
<t></t>
</section>
<section title="Availability" anchor="n-availability"><section title="Data loss" anchor="n-data-loss"><t>Loss of the pictures of the kids at 5</t>
</section>
<section title="Partial data survivability" anchor="n-partial-data-survivability"><t>Where they buried Aunt Agatha's jewelry but not where they buried Aunt Agatha.</t>
</section>
</section>
<section title="Inbound Messaging Abuse (Spam)" anchor="n-inbound-messaging-abuse-spam"></section>
</section>
<section title="Threats" anchor="n-threats"><section title="End point Compromise" anchor="n-end-point-compromise"></section>
</section>
<section title="Controls" anchor="n-controls"><section title="Cryptographic" anchor="n-cryptographic"><section title="Triple lock" anchor="n-triple-lock"><section title="Transport Security" anchor="n-transport-security"><t>Traffic analysis protection</t>
</section>
<section title="Message Security" anchor="n-message-security"><t>Access control</t>
<t>Authentication / Integrity</t>
</section>
<section title="Data Level Security" anchor="n-data-level-security"><t>Data Confidentiality</t>
<t>Non-Repudiation </t>
</section>
</section>
<section title="Key Protection" anchor="n-key-protection"><t>Use of platform provided facilities to bind private keys in the Device profile to the device is highly desirable. Ideally, private keys should be protected against extraction by hardware techniques presenting a high degree of resistance.</t>
<section title="Windows" anchor="n-windows"><t>Use encrypted key store</t>
<t>Preferably use BitLocker</t>
</section>
<section title="OSX" anchor="n-osx"><t>Use Key Ring</t>
</section>
<section title="iOS" anchor="n-ios"><t>Use ???</t>
</section>
<section title="Linux" anchor="n-linux"><t>Use the DBUS mechanism</t>
</section>
<section title="Android" anchor="n-android"><t>Hope and prayers.</t>
</section>
</section>
<section title="Key and Nonce Generation" anchor="n-key-and-nonce-generation"><t>Use strong mechanisms as described in RFC???</t>
<t>Use of key co-generation as described in part 8 is advised</t>
</section>
<section title="Key Escrow and Recovery" anchor="n-key-escrow-and-recovery"><t>Master profile keys should be escrowed</t>
<t>Escrow strategies for DARE should take account of the fact that users may want some but not all their data assets to survive them. </t>
</section>
<section title="Profile Verification" anchor="n-profile-verification"><t>Check that the device credential has been signed by an administration device and that the administration device was properly authorized by the master profile.</t>
<t>Device catalog <bcp14>MUST</bcp14> be signed by the admin device. </t>
<t>Future ? provide protection against rollback attacks.</t>
</section>
<section title="Identity Validation" anchor="n-identity-validation"><t>See the separate document on the trust model</t>
</section>
<section title="Trust Broker Accountability" anchor="n-trust-broker-accountability"><t>Cert transparency type techniques</t>
</section>
</section>
<section title="Mesh Messaging" anchor="n-mesh-messaging"><section title="Ingress Control" anchor="n-ingress-control"><t>Every message is subject to access control</t>
<t>Mesh Services should perform abuse filtering on inbound mail</t>
<t>Mesh Services <bcp14>MUST</bcp14> apply user specified ingress control as specified in their contacts catalog.</t>
</section>
<section title="Egress Control" anchor="n-egress-control"><t>Some applications may require egress control</t>
<t>For example, classified environments</t>
<t>Mail too stupid to send</t>
</section>
<section title="Security Signal" anchor="n-security-signal"><t>Confirmation messages requiring payments</t>
<t>Need Accountability</t>
<t>Need to know the source of the accountability assertions</t>
<t>Should be distinguished from sender controlled part of a message</t>
<section title="Brand" anchor="n-brand"><t>If messages are being sent on behalf of a corporate entity, this should be signaled to both sender and receiver</t>
<t>Sender ? remind them that they are speaking on behalf of another party</t>
<t>Receiver ? establish who is speaking by the familiar technique.</t>
</section>
</section>
<section title="Accountability" anchor="n-accountability"><t>Authentication and consequences</t>
</section>
</section>
</section>
<section title="Security Considerations" anchor="n-security-considerations"><t>This document comprises the security considerations for the use and implementation of the Mathematical Mesh.</t>
<t></t>
<section title="Integrity" anchor="n-integrity-0"><section title="DNS Spoofing" anchor="n-dns-spoofing"></section>
<section title="TLS Downgrade" anchor="n-tls-downgrade"></section>
<section title="TLS Service Impersonation" anchor="n-tls-service-impersonation"></section>
<section title="Request Replay Attack" anchor="n-request-replay-attack"></section>
<section title="Response Replay Attack" anchor="n-response-replay-attack"></section>
</section>
<section title="Confidentiality" anchor="n-confidentiality-0"><section title="Side Channel Attack" anchor="n-side-channel-attack"></section>
<section title="Session Key Leakage" anchor="n-session-key-leakage"><t></t>
</section>
</section>
</section>
<section title="IANA Considerations" anchor="n-iana-considerations"><t>All the IANA considerations for the Mesh documents are specified in this document</t>
</section>
<section title="Acknowledgements" anchor="n-acknowledgements"><t>A list of people who have contributed to the design of the Mesh is presented in <xref target="draft-hallambaker-mesh-architecture"></xref>.</t>
<t></t>
</section>
</middle>
<back>
<references title="Normative References"><reference anchor="RFC2119"><front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname="S. Bradner" initials="S." surname="Bradner"><organization/>
<address>
</address>
</author>
<date month="March" year="1997"/>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="draft-hallambaker-mesh-architecture"><front>
<title>Mathematical Mesh 3.0 Part I: Architecture Guide</title>
<author fullname="Phillip Hallam-Baker"><organization>ThresholdSecrets.com</organization>
<address>
</address>
</author>
<date day="25" month="October" year="2021"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-hallambaker-mesh-architecture-19"/>
<format type="TXT" target="https://www.ietf.org/archive/id/draft-hallambaker-mesh-architecture-19.txt"/>
</reference>
</references>
<references title="Informative References"><reference anchor="draft-hallambaker-mesh-developer"><front>
<title>Mathematical Mesh: Reference Implementation</title>
<author fullname="Phillip Hallam-Baker"><address>
</address>
</author>
<date day="27" month="July" year="2020"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-hallambaker-mesh-developer-10"/>
<format type="TXT" target="https://www.ietf.org/archive/id/draft-hallambaker-mesh-developer-10.txt"/>
</reference>
</references>
</back>
</rfc>
