Internet DRAFT - draft-hallambaker-cryptomesh

draft-hallambaker-cryptomesh



Internet Engineering Task Force (IETF)              Phillip Hallam-Baker
INTERNET-DRAFT                                         Comodo Group Inc.
Intended Status: Standards Track                           June 29, 2015
Expires: December 31, 2015


                       Modular Mathematical Mesh
                    draft-hallambaker-cryptomesh-00

Abstract

   The Magic Mathematical Mesh 'the Mesh' is a security infrastructure 
   for the Internet that puts individual users in control of their 
   security. Through large scale redundancy and replication techniques, 
   mesh users have a high level of assurance that data stored in the 
   mesh through a mesh gateway node will be available at a later date.

   The mesh does not offer confidentiality guarantees. All data in the 
   mesh is assumed to be public. Confidential data stored in the mesh 
   must be protected using strong encryption. The mesh provides a medium
   that enables the exchange of private key data but never passes 
   private data of any form in plaintext form.

   The mesh enables use of end-to-end and transport security with mutual
   authentication in a wide range of client server and peer-peer 
   applications. These include email, remote access and the Web. Unlike 
   previous attempts to establish such infrastructures, the password 
   management application supported by the mesh delivers users with an 
   immediate benefit that does not rely on adoption by others.

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 http://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."

