idnits 2.17.1 draft-hallambaker-mesh-developer-05.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 (September 18, 2017) is 2406 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 779 -- Looks like a reference, but probably isn't: '0' on line 549 -- Looks like a reference, but probably isn't: '2' on line 550 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 September 18, 2017 5 Expires: March 22, 2018 7 Mathematical Mesh: Reference Implementation 8 draft-hallambaker-mesh-developer-05 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 March 22, 2018. 41 Copyright Notice 43 Copyright (c) 2017 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. Running the Reference Code Examples . . . . . . . . . . . . . 5 68 3.1. Starting the Server . . . . . . . . . . . . . . . . . . . 5 69 3.2. The Profile Manager Wizard . . . . . . . . . . . . . . . 5 70 3.3. The Profile Connection Wizard . . . . . . . . . . . . . . 6 71 4. Platform specific configuration data . . . . . . . . . . . . 6 72 4.1. Windows . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 4.1.1. Private Key Data . . . . . . . . . . . . . . . . . . 6 74 4.1.2. Registry settings . . . . . . . . . . . . . . . . . . 6 75 4.1.3. Profile data files . . . . . . . . . . . . . . . . . 7 76 4.2. OSX and Linux . . . . . . . . . . . . . . . . . . . . . . 7 77 5. Using the Mesh C#/.Net Libraries in an Application . . . . . 7 78 5.1. Portals, Sessions and Clients . . . . . . . . . . . . . . 7 79 5.1.1. MeshSession vs PersonalSession . . . . . . . . . . . 8 80 5.2. Creating a Mesh Session . . . . . . . . . . . . . . . . . 9 81 5.3. Creating a Mesh Session for Testing . . . . . . . . . . . 9 82 5.4. Checking that a Portal Account name is acceptable . . . . 10 83 5.5. Creating a Personal Profile . . . . . . . . . . . . . . . 11 84 5.6. Creating an Offline Escrow Entry . . . . . . . . . . . . 11 85 5.7. Deleting Profile Data . . . . . . . . . . . . . . . . . . 12 86 5.8. Recovering Profile Data . . . . . . . . . . . . . . . . . 12 87 5.9. Connecting a New Device . . . . . . . . . . . . . . . . . 12 88 5.10. Managing Applications . . . . . . . . . . . . . . . . . . 13 89 6. Using other languages . . . . . . . . . . . . . . . . . . . . 14 90 6.1. Lightweight API . . . . . . . . . . . . . . . . . . . . . 14 91 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 14 92 7.1. Reference Implementation . . . . . . . . . . . . . . . . 15 93 7.1.1. Coverage: . . . . . . . . . . . . . . . . . . . . . . 15 94 7.1.2. Licensing . . . . . . . . . . . . . . . . . . . . . . 16 95 7.1.3. Implementation Experience . . . . . . . . . . . . . . 16 96 7.1.4. Contact Info . . . . . . . . . . . . . . . . . . . . 16 98 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 99 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 100 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 101 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 102 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 103 11.2. Informative References . . . . . . . . . . . . . . . . . 17 104 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 17 105 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 107 1. Definitions 109 This section presents the related specifications and standard, the 110 terms that are used as terms of art within the documents and the 111 terms used as requirements language. 113 1.1. Requirements Language 115 This document is not normative and does not contain requirements 116 language 118 1.2. Defined Terms 120 The terms of art used in this document are described in the Mesh 121 Architecture Guide [draft-hallambaker-mesh-architecture] . 123 1.3. Related Specifications 125 The architecture of the Mathematical Mesh is described in the Mesh 126 Architecture Guide [draft-hallambaker-mesh-architecture] . The Mesh 127 documentation set and related specifications are described in this 128 document. 130 1.4. Implementation Status 132 The implementation status of the reference code base is described in 133 the companion document [draft-hallambaker-mesh-developer] . 135 2. Getting the Reference Code and Build Tools 137 The Mesh Reference library was developed using Visual Studio 2017 138 Community Edition [VS2017] using PHB?s Build Tools [PHB2017] 139 extensions. The reference code itself is currently limited to C# 140 libraries. 142 The code should in theory run under other operating systems but this 143 has not been tested recently. 145 Development under different development environments is also possible 146 but would require re-engineering to make use of the line mode 147 versions of the build tools. 149 2.1. Obtaining the Development Environment 151 Visual Studio 2015 Community Edition is currently available at no 152 cost for a wide range of non-commercial development including 153 personal use and development of Open Source software. For full 154 details, please consult the license published by Microsoft. 156 https://www.visualstudio.com/ 158 Figure 1 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 Figure 2 186 The source code for the build tools is available from: 188 https://sourceforge.net/projects/phb-build-tools/ 190 Figure 3 192 2.3. Obtaining the Mesh Source Libraries 194 The Mesh reference library source code is published under an MIT 195 license and is available from: 197 https://sourceforge.net/projects/mathematicalmesh/ 199 Figure 4 201 3. Running the Reference Code Examples 203 The reference code examples are designed to illustrate how the Mesh 204 might be used in an application rather than be standalone tools in 205 their own right. The Mesh is designed to make it each for developers 206 to add security to their own applications rather than providing the 207 applications themselves. 209 3.1. Starting the Server 211 On the Windows platform, the server runs in the context of the 212 platform Web server and must be granted permission to bind to the 213 range of server addresses used using the netsh command. 215 From a command prompt with administrator privileges, run the 216 following command: 218 netsh http add urlacl http:///.well-known/mmm/ 219 \user=\ 221 Figure 5 223 Where is the DNS domain name under which the service is run, is the 224 Windows domain name of the machine and the account name. 226 To start the service from the command line type: 228 servermesh 230 Figure 6 232 The server does not require administration privileges. 234 3.2. The Profile Manager Wizard 236 The profile manager wizard demonstrates functions that are performed 237 on an administration device. These include creating a completely new 238 profile and initial configuration of applications, connecting a 239 device to the profile and recovery of the profile from escrow data. 241 To run the client from the command line, place the executable image 242 in a location that it will be found in the PATH variable and type: 244 meshclient 246 Figure 7 248 3.3. The Profile Connection Wizard 250 The Profile connection wizard demonstrates the much more restricted 251 functionality that would be required in a Mesh connected application 252 and/or a profile manager for a non-administration device. 254 To run the client from the command line, place the executable image 255 in a location that it will be found in the PATH variable and type: 257 meshconnect 259 Figure 8 261 4. Platform specific configuration data 263 4.1. Windows 265 4.1.1. Private Key Data 267 All private key data is stored using the Windows public key store. 268 At minimum, this ensures that private keys are obfuscated and 269 encrypted under the account password to protect the data against 270 casual extraction attacks. On a machine with cryptographic hardware 271 support such as a TPM or HSM, extraction of the private key may be 272 infeasible without physical access to the machine and possibly 273 require sophisticated diagnostic equipment. 275 4.1.2. Registry settings 277 Separate settings are used for production and test code. Test Code 278 should use the Registry Hive: 280 HKEY_CURRENT_USER\SOFTWARE\CryptoMesh 282 Production code should use the hive 284 HKEY_CURRENT_USER\SOFTWARE\MathematicalMesh 286 In either case the sub structure is: 288 Accounts Contains the set of Mesh Portal Accounts for the user. The 289 default value is the account name of the default account. The 290 Name of the each key is a portal account name and the value a 291 REG_SZ entry containing the UDF of the profile master key. 293 PersonalProfiles Contains the set of Mesh Profiles for the user. 294 The default value is the UDF of the default profile master key. 295 The Name of each key is the UDF of the master key and the value a 296 REG_SZ entry containing the file location of the cached copy of 297 the personal profile. 299 ThisDevice Contains the set of Device profiles in the same format as 300 the PersonalProfiles. 302 4.1.3. Profile data files 304 The profile data itself is stored in data files at the location 305 specified in the registry. The files are standard XML files in UTF8 306 encoding. 308 4.2. OSX and Linux 310 [[Not yet implemented, subject to change.] 312 All configuration information is stored in the user directory ~/.mmm 314 Keys are stored in SSH key file format [RFC4716] using the customary 315 name and extension conventions for that application. 317 5. Using the Mesh C#/.Net Libraries in an Application 319 The application ExampleGenerator shows the use of the Mesh in an 320 application using the convenience API. It is the application program 321 used to generate the examples in the reference document. 323 ExampleGenerator implements a client that connects to a remote Web 324 Service, creates new personal profile with an escrow entry with 325 offline recovery codes, attaches applications and other devices, 326 updates an application profile, deletes all the profile data from the 327 local machine and then restores them using the recovery codes and 328 escrow entry. 330 5.1. Portals, Sessions and Clients 332 The libraries are designed to support testing and development use. 333 For this reason, the client side of the libraries is divided into the 334 following main classes: 336 MeshClient Provides a logical connection to a remote or simulated 337 Mesh service. 339 MeshPortal Provides the interface to a Mesh service which may be an 340 actual remote service accessed via a network connection, or local 341 code running in the same process as the client to simulate a Mesh 342 service for testing purposes. 344 MeshMachine Provides an interface to Mesh data stored on the local 345 machine. 347 MeshSession / PersonalSession Provide the high level application 348 interface to the Mesh combining access through the MeshClient and 349 MeshMachine. 351 The relationship between these parts is shown in . The application 352 programmer will typically need only the MeshSession class. 354 The principal classes in the Mesh Client side API. 356 This division makes it possible to test Mesh clients and server 357 implementations in a single process with a single debugger which is 358 usually more convenient than spinning up a separate development 359 session for the client and service. 361 5.1.1. MeshSession vs PersonalSession 363 Most Mesh operations are performed within the context of a specific 364 PersonalProfile registered on the current machine. This context is 365 provided by an instance of the PersonalSession class. 367 An instance of the MeshSession class is used for operations that are 368 not bound to a specific PersonalProfile registered on the machine. 369 These operations are: 371 o Binding a new PersonalProfile to the machine. 373 o Offline key recovery. 375 o Requesting and completing a device connection request from the new 376 device. 378 o Acquiring a PersonalSession instance. 380 5.2. Creating a Mesh Session 382 The primary interface for the application programmer is the 383 MeshSession class. To create a mesh session class, the following 384 steps are required: 386 1. Initialize the Mesh code for the intended platform 388 2. Request a new MeshSession instance. 390 Although C# code is nominally 'write once, run anywhere', this 391 approach does not ensure use of platform specific features such as 392 the Windows registry or protected storage for cryptographic keys. 393 Calling MeshWindows.Initialize() causes the platform specific code 394 for the Windows to be initialized in production mode. Alternatively, 395 calls to MeshLinux.Initialize() or MeshOSX.Initialize() causes the 396 platform specific code for those platforms to be initialized. 398 The code to initialize a production instance of the code is shown in 399 : 401 static MeshSession MeshSession = null; 403 static void ApplicationInit () { 404 MeshWindows.Initialize(); 405 MeshSession = new MeshSession(); 406 } 408 Figure 9 410 If the user has already created a PersonalProfile and connected it to 411 the machine, it will automatically be read from local storage. The 412 instance will automatically create MeshClient instances as required 413 to establish a web service using the default transport (HTTP) to the 414 service as necessary (see ). 416 Connecting to a remote service from a Windows platform. 418 The server implementation is managed in the same fashion. 419 Internally, the MeshService and MeshClient classes are both descended 420 from the same parent. 422 5.3. Creating a Mesh Session for Testing 424 Since the purpose of the ExampleGenerator is to create examples for 425 the documentation, it is not necessary for the JSON Remote Procedure 426 Calls to actually be ?Remote?. Instead the ?Local? Procedure Call 427 mode is used in which the client and server both run in the same 428 process with the client API invoking the server dispatch methods 429 through an interface that performs JSON serialization and 430 deserialization but does not invoke the network transport. 432 Connecting to a direct service for testing. 434 A direct connection to the service provider may be established by 435 either specifying the portal to use in the initialization of 436 MeshSession or by setting the default portal property of the 437 MeshPortal class as is done here . 439 static void DebugApplicationInit () { 441 MeshPortal.Default = new MeshPortalDirect("example.com", 442 "MeshLog.jlog", "PortalLog.jlog"); 444 MeshWindows.Initialize(true); 445 MeshSession = new MeshSession(); 446 MeshSession.EraseTest(); 447 } 449 Figure 10 451 This time, we initialize a specific version of the platform dependent 452 code and specify that it is to be initialized as test code rather 453 than production. This will cause all persistent data stored on the 454 machine (keys, profiles) to be stored in locations marked as test 455 locations. The EraseTest() method causes all data stored in test 456 locations to be erased from the machine, thus ensuring that the test 457 begins from a known state with no results from previous runs. 459 When writing test code, it is frequently useful to create multiple 460 independent MeshSessions to simulate multiple machines. To prevent 461 data written to one machine interfering with another, a new simulated 462 machine is created for each session using the MeshMachineCached class 464 MeshSession = new MeshSession(new MeshMachineCached()); 466 Figure 11 468 5.4. Checking that a Portal Account name is acceptable 470 The user experience is improved if the application indicates whether 471 their choice of portal account name is acceptable or not while they 472 are entering it. The Validate method allows the user's choice of 473 account name to be validated . 475 PersonalProfile PersonalProfile; 476 PersonalSession PersonalSession; 477 OfflineEscrowEntry OfflineEscrowEntry; 479 void DebugCreateProfile () { 480 var Response = MeshSession.Validate("alice@example.com"); 481 if (!Response.Valid) { 482 throw new Exception(); 483 } 484 ... 486 Figure 12 488 The portal address is given in the usual username@domain format, for 489 example alice@example.com. 491 5.5. Creating a Personal Profile 493 Creating a PersonalProfile has two steps: 495 1. Create a DeviceProfile (if necessary) 497 2. Create the PersonalProfile 499 3. Create an account bound to the profile at the portal. 501 These steps are shown in . 503 var Device = MeshSession.CreateDevice(); 504 PersonalProfile = new PersonalProfile( 505 Device.DeviceProfile); 506 PersonalSession = MeshSession.CreateAccount( 507 "alice@example.com", PersonalProfile); 509 Figure 13 511 The application could have overridden the default values of DeviceID 512 and DeviceDescription when creating the device. 514 5.6. Creating an Offline Escrow Entry 516 Having created a potentially valuable profile, we probably want to 517 back it up. To do this, we create an instance of the 518 OfflineEscrowEntry class with the desired quorum and number of shares 519 (2 out of 4) . 521 OfflineEscrowEntry = new OfflineEscrowEntry( 522 PersonalProfile, 2, 4); 523 PersonalSession.Escrow(OfflineEscrowEntry); 525 Figure 14 527 5.7. Deleting Profile Data 529 We can test our escrow parameters by deleting the profile from the 530 current machine using the Delete method . 532 PersonalSession.Delete(); 534 Figure 15 536 5.8. Recovering Profile Data 538 Profile recovery has two steps: 540 1. Reconstruct the shared secret from the recovery shares. 542 2. Recover the profile. 544 In this case our recovery shares are the first and the third key 545 shares we just generated. The Recover method recovers the profile 546 and rebinds it to the existing portal . 548 var RecoveryShares = new KeyShare[] { 549 OfflineEscrowEntry.KeyShares[0], 550 OfflineEscrowEntry.KeyShares[2] }; 552 var Secret = new Secret(RecoveryShares); 553 PersonalSession = MeshSession.Recover( 554 Secret, "alice@example.com"); 555 } 557 Figure 16 559 5.9. Connecting a New Device 561 Device connection involves two devices, the device to be connected 562 and the device used to approve the request. 564 The new device: 566 1. Create a device profile for the new device. 568 2. Request connection to the new device 569 3. Wait for the result. 571 These calls are shown . 573 void RequestConnect (string Address) { 574 var DeviceRegistration = MeshSession.CreateDevice(); 575 var Connect = MeshSession.Connect(DeviceRegistration, 576 Address, out var Authenticator); 577 PersonalSession = Connect.Await(); 578 } 580 Figure 17 582 In a real example, we would want to show the connection 583 authentication code to the user so that they can verify that they are 584 responding to the right request on the approval device. 586 On the approval device, the application 588 1. Requests a list of pending requests using ConnectPending. 590 2. Accepts or Rejects devices using ConnectClose. 592 void AcceptPending () { 594 var Pending = PersonalSession.ConnectPending(); 595 foreach (var Request in Pending.Pending) { 596 var Result = PersonalSession.ConnectClose(Request, 597 ConnectionStatus.Accepted); 598 } 599 } 601 Figure 18 603 5.10. Managing Applications 605 Application profiles are created in the same manner as personal 606 profiles . 608 var PasswordProfile = new PasswordProfile(true); 609 var RegistrationApplication = 610 RegistrationPersonal.Add(PasswordProfile, false); 612 Figure 19 614 Changes to the Application Profile are written to the 615 RegistrationApplication instance and then committed using the 616 Update() method. 618 6. Using other languages 620 If you are building Mesh applications in another language, the least 621 effort approach may be to rewrite the PROTOGEN build tool to target 622 your language. 624 Protogen does support generation of C header files that may be used 625 to drive a parser. If however you are adding Mesh support for an 626 application that already uses JSON based protocols, you might want to 627 edit the generator scripting files to generate code for your existing 628 libraries. 630 6.1. Lightweight API 632 A lightweight API providing the minimal features required to Mesh 633 enable an application is required. Such an API should exclude most 634 account management features: 636 o Creating new Personal Profiles and portal accounts. 638 o Key escrow, recovery 640 o List, accept pending device connection requests 642 This leaves the following features: 644 o Create Device Profile 646 o Request device connection 648 o Get Personal Profile 650 o Get, Update, Application Profile 652 In addition to providing less functionality, an implementation of the 653 lightweight binding is likely to be written in a 'flattened' style 654 rather than the abstracted, object oriented approach of the reference 655 code. 657 7. Implementation Status 659 This section records the status of known implementations of the 660 protocol defined by this specification at the time of posting of this 661 Internet-Draft, and is based on a proposal described in [RFC6892] . 662 The description of implementations in this section is intended to 663 assist the IETF in its decision processes in progressing drafts to 664 RFCs. Please note that the listing of any individual implementation 665 here does not imply endorsement by the IETF. Furthermore, no effort 666 has been spent to verify the information presented here that was 667 supplied by IETF contributors. This is not intended as, and must not 668 be construed to be, a catalog of available implementations or their 669 features. Readers are advised to note that other implementations may 670 exist. 672 According to [RFC6892] , "this will allow reviewers and working 673 groups to assign due consideration to documents that have the benefit 674 of running code, which may serve as evidence of valuable 675 experimentation and feedback that have made the implemented protocols 676 more mature. It is up to the individual working groups to use this 677 information as they see fit". 679 7.1. Reference Implementation 681 Organization: Comodo Group Inc. 683 Implementer: Phillip Hallam-Baker 685 Maturity: Experimental Prototype 687 This implementation was used to produce the reference section and all 688 the examples in this document. Since the conversion of specification 689 to code is automatic, there is a high degree of assurance that the 690 reference implementation is consistent with this document. 692 7.1.1. Coverage: 694 The draft-xx branch describes the code used to create version xx of 695 this document. 697 The main current limitations are that the code only supports RSA key 698 pairs and for ease of development the server does not persist keys 699 across sessions. Nor does the implementation currently support the 700 HTTP payload authentication and encryption layer or make use of TLS. 701 These could be easily fixed. 703 The client and server are implemented as libraries that may be called 704 from a multi-protocol server. A standalone server will be provided 705 in a future release. 707 Only the JSON encoding is currently implemented. The JSON-B, JSON-C, 708 ASN.1 and TLS Schema implementations are all supported by the code 709 generation tool but not currently implemented as the build tool 710 bindings for those encodings have not yet been finalized or 711 documented. 713 The key restrictions for TLS key exchange have not yet been 714 implemented. 716 The code has only been tested on Windows 10 but passed compatibility 717 testing for both Mono and dotNetCore 10 run times which should in 718 theory permit use on Linux and OSX platforms. 720 7.1.2. Licensing 722 The code is released under an MIT License 724 Source code is available from GitHub at 725 https://github.com/hallambaker/Mathematical-Mesh 727 7.1.3. Implementation Experience 729 The implementation and specification documentation were developed in 730 Visual Studio using the PHB Build Tools suite. 732 7.1.4. Contact Info 734 Contact Phillip Hallam-Baker phill@hallambaker.com 736 8. Security Considerations 738 Security Considerations are addressed in the companion document 739 [draft-hallambaker-mesh-architecture] 741 9. IANA Considerations 743 This document specifies no actions for IANA 745 10. Acknowledgements 747 Comodo Group: Egemen Tas, Melhi Abdulhayo?lu, Rob Stradling, Robin 748 Alden. 750 11. References 752 11.1. Normative References 754 [RFC4716] Galbraith, J. and R. Thayer, "The Secure Shell (SSH) 755 Public Key File Format", RFC 4716, DOI 10.17487/RFC4716, 756 November 2006. 758 11.2. Informative References 760 [draft-hallambaker-mesh-architecture] 761 Hallam-Baker, P., "Mathematical Mesh: Architecture", 762 draft-hallambaker-mesh-architecture-03 (work in progress), 763 May 2017. 765 [draft-hallambaker-mesh-developer] 766 Hallam-Baker, P., "Mathematical Mesh: Reference 767 Implementation", draft-hallambaker-mesh-developer-04 (work 768 in progress), September 2017. 770 [PHB2017] "[Reference Not Found!]". 772 [RFC6892] Wilde, E., "The 'describes' Link Relation Type", RFC 6892, 773 DOI 10.17487/RFC6892, March 2013. 775 [VS2017] "[Reference Not Found!]". 777 11.3. URIs 779 [1] http://prismproof.org/Documents/draft-hallambaker-mesh- 780 developer.html 782 Author's Address 784 Phillip Hallam-Baker 785 Comodo Group Inc. 787 Email: philliph@comodo.com