Comodo Group Inc.

philliph@comodo.com

The use of the Mathematical Mesh to manage cryptographic keys for use with Mail and SSH is described. The format of the application profiles is described with examples. This document is also available online at http://prismproof.org/Documents/draft-hallambaker-mesh-app.html .

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.

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 .

The related specifications are described in the Mesh Architecture specification

No terms of art are defined.

The implementation status of the reference code base is described in the companion document .

(Pull piece from Mesh Reference to here)

Catalog profiles are used to synchronize encrypted data sets across devices. The catalog data model is restricted so as to permit a common set of management tools to be used to access and maintain profiles containing different types of data (bookmarks, credentials, contacts, etc.). Catalogs do not contain per device data. A catalog may not be shared with every device in the user?s profile but all the data in a catalog is available to all the devices with which it is shared. The management operations supported are: Permit user to add, delete and update entries from multiple devices with minimal surprise. The mechanism is designed to be reasonably robust if network connectivity is lost during an attempted update. Allow entries to be grouped into hierarchical categories defined by the user. An entry may be added to more than one category at once. Each catalog entry SHOULD contain exactly one timestamp field of time Added, Updated or Deleted. If present, the timestamp entries and the entry identifiers are used to merge catalog profiles that have been updated separately leading to an inconsistent state. Applications SHOULD specify a timestamp field on every entry unless it is known that update inconsistency cannot occur. For example, when initially populating a catalog.

Alice creates a new bookmarks profile which is shared between her laptop and her phone. The initial profile is empty:

Alice adds a bookmark entry to her profile on the browser on her laptop:

Later, Alice is attempting to connect to a site on her phone but has no network connection. She decides to bookmark the site instead.

At this point, the profiles on Alice's two devices are out of sync. When the phone is finally able to connect to the network, the profiles are merged:

A credentials catalog contains access credentials, typically usernames and passwords, for a set of network resources such as Web sites that do not support the use of Mesh device profile data for authentication. Mesh/Credential enabled applications SHOULD offer to generate strong passwords for the user if the AutoGenerate field is set to true in the credential profile. Since the use of automatically generated passwords is likely to be inconvenient for users unless all the applications on all the devices they might use support Mesh/Credential profiles, applications MUST NOT automatically generate passwords unless the user has affirmatively indicated that they want to use them. Further Work: Credential entries MAY specify that the credential is restricted to use with certain protocols (Web browsing, SFTP, etc.) and/or certain authentication mechanisms but the precise means of identifying both is not currently defined.

A bookmarks catalog contains a collection of bookmarks that have been saved for later use. While the ability share bookmarks between groups of users has obvious advantages, at present, the implementation and specification are only written with the use of a single user have been considered. A bookmark entry contains the URI of the target and a title. If the book mark entry is a HTML resource, the title is taken from the <title> element in the document header. If network and storage resources permit, catalog entries MAY include a favicon value for easy identification. Further Work: Bookmark entries MAY contain details describing the security properties of the connection to protect against downgrade attack. For example, information from HTTP strict security and key pinning headers . tbs

A contacts catalog contains a collection of contacts. The ContactEntry object contains the usual fields for describing the person or organization the entry refers to, and means of contact (Internet, Postal). One significant deviation from existing formats is that the fact that people change names (e.g. marriage) is captured and that means of contact MAY be scoped to a particular organization.

It is generally acknowledged that representation of calendar information is a ?difficult? problem. Since it is the author?s experience that such problems almost invariably arise from an attempt to make use of an inadequate data model, the format for exchange of calendar information is currently undefined. Further Work: Two major causes of difficulty are the use of local time zones and daylight savings, the definition of which are capricious at best. When a recurring meeting is specified it is vital that the time zone in which the meeting is to recur is specified explicitly. Attempts to normalize meetings to a single time zone will inevitably fail when the definition of time changes between the time the meeting is called and the meeting is held. Another major limitation in existing formats is the lack of understanding that when the user travels, at least some part of their context for scheduling also changes. It should be possible to integrate all parts of the user?s schedule to offer alerts and reminders appropriate to their current location.

Mesh Mail profiles serve two distinct purposes: To provision a user?s devices with the credentials, network configuration and cryptographic keys necessary to support use of mail and end-to-end mail security enhancements. To publish necessary information for use by mail senders. While the principle focus of Mesh/Mail is to support exchange of mail over SMTP protocol, any infrastructure that provides a mechanism for publishing a recipient?s public keys for use by senders can, at least in principle, also publish information describing the user?s mail capabilities including the ability to support new messaging protocols. The use of end-to-end secure protocols requires the generation and use of at least one public key pair for signature and encryption. Best current practices require the use of separate keypairs for signature and encryption and if practical separate signature keys for each device. Since S/MIME and OpenPGP as currently specified do not support the use of Proxy Re-Encryption (recryption) to enable separate the use of separate decryption keys for each device, a single encryption keypair is used. A mail profile must therefore contain an encrypted copy of the corresponding decryption key for each device. Further Work: Support Signal etc. At present the profiles are not differentiated on a per device level. It is likely that it would be useful to specify that certain devices are to carry a complete copy of the user?s mail while others should only carry messages from the last few weeks or months. It is also likely that it would be useful to be able to mark certain selections as being likely to be most useful offline.