Copyright Notice

   Copyright (c) 2015 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 
   (http://trustee.ietf.org/license-info) in effect on the date of 



Hallam-Baker               December 31, 2015                    [Page 1]

Internet-Draft         Modular Mathematical Mesh               June 2015

   publication of this document. Please review these documents 
   carefully, as they describe your rights and restrictions with respect
   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.
















































Hallam-Baker               December 31, 2015                    [Page 2]

Internet-Draft         Modular Mathematical Mesh               June 2015

Table of Contents

   1.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  5
      1.1.  Requirements Language . . . . . . . . . . . . . . . . . .  5
      1.2.  Defined Terms . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  6
      2.1.  What does the Mesh do for me? . . . . . . . . . . . . . .  7
         2.1.1.  User Experience  . . . . . . . . . . . . . . . . . .  8
         2.1.2.  What else can the Mesh do for me in the future?  . .  9
      2.2.  No-Password Authentication  . . . . . . . . . . . . . . . 10
      2.3.  Encrypted Email . . . . . . . . . . . . . . . . . . . . . 10
      2.4.  WiFi and Networking . . . . . . . . . . . . . . . . . . . 11
      2.5.  Internet of Things  . . . . . . . . . . . . . . . . . . . 11
      2.6.  Developer Tools . . . . . . . . . . . . . . . . . . . . . 12
   3.  Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 12
      3.1.  Profiles  . . . . . . . . . . . . . . . . . . . . . . . . 13
         3.1.1.  Personal Profile . . . . . . . . . . . . . . . . . . 13
         3.1.2.  Device Profile . . . . . . . . . . . . . . . . . . . 15
      3.2.  Escrow  . . . . . . . . . . . . . . . . . . . . . . . . . 15
         3.2.1.  Offline Escrow . . . . . . . . . . . . . . . . . . . 16
      3.3.  Identifiers . . . . . . . . . . . . . . . . . . . . . . . 16
         3.3.1.  Object Identifiers . . . . . . . . . . . . . . . . . 16
         3.3.2.  Account Identifier . . . . . . . . . . . . . . . . . 17
         3.3.3.  Profile Identifier URI . . . . . . . . . . . . . . . 17
   4.  Application Profiles . . . . . . . . . . . . . . . . . . . . . 18
      4.1.  Administration  . . . . . . . . . . . . . . . . . . . . . 18
      4.2.  Escrow  . . . . . . . . . . . . . . . . . . . . . . . . . 18
      4.3.  Network Connection  . . . . . . . . . . . . . . . . . . . 18
      4.4.  Password Manager  . . . . . . . . . . . . . . . . . . . . 19
      4.5.  Authentication  . . . . . . . . . . . . . . . . . . . . . 19
      4.6.  Email . . . . . . . . . . . . . . . . . . . . . . . . . . 19
   5.  Mesh Services  . . . . . . . . . . . . . . . . . . . . . . . . 20
      5.1.  Mesh Log  . . . . . . . . . . . . . . . . . . . . . . . . 21
      5.2.  Mesh Replication  . . . . . . . . . . . . . . . . . . . . 21
   6.  Requirements and Recommendations . . . . . . . . . . . . . . . 21
      6.1.  Requirements  . . . . . . . . . . . . . . . . . . . . . . 21
      6.2.  Recommendations . . . . . . . . . . . . . . . . . . . . . 22
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 22
      7.1.  Mesh Integrity  . . . . . . . . . . . . . . . . . . . . . 22
      7.2.  Mesh Data Confidentiality . . . . . . . . . . . . . . . . 22
      7.3.  Disclosure of Private Key . . . . . . . . . . . . . . . . 23
      7.4.  Denial of Service . . . . . . . . . . . . . . . . . . . . 23
      7.5.  Traffic Analysis  . . . . . . . . . . . . . . . . . . . . 23
      7.6.  Covert Channels . . . . . . . . . . . . . . . . . . . . . 23
      7.7.  Data Loss . . . . . . . . . . . . . . . . . . . . . . . . 24
      7.8.  User Capture  . . . . . . . . . . . . . . . . . . . . . . 24
   8.  IANA Requirements  . . . . . . . . . . . . . . . . . . . . . . 24
      8.1.  Registration of mmm URI Scheme (provisional)  . . . . . . 24
      8.2.  Registration of application/mesh Content Types  . . . . . 24
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25



Hallam-Baker               December 31, 2015                    [Page 3]

Internet-Draft         Modular Mathematical Mesh               June 2015























































Hallam-Baker               December 31, 2015                    [Page 4]

Internet-Draft         Modular Mathematical Mesh               June 2015

1. Definitions

1.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 RFC 2119 [RFC2119].

1.2. Defined Terms

         Mesh Object
            A collection of data items stored in the mesh with a unique 
            and fixed identifier.

         Mesh Entry
            An entry in the mesh recording the value of a mesh object at
            a particular instant.

         Profile
            A mesh object that contains

         Personal Profile
            A profile that contains a description of a user?s personal 
            PKI, credentials and connected devices and applications.

         Device Profile
            A profile that contains a description of a device and its 
            associated credentials.

         Application Profile
            A profile that contains a description of the use of an 
            application by a user

         Enterprise Profile
            A profile that contains a description of a enterprise?s PKI,
            credentials and connected devices and applications.

         Mesh Node
            One or more host machines that provide mesh services under 
            the same domain name and share the same state.

         Gateway Node
            A Mesh node that supports services that append data to the 
            Mesh.

         Distribution Node
            A Mesh node that supports services that report but do not 
            change the state of the Mesh.






Hallam-Baker               December 31, 2015                    [Page 5]

Internet-Draft         Modular Mathematical Mesh               June 2015

         Mesh
            A collection of interlinked Mesh Nodes exchanging data 
            through the replication protocol so as to present a single 
            consistent repository for all mesh

         Public Key
            Non-secret portion of a public key pair.

         Private Key
            Secret portion of a public key pair.

         Fingerprint
            The output of a cryptographic digest function presented in a
            form that facilitates verification that the original data 
            input is unchanged.

         Public Profile
            A profile or portion of a profile containing plaintext data.

         Private Profile
            A profile or portion of a profile containing encrypted data.

2. Introduction

   The Magic Mathematical Mesh 'the Mesh' is a security infrastructure 
   for the Internet that puts individual users in control of their 
   security. The Mesh is based on three principles:

         Magic
            From the point of view of the user, the mesh should appear 
            to work 'by magic'. Visiting a Web site secured using https 
            requires no more effort from the user than visiting an 
            insecure site. That principle of 'security by magic' should 
            apply to every interaction.

         Mathematical
            The mesh provides security through the use of cryptography. 
            Users do not need to understand the mathematics that make 
            the mesh work but every part of the mathematics supporting 
            the mesh must be public and fully documented.

         Mesh
            The mesh itself is a decentralized cloud service similar to 
            the blockchain that supports BitCoin. Like the services that
            support the blockchain, every operation on the mesh is 
            public and the integrity of the mesh is preserved by means 
            of a hash chain mechanism. The mesh does not store or have 
            access to any confidential plaintext data of any kind 
            including private keys. Once information has been replicated
            across the surface of the mesh, it cannot be deleted without
            the collusion of every mesh node and without the originator 



Hallam-Baker               December 31, 2015                    [Page 6]

Internet-Draft         Modular Mathematical Mesh               June 2015

            being able to detect the default.

   While constructing such an infrastructure would have been considered 
   an absurd challenge in 1995, the success of BitCoin provides a 
   demonstration that deploying infrastructures of this size is now both
   practical and possible.

   The indexed Web contains over 4.6 billion pages and 5 zettabytes of 
   data and both are growing at an exponential rate. To serve its 
   function, the mesh need only store a personal profile of a few tens 
   of kilobytes for each person on the planet. A single desktop RAID 
   array could store a personal profile for every one of the three 
   billion users of the Web today.

2.1. What does the Mesh do for me?

   Today the World Wide Web has thousands of uses from information 
   retrieval to online banking to turning light switches on and off in 
   the home. But the original success of the Web at CERN was came from 
   serving just one function and doing that very well: Providing access 
   to the CERN phoned directory.

   Today's Internet users have myriad security desires and even greater 
   needs. They want encrypted mail; they want encrypted documents; they 
   want encrypted Web sites. But the single biggest security related 
   aggravation is the need to remember usernames and passwords for 
   hundreds of individual Web Sites. Attempts to solve this problem to 
   date have focused on two particular strategies:

         *  Persuade users to store all their passwords in a network 
            accessible service.

         *  Persuade Web site providers to use an external 'identity 
            service' to perform account management for them.

   Both approaches have major flaws as the recent breach at LastPass and
   Google's decision to drop support for OpenID 2.0 demonstrate. If a 
   Web Site decides to outsource identity management to a third party 
   they are making their business dependent on that third party 
   operating their infrastructure securely and continuing to do business
   in a particular way.

   Storing account credentials in the mesh overcomes the problems 
   associated with both legacy approaches:

         *  The mesh is not a trusted service. The mesh cannot be 
            breached because the mesh does not offer any security 
            guarantees. The security of mesh applications depends on the
            security of the end points, not the security of the mesh.





Hallam-Baker               December 31, 2015                    [Page 7]

Internet-Draft         Modular Mathematical Mesh               June 2015

         *  All data stored in the mesh is encrypted, including 
            usernames and passwords.

         *  Decrypting data stored in the mesh always requires 
            information stored outside the mesh.

         *  The mesh is not a restricted service. Anyone can set up a 
            mesh at any time and anyone can distribute an established 
            public mesh.

         *  Mesh users connect through a mesh gateway. By definition, a 
            public mesh has multiple gateway providers and can change 
            their gateway at any time.

         *  Mesh users can always recover the information assets they 
            stored, either from local storage or from a mesh 
            distributor.

         *  The only necessary requirement for a mesh gateway is to 
            impose some form of abuse limiting mechanism to stop denial 
            of service attack against the mesh by flooding it with bogus
            data.

   Although the primary purpose of this proposal is to establish a 
   single cryptomesh as a ubiquitous public infrastructure analogous to 
   the Internet, DNS and the WebPKI, it is recognized that such 
   infrastructures are more likely to grow organically rather than 
   through a top-down approach. Reflecting this approach, the mesh is 
   conceived as a collection of loosely coupled nodes, each of which is 
   independently hosted and operated.

   A mesh gateway node may assure users that their data is protected in 
   the event of a permanent or temporary loss of service at that node by
   establishing replication agreements with one or more independent 
   nodes. Such agreements may be reasonably expected to encourage the 
   emergence of a single public mesh over time.

2.1.1. User Experience

   A personal profile is created using the profile management tool. In 
   quickstart mode the user need provide nothing more than an account 
   name for the profile and the domain of a mesh gateway (e.g. 
   comodo.com). Even the account name is not strictly necessary unless 
   the user has more than one profile. It just proved easier for users 
   to ask than making this an option. The second can be given by default
   with a user override option.

   Whenever a new profile is created, the profile manager reports a 
   profile fingerprint. This is conceptually similar to an OpenPGP key 
   but with the important distinction of not being limited to a single 
   application. Once a profile is generated, its fingerprint never 



Hallam-Baker               December 31, 2015                    [Page 8]

Internet-Draft         Modular Mathematical Mesh               June 2015

   changes. The profile fingerprint is used when connecting new devices 
   to a profile to ensure that the correct device is being connected and
   not an impostor. While at present fingerprints are Base32 encoded 
   alphanumeric strings, other formats such as a sequence of images may 
   be used for verification.

   Since a new profile does not contain any data at all, the user may 
   skip the key escrow option. Otherwise the master signature and 
   decryption keys for the profile are encrypted under a symmetric key 
   and stored in a private profile. The symmetric key is then split 
   using Shamir secret sharing and each share presented to the user as 
   an alphanumeric recovery key and/or QR code. These may be printed and
   stored in case recovery should be required.

   Once a profile has been established, a mesh enabled application 
   running on the same device may use it automatically or after 
   requesting user consent. Thus a mesh enabled password manager might 
   prompt the user to ask if they wanted to store usernames and 
   passwords in their mesh profile.

   To make use of an existing profile on a second device, a user starts 
   the profile manager and gives the account name. The profile manager 
   displays the profile fingerprint for verification purposes. When the 
   user runs the profile manager on a machine that has been connected to
   the profile already and granted administration privileges, it 
   displays a list of pending connection requests which may be approved 
   or declined as the user decides. Once the request is approved, the 
   user will have full access to their passwords stored in the crypto 
   mesh on the second machine.

   Even though the user experience of a mesh based password manager is 
   no more complicated than that of a traditional scheme, no 
   confidential data is ever passed unencrypted through the mesh and all
   encryption is end to end and uses the strongest level of AES 
   encryption. The mesh is thus immune to the risk of breach since there
   is no information to be breached.

   More importantly, once a user has made the effort of installing a 
   mesh profile manager, they have the tools at their disposal to use 
   the mesh with any application that is mesh-enabled. By design, the 
   mesh supports any application that uses cryptographic credentials.

2.1.2. What else can the Mesh do for me in the future?

   Use of the Web at CERN began with the phone book. But that use alone 
   would not have been enough to justify the effort of developing the 
   tool. The reason CERN was willing to invest the time and effort 
   required to build the Web was the understanding that it would one day
   be capable of doing much more.





Hallam-Baker               December 31, 2015                    [Page 9]

Internet-Draft         Modular Mathematical Mesh               June 2015

   While the CERN phone book was the 'killer application' of the Web on 
   CERN main site, the Web itself was originally designed to enable 
   distribution of research materials. In the same way, secure password 
   storage represents a 'killer application' that requires no other 
   party to buy-in or make use of the mesh in order to build out the 
   infrastructure. But it is sincerely hoped that once that 
   infrastructure is established it will enable second generation 
   applications that are far more useful.

   The mesh provides a mechanism for storing and retrieving profiles. In
   this paper we only consider the profile types relevant to one 
   particular mesh, the cryptographic mesh (cryptomesh) used to store 
   cryptographic credentials and other data relevant to enabling use of 
   applications. Since strong cryptographic keys need only be tens or 
   hundreds of bytes, such profiles would typically be very small, a few
   tens or hundreds of kilobytes at most. But given suitable storage 
   capability, the same technology used to build the cryptomesh could 
   also be applied to storage of data (aka the datamesh).

2.2. No-Password Authentication

   Making passwords easier to use is good. But the getting rid of them 
   entirely is better. There is no little irony in the fact that after 
   rendering the telephone book obsolete, the Internet quickly rendered 
   the public telephone network obsolete. It would be the greatest 
   service if the mesh could render passwords obsolete as a network 
   authentication mechanism.

   There is no shortage of protocols and mechanisms that eliminate the 
   need for password authentication. The chief deployment obstacle has 
   been the lack of support infrastructure. Until there is a large 
   population of Web users equipped with the means to use a password 
   alternative, there is no incentive for Web sites to accept 
   alternatives. And until Web sites accept alternatives there is no 
   incentive for users to change their behavior.

   The mesh provides a mechanism that allows every device a user owns to
   be provisioned with a public key pair and credential chain. This 
   allows the use of existing protocols such as SAML and OpenID Connect 
   to be used to replace passwords completely.

   Instead of being asked to provide a username and password on visiting
   a Web Site, a user would only need to provide authentication when a 
   security critical choice was being made. A user should not need to 
   'log in' to read a newspaper but additional confirmation is certainly
   required when they decide to make a purchase or transfer funds from 
   their bank.







Hallam-Baker               December 31, 2015                   [Page 10]

Internet-Draft         Modular Mathematical Mesh               June 2015

2.3. Encrypted Email

   Encrypted email was the original purpose for which the mesh 
   technology was developed under the name 'Prism-Proof email'. By 
   default, the mesh prototype will automatically configure certain 
   email clients for the use of encrypted mail. Once a client is 
   enabled, use of encryption is completely seamless and automatic 
   provided that an S/MIME capable email client is used.

   While the large deployed base of S/MIME capable clients makes support
   for this encryption format expedient, the mesh is designed to be 
   completely technology neutral. A public application profile for email
   can specify the public encryption keys to be used and the encryption 
   formats they should be used with. If the user prefers OpenPGP, this 
   can be offered as an alternative. But rather than perpetuating 
   unnecessary format wars, the preferred situation would be for the 
   default to be to support both.

   When using mesh enabled email security, a user may opt to make end-
   to-end encryption their preferred option for an account. But doing so
   will of course render any email messages unreadable on devices that 
   they have not yet connected to their profile. For this reason it is 
   suggested that early adopters of the email encryption capabilities 
   should consider creating a secondary account for their mesh email. 
   For example, alice@example.com might use mesh.alice@example.com to 
   receive encrypted messages.

   The mesh provides a solution to two of the major challenges of end-
   to-end encrypted email, distribution of public keys and management of
   private keys. As described earlier, use of a public profile on the 
   cryptomesh solves the problem of public key distribution and use of 
   private profiles allows any device that has been connected to a 
   profile to access the current decryption key.

2.4. WiFi and Networking

   One of the most tedious chores in administering a home network is 
   configuring devices to connect to one or more WiFi networks. And once
   a device has been tediously configured, the work is likely to be 
   undone for the most trivial of reasons or for no reason at all.

   Once a device is connected to a personal profile, it may be 
   authorized to use any WiFi network that is managed under that 
   profile. Alternatively the network owner may authorize a more limited
   degree of network access. For example, a house guest might be 
   permitted to access a home WiFi network but only for a limited 
   period.







Hallam-Baker               December 31, 2015                   [Page 11]

Internet-Draft         Modular Mathematical Mesh               June 2015

2.5. Internet of Things

   One of the primary motivations for designing the mesh was the 
   realization that with 50 IP addresses already assigned on the home 
   networks and a further 30 non-IP based network devices already 
   deployed, reducing network administration effort has become a 
   necessity, not a luxury. An automated home does not reduce effort or 
   stress if connected devices are perpetually failing or requiring 
   software upgrades.

   Connecting an Internet of Things device such as a light bulb or a 3D 
   printer is little different in principle to connecting a computer or 
   a phone. The chief difference being that such devices may lack a 
   keyboard or a display of any kind and it may be desirable to limit 
   the degree of network access allowed. The coffee pot does not need to
   run a file server or send thousands of emails a second, permitting 
   such access increases the risk of the device being compromised, 
   therefore the principle of least privilege demands that such a device
   not be allowed unrestricted Internet access.

2.6. Developer Tools

   Although the mesh is designed to support the needs of all Web users, 
   it is to be expected that early most adopters will be among the more 
   expert users.

   The mesh provides a general purpose infrastructure on which any 
   application such as SSH or code signing can connect to cryptographic 
   credentials and resources as required.

3. Architecture

   The foundational principle of the mesh is that the mesh cannot be 
   breached because the mesh does not offer any security guarantees.

         *  The mesh cannot suffer disclosure breach because all 
            confidential data stored in the mesh is encrypted end-to-end
            using strong cryptographic algorithms and keys. This ensures
            that the confidentiality of the data is protected unless the
            encryption algorithms are broken or a breach occurs at the 
            end points where the private keys are stored.

         *  The mesh cannot suffer a permanent denial of service attack 
            as each mesh profile manager maintains a local copy of all 
            data stored in the mesh. Even if a mesh ceases operations 
            completely, a user may provision the same personal 
            profile(s) to a different mesh to quickly re-establish 
            service.






Hallam-Baker               December 31, 2015                   [Page 12]

Internet-Draft         Modular Mathematical Mesh               June 2015

         *  Recognizing the advances in computational power since the 
            original development of PKI in the mid-1990s, cryptographic 
            hygiene is encouraged through use of separate cryptographic 
            key material unless there are practical reasons to avoid 
            this approach.

   A consequence of the last principle is that a Personal PKI for a user
   with a large number of devices will have a large number of 
   cryptographic keys. In particular every device has its own keys for 
   authentication and key distribution and key material SHOULD NOT be 
   shared between application profiles. For applications such as email 
   encryption where it is desirable to be able to decrypt messages on 
   any connected device, a single encryption/decryption keypair MAY be 
   provisioned to multiple devices. In such circumstances, it is highly 
   desirable that such keys be rotated on a regular basis and in 
   particular when a device that has been provisioned with a current 
   decryption key is being disconnected from a profile.

3.1. Profiles

   Three types of profile are currently defined:

         Personal Profile
            Each mesh user has one or more personal profiles to which 
            they may connect devices and applications as they choose.

         Device Profile
            Contains keys and settings for a device. A device profile 
            MAY be connected to multiple Personal Profiles at the same 
            time.

         Application Profile
            Contains keys and settings for a set of applications. An 
            application profile can only connect to one personal profile
            at a time but MAY be transferred from one Personal Profile 
            to a successor.

   The need for a profile to describe enterprise security configuration 
   data is acknowledged but not currently addressed.

3.1.1. Personal Profile

   A personal profile consists of:

         *  A Personal PKI. [Public]

         *  A set of masked account identifiers. [Public, Signed]

         *  A set of Device Connection Entries. [Private, Signed]





Hallam-Baker               December 31, 2015                   [Page 13]

Internet-Draft         Modular Mathematical Mesh               June 2015

         *  A set of profiles describing applications enabled for that 
            account. [Private, Signed]

   Items marked [Signed] are signed under a current Administration key 
   and Items marked [Private] are encrypted under the set of current 
   profile administration keys.

3.1.1.1. Personal PKI

   Each Personal Profile contains a personal PKI hierarchy consisting 
   of:

         Personal Master Signature Key (PMSK)
            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.

         Personal Master Escrow Key(s) (PMEK)
            A Personal Profile MAY contain one or more PMEK keys to 
            enable escrow of private keys used for stored data. Note 
            that the presence and use of an escrow key are both 
            optional. A user MAY chose to create a profile without a 
            PMEK or choose not to use the escrow capability of a profile
            that has a PMEK specified.

         Personal Online Signature Key (POSK)
            A Personal profile contains at least one POSK which is used 
            to sign device administration application keys.

   The private key portions of the PMSK and PMEK are only ever used 
   during the initial configuration of the Personal PKI and in disaster 
   recovery situations. If a user loses access to a decryption key, the 
   PMEK may be used to recover and decrypt an escrowed copy. If a user 
   loses control over their POSK private key due to a device theft or 
   other compromise, the PMSK may be used to revoke it and possibly 
   establish a replacement.

   Due to the importance of and infrequent need for access to the PMSK 
   and PMEK, profile managers MUST support and SHOULD encourage use of 
   the offline escrow mechanism described below for these private keys.

   The key fingerprint of the PMSK is used as a unique identifier for 
   the corresponding profile.










Hallam-Baker               December 31, 2015                   [Page 14]

Internet-Draft         Modular Mathematical Mesh               June 2015

3.1.1.2. Device Connection Entry

   A Device Connection Entry contains:

         *  The fingerprint of the Device Master Signature Key to which 
            it applies

         *  A set of application profiles connected to the personal 
            profile that the device is authorized to access

3.1.1.3. Application Profile

   An Application Profile contains credential and network connection 
   data necessary to use a particular type of application such as 
   'email' or the password manager.

3.1.2. Device Profile

   Each device that is connected to one or more Personal Profiles 
   publishes a device profile. A device may be connected to more than 
   one profile simultaneously. In this case the device MAY have separate
   device profiles for each Personal Profile it is connected to or use a
   common profile.

         Device Master Signature Key (DSKK)
            Used sign certificates for the DAK, DDK and DKEK and device 
            profiles.

         Device Authentication Key (DAK)
            Used to authenticate device requests.

         Device Decryption Key (DDK)
            Used to decrypt private portions of a device profile for 
            that device. For example, private keys, passwords etc.

3.2. Escrow

   The mesh is a mechanism for managing cryptographic keys. Since the 
   ability to escrow private keys is an important function of a key 
   management infrastructure, the mesh provides an escrow mechanism. The
   allows the mesh to enable applications involving stored data such as 
   whole disk encryption and end-to-end encrypted email while providing 
   safeguards against the risk of data loss should a device securing a 
   decryption key fail.

   Although it is in principle possible to escrow any private key, the 
   use of an escrow mechanism dilutes the non-repudiation and forward 
   secrecy assurances that an application might assume. Thus the use of 
   key escrow is typically limited to:





Hallam-Baker               December 31, 2015                   [Page 15]

Internet-Draft         Modular Mathematical Mesh               June 2015

         *  Profile Master Keys (the PMSK and PMEKs)

         *  Decryption Keys used for encrypted stored data

   A two tier escrow scheme is supported:

         Online Escrow
            The private key data is encrypted under a PMEK key described
            in the Personal Profile.

         Offline Escrow
            The private key data is encrypted under a symmetric recovery
            key. The recovery key is typically split using a key sharing
            mechanism and the shares stored in a non-volatile media such
            as ink and paper.

            Note that in each case, the encrypted private key data is 
            typically stored in the mesh. It is only the means to 
            decrypt the escrow record that is online or offline.

3.2.1. Offline Escrow

   Use of the offline escrow mechanism is typically limited to escrow of
   the profile master keys (PMSK, PMEK) for which the online escrow 
   mechanism cannot be used.

   Since the encrypted data will be stored as public data in the mesh, 
   the process used to generate the recovery key MUST ensure that it 
   contains at least as much ergodicity as the private key being 
   protected without disclosing information on the private key itself. 
   One means of ensuring that this is achieved is to generate a random 
   nonce value using the best available source and combine it with the 
   private key being escrowed by means of a secure cryptographic digest.

   In order to minimize the amount of data required to recover escrowed 
   data, the object identifier of an offline escrow entry is the 
   fingerprint (i.e. a one way secure digest) of the recovery key.

   Online Escrow

   In the online escrow mechanism, the private key data is encrypted 
   under the PMEK of the associated profile.

   The object identifier of an online escrow entry is formed by 
   encrypting the corresponding public key identifier under the PKEK of 
   the associated profile and taking the fingerprint.








Hallam-Baker               December 31, 2015                   [Page 16]

Internet-Draft         Modular Mathematical Mesh               June 2015

3.3. Identifiers

3.3.1. Object Identifiers

   Every entry stored in the Mesh has an object identifier. The form of 
   the identifier is a Uniform Data Fingerprint (UDF). The input data 
   and precision are chosen to ensure that the object identifier is 
   globally unique with an acceptably high degree of assurance.

   For the sake of convenience, the prototype mesh uses identifiers with
   125 bit precision ensuring a negligible probability of two objects 
   being created with the same identifier until 2^50 (~10^15) entries 
   have been registered. A mesh gateway MAY chose a different level of 
   required precision or increase the level of precision required at any
   time.

3.3.2. Account Identifier

   An account identifier provides a user-friendly means of identifying a
   mesh profile. A personal profile MAY have multiple account 
   identifiers but a MESH gateway MUST NOT permit the same account 
   identifier to be used to identify more than one profile at a time.

   Account identifiers are assigned by a mesh gateway and entered using 
   the same form as an email address (i.e. @) where  is the domain name 
   of the mesh gateway that assigned the identifier. This approach 
   avoids the need to ensure that account identifiers are globally 
   unique. To avoid enumeration attacks and similar forms of abuse, only
   the fingerprint of the account identifier is exposed to the Mesh.

   For example, Alice registers her personal profile at example.com 
   using the account identifiers 'alice' and 'bob'. This prevents Bob 
   from registering his profile at example.com as 'bob'. Alice then buys
   a phone, to connect her phone to her Personal Profile, Alice enters 
   'alice@example.com' as her account identifier in the phone profile 
   manager. This allows the phone to retrieve Alice's personal profile 
   from the Mesh and present the fingerprint of the profile to Alice for
   verification.

   meshid = accountid ["@" domain]

   accountid = username | fingerprint

3.3.3. Profile Identifier URI

   The URI form of the profile identifier is a compact, machine 
   independent means of identifying a mesh profile. Since a personal 
   profile provides both a means of specifying an account






Hallam-Baker               December 31, 2015                   [Page 17]

Internet-Draft         Modular Mathematical Mesh               June 2015

   For example, a server configuration file might grant access to Alice 
   as follows.

   mmm:MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ:alice@cryptomesh.org {RWED}

   Mesh profiles are identified using the mmm URI scheme as follows:

   meshuri = "mmm:" fingerprint [ ":" meshid]

4. Application Profiles

   Application profiles store information for use by a particular class 
   of application. A Personal Profile MAY contain more than one 
   application profile of a particular type and a single application 
   profile MAY describe the use of multiple protocols.

   For example a user with multiple email accounts would require a 
   separate Email Application Profile for each account each of which 
   would typically specify connections for SUBMIT and IMAP/POP services 
   and public and private key sets for S/MIME and OpenPGP.

   Application profiles are exchanged in JSON format. The schemas for 
   the individual application profiles will be described in a future 
   document.

4.1. Administration

   The administration application profile is used to administer 
   connection of devices to a Personal Profile and enable the use of 
   particular application profiles on particular devices.

   The public portion of the administration profile is the Personal 
   Profile itself. The private profile contains:

         *  Private Key of the POSK

4.2. Escrow

   The escrow application profile is used to administer escrow of 
   private keys. The escrow profile contains:

         *  Escrow Public Key

         *  Escrow Identifier Encryption Key

4.3. Network Connection

   A network application profile contains information for configuring a 
   network connection. This may include:





Hallam-Baker               December 31, 2015                   [Page 18]

Internet-Draft         Modular Mathematical Mesh               June 2015

         *  Connection data for one or more DNS services

         *  A scope for which the network connection is applied

4.4. Password Manager

   A password manager application profile contains a list of password 
   entries each containing:

         *  The domain(s) for which the entry is to be used [required]

         *  Username [required]

         *  Password [required]

         *  HTTP strict security policy entry for the site [optional]

         *  HTTP Key Pining Security Policy for the site [optional]

         *  Acceptable authentication mechanisms [optional]

   All the entries in the password manager are private with a decryption
   blob for the device keys of each authorized device.

4.5. Authentication

   While the password manager application is currently necessary it is 
   intended that this should be a transitional infrastructure rather 
   than a permanent one.

         *  The domain(s) for which the entry is to be used [optional]

         *  HTTP strict security policy entry for the site [optional]

         *  HTTP Key Pining Security Policy for the site [optional]

         *  Acceptable authentication mechanisms [optional]

   In addition each device connected to an authentication profile has 
   the following device specific attributes:

         *  Authentication credential

4.6. Email

   Under normal circumstances an email application profile enables use 
   of both S/MIME and OpenPGP security formats.

         *  Outbound mail server connection(s) (e.g. SUBMIT)





Hallam-Baker               December 31, 2015                   [Page 19]

Internet-Draft         Modular Mathematical Mesh               June 2015

         *  Inbound mail server connection(s) (e.g. POP3, IMAP4)

         *  Email encryption key (S/MIME) [Public]

         *  Email encryption key (OpenPGP) [Public]

         *  Email decryption key (S/MIME) [Private]

         *  Email decryption key (OpenPGP) [Private]

   In addition each device connected to an email profile has the 
   following device specific attributes

         *  Email authentication credentials (OpenPGP)

         *  Email authentication credentials (S/MIME)

5. Mesh Services

   The Mesh supports four separate protocols:

         Mesh Gateway Service [Gateway]
            Supports operations that create a permanent record in the 
            Gateway log. These include creation, update and management 
            of Profiles.

         Mesh Gateway Request Service [Gateway]
            Supports operations that will only create a permanent record
            in the Gateway log if confirmed by a properly authorized 
            administration device.

         Mesh Query Service [Gateway,Distribution]
            Allows retrieval of information stored in the mesh without 
            creating a record in the Gateway log.

         Mesh Replication Service [Gateway,Distribution]
            Manages replication of closed Mesh logs between nodes.

   The distinction between the two gateway services is that actions 
   performed using the Mesh Gateway Service will be eventually 
   replicated to every node in the mesh. The choice of Mesh node to 
   which a request was originally directed makes no difference after the
   mesh has synchronized. In contrast, actions requested in the Mesh 
   Gateway Request Service are not permanently recorded or synchronized 
   to other nodes. It is therefore essential that all the steps 
   necessary to complete a transaction be directed to the same service.

   The detailed description of the Mesh protocols will be described 
   separately in a future document.





Hallam-Baker               December 31, 2015                   [Page 20]

Internet-Draft         Modular Mathematical Mesh               June 2015

5.1. Mesh Log

   Each mesh gateway node maintains an independent, append only log. 
   Each log is maintained as an incremental sequence of parts. Each part
   is terminated by a signed record containing a digest over all the 
   entries in the current log and a chained digest over the digest of 
   the current log and the chained digest of the previous log.

   Each mesh gateway performs a log rollover operation at frequent 
   intervals. The gateway begins a new log part which becomes the active
   part in which all new transactions are recorded. The gateway then 
   calculates the terminal record for the previously active part and 
   writes it to the log to complete it.

   Note that while this approach is simple and efficient for the mesh 
   gateway, it is not optimized for use by readers attempting to quickly
   verify a single entry in the log. This may be revisited in future 
   versions of the Mesh if warranted.

5.2. Mesh Replication

   At present the Mesh Replication Service has not been implemented. 
   Think NNTP in JSON with transaction records for each gateway node 
   being written to the equivalent of a newsgroup.

   At present mesh services are presented as JSON services over HTTPS.

6. Requirements and Recommendations

   Since the Mesh MAY be used to store keys for use with the highest 
   security levels supported by standards based cryptography and there 
   is no means of distinguishing high security keys from lesser keys, 
   all cryptographic operations employ the highest security level of the
   available standards based cryptographic algorithms. This means use of
   256 bit symmetric keys for encryption and MAC operations and 2048 bit
   RSA. While longer RSA key sizes are available, the security advantage
   they offer is not sufficient to justify use. A transition to use of 
   an ECC public key algorithm is preferred.

6.1. Requirements

   A Mesh profile manager MUST support the following algorithms and data
   formats:

         *  Encryption: AES-256

         *  Digest: SHA-2-512

         *  Public Key Encryption: RSA-2048





Hallam-Baker               December 31, 2015                   [Page 21]

Internet-Draft         Modular Mathematical Mesh               June 2015

         *  Public Key Signature: RSA-2048

         *  Public Key Agreement: DH-2048

         *  PKIX X.509v3 Certificate

         *  JSON (generate, read), JSON-B (read)

6.2. Recommendations

   A Mesh profile manager SHOULD support the following algorithms and 
   data formats:

         *  Encryption: None

         *  Digest: SHA-3-512 [Once published by NIST]

         *  Public Key Encryption: CFRG-448 [When published]

         *  Public Key Signature: CFRG-448 [When published]

         *  JSON-B

7. Security Considerations

   Currently the architecture of the Mesh is in a state of rapid change.
   Users SHOULD not therefore rely on the security considerations set 
   out in this document without first checking to see if the instance of
   the mesh they are connecting to follows the version of the mesh 
   protocols to which they refer.

7.1. Mesh Integrity

   The state of the mesh is fully contained in the append-only logs 
   maintained by each mesh gateway. The mesh management protocols 
   require that each gateway sign their append-only log at regular 
   intervals and validate all data provided by other gateway nodes in 
   the mesh. Thus a mesh gateway node is the only party that can perform
   a record insertion attack that another mesh node can be induced to 
   accept.

   Further, the management of the logs provides complete transparency 
   for addition of entries by the gateway with continuous auditing by 
   every other mesh gateway. Thus it is impossible for one mesh gateway 
   node to defect unless every other gateway node in the mesh is willing
   to collude in the deception.








Hallam-Baker               December 31, 2015                   [Page 22]

Internet-Draft         Modular Mathematical Mesh               June 2015

7.2. Mesh Data Confidentiality

   The Mesh does not provide any confidentiality guarantees as all data 
   stored in the mesh is considered to be public. Thus the mesh cannot 
   be breached by definition but private data may be breached through 
   disclosure of the decryption keys or by use of faulty encryption 
   algorithm.

7.3. Disclosure of Private Key

   Disclosure of the private keys used to secure private data may result
   in disclosure of confidential data. Unencrypted private keys are only
   kept at end point devices. Private key disclosure is bad, avoid.

   Trustworthy computing features preventing/making it difficult to 
   extract keys from a device are highly desirable.

7.4. Denial of Service

   Denial of Service attacks are an important threat that is not 
   currently addressed in the prototype implementation.

   The use of a combination of proof of work and lightweight 
   authentication approaches is anticipated to address this 
   consideration.

7.5. Traffic Analysis

   Mesh transactions SHOULD be considered to be vulnerable to traffic 
   analysis unless a security analysis of a specific mesh instance has 
   been performed to provide evidence to the contrary.

7.6. Covert Channels

   The mesh provides a medium for exchange of end-to-end encrypted data.
   Since the mesh nodes have no means of determining the contents of 
   profile entries, there is no means of restricting use to those 
   approved by the operators. The mesh thus represents a ubiquitous and 
   pervasive covert channel.

   While this situation is not necessarily to be considered a security 
   concern for mesh operators, the resources consumed by such operations
   may be a concern. Since all profiles entered into the mesh are 
   permanently recorded and replicated to every mesh node, use of the 
   mesh for purposes such as covert transfer of streaming video are 
   likely to be a concern.

   The use of resource limiting strategies such as CAPTCHAs, profile 
   size limits and limits on the number of updates individual users are 
   permitted to make in a short time period SHOULD therefore be 
   considered.



Hallam-Baker               December 31, 2015                   [Page 23]

Internet-Draft         Modular Mathematical Mesh               June 2015


7.7. Data Loss

   The risk of data loss is mitigated through a combination of local 
   retention, use of the mesh to provide data persistence and key 
   escrow.

7.8. User Capture

   User capture is the situation where a user of a software service is 
   unable to change software service providers due to unacceptably high 
   switching costs. This puts the user of the service at a severe 
   disadvantage to the provider. While achieving such a circumstance is 
   frequently the objective of many a business plan, such plans almost 
   invariably fail.

   Local capture of Mesh data and the planned mesh replication 
   infrastructure ensure that switching costs for users are never 
   prohibitive. Thus user capture is avoided.

8. IANA Requirements

8.1. Registration of mmm URI Scheme (provisional)

   TBS

8.2. Registration of application/mesh Content Types

   TBS

9. Acknowledgements

   The mesh builds on much prior art in the field.

   As described above, the mesh deployment model consciously follows the
   pattern set by the World Wide Web which was in turn based on 
   observation of the success of earlier innovations such as the micro-
   computer. The purpose for which the Web was designed was to make the 
   universe of information accessible, the killer application for the 
   Web at CERN was the ability to access the telephone directory online.

   The use of append-only logs with chained cryptographic digests was 
   originally proposed by Harber and Stornetta but only popularized 
   through the use in the BitCoin blockchain and the Certificate 
   Transparency log after the patent protection expired.

   The idea of using X.509 to establish a personal PKI hierarchy arose 
   from discussions with Sir Tim Berners-Lee at CERN in 1994. The use of
   fingerprints of public keys was introduced by Phil Zimmerman in PGP.





Hallam-Baker               December 31, 2015                   [Page 24]

Internet-Draft         Modular Mathematical Mesh               June 2015

Author's Address

   Phillip Hallam-Baker
   Comodo Group Inc.

   philliph@comodo.com
















































Hallam-Baker               December 31, 2015                   [Page 25]