idnits 2.17.1 draft-hallambaker-mesh-developer-10.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 document seems to lack an Authors' Addresses Section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (27 July 2020) is 1362 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 612 -- Looks like a reference, but probably isn't: '2' on line 613 Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. M. Hallam-Baker 3 Internet-Draft 27 July 2020 4 Intended status: Informational 5 Expires: 28 January 2021 7 Mathematical Mesh: Reference Implementation 8 draft-hallambaker-mesh-developer-10 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. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 28 January 2021. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. 51 Table of Contents 53 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 55 1.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 3 56 1.3. Related Specifications . . . . . . . . . . . . . . . . . 3 57 1.4. Implementation Status . . . . . . . . . . . . . . . . . . 3 58 2. Getting the Reference Code and Build Tools . . . . . . . . . 3 59 2.1. Obtaining the Development Environment . . . . . . . . . . 4 60 2.2. Obtaining the Build Tools . . . . . . . . . . . . . . . . 4 61 2.3. Obtaining the Mesh Source Libraries . . . . . . . . . . . 4 62 3. Compiling the Reference Code . . . . . . . . . . . . . . . . 5 63 3.1. Creating a software signing key . . . . . . . . . . . . . 5 64 3.2. Create (dummy) build action files . . . . . . . . . . . . 6 65 4. Running the Reference Code Examples . . . . . . . . . . . . . 7 66 4.1. Starting the Server . . . . . . . . . . . . . . . . . . . 7 67 4.2. The Profile Manager Wizard . . . . . . . . . . . . . . . 7 68 4.3. The Profile Connection Wizard . . . . . . . . . . . . . . 8 69 5. Platform specific configuration data . . . . . . . . . . . . 8 70 5.1. Windows . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 5.1.1. Private Key Data . . . . . . . . . . . . . . . . . . 8 72 5.1.2. Registry settings . . . . . . . . . . . . . . . . . . 8 73 5.1.3. Profile data files . . . . . . . . . . . . . . . . . 9 74 5.2. OSX and Linux . . . . . . . . . . . . . . . . . . . . . . 9 75 6. Using the Mesh C#/.Net Libraries in an Application . . . . . 9 76 6.1. Portals, Sessions and Clients . . . . . . . . . . . . . . 9 77 6.1.1. MeshSession vs PersonalSession . . . . . . . . . . . 10 78 6.2. Creating a Mesh Session . . . . . . . . . . . . . . . . . 10 79 6.3. Creating a Mesh Session for Testing . . . . . . . . . . . 11 80 6.4. Checking that a Portal Account name is acceptable . . . . 12 81 6.5. Creating a Personal Profile . . . . . . . . . . . . . . . 13 82 6.6. Creating an Offline Escrow Entry . . . . . . . . . . . . 13 83 6.7. Deleting Profile Data . . . . . . . . . . . . . . . . . . 13 84 6.8. Recovering Profile Data . . . . . . . . . . . . . . . . . 13 85 6.9. Connecting a New Device . . . . . . . . . . . . . . . . . 14 86 6.10. Managing Applications . . . . . . . . . . . . . . . . . . 15 87 7. Using other languages . . . . . . . . . . . . . . . . . . . . 15 88 7.1. Lightweight API . . . . . . . . . . . . . . . . . . . . . 15 89 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 16 90 8.1. Reference Implementation . . . . . . . . . . . . . . . . 16 91 8.1.1. Coverage: . . . . . . . . . . . . . . . . . . . . . . 17 92 8.1.2. Licensing . . . . . . . . . . . . . . . . . . . . . . 17 93 8.1.3. Implementation Experience . . . . . . . . . . . . . . 17 94 8.1.4. Contact Info . . . . . . . . . . . . . . . . . . . . 17 95 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 96 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 97 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 98 12. Normative References . . . . . . . . . . . . . . . . . . . . 18 99 13. Informative References . . . . . . . . . . . . . . . . . . . 18 101 1. Definitions 103 This section presents the related specifications and standard, the 104 terms that are used as terms of art within the documents and the 105 terms used as requirements language. 107 1.1. Requirements Language 109 This document is not normative and does not contain requirements 110 language 112 1.2. Defined Terms 114 The terms of art used in this document are described in the _Mesh 115 Architecture Guide_ [draft-hallambaker-mesh-architecture]. 117 1.3. Related Specifications 119 The architecture of the Mathematical Mesh is described in the _Mesh 120 Architecture Guide_ [draft-hallambaker-mesh-architecture]. The Mesh 121 documentation set and related specifications are described in this 122 document. 124 1.4. Implementation Status 126 The implementation status of the reference code base is described in 127 the companion document [draft-hallambaker-mesh-developer]. 129 2. Getting the Reference Code and Build Tools 131 The Mesh Reference library was developed using Visual Studio 2017 132 Community Edition [VS2017] using PHB's Build Tools [PHB2017] 133 extensions. The reference code itself is currently limited to C# 134 libraries. 136 The code should in theory run under other operating systems but this 137 has not been tested recently. 139 Development under different development environments is also possible 140 but would require re-engineering to make use of the line mode 141 versions of the build tools. 143 2.1. Obtaining the Development Environment 145 Visual Studio 2017 Community Edition is currently available at no 146 cost for a wide range of non-commercial development including 147 personal use and development of Open Source software. For full 148 details, please consult the license published by Microsoft. 150 https://www.visualstudio.com/ 152 2.2. Obtaining the Build Tools 154 Over half the code in the reference code library is generated using 155 code generators. These are used to ensure that the specification, 156 examples and reference code are always kept in synchronization. 158 The build tools are published under an MIT License and are available 159 in two forms: 161 As stand-alone tools to be run from the command line. 163 As a VSIX package that integrates into the Visual Studio environment. 165 The source distribution is configured to use the tools integrated 166 into the Visual Studio environment. If development on other 167 platforms is desired, the simplest approach is likely to be to write 168 a tool that reads the Visual Studio configuration files and generates 169 the corresponding files for use with make. 171 The VSIX package is available from the Visual Studio extensions 172 gallery: 174 PHB Code Generation Tools 176 The source code for the build tools is available from: 178 https://sourceforge.net/projects/phb-build-tools/ 180 2.3. Obtaining the Mesh Source Libraries 182 The Mesh reference library source code is published under an MIT 183 license and is available from: 185 https://sourceforge.net/projects/mathematicalmesh/ 187 3. Compiling the Reference Code 189 To compile the code it is necessary to 191 Create a signing key 193 Create batch files for pre and post build tasks 195 3.1. Creating a software signing key 197 The purpose of signing assemblies is so that they can be 198 authenticated during the load process. For this to be secure, it is 199 of course essential that each developer has their own key. 201 To create a software developer signing key, the Visual Studio 'sn' 202 tool is used. To run the tool, start the Visual Studio Developer 203 Console _in administrator mode_. This requires the following steps: 205 Move to a directory you want to write to. 207 Set the machine to create user based keys 209 Create a new key and write it to a file. 211 Copy the file from the key to a container. 213 Delete the container. 215 Locate the private key file 217 Give permission to use the key. 219 This is of course one of the tasks we would like to automate with the 220 Mesh tools in due course but that presents a bootstrap problem. 222 C:\Windows\System32>cd hallam 224 c:\Users\hallam>sn -m N 226 Microsoft (R) .NET Framework Strong Name Utility Version 4.0.30319.0 227 Copyright (c) Microsoft Corporation. All rights reserved. 229 Key containers are user based 231 c:\Users\hallam>sn -k fred.snk 233 Microsoft (R) .NET Framework Strong Name Utility Version 4.0.30319.0 234 Copyright (c) Microsoft Corporation. All rights reserved. 236 Key pair written to fred.snk 238 c:\Users\hallam>sn -i fred.snk SigningKeyDeveloper 240 Microsoft (R) .NET Framework Strong Name Utility Version 4.0.30319.0 241 Copyright (c) Microsoft Corporation. All rights reserved. 243 Key pair installed into 'SigningKeyDeveloper' 245 c:\Users\hallam>del fred.snk 247 c:\Users\hallam> 249 3.2. Create (dummy) build action files 251 Visual Studio allows projects to specify batch files to be run before 252 and after a project build. Since the actions to be taken are likely 253 to change from developer to developer, these are specified in 254 separate batch files. All that is necessary to build the code 255 without warnings is to specify a set of dummy batch files with the 256 following names and place them somewhere in the command line $PATH 257 environment variable. 259 The files required are: 261 VSPreBuild.bat 263 VSPostBuild.bat 265 VSPostBuildWindows.bat 267 VSPostBuildOSX.bat 269 VSPostBuildLinux.bat 270 The following code will prevent error messages being thrown: 272 @echo off 273 SETLOCAL 274 exit /b 0 276 4. Running the Reference Code Examples 278 The reference code examples are designed to illustrate how the Mesh 279 might be used in an application rather than be standalone tools in 280 their own right. The Mesh is designed to make it each for developers 281 to add security to their own applications rather than providing the 282 applications themselves. 284 4.1. Starting the Server 286 On the Windows platform, the server runs in the context of the 287 platform Web server and must be granted permission to bind to the 288 range of server addresses used using the netsh command. 290 From a command prompt with administrator privileges, run the 291 following command: 293 netsh http add urlacl http:///.well-known/mmm/ 294 \user=\ 296 Where is the DNS domain name under which the service is run, 297 is the Windows domain name of the machine and the 298 account name. 300 To start the service from the command line type: 302 servermesh 304 The server does not require administration privileges. 306 4.2. The Profile Manager Wizard 308 The profile manager wizard demonstrates functions that are performed 309 on an administration device. These include creating a completely new 310 profile and initial configuration of applications, connecting a 311 device to the profile and recovery of the profile from escrow data. 313 To run the client from the command line, place the executable image 314 in a location that it will be found in the PATH variable and type: 316 meshclient 318 4.3. The Profile Connection Wizard 320 The Profile connection wizard demonstrates the much more restricted 321 functionality that would be required in a Mesh connected application 322 and/or a profile manager for a non-administration device. 324 To run the client from the command line, place the executable image 325 in a location that it will be found in the PATH variable and type: 327 meshconnect 329 5. Platform specific configuration data 331 5.1. Windows 333 5.1.1. Private Key Data 335 All private key data is stored using the Windows public key store. 336 At minimum, this ensures that private keys are obfuscated and 337 encrypted under the account password to protect the data against 338 casual extraction attacks. On a machine with cryptographic hardware 339 support such as a TPM or HSM, extraction of the private key may be 340 infeasible without physical access to the machine and possibly 341 require sophisticated diagnostic equipment. 343 5.1.2. Registry settings 345 Separate settings are used for production and test code. Test Code 346 should use the Registry Hive: 348 HKEY_CURRENT_USER\SOFTWARE\CryptoMesh 350 Production code should use the hive 352 HKEY_CURRENT_USER\SOFTWARE\MathematicalMesh 354 In either case the sub structure is: 356 Accounts Contains the set of Mesh Portal Accounts for the user. The 357 default value is the account name of the default account. The 358 Name of the each key is a portal account name and the value a 359 REG_SZ entry containing the UDF of the profile master key. 361 PersonalProfiles Contains the set of Mesh Profiles for the user. 362 The default value is the UDF of the default profile master key. 363 The Name of each key is the UDF of the master key and the value a 364 REG_SZ entry containing the file location of the cached copy of 365 the personal profile. 367 ThisDevice Contains the set of Device profiles in the same format as 368 the PersonalProfiles. 370 5.1.3. Profile data files 372 The profile data itself is stored in data files at the location 373 specified in the registry. The files are standard XML files in UTF8 374 encoding. 376 5.2. OSX and Linux 378 [[Not yet implemented, subject to change.] 380 All configuration information is stored in the user directory ~/.mmm 382 Keys are stored in SSH key file format [RFC4716] using the customary 383 name and extension conventions for that application. 385 6. Using the Mesh C#/.Net Libraries in an Application 387 The application "ExampleGenerator" shows the use of the Mesh in an 388 application using the convenience API. It is the application program 389 used to generate the examples in the reference document. 391 "ExampleGenerator" implements a client that connects to a remote Web 392 Service, creates new personal profile with an escrow entry with 393 offline recovery codes, attaches applications and other devices, 394 updates an application profile, deletes all the profile data from the 395 local machine and then restores them using the recovery codes and 396 escrow entry. 398 6.1. Portals, Sessions and Clients 400 The libraries are designed to support testing and development use. 401 For this reason, the client side of the libraries is divided into the 402 following main classes: 404 "MeshClient" Provides a logical connection to a remote or simulated 405 Mesh service. 407 "MeshPortal" Provides the interface to a Mesh service which may be 408 an actual remote service accessed via a network connection, or 409 local code running in the same process as the client to simulate a 410 Mesh service for testing purposes. 412 "MeshMachine" Provides an interface to Mesh data stored on the local 413 machine. 415 "MeshSession" / "PersonalSession" Provide the high-level application 416 interface to the Mesh combining access through the MeshClient and 417 MeshMachine. 419 The relationship between these parts is shown below. The application 420 programmer will typically need only the MeshSession class. 422 (Artwork only available as svg: No external link available, see 423 draft-hallambaker-mesh-developer-10.html for artwork.) 425 Figure 1 427 This division makes it possible to test Mesh clients and server 428 implementations in a single process with a single debugger which is 429 usually more convenient than spinning up a separate development 430 session for the client and service. 432 6.1.1. MeshSession vs PersonalSession 434 Most Mesh operations are performed within the context of a specific 435 PersonalProfile registered on the current machine. This context is 436 provided by an instance of the PersonalSession class. 438 An instance of the MeshSession class is used for operations that are 439 not bound to a specific PersonalProfile registered on the machine. 440 These operations are: 442 * Binding a new PersonalProfile to the machine. 444 * Offline key recovery. 446 * Requesting and completing a device connection request from the new 447 device. 449 * Acquiring a PersonalSession instance. 451 6.2. Creating a Mesh Session 453 The primary interface for the application programmer is the 454 "MeshSession" class. To create a mesh session class, the following 455 steps are required: 457 0. Initialize the Mesh code for the intended platform 459 1. Request a new "MeshSession" instance. 461 Although C# code is nominally 'write once, run anywhere', this 462 approach does not ensure use of platform specific features such as 463 the Windows registry or protected storage for cryptographic keys. 464 Calling "MeshWindows.Initialize()" causes the platform specific code 465 for the Windows to be initialized in production mode. Alternatively, 466 calls to MeshLinux.Initialize() or MeshOSX.Initialize() causes the 467 platform specific code for those platforms to be initialized. 469 The code to initialize a production instance of the code is: 471 static MeshSession MeshSession = null; 473 static void ApplicationInit () { 474 MeshWindows.Initialize(); 475 MeshSession = new MeshSession(); 476 } 478 If the user has already created a "PersonalProfile" and connected it 479 to the machine, it will automatically be read from local storage. 480 The instance will automatically create "MeshClient" instances as 481 required to establish a web service using the default transport 482 (HTTP) to the service as necessary. 484 (Artwork only available as svg: No external link available, see 485 draft-hallambaker-mesh-developer-10.html for artwork.) 487 Figure 2 489 The server implementation is managed in the same fashion. 490 Internally, the "MeshService" and "MeshClient" classes are both 491 descended from the same parent. 493 6.3. Creating a Mesh Session for Testing 495 Since the purpose of the "ExampleGenerator" is to create examples for 496 the documentation, it is not necessary for the JSON Remote Procedure 497 Calls to actually be 'Remote'. Instead the 'Local' Procedure Call 498 mode is used in which the client and server both run in the same 499 process with the client API invoking the server dispatch methods 500 through an interface that performs JSON serialization and 501 deserialization but does not invoke the network transport. 503 (Artwork only available as svg: No external link available, see 504 draft-hallambaker-mesh-developer-10.html for artwork.) 506 Figure 3 508 A direct connection to the service provider may be established by 509 either specifying the portal to use in the initialization of 510 MeshSession or by setting the default portal property of the 511 MeshPortal class as is done here. 513 static void DebugApplicationInit () { 515 MeshPortal.Default = new MeshPortalDirect("example.com", 516 "MeshLog.jlog", "PortalLog.jlog"); 518 MeshWindows.Initialize(true); 519 MeshSession = new MeshSession(); 520 MeshSession.EraseTest(); 521 } 523 This time, we initialize a specific version of the platform dependent 524 code and specify that it is to be initialized as test code rather 525 than production. This will cause all persistent data stored on the 526 machine (keys, profiles) to be stored in locations marked as test 527 locations. The EraseTest() method causes all data stored in test 528 locations to be erased from the machine, thus ensuring that the test 529 begins from a known state with no results from previous runs. 531 When writing test code, it is frequently useful to create multiple 532 independent "MeshSessions" to simulate multiple machines. To prevent 533 data written to one machine interfering with another, a new simulated 534 machine is created for each session using the "MeshMachineCached" 535 class. 537 MeshSession = new MeshSession(new MeshMachineCached()); 539 6.4. Checking that a Portal Account name is acceptable 541 The user experience is improved if the application indicates whether 542 their choice of portal account name is acceptable or not while they 543 are entering it. The Validate method allows the user's choice of 544 account name to be validated. 546 PersonalProfile PersonalProfile; 547 PersonalSession PersonalSession; 548 OfflineEscrowEntry OfflineEscrowEntry; 550 void DebugCreateProfile () { 551 var Response = MeshSession.Validate("alice@example.com"); 552 if (!Response.Valid) { 553 throw new Exception(); 554 } 555 ... 557 The portal address is given in the usual "username@domain" format, 558 for example "alice@example.com". 560 6.5. Creating a Personal Profile 562 Creating a PersonalProfile has two steps: 564 0. Create a "DeviceProfile" (if necessary) 566 1. Create the "PersonalProfile" 568 2. Create an account bound to the profile at the portal. 570 These steps are shown in. 572 var Device = MeshSession.CreateDevice(); 573 PersonalProfile = new PersonalProfile( 574 Device.DeviceProfile); 575 PersonalSession = MeshSession.CreateAccount( 576 "alice@example.com", PersonalProfile); 578 The application could have overridden the default values of 579 "DeviceID" and "DeviceDescription" when creating the device. 581 6.6. Creating an Offline Escrow Entry 583 Having created a potentially valuable profile, we probably want to 584 back it up. To do this, we create an instance of the 585 "OfflineEscrowEntry" class with the desired quorum and number of 586 shares (2 out of 4). 588 OfflineEscrowEntry = new OfflineEscrowEntry( 589 PersonalProfile, 2, 4); 590 PersonalSession.Escrow(OfflineEscrowEntry); 592 6.7. Deleting Profile Data 594 We can test our escrow parameters by deleting the profile from the 595 current machine using the "Delete" method. 597 PersonalSession.Delete(); 599 6.8. Recovering Profile Data 601 Profile recovery has two steps: 603 0. Reconstruct the shared secret from the recovery shares. 605 1. Recover the profile. 607 In this case our recovery shares are the first and the third key 608 shares we just generated. The Recover method recovers the profile 609 and rebinds it to the existing portal. 611 var RecoveryShares = new KeyShare[] { 612 OfflineEscrowEntry.KeyShares[0], 613 OfflineEscrowEntry.KeyShares[2] }; 615 var Secret = new Secret(RecoveryShares); 616 PersonalSession = MeshSession.Recover( 617 Secret, "alice@example.com"); 618 } 620 6.9. Connecting a New Device 622 Device connection involves two devices, the device to be connected 623 and the device used to approve the request. 625 The new device: 627 0. Create a device profile for the new device. 629 1. Request connection to the new device 631 2. Wait for the result. 633 These calls are shown. 635 void RequestConnect (string Address) { 636 var DeviceRegistration = MeshSession.CreateDevice(); 637 var Connect = MeshSession.Connect(DeviceRegistration, 638 Address, out var Authenticator); 639 PersonalSession = Connect.Await(); 640 } 642 In a real example, we would want to show the connection 643 authentication code to the user so that they can verify that they are 644 responding to the right request on the approval device. 646 On the approval device, the application 648 0. Requests a list of pending requests using "ConnectPending". 650 1. Accepts or Rejects devices using "ConnectClose". 652 void AcceptPending () { 654 var Pending = PersonalSession.ConnectPending(); 655 foreach (var Request in Pending.Pending) { 656 var Result = PersonalSession.ConnectClose(Request, 657 ConnectionStatus.Accepted); 658 } 659 } 661 6.10. Managing Applications 663 Application profiles are created in the same manner as personal 664 profiles. 666 var PasswordProfile = new PasswordProfile(true); 667 var RegistrationApplication = 668 RegistrationPersonal.Add(PasswordProfile, false); 670 Changes to the Application Profile are written to the 671 "RegistrationApplication" instance and then committed using the 672 "Update()" method. 674 7. Using other languages 676 If you are building Mesh applications in another language, the least 677 effort approach may be to rewrite the PROTOGEN build tool to target 678 your language. 680 Protogen does support generation of C header files that may be used 681 to drive a parser. If however you are adding Mesh support for an 682 application that already uses JSON based protocols, you might want to 683 edit the generator scripting files to generate code for your existing 684 libraries. 686 7.1. Lightweight API 688 A lightweight API providing the minimal features required to Mesh 689 enable an application is required. Such an API should exclude most 690 account management features: 692 * Creating new Personal Profiles and portal accounts. 694 * Key escrow, recovery 696 * List, accept pending device connection requests 698 This leaves the following features: 700 * Create Device Profile 702 * Request device connection 704 * Get Personal Profile 706 * Get, Update, Application Profile 708 In addition to providing less functionality, an implementation of the 709 lightweight binding is likely to be written in a 'flattened' style 710 rather than the abstracted, object oriented approach of the reference 711 code. 713 8. Implementation Status 715 This section records the status of known implementations of the 716 protocol defined by this specification at the time of posting of this 717 Internet-Draft, and is based on a proposal described in [RFC6892]. 718 The description of implementations in this section is intended to 719 assist the IETF in its decision processes in progressing drafts to 720 RFCs. Please note that the listing of any individual implementation 721 here does not imply endorsement by the IETF. Furthermore, no effort 722 has been spent to verify the information presented here that was 723 supplied by IETF contributors. This is not intended as, and must not 724 be construed to be, a catalog of available implementations or their 725 features. Readers are advised to note that other implementations may 726 exist. 728 According to [RFC6892], "this will allow reviewers and working groups 729 to assign due consideration to documents that have the benefit of 730 running code, which may serve as evidence of valuable experimentation 731 and feedback that have made the implemented protocols more mature. 732 It is up to the individual working groups to use this information as 733 they see fit". 735 8.1. Reference Implementation 737 Organization: Threshold Secrets LLC. 739 Implementer: Phillip Hallam-Baker 741 Maturity: Experimental Prototype 743 This implementation was used to produce the reference section and all 744 the examples in this document. Since the conversion of specification 745 to code is automatic, there is a high degree of assurance that the 746 reference implementation is consistent with this document. 748 8.1.1. Coverage: 750 The draft-xx branch describes the code used to create version xx of 751 this document. 753 The main current limitations are that the code only supports RSA key 754 pairs and for ease of development the server does not persist keys 755 across sessions. Nor does the implementation currently support the 756 HTTP payload authentication and encryption layer or make use of TLS. 757 These could be easily fixed. 759 The client and server are implemented as libraries that may be called 760 from a multi-protocol server. A standalone server will be provided 761 in a future release. 763 Only the JSON encoding is currently implemented. The JSON-B, JSON-C, 764 ASN.1 and TLS Schema implementations are all supported by the code 765 generation tool but not currently implemented as the build tool 766 bindings for those encodings have not yet been finalized or 767 documented. 769 The key restrictions for TLS key exchange have not yet been 770 implemented. 772 The code has only been tested on Windows 10 but passed compatibility 773 testing for both Mono and dotNetCore 2.0 run times which should in 774 theory permit use on Linux and OSX platforms. 776 8.1.2. Licensing 778 The code is released under an MIT License 780 Source code is available from GitHub at 781 https://github.com/hallambaker/Mathematical-Mesh 783 8.1.3. Implementation Experience 785 The implementation and specification documentation were developed in 786 Visual Studio using the PHB Build Tools suite. 788 8.1.4. Contact Info 790 Contact Phillip Hallam-Baker phill@hallambaker.com 792 9. Security Considerations 794 Security Considerations are addressed in the companion document 795 [draft-hallambaker-mesh-architecture] 797 10. IANA Considerations 799 This document specifies no actions for IANA 801 11. Acknowledgements 803 Comodo Group: Egemen Tas, Melhi Abdulhayo?lu, Rob Stradling, Robin 804 Alden. 806 12. 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 13. Informative References 814 [draft-hallambaker-mesh-architecture] 815 Hallam-Baker, P., "Mathematical Mesh 3.0 Part I: 816 Architecture Guide", Work in Progress, Internet-Draft, 817 draft-hallambaker-mesh-architecture-13, 9 March 2020, 818 . 821 [draft-hallambaker-mesh-developer] 822 Hallam-Baker, P., "Mathematical Mesh: Reference 823 Implementation", Work in Progress, Internet-Draft, draft- 824 hallambaker-mesh-developer-09, 23 October 2019, 825 . 828 [PHB2017] "[Reference Not Found!]". 830 [RFC6892] Wilde, E., "The 'describes' Link Relation Type", RFC 6892, 831 DOI 10.17487/RFC6892, March 2013, 832 . 834 [VS2017] "[Reference Not Found!]".