The Secure Shell (SSH) transport layer protocol is widely used as a mechanism for securing access to remote hosts. In addition to providing a terminal connection to a remote host, SSH also supports file transfer and remote access (VPN) functionality. It is also used to provide remote procedure call (RPC) capabilities in applications such as Git. While SSH permits a high level of security to be achieved, achieving a high security configuration requires a considerable degree of attention to detail. Numerous ?how to? guides found on the Internet advise the user to engage in many unsafe practices. These include: Using a single private key for authentication for every machine to be used as a client. Emailing a copy of the authentication key to yourself to transfer it to a new machine. (Alternatively use of insecure FTP, copying the data to /temp, etc.) Of equal concern was the fact that none of the guides mentioned any form of maintenance activity such as deleting authentication keys for a decommissioned device or performing a rekey operation in the case that a device is compromised. Configuring SSH securely is a non-trivial task because SSH is the tool through which the administrator will be connecting to secure their system. This is a bootstrap problem: It is easy to solve the problem of SSH configuration once we have SSH configured for use. To enable SSH access to a machine without creating an insecure path first is not a trivial matter. A Mesh/SSH profile contains three sets of information: A set of the user?s public authentication keys. This is used to generate auth_hosts files and equivalents to enable the user to access machines. A set of hosts known to the user. This is encrypted as it shows the machines that the user at least is likely to visit. This is used to generate known_hosts files and equivalents to enable the user to authenticate hosts. A set of device key entries. The entry for each host is encrypted. This is used to create the private key file(s) for the user on each of their devices.

Catalogues are application profiles that consist of a set of related information (contacts, passwords, bookmarks) but do not contain any cryptographic private keys or device specific data. These restrictions allow management of these profiles to be simplified.

The following objects are common to multiple profiles.

Base class for all application profiles that are tied to an account profile The account to which this profile is bound The person to which this profile is bound

Base class for catalog entries, contains base information on which catalog operations are performed. Unique identifier for the entry. If present, overrides the identifier specified in the entry. The time the site was added The last time the entry was updated The last time the entry was updated Labels identifying the group(s) that the entry is filed under Source data for the entry

Typed content. IANA Content Type identifier The described data

Profile for recording access credentials for Web sites and other projects. Currently this is limited to usernames and passwords but could expand to include other credential forms.

Stores usernames and passwords. There are no public fields. [No fields]

Private part of the profile. If true, a client MAY offer to automatically generate strong (i.e. not memorable) passwords for a user. A user would not normally want to use this feature unless they have access to Mesh password management on every device they use to browse the Web A list of password credential entries. A list of domain names of sites for which clients MUST NOT ask to store passwords for.

Username password entry for a single site DNS name of site *.example.com matches www.example.com etc. Case sensitive username Case sensitive password. Protocol identifier, e.g. http, sftp, ssh, etc.

Profile for recording Web site bookmarks and related information.

Stores Web site bookmarks in a hierarchical [No fields]

Private part of the profile. The bookmark entries

Bookmark entry for a single site The resource name The resource identifier UDF fingerprint of related favicon image

Profile for recording user contact information

Stores Web site bookmarks in a hierarchical [No fields]

Private part of the profile. The contact entries

Contact entry Personal names. List of mesh profiles fingerprints for the user. List of Internet, telephone, etc addresses for contacting this party List of postal addresses for this party

Personal name structure. First name Last name Middle names (if used).

Contact address. Labels identifying the modes in which the label may be used e.g. Home, Business, Mobile Attributes describing the mode in which the contact address may be used.

Internet contact address The resource identifier describing the mode of contact

Postal or geographic address. The postal name Street name and number Name of town or city State, county, department or other government unit. The country name The ISO 3 letter country code

Contact entry for a single person The name of the person The name of the organizations the person is associated with

Contact entry for a single organization The name of the organization

Stores usernames and passwords. There are no public fields. [No fields]

Private part of the profile. A list of access point entries A list of VPN entries

Describes network access credentials Network configuration data.

Profiles that describe mail user agent configuration

Public profile describes mail receipt policy. Private describes Sending policy The current OpenPGP encryption key The current S/MIME encryption key

Contains public device description [No fields]

Describes a mail account configuration Private profile contains connection settings for the inbound and outbound mail server(s) and cryptographic private keys. Public profile may contain security policy information for the sender. The RFC822 Email address. [e.g. "alice@example.com"] The RFC822 Reply toEmail address. [e.g. "alice@example.com"] When set, allows a sender to tell the receiver that replies to this account should be directed to this address. The Display Name. [e.g. "Alice Example"] The Account Name for display to the app user [e.g. "Work Account"] The Inbound Mail Connection(s). This is typically IMAP4 or POP3 If multiple connections are specified, the order in the sequence indicates the preference order. The Outbound Mail Connection(s). This is typically SMTP/SUBMIT If multiple connections are specified, the order in the sequence indicates the preference order. The public keypair(s) for signing and decrypting email. If multiple public keys are specified, the order indicates preference. The public keypairs for encrypting and decrypting email. If multiple public keys are specified, the order indicates preference.

Private data specific to the device [No fields]

Profiles that describe SSH user agent configuration

Application profile for SSH. This is an initial cut of the profile and will need revision. In particular, a sysadmin with a very large number of hosts they are accessing will need some means of avoiding combinatorial explosion. [No fields]

Contains public device description Public authentication key for a device.

Private portion or profile. The account to which the profile is bound Hosts bound to the profile

Describe a host connected to the SSH profile. This is a machine that the user will access using the credential. The DNS address or IP address of the host The SSH Algorithm identifier The Base64 encoded public key

Private data specific to the device A private keypair or keypair contribution created for exclusive use of this device. Fingerprint of device that this key corresponds to.

Your name could appear here.

[This is just a sketch for the present.]

[TBS list out all the code points that require an IANA registration]