idnits 2.17.1 draft-hallambaker-mesh-developer-08.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 4, 2019) is 1821 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 833 -- Looks like a reference, but probably isn't: '0' on line 610 -- Looks like a reference, but probably isn't: '2' on line 611 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 April 4, 2019 4 Intended status: Informational 5 Expires: October 6, 2019 7 Mathematical Mesh: Reference Implementation 8 draft-hallambaker-mesh-developer-08 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://mathmesh.com/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 6, 2019. 41 Copyright Notice 43 Copyright (c) 2019 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 . . . . . . . . . . . . 6 70 4. Running the Reference Code Examples . . . . . . . . . . . . . 7 71 4.1. Starting the Server . . . . . . . . . . . . . . . . . . . 7 72 4.2. The Profile Manager Wizard . . . . . . . . . . . . . . . 7 73 4.3. The Profile Connection Wizard . . . . . . . . . . . . . . 8 74 5. Platform specific configuration data . . . . . . . . . . . . 8 75 5.1. Windows . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 5.1.1. Private Key Data . . . . . . . . . . . . . . . . . . 8 77 5.1.2. Registry settings . . . . . . . . . . . . . . . . . . 8 78 5.1.3. Profile data files . . . . . . . . . . . . . . . . . 9 79 5.2. OSX and Linux . . . . . . . . . . . . . . . . . . . . . . 9 80 6. Using the Mesh C#/.Net Libraries in an Application . . . . . 9 81 6.1. Portals, Sessions and Clients . . . . . . . . . . . . . . 9 82 6.1.1. MeshSession vs PersonalSession . . . . . . . . . . . 10 83 6.2. Creating a Mesh Session . . . . . . . . . . . . . . . . . 10 84 6.3. Creating a Mesh Session for Testing . . . . . . . . . . . 11 85 6.4. Checking that a Portal Account name is acceptable . . . . 12 86 6.5. Creating a Personal Profile . . . . . . . . . . . . . . . 13 87 6.6. Creating an Offline Escrow Entry . . . . . . . . . . . . 13 88 6.7. Deleting Profile Data . . . . . . . . . . . . . . . . . . 13 89 6.8. Recovering Profile Data . . . . . . . . . . . . . . . . . 13 90 6.9. Connecting a New Device . . . . . . . . . . . . . . . . . 14 91 6.10. Managing Applications . . . . . . . . . . . . . . . . . . 15 92 7. Using other languages . . . . . . . . . . . . . . . . . . . . 15 93 7.1. Lightweight API . . . . . . . . . . . . . . . . . . . . . 15 94 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 16 95 8.1. Reference Implementation . . . . . . . . . . . . . . . . 16 96 8.1.1. Coverage: . . . . . . . . . . . . . . . . . . . . . . 17 97 8.1.2. Licensing . . . . . . . . . . . . . . . . . . . . . . 17 98 8.1.3. Implementation Experience . . . . . . . . . . . . . . 17 99 8.1.4. Contact Info . . . . . . . . . . . . . . . . . . . . 17 100 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 101 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 102 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 103 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 104 12.1. Normative References . . . . . . . . . . . . . . . . . . 18 105 12.2. Informative References . . . . . . . . . . . . . . . . . 18 106 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 18 107 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 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 2.2. Obtaining the Build Tools 162 Over half the code in the reference code library is generated using 163 code generators. These are used to ensure that the specification, 164 examples and reference code are always kept in synchronization. 166 The build tools are published under an MIT License and are available 167 in two forms: 169 As stand-alone tools to be run from the command line. 171 As a VSIX package that integrates into the Visual Studio environment. 173 The source distribution is configured to use the tools integrated 174 into the Visual Studio environment. If development on other 175 platforms is desired, the simplest approach is likely to be to write 176 a tool that reads the Visual Studio configuration files and generates 177 the corresponding files for use with make. 179 The VSIX package is available from the Visual Studio extensions 180 gallery: 182 PHB Code Generation Tools 184 The source code for the build tools is available from: 186 https://sourceforge.net/projects/phb-build-tools/ 188 2.3. Obtaining the Mesh Source Libraries 190 The Mesh reference library source code is published under an MIT 191 license and is available from: 193 https://sourceforge.net/projects/mathematicalmesh/ 195 3. Compiling the Reference Code 197 To compile the code it is necessary to 199 Create a signing key 201 Create batch files for pre and post build tasks 203 3.1. Creating a software signing key 205 The purpose of signing assemblies is so that they can be 206 authenticated during the load process. For this to be secure, it is 207 of course essential that each developer has their own key. 209 To create a software developer signing key, the Visual Studio 'sn' 210 tool is used. To run the tool, start the Visual Studio Developer 211 Console in administrator mode. This requires the following steps: 213 Move to a directory you want to write to. 215 Set the machine to create user based keys 217 Create a new key and write it to a file. 219 Copy the file from the key to a container. 221 Delete the container. 223 Locate the private key file 225 Give permission to use the key. 227 This is of course one of the tasks we would like to automate with the 228 Mesh tools in due course but that presents a bootstrap problem. 230 C:\Windows\System32>cd hallam 232 c:\Users\hallam>sn -m N 234 Microsoft (R) .NET Framework Strong Name Utility Version 4.0.30319.0 235 Copyright (c) Microsoft Corporation. All rights reserved. 237 Key containers are user based 239 c:\Users\hallam>sn -k fred.snk 241 Microsoft (R) .NET Framework Strong Name Utility Version 4.0.30319.0 242 Copyright (c) Microsoft Corporation. All rights reserved. 244 Key pair written to fred.snk 246 c:\Users\hallam>sn -i fred.snk SigningKeyDeveloper 248 Microsoft (R) .NET Framework Strong Name Utility Version 4.0.30319.0 249 Copyright (c) Microsoft Corporation. All rights reserved. 251 Key pair installed into 'SigningKeyDeveloper' 253 c:\Users\hallam>del fred.snk 255 c:\Users\hallam> 257 3.2. Create (dummy) build action files 259 Visual Studio allows projects to specify batch files to be run before 260 and after a project build. Since the actions to be taken are likely 261 to change from developer to developer, these are specified in 262 separate batch files. All that is necessary to build the code 263 without warnings is to specify a set of dummy batch files with the 264 following names and place them somewhere in the command line $PATH 265 environment variable. 267 The files required are: 269 VSPreBuild.bat 271 VSPostBuild.bat 273 VSPostBuildWindows.bat 275 VSPostBuildOSX.bat 277 VSPostBuildLinux.bat 278 The following code will prevent error messages being thrown: 280 @echo off 281 SETLOCAL 282 exit /b 0 284 4. Running the Reference Code Examples 286 The reference code examples are designed to illustrate how the Mesh 287 might be used in an application rather than be standalone tools in 288 their own right. The Mesh is designed to make it each for developers 289 to add security to their own applications rather than providing the 290 applications themselves. 292 4.1. Starting the Server 294 On the Windows platform, the server runs in the context of the 295 platform Web server and must be granted permission to bind to the 296 range of server addresses used using the netsh command. 298 From a command prompt with administrator privileges, run the 299 following command: 301 netsh http add urlacl http:///.well-known/mmm/ 302 \user=\ 304 Where is the DNS domain name under which the service is run, is the 305 Windows domain name of the machine and the account name. 307 To start the service from the command line type: 309 servermesh 311 The server does not require administration privileges. 313 4.2. The Profile Manager Wizard 315 The profile manager wizard demonstrates functions that are performed 316 on an administration device. These include creating a completely new 317 profile and initial configuration of applications, connecting a 318 device to the profile and recovery of the profile from escrow data. 320 To run the client from the command line, place the executable image 321 in a location that it will be found in the PATH variable and type: 323 meshclient 325 4.3. The Profile Connection Wizard 327 The Profile connection wizard demonstrates the much more restricted 328 functionality that would be required in a Mesh connected application 329 and/or a profile manager for a non-administration device. 331 To run the client from the command line, place the executable image 332 in a location that it will be found in the PATH variable and type: 334 meshconnect 336 5. Platform specific configuration data 338 5.1. Windows 340 5.1.1. Private Key Data 342 All private key data is stored using the Windows public key store. 343 At minimum, this ensures that private keys are obfuscated and 344 encrypted under the account password to protect the data against 345 casual extraction attacks. On a machine with cryptographic hardware 346 support such as a TPM or HSM, extraction of the private key may be 347 infeasible without physical access to the machine and possibly 348 require sophisticated diagnostic equipment. 350 5.1.2. Registry settings 352 Separate settings are used for production and test code. Test Code 353 should use the Registry Hive: 355 HKEY_CURRENT_USER\SOFTWARE\CryptoMesh 357 Production code should use the hive 359 HKEY_CURRENT_USER\SOFTWARE\MathematicalMesh 361 In either case the sub structure is: 363 Accounts Contains the set of Mesh Portal Accounts for the user. The 364 default value is the account name of the default account. The 365 Name of the each key is a portal account name and the value a 366 REG_SZ entry containing the UDF of the profile master key. 368 PersonalProfiles Contains the set of Mesh Profiles for the user. 369 The default value is the UDF of the default profile master key. 370 The Name of each key is the UDF of the master key and the value a 371 REG_SZ entry containing the file location of the cached copy of 372 the personal profile. 374 ThisDevice Contains the set of Device profiles in the same format as 375 the PersonalProfiles. 377 5.1.3. Profile data files 379 The profile data itself is stored in data files at the location 380 specified in the registry. The files are standard XML files in UTF8 381 encoding. 383 5.2. OSX and Linux 385 [[Not yet implemented, subject to change.] 387 All configuration information is stored in the user directory ~/.mmm 389 Keys are stored in SSH key file format [RFC4716] using the customary 390 name and extension conventions for that application. 392 6. Using the Mesh C#/.Net Libraries in an Application 394 The application ExampleGenerator shows the use of the Mesh in an 395 application using the convenience API. It is the application program 396 used to generate the examples in the reference document. 398 ExampleGenerator implements a client that connects to a remote Web 399 Service, creates new personal profile with an escrow entry with 400 offline recovery codes, attaches applications and other devices, 401 updates an application profile, deletes all the profile data from the 402 local machine and then restores them using the recovery codes and 403 escrow entry. 405 6.1. Portals, Sessions and Clients 407 The libraries are designed to support testing and development use. 408 For this reason, the client side of the libraries is divided into the 409 following main classes: 411 MeshClient Provides a logical connection to a remote or simulated 412 Mesh service. 414 MeshPortal Provides the interface to a Mesh service which may be an 415 actual remote service accessed via a network connection, or local 416 code running in the same process as the client to simulate a Mesh 417 service for testing purposes. 419 MeshMachine Provides an interface to Mesh data stored on the local 420 machine. 422 MeshSession / PersonalSession Provide the high level application 423 interface to the Mesh combining access through the MeshClient and 424 MeshMachine. 426 The relationship between these parts is shown in . The application 427 programmer will typically need only the MeshSession class. 429 The principal classes in the Mesh Client side API. 431 This division makes it possible to test Mesh clients and server 432 implementations in a single process with a single debugger which is 433 usually more convenient than spinning up a separate development 434 session for the client and service. 436 6.1.1. MeshSession vs PersonalSession 438 Most Mesh operations are performed within the context of a specific 439 PersonalProfile registered on the current machine. This context is 440 provided by an instance of the PersonalSession class. 442 An instance of the MeshSession class is used for operations that are 443 not bound to a specific PersonalProfile registered on the machine. 444 These operations are: 446 o Binding a new PersonalProfile to the machine. 448 o Offline key recovery. 450 o Requesting and completing a device connection request from the new 451 device. 453 o Acquiring a PersonalSession instance. 455 6.2. Creating a Mesh Session 457 The primary interface for the application programmer is the 458 MeshSession class. To create a mesh session class, the following 459 steps are required: 461 1. Initialize the Mesh code for the intended platform 463 2. Request a new MeshSession instance. 465 Although C# code is nominally 'write once, run anywhere', this 466 approach does not ensure use of platform specific features such as 467 the Windows registry or protected storage for cryptographic keys. 468 Calling MeshWindows.Initialize() causes the platform specific code 469 for the Windows to be initialized in production mode. Alternatively, 470 calls to MeshLinux.Initialize() or MeshOSX.Initialize() causes the 471 platform specific code for those platforms to be initialized. 473 The code to initialize a production instance of the code is shown in 474 : 476 static MeshSession MeshSession = null; 478 static void ApplicationInit () { 479 MeshWindows.Initialize(); 480 MeshSession = new MeshSession(); 481 } 483 If the user has already created a PersonalProfile and connected it to 484 the machine, it will automatically be read from local storage. The 485 instance will automatically create MeshClient instances as required 486 to establish a web service using the default transport (HTTP) to the 487 service as necessary (see ). 489 Connecting to a remote service from a Windows platform. 491 The server implementation is managed in the same fashion. 492 Internally, the MeshService and MeshClient classes are both descended 493 from the same parent. 495 6.3. Creating a Mesh Session for Testing 497 Since the purpose of the ExampleGenerator is to create examples for 498 the documentation, it is not necessary for the JSON Remote Procedure 499 Calls to actually be 'Remote'. Instead the 'Local' Procedure Call 500 mode is used in which the client and server both run in the same 501 process with the client API invoking the server dispatch methods 502 through an interface that performs JSON serialization and 503 deserialization but does not invoke the network transport. 505 Connecting to a direct service for testing. 507 A direct connection to the service provider may be established by 508 either specifying the portal to use in the initialization of 509 MeshSession or by setting the default portal property of the 510 MeshPortal class as is done here . 512 static void DebugApplicationInit () { 514 MeshPortal.Default = new MeshPortalDirect("example.com", 515 "MeshLog.jlog", "PortalLog.jlog"); 517 MeshWindows.Initialize(true); 518 MeshSession = new MeshSession(); 519 MeshSession.EraseTest(); 520 } 522 This time, we initialize a specific version of the platform dependent 523 code and specify that it is to be initialized as test code rather 524 than production. This will cause all persistent data stored on the 525 machine (keys, profiles) to be stored in locations marked as test 526 locations. The EraseTest() method causes all data stored in test 527 locations to be erased from the machine, thus ensuring that the test 528 begins from a known state with no results from previous runs. 530 When writing test code, it is frequently useful to create multiple 531 independent MeshSessions to simulate multiple machines. To prevent 532 data written to one machine interfering with another, a new simulated 533 machine is created for each session using the MeshMachineCached class 535 MeshSession = new MeshSession(new MeshMachineCached()); 537 6.4. Checking that a Portal Account name is acceptable 539 The user experience is improved if the application indicates whether 540 their choice of portal account name is acceptable or not while they 541 are entering it. The Validate method allows the user's choice of 542 account name to be validated . 544 PersonalProfile PersonalProfile; 545 PersonalSession PersonalSession; 546 OfflineEscrowEntry OfflineEscrowEntry; 548 void DebugCreateProfile () { 549 var Response = MeshSession.Validate("alice@example.com"); 550 if (!Response.Valid) { 551 throw new Exception(); 552 } 553 ... 555 The portal address is given in the usual username@domain format, for 556 example alice@example.com. 558 6.5. Creating a Personal Profile 560 Creating a PersonalProfile has two steps: 562 1. Create a DeviceProfile (if necessary) 564 2. Create the PersonalProfile 566 3. Create an account bound to the profile at the portal. 568 These steps are shown in . 570 var Device = MeshSession.CreateDevice(); 571 PersonalProfile = new PersonalProfile( 572 Device.DeviceProfile); 573 PersonalSession = MeshSession.CreateAccount( 574 "alice@example.com", PersonalProfile); 576 The application could have overridden the default values of DeviceID 577 and DeviceDescription when creating the device. 579 6.6. Creating an Offline Escrow Entry 581 Having created a potentially valuable profile, we probably want to 582 back it up. To do this, we create an instance of the 583 OfflineEscrowEntry class with the desired quorum and number of shares 584 (2 out of 4) . 586 OfflineEscrowEntry = new OfflineEscrowEntry( 587 PersonalProfile, 2, 4); 588 PersonalSession.Escrow(OfflineEscrowEntry); 590 6.7. Deleting Profile Data 592 We can test our escrow parameters by deleting the profile from the 593 current machine using the Delete method . 595 PersonalSession.Delete(); 597 6.8. Recovering Profile Data 599 Profile recovery has two steps: 601 1. Reconstruct the shared secret from the recovery shares. 603 2. Recover the profile. 605 In this case our recovery shares are the first and the third key 606 shares we just generated. The Recover method recovers the profile 607 and rebinds it to the existing portal . 609 var RecoveryShares = new KeyShare[] { 610 OfflineEscrowEntry.KeyShares[0], 611 OfflineEscrowEntry.KeyShares[2] }; 613 var Secret = new Secret(RecoveryShares); 614 PersonalSession = MeshSession.Recover( 615 Secret, "alice@example.com"); 616 } 618 6.9. Connecting a New Device 620 Device connection involves two devices, the device to be connected 621 and the device used to approve the request. 623 The new device: 625 1. Create a device profile for the new device. 627 2. Request connection to the new device 629 3. Wait for the result. 631 These calls are shown . 633 void RequestConnect (string Address) { 634 var DeviceRegistration = MeshSession.CreateDevice(); 635 var Connect = MeshSession.Connect(DeviceRegistration, 636 Address, out var Authenticator); 637 PersonalSession = Connect.Await(); 638 } 640 In a real example, we would want to show the connection 641 authentication code to the user so that they can verify that they are 642 responding to the right request on the approval device. 644 On the approval device, the application 646 1. Requests a list of pending requests using ConnectPending. 648 2. Accepts or Rejects devices using ConnectClose. 650 void AcceptPending () { 652 var Pending = PersonalSession.ConnectPending(); 653 foreach (var Request in Pending.Pending) { 654 var Result = PersonalSession.ConnectClose(Request, 655 ConnectionStatus.Accepted); 656 } 657 } 659 6.10. Managing Applications 661 Application profiles are created in the same manner as personal 662 profiles . 664 var PasswordProfile = new PasswordProfile(true); 665 var RegistrationApplication = 666 RegistrationPersonal.Add(PasswordProfile, false); 668 Changes to the Application Profile are written to the 669 RegistrationApplication instance and then committed using the 670 Update() method. 672 7. Using other languages 674 If you are building Mesh applications in another language, the least 675 effort approach may be to rewrite the PROTOGEN build tool to target 676 your language. 678 Protogen does support generation of C header files that may be used 679 to drive a parser. If however you are adding Mesh support for an 680 application that already uses JSON based protocols, you might want to 681 edit the generator scripting files to generate code for your existing 682 libraries. 684 7.1. Lightweight API 686 A lightweight API providing the minimal features required to Mesh 687 enable an application is required. Such an API should exclude most 688 account management features: 690 o Creating new Personal Profiles and portal accounts. 692 o Key escrow, recovery 694 o List, accept pending device connection requests 696 This leaves the following features: 698 o Create Device Profile 700 o Request device connection 702 o Get Personal Profile 704 o Get, Update, Application Profile 706 In addition to providing less functionality, an implementation of the 707 lightweight binding is likely to be written in a 'flattened' style 708 rather than the abstracted, object oriented approach of the reference 709 code. 711 8. Implementation Status 713 This section records the status of known implementations of the 714 protocol defined by this specification at the time of posting of this 715 Internet-Draft, and is based on a proposal described in [RFC6892] . 716 The description of implementations in this section is intended to 717 assist the IETF in its decision processes in progressing drafts to 718 RFCs. Please note that the listing of any individual implementation 719 here does not imply endorsement by the IETF. Furthermore, no effort 720 has been spent to verify the information presented here that was 721 supplied by IETF contributors. This is not intended as, and must not 722 be construed to be, a catalog of available implementations or their 723 features. Readers are advised to note that other implementations may 724 exist. 726 According to [RFC6892] , "this will allow reviewers and working 727 groups to assign due consideration to documents that have the benefit 728 of running code, which may serve as evidence of valuable 729 experimentation and feedback that have made the implemented protocols 730 more mature. It is up to the individual working groups to use this 731 information as they see fit". 733 8.1. Reference Implementation 735 Organization: Comodo Group Inc. 737 Implementer: Phillip Hallam-Baker 739 Maturity: Experimental Prototype 741 This implementation was used to produce the reference section and all 742 the examples in this document. Since the conversion of specification 743 to code is automatic, there is a high degree of assurance that the 744 reference implementation is consistent with this document. 746 8.1.1. Coverage: 748 The draft-xx branch describes the code used to create version xx of 749 this document. 751 The main current limitations are that the code only supports RSA key 752 pairs and for ease of development the server does not persist keys 753 across sessions. Nor does the implementation currently support the 754 HTTP payload authentication and encryption layer or make use of TLS. 755 These could be easily fixed. 757 The client and server are implemented as libraries that may be called 758 from a multi-protocol server. A standalone server will be provided 759 in a future release. 761 Only the JSON encoding is currently implemented. The JSON-B, JSON-C, 762 ASN.1 and TLS Schema implementations are all supported by the code 763 generation tool but not currently implemented as the build tool 764 bindings for those encodings have not yet been finalized or 765 documented. 767 The key restrictions for TLS key exchange have not yet been 768 implemented. 770 The code has only been tested on Windows 10 but passed compatibility 771 testing for both Mono and dotNetCore 2.0 run times which should in 772 theory permit use on Linux and OSX platforms. 774 8.1.2. Licensing 776 The code is released under an MIT License 778 Source code is available from GitHub at 779 https://github.com/hallambaker/Mathematical-Mesh 781 8.1.3. Implementation Experience 783 The implementation and specification documentation were developed in 784 Visual Studio using the PHB Build Tools suite. 786 8.1.4. Contact Info 788 Contact Phillip Hallam-Baker phill@hallambaker.com 790 9. Security Considerations 792 Security Considerations are addressed in the companion document 793 [draft-hallambaker-mesh-architecture] 795 10. IANA Considerations 797 This document specifies no actions for IANA 799 11. Acknowledgements 801 Comodo Group: Egemen Tas, Melhi Abdulhayo?lu, Rob Stradling, Robin 802 Alden. 804 12. References 806 12.1. Normative References 808 [RFC4716] Galbraith, J. and R. Thayer, "The Secure Shell (SSH) 809 Public Key File Format", RFC 4716, DOI 10.17487/RFC4716, 810 November 2006. 812 12.2. Informative References 814 [draft-hallambaker-mesh-architecture] 815 Hallam-Baker, P., "Mathematical Mesh Part I: Architecture 816 Guide", draft-hallambaker-mesh-architecture-06 (work in 817 progress), August 2018. 819 [draft-hallambaker-mesh-developer] 820 Hallam-Baker, P., "Mathematical Mesh: Reference 821 Implementation", draft-hallambaker-mesh-developer-07 (work 822 in progress), April 2018. 824 [PHB2017] "[Reference Not Found!]". 826 [RFC6892] Wilde, E., "The 'describes' Link Relation Type", RFC 6892, 827 DOI 10.17487/RFC6892, March 2013. 829 [VS2017] "[Reference Not Found!]". 831 12.3. URIs 833 [1] http://mathmesh.com/Documents/draft-hallambaker-mesh- 834 developer.html 836 Author's Address 838 Phillip Hallam-Baker 840 Email: phill@hallambaker.com