idnits 2.17.1 draft-hallambaker-mesh-developer-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 10, 2018) is 2201 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 1070 -- Looks like a reference, but probably isn't: '0' on line 782 -- Looks like a reference, but probably isn't: '2' on line 786 Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hallam-Baker 3 Internet-Draft Comodo Group Inc. 4 Intended status: Informational April 10, 2018 5 Expires: October 12, 2018 7 Mathematical Mesh: Reference Implementation 8 draft-hallambaker-mesh-developer-06 10 Abstract 12 The Mathematical Mesh ?The Mesh? is an end-to-end secure 13 infrastructure that facilitates the exchange of configuration and 14 credential data between multiple user devices. 16 This document describes the Mesh reference code and how to install, 17 run and make use of it in applications. It does not form a part of 18 the Mesh specifications and is not normative. 20 This document is also available online at 21 http://prismproof.org/Documents/draft-hallambaker-mesh-developer.html 22 [1] . 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on October 12, 2018. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 60 1.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 3 61 1.3. Related Specifications . . . . . . . . . . . . . . . . . 3 62 1.4. Implementation Status . . . . . . . . . . . . . . . . . . 3 63 2. Getting the Reference Code and Build Tools . . . . . . . . . 3 64 2.1. Obtaining the Development Environment . . . . . . . . . . 4 65 2.2. Obtaining the Build Tools . . . . . . . . . . . . . . . . 4 66 2.3. Obtaining the Mesh Source Libraries . . . . . . . . . . . 5 67 3. Compiling the Reference Code . . . . . . . . . . . . . . . . 5 68 3.1. Creating a software signing key . . . . . . . . . . . . . 5 69 3.2. Create (dummy) build action files . . . . . . . . . . . . 8 70 4. Running the Reference Code Examples . . . . . . . . . . . . . 9 71 4.1. Starting the Server . . . . . . . . . . . . . . . . . . . 9 72 4.2. The Profile Manager Wizard . . . . . . . . . . . . . . . 10 73 4.3. The Profile Connection Wizard . . . . . . . . . . . . . . 10 74 5. Platform specific configuration data . . . . . . . . . . . . 10 75 5.1. Windows . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 5.1.1. Private Key Data . . . . . . . . . . . . . . . . . . 10 77 5.1.2. Registry settings . . . . . . . . . . . . . . . . . . 10 78 5.1.3. Profile data files . . . . . . . . . . . . . . . . . 11 79 5.2. OSX and Linux . . . . . . . . . . . . . . . . . . . . . . 11 80 6. Using the Mesh C#/.Net Libraries in an Application . . . . . 11 81 6.1. Portals, Sessions and Clients . . . . . . . . . . . . . . 12 82 6.1.1. MeshSession vs PersonalSession . . . . . . . . . . . 12 83 6.2. Creating a Mesh Session . . . . . . . . . . . . . . . . . 13 84 6.3. Creating a Mesh Session for Testing . . . . . . . . . . . 14 85 6.4. Checking that a Portal Account name is acceptable . . . . 16 86 6.5. Creating a Personal Profile . . . . . . . . . . . . . . . 17 87 6.6. Creating an Offline Escrow Entry . . . . . . . . . . . . 18 88 6.7. Deleting Profile Data . . . . . . . . . . . . . . . . . . 18 89 6.8. Recovering Profile Data . . . . . . . . . . . . . . . . . 18 90 6.9. Connecting a New Device . . . . . . . . . . . . . . . . . 19 91 6.10. Managing Applications . . . . . . . . . . . . . . . . . . 21 92 7. Using other languages . . . . . . . . . . . . . . . . . . . . 22 93 7.1. Lightweight API . . . . . . . . . . . . . . . . . . . . . 22 94 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 22 95 8.1. Reference Implementation . . . . . . . . . . . . . . . . 23 96 8.1.1. Coverage: . . . . . . . . . . . . . . . . . . . . . . 23 97 8.1.2. Licensing . . . . . . . . . . . . . . . . . . . . . . 24 98 8.1.3. Implementation Experience . . . . . . . . . . . . . . 24 99 8.1.4. Contact Info . . . . . . . . . . . . . . . . . . . . 24 100 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 101 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 102 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 103 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 104 12.1. Normative References . . . . . . . . . . . . . . . . . . 24 105 12.2. Informative References . . . . . . . . . . . . . . . . . 25 106 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 25 107 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25 109 1. Definitions 111 This section presents the related specifications and standard, the 112 terms that are used as terms of art within the documents and the 113 terms used as requirements language. 115 1.1. Requirements Language 117 This document is not normative and does not contain requirements 118 language 120 1.2. Defined Terms 122 The terms of art used in this document are described in the Mesh 123 Architecture Guide [draft-hallambaker-mesh-architecture] . 125 1.3. Related Specifications 127 The architecture of the Mathematical Mesh is described in the Mesh 128 Architecture Guide [draft-hallambaker-mesh-architecture] . The Mesh 129 documentation set and related specifications are described in this 130 document. 132 1.4. Implementation Status 134 The implementation status of the reference code base is described in 135 the companion document [draft-hallambaker-mesh-developer] . 137 2. Getting the Reference Code and Build Tools 139 The Mesh Reference library was developed using Visual Studio 2017 140 Community Edition [VS2017] using PHB?s Build Tools [PHB2017] 141 extensions. The reference code itself is currently limited to C# 142 libraries. 144 The code should in theory run under other operating systems but this 145 has not been tested recently. 147 Development under different development environments is also possible 148 but would require re-engineering to make use of the line mode 149 versions of the build tools. 151 2.1. Obtaining the Development Environment 153 Visual Studio 2017 Community Edition is currently available at no 154 cost for a wide range of non-commercial development including 155 personal use and development of Open Source software. For full 156 details, please consult the license published by Microsoft. 158 https://www.visualstudio.com/ 160 Figure 1 162 2.2. Obtaining the Build Tools 164 Over half the code in the reference code library is generated using 165 code generators. These are used to ensure that the specification, 166 examples and reference code are always kept in synchronization. 168 The build tools are published under an MIT License and are available 169 in two forms: 171 As stand-alone tools to be run from the command line. 173 As a VSIX package that integrates into the Visual Studio environment. 175 The source distribution is configured to use the tools integrated 176 into the Visual Studio environment. If development on other 177 platforms is desired, the simplest approach is likely to be to write 178 a tool that reads the Visual Studio configuration files and generates 179 the corresponding files for use with make. 181 The VSIX package is available from the Visual Studio extensions 182 gallery: 184 PHB Code Generation Tools 186 Figure 2 188 The source code for the build tools is available from: 190 https://sourceforge.net/projects/phb-build-tools/ 192 Figure 3 194 2.3. Obtaining the Mesh Source Libraries 196 The Mesh reference library source code is published under an MIT 197 license and is available from: 199 https://sourceforge.net/projects/mathematicalmesh/ 201 Figure 4 203 3. Compiling the Reference Code 205 To compile the code it is necessary to 207 Create a signing key 209 Create batch files for pre and post build tasks 211 3.1. Creating a software signing key 213 The purpose of signing assemblies is so that they can be 214 authenticated during the load process. For this to be secure, it is 215 of course essential that each developer has their own key. 217 To create a software developer signing key, the Visual Studio 'sn' 218 tool is used. To run the tool, start the Visual Studio Developer 219 Console in administrator mode. This requires the following steps: 221 Move to a directory you want to write to. 223 Set the machine to create user based keys 225 Create a new key and write it to a file. 227 Copy the file from the key to a container. 229 Delete the container. 231 Locate the private key file 233 Give permission to use the key. 235 This is of course one of the tasks we would like to automate with the 236 Mesh tools in due course but that presents a bootstrap problem. 238 C:\Windows\System32>cd hallam 240 Figure 5 242 Figure 6 244 c:\Users\hallam>sn -m N 246 Figure 7 248 Figure 8 250 Microsoft (R) .NET Framework Strong Name Utility Version 4.0.30319.0 252 Figure 9 254 Copyright (c) Microsoft Corporation. All rights reserved. 256 Figure 10 258 Figure 11 260 Key containers are user based 262 Figure 12 264 Figure 13 266 c:\Users\hallam>sn -k fred.snk 268 Figure 14 270 Figure 15 272 Microsoft (R) .NET Framework Strong Name Utility Version 4.0.30319.0 274 Figure 16 276 Copyright (c) Microsoft Corporation. All rights reserved. 278 Figure 17 280 Figure 18 282 Key pair written to fred.snk 284 Figure 19 286 Figure 20 288 c:\Users\hallam>sn -i fred.snk SigningKeyDeveloper 290 Figure 21 292 Figure 22 294 Microsoft (R) .NET Framework Strong Name Utility Version 4.0.30319.0 296 Figure 23 298 Copyright (c) Microsoft Corporation. All rights reserved. 300 Figure 24 302 Figure 25 304 Key pair installed into 'SigningKeyDeveloper' 306 Figure 26 308 Figure 27 310 c:\Users\hallam>del fred.snk 312 Figure 28 314 Figure 29 316 c:\Users\hallam> 318 Figure 30 320 3.2. Create (dummy) build action files 322 Visual Studio allows projects to specify batch files to be run before 323 and after a project build. Since the actions to be taken are likely 324 to change from developer to developer, these are specified in 325 separate batch files. All that is necessary to build the code 326 without warnings is to specify a set of dummy batch files with the 327 following names and place them somewhere in the command line $PATH 328 environment variable. 330 The files required are: 332 VSPreBuild.bat 334 VSPostBuild.bat 336 VSPostBuildWindows.bat 338 VSPostBuildOSX.bat 340 VSPostBuildLinux.bat 342 The following code will prevent error messages being thrown: 344 @echo off 346 Figure 31 348 SETLOCAL 350 Figure 32 352 exit /b 0 354 Figure 33 356 4. Running the Reference Code Examples 358 The reference code examples are designed to illustrate how the Mesh 359 might be used in an application rather than be standalone tools in 360 their own right. The Mesh is designed to make it each for developers 361 to add security to their own applications rather than providing the 362 applications themselves. 364 4.1. Starting the Server 366 On the Windows platform, the server runs in the context of the 367 platform Web server and must be granted permission to bind to the 368 range of server addresses used using the netsh command. 370 From a command prompt with administrator privileges, run the 371 following command: 373 netsh http add urlacl http:///.well-known/mmm/ 374 \user=\ 376 Figure 34 378 Where is the DNS domain name under which the service is run, is the 379 Windows domain name of the machine and the account name. 381 To start the service from the command line type: 383 servermesh 385 Figure 35 387 The server does not require administration privileges. 389 4.2. The Profile Manager Wizard 391 The profile manager wizard demonstrates functions that are performed 392 on an administration device. These include creating a completely new 393 profile and initial configuration of applications, connecting a 394 device to the profile and recovery of the profile from escrow data. 396 To run the client from the command line, place the executable image 397 in a location that it will be found in the PATH variable and type: 399 meshclient 401 Figure 36 403 4.3. The Profile Connection Wizard 405 The Profile connection wizard demonstrates the much more restricted 406 functionality that would be required in a Mesh connected application 407 and/or a profile manager for a non-administration device. 409 To run the client from the command line, place the executable image 410 in a location that it will be found in the PATH variable and type: 412 meshconnect 414 Figure 37 416 5. Platform specific configuration data 418 5.1. Windows 420 5.1.1. Private Key Data 422 All private key data is stored using the Windows public key store. 423 At minimum, this ensures that private keys are obfuscated and 424 encrypted under the account password to protect the data against 425 casual extraction attacks. On a machine with cryptographic hardware 426 support such as a TPM or HSM, extraction of the private key may be 427 infeasible without physical access to the machine and possibly 428 require sophisticated diagnostic equipment. 430 5.1.2. Registry settings 432 Separate settings are used for production and test code. Test Code 433 should use the Registry Hive: 435 HKEY_CURRENT_USER\SOFTWARE\CryptoMesh 436 Production code should use the hive 438 HKEY_CURRENT_USER\SOFTWARE\MathematicalMesh 440 In either case the sub structure is: 442 Accounts Contains the set of Mesh Portal Accounts for the user. The 443 default value is the account name of the default account. The 444 Name of the each key is a portal account name and the value a 445 REG_SZ entry containing the UDF of the profile master key. 447 PersonalProfiles Contains the set of Mesh Profiles for the user. 448 The default value is the UDF of the default profile master key. 449 The Name of each key is the UDF of the master key and the value a 450 REG_SZ entry containing the file location of the cached copy of 451 the personal profile. 453 ThisDevice Contains the set of Device profiles in the same format as 454 the PersonalProfiles. 456 5.1.3. Profile data files 458 The profile data itself is stored in data files at the location 459 specified in the registry. The files are standard XML files in UTF8 460 encoding. 462 5.2. OSX and Linux 464 [[Not yet implemented, subject to change.] 466 All configuration information is stored in the user directory ~/.mmm 468 Keys are stored in SSH key file format [RFC4716] using the customary 469 name and extension conventions for that application. 471 6. Using the Mesh C#/.Net Libraries in an Application 473 The application ExampleGenerator shows the use of the Mesh in an 474 application using the convenience API. It is the application program 475 used to generate the examples in the reference document. 477 ExampleGenerator implements a client that connects to a remote Web 478 Service, creates new personal profile with an escrow entry with 479 offline recovery codes, attaches applications and other devices, 480 updates an application profile, deletes all the profile data from the 481 local machine and then restores them using the recovery codes and 482 escrow entry. 484 6.1. Portals, Sessions and Clients 486 The libraries are designed to support testing and development use. 487 For this reason, the client side of the libraries is divided into the 488 following main classes: 490 MeshClient Provides a logical connection to a remote or simulated 491 Mesh service. 493 MeshPortal Provides the interface to a Mesh service which may be an 494 actual remote service accessed via a network connection, or local 495 code running in the same process as the client to simulate a Mesh 496 service for testing purposes. 498 MeshMachine Provides an interface to Mesh data stored on the local 499 machine. 501 MeshSession / PersonalSession Provide the high level application 502 interface to the Mesh combining access through the MeshClient and 503 MeshMachine. 505 The relationship between these parts is shown in . The application 506 programmer will typically need only the MeshSession class. 508 The principal classes in the Mesh Client side API. 510 This division makes it possible to test Mesh clients and server 511 implementations in a single process with a single debugger which is 512 usually more convenient than spinning up a separate development 513 session for the client and service. 515 6.1.1. MeshSession vs PersonalSession 517 Most Mesh operations are performed within the context of a specific 518 PersonalProfile registered on the current machine. This context is 519 provided by an instance of the PersonalSession class. 521 An instance of the MeshSession class is used for operations that are 522 not bound to a specific PersonalProfile registered on the machine. 523 These operations are: 525 o Binding a new PersonalProfile to the machine. 527 o Offline key recovery. 529 o Requesting and completing a device connection request from the new 530 device. 532 o Acquiring a PersonalSession instance. 534 6.2. Creating a Mesh Session 536 The primary interface for the application programmer is the 537 MeshSession class. To create a mesh session class, the following 538 steps are required: 540 1. Initialize the Mesh code for the intended platform 542 2. Request a new MeshSession instance. 544 Although C# code is nominally 'write once, run anywhere', this 545 approach does not ensure use of platform specific features such as 546 the Windows registry or protected storage for cryptographic keys. 547 Calling MeshWindows.Initialize() causes the platform specific code 548 for the Windows to be initialized in production mode. Alternatively, 549 calls to MeshLinux.Initialize() or MeshOSX.Initialize() causes the 550 platform specific code for those platforms to be initialized. 552 The code to initialize a production instance of the code is shown in 553 : 555 static MeshSession MeshSession = null; 557 Figure 38 559 Figure 39 561 static void ApplicationInit () { 563 Figure 40 565 MeshWindows.Initialize(); 567 Figure 41 569 MeshSession = new MeshSession(); 571 Figure 42 573 } 575 Figure 43 577 If the user has already created a PersonalProfile and connected it to 578 the machine, it will automatically be read from local storage. The 579 instance will automatically create MeshClient instances as required 580 to establish a web service using the default transport (HTTP) to the 581 service as necessary (see ). 583 Connecting to a remote service from a Windows platform. 585 The server implementation is managed in the same fashion. 586 Internally, the MeshService and MeshClient classes are both descended 587 from the same parent. 589 6.3. Creating a Mesh Session for Testing 591 Since the purpose of the ExampleGenerator is to create examples for 592 the documentation, it is not necessary for the JSON Remote Procedure 593 Calls to actually be ?Remote?. Instead the ?Local? Procedure Call 594 mode is used in which the client and server both run in the same 595 process with the client API invoking the server dispatch methods 596 through an interface that performs JSON serialization and 597 deserialization but does not invoke the network transport. 599 Connecting to a direct service for testing. 601 A direct connection to the service provider may be established by 602 either specifying the portal to use in the initialization of 603 MeshSession or by setting the default portal property of the 604 MeshPortal class as is done here . 606 static void DebugApplicationInit () { 608 Figure 44 610 Figure 45 612 MeshPortal.Default = new MeshPortalDirect("example.com", 614 Figure 46 616 "MeshLog.jlog", "PortalLog.jlog"); 618 Figure 47 620 Figure 48 622 MeshWindows.Initialize(true); 624 Figure 49 626 MeshSession = new MeshSession(); 628 Figure 50 630 MeshSession.EraseTest(); 632 Figure 51 634 } 636 Figure 52 638 This time, we initialize a specific version of the platform dependent 639 code and specify that it is to be initialized as test code rather 640 than production. This will cause all persistent data stored on the 641 machine (keys, profiles) to be stored in locations marked as test 642 locations. The EraseTest() method causes all data stored in test 643 locations to be erased from the machine, thus ensuring that the test 644 begins from a known state with no results from previous runs. 646 When writing test code, it is frequently useful to create multiple 647 independent MeshSessions to simulate multiple machines. To prevent 648 data written to one machine interfering with another, a new simulated 649 machine is created for each session using the MeshMachineCached class 651 MeshSession = new MeshSession(new MeshMachineCached()); 653 Figure 53 655 6.4. Checking that a Portal Account name is acceptable 657 The user experience is improved if the application indicates whether 658 their choice of portal account name is acceptable or not while they 659 are entering it. The Validate method allows the user's choice of 660 account name to be validated . 662 PersonalProfile PersonalProfile; 664 Figure 54 666 PersonalSession PersonalSession; 668 Figure 55 670 OfflineEscrowEntry OfflineEscrowEntry; 672 Figure 56 674 Figure 57 676 void DebugCreateProfile () { 678 Figure 58 680 var Response = MeshSession.Validate("alice@example.com"); 682 Figure 59 684 if (!Response.Valid) { 686 Figure 60 688 throw new Exception(); 690 Figure 61 692 } 694 Figure 62 696 ... 698 Figure 63 700 The portal address is given in the usual username@domain format, for 701 example alice@example.com. 703 6.5. Creating a Personal Profile 705 Creating a PersonalProfile has two steps: 707 1. Create a DeviceProfile (if necessary) 709 2. Create the PersonalProfile 711 3. Create an account bound to the profile at the portal. 713 These steps are shown in . 715 var Device = MeshSession.CreateDevice(); 717 Figure 64 719 PersonalProfile = new PersonalProfile( 721 Figure 65 723 Device.DeviceProfile); 725 Figure 66 727 PersonalSession = MeshSession.CreateAccount( 729 Figure 67 731 "alice@example.com", PersonalProfile); 733 Figure 68 735 The application could have overridden the default values of DeviceID 736 and DeviceDescription when creating the device. 738 6.6. Creating an Offline Escrow Entry 740 Having created a potentially valuable profile, we probably want to 741 back it up. To do this, we create an instance of the 742 OfflineEscrowEntry class with the desired quorum and number of shares 743 (2 out of 4) . 745 OfflineEscrowEntry = new OfflineEscrowEntry( 747 Figure 69 749 PersonalProfile, 2, 4); 751 Figure 70 753 PersonalSession.Escrow(OfflineEscrowEntry); 755 Figure 71 757 6.7. Deleting Profile Data 759 We can test our escrow parameters by deleting the profile from the 760 current machine using the Delete method . 762 PersonalSession.Delete(); 764 Figure 72 766 6.8. Recovering Profile Data 768 Profile recovery has two steps: 770 1. Reconstruct the shared secret from the recovery shares. 772 2. Recover the profile. 774 In this case our recovery shares are the first and the third key 775 shares we just generated. The Recover method recovers the profile 776 and rebinds it to the existing portal . 778 var RecoveryShares = new KeyShare[] { 780 Figure 73 782 OfflineEscrowEntry.KeyShares[0], 784 Figure 74 786 OfflineEscrowEntry.KeyShares[2] }; 788 Figure 75 790 Figure 76 792 var Secret = new Secret(RecoveryShares); 794 Figure 77 796 PersonalSession = MeshSession.Recover( 798 Figure 78 800 Secret, "alice@example.com"); 802 Figure 79 804 } 806 Figure 80 808 6.9. Connecting a New Device 810 Device connection involves two devices, the device to be connected 811 and the device used to approve the request. 813 The new device: 815 1. Create a device profile for the new device. 817 2. Request connection to the new device 819 3. Wait for the result. 821 These calls are shown . 823 void RequestConnect (string Address) { 825 Figure 81 827 var DeviceRegistration = MeshSession.CreateDevice(); 829 Figure 82 831 var Connect = MeshSession.Connect(DeviceRegistration, 833 Figure 83 835 Address, out var Authenticator); 837 Figure 84 839 PersonalSession = Connect.Await(); 841 Figure 85 843 } 845 Figure 86 847 In a real example, we would want to show the connection 848 authentication code to the user so that they can verify that they are 849 responding to the right request on the approval device. 851 On the approval device, the application 853 1. Requests a list of pending requests using ConnectPending. 855 2. Accepts or Rejects devices using ConnectClose. 857 void AcceptPending () { 859 Figure 87 861 Figure 88 863 var Pending = PersonalSession.ConnectPending(); 865 Figure 89 867 foreach (var Request in Pending.Pending) { 869 Figure 90 871 var Result = PersonalSession.ConnectClose(Request, 873 Figure 91 875 ConnectionStatus.Accepted); 877 Figure 92 879 } 881 Figure 93 883 } 885 Figure 94 887 6.10. Managing Applications 889 Application profiles are created in the same manner as personal 890 profiles . 892 var PasswordProfile = new PasswordProfile(true); 894 Figure 95 896 var RegistrationApplication = 898 Figure 96 900 RegistrationPersonal.Add(PasswordProfile, false); 902 Figure 97 904 Changes to the Application Profile are written to the 905 RegistrationApplication instance and then committed using the 906 Update() method. 908 7. Using other languages 910 If you are building Mesh applications in another language, the least 911 effort approach may be to rewrite the PROTOGEN build tool to target 912 your language. 914 Protogen does support generation of C header files that may be used 915 to drive a parser. If however you are adding Mesh support for an 916 application that already uses JSON based protocols, you might want to 917 edit the generator scripting files to generate code for your existing 918 libraries. 920 7.1. Lightweight API 922 A lightweight API providing the minimal features required to Mesh 923 enable an application is required. Such an API should exclude most 924 account management features: 926 o Creating new Personal Profiles and portal accounts. 928 o Key escrow, recovery 930 o List, accept pending device connection requests 932 This leaves the following features: 934 o Create Device Profile 936 o Request device connection 938 o Get Personal Profile 940 o Get, Update, Application Profile 942 In addition to providing less functionality, an implementation of the 943 lightweight binding is likely to be written in a 'flattened' style 944 rather than the abstracted, object oriented approach of the reference 945 code. 947 8. Implementation Status 949 This section records the status of known implementations of the 950 protocol defined by this specification at the time of posting of this 951 Internet-Draft, and is based on a proposal described in [RFC6892] . 953 The description of implementations in this section is intended to 954 assist the IETF in its decision processes in progressing drafts to 955 RFCs. Please note that the listing of any individual implementation 956 here does not imply endorsement by the IETF. Furthermore, no effort 957 has been spent to verify the information presented here that was 958 supplied by IETF contributors. This is not intended as, and must not 959 be construed to be, a catalog of available implementations or their 960 features. Readers are advised to note that other implementations may 961 exist. 963 According to [RFC6892] , "this will allow reviewers and working 964 groups to assign due consideration to documents that have the benefit 965 of running code, which may serve as evidence of valuable 966 experimentation and feedback that have made the implemented protocols 967 more mature. It is up to the individual working groups to use this 968 information as they see fit". 970 8.1. Reference Implementation 972 Organization: Comodo Group Inc. 974 Implementer: Phillip Hallam-Baker 976 Maturity: Experimental Prototype 978 This implementation was used to produce the reference section and all 979 the examples in this document. Since the conversion of specification 980 to code is automatic, there is a high degree of assurance that the 981 reference implementation is consistent with this document. 983 8.1.1. Coverage: 985 The draft-xx branch describes the code used to create version xx of 986 this document. 988 The main current limitations are that the code only supports RSA key 989 pairs and for ease of development the server does not persist keys 990 across sessions. Nor does the implementation currently support the 991 HTTP payload authentication and encryption layer or make use of TLS. 992 These could be easily fixed. 994 The client and server are implemented as libraries that may be called 995 from a multi-protocol server. A standalone server will be provided 996 in a future release. 998 Only the JSON encoding is currently implemented. The JSON-B, JSON-C, 999 ASN.1 and TLS Schema implementations are all supported by the code 1000 generation tool but not currently implemented as the build tool 1001 bindings for those encodings have not yet been finalized or 1002 documented. 1004 The key restrictions for TLS key exchange have not yet been 1005 implemented. 1007 The code has only been tested on Windows 10 but passed compatibility 1008 testing for both Mono and dotNetCore 2.0 run times which should in 1009 theory permit use on Linux and OSX platforms. 1011 8.1.2. Licensing 1013 The code is released under an MIT License 1015 Source code is available from GitHub at 1016 https://github.com/hallambaker/Mathematical-Mesh 1018 8.1.3. Implementation Experience 1020 The implementation and specification documentation were developed in 1021 Visual Studio using the PHB Build Tools suite. 1023 8.1.4. Contact Info 1025 Contact Phillip Hallam-Baker phill@hallambaker.com 1027 9. Security Considerations 1029 Security Considerations are addressed in the companion document 1030 [draft-hallambaker-mesh-architecture] 1032 10. IANA Considerations 1034 This document specifies no actions for IANA 1036 11. Acknowledgements 1038 Comodo Group: Egemen Tas, Melhi Abdulhayo?lu, Rob Stradling, Robin 1039 Alden. 1041 12. References 1043 12.1. Normative References 1045 [RFC4716] Galbraith, J. and R. Thayer, "The Secure Shell (SSH) 1046 Public Key File Format", RFC 4716, DOI 10.17487/RFC4716, 1047 November 2006. 1049 12.2. Informative References 1051 [draft-hallambaker-mesh-architecture] 1052 Hallam-Baker, P., "Mathematical Mesh: Architecture", 1053 draft-hallambaker-mesh-architecture-04 (work in progress), 1054 September 2017. 1056 [draft-hallambaker-mesh-developer] 1057 Hallam-Baker, P., "Mathematical Mesh: Reference 1058 Implementation", draft-hallambaker-mesh-developer-05 (work 1059 in progress), September 2017. 1061 [PHB2017] "[Reference Not Found!]". 1063 [RFC6892] Wilde, E., "The 'describes' Link Relation Type", RFC 6892, 1064 DOI 10.17487/RFC6892, March 2013. 1066 [VS2017] "[Reference Not Found!]". 1068 12.3. URIs 1070 [1] http://prismproof.org/Documents/draft-hallambaker-mesh- 1071 developer.html 1073 Author's Address 1075 Phillip Hallam-Baker 1076 Comodo Group Inc. 1078 Email: philliph@comodo.com