idnits 2.17.1 draft-hallambaker-mesh-advanced-00.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 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 (August 31, 2018) is 2064 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 867 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 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 August 31, 2018 5 Expires: March 4, 2019 7 Mathematical Mesh Part III: Advanced Cryptographic Services 8 draft-hallambaker-mesh-advanced-00 10 Abstract 12 The Mathematical Mesh ?The Mesh? is an infrastructure that 13 facilitates the exchange of configuration and credential data between 14 multiple user devices and provides end-to-end security. This 15 document describes the advanced encryption services supported by the 16 Mesh. 18 This document is also available online at 19 http://mathmesh.com/Documents/draft-hallambaker-mesh-advanced.html 20 [1] . 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on March 4, 2019. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 59 2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 3 60 2.3. Related Specifications . . . . . . . . . . . . . . . . . 3 61 2.4. Implementation Status . . . . . . . . . . . . . . . . . . 3 62 3. Secret Splitting . . . . . . . . . . . . . . . . . . . . . . 3 63 3.1. Example: Securing a recovery record . . . . . . . . . . . 4 64 4. Key Co-Generation . . . . . . . . . . . . . . . . . . . . . . 5 65 4.1. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 6 66 4.1.1. Application to Elliptic Curve systems . . . . . . . . 7 67 4.2. Implementation for Ed25519 and Ed 448 . . . . . . . . . . 7 68 4.3. Example: Provisioning the Confirmation Service . . . . . 8 69 5. Recryption . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 5.1. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 10 71 5.2. Implementation . . . . . . . . . . . . . . . . . . . . . 11 72 5.2.1. Group Creation . . . . . . . . . . . . . . . . . . . 12 73 5.2.2. Provisioning a Member . . . . . . . . . . . . . . . . 12 74 5.2.3. Message Encryption and Decryption . . . . . . . . . . 13 75 5.3. Example: Messaging group . . . . . . . . . . . . . . . . 13 76 6. Quantum Resistant Signatures. . . . . . . . . . . . . . . . . 15 77 6.1. Example: Creating a Quantum Resistant Signature 78 Fingerprint . . . . . . . . . . . . . . . . . . . . . . . 16 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 81 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 82 10. Appendix A: Prime Values for Secret Sharing . . . . . . . . . 17 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 84 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 85 11.2. Informative References . . . . . . . . . . . . . . . . . 18 86 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 19 87 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 89 1. Introduction 91 One of the core goals of the Mesh is to move the state of the art in 92 commercial cryptography beyond that achieved in the 1990s when PKIX, 93 S/MIME and OpenPGP were first developed. While each of these 94 infrastructures and protocols has been subject to incremental 95 improvement, none has seen widespread adoption of new cryptographic 96 approaches. 98 This document describes the application of four technologies which 99 have been discussed in the cryptographic literature for many decades 100 but have not (yet) been applied to standards-based network protocols: 102 o Secret Splitting 104 o Recryption 106 o Key Co-Generation 108 o Quantum Resistant Signatures. 110 2. Definitions 112 This section presents the related specifications and standard, the 113 terms that are used as terms of art within the documents and the 114 terms used as requirements language. 116 2.1. Requirements Language 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119] . 122 2.2. Defined Terms 124 The terms of art used in this document are described in the Mesh 125 Architecture Guide [draft-hallambaker-mesh-architecture] . 127 2.3. Related Specifications 129 The architecture of the Mathematical Mesh is described in the Mesh 130 Architecture Guide [draft-hallambaker-mesh-architecture] . The Mesh 131 documentation set and related specifications are described in this 132 document. 134 2.4. Implementation Status 136 The implementation status of the reference code base is described in 137 the companion document [draft-hallambaker-mesh-developer] . 139 3. Secret Splitting 141 The secret sharing mechanism used is based on the method of Shamir 142 [Shamir79] . 144 The mechanism described allows creation of up to 16 shares with a 145 threshold of between 1 and 16 shares. 147 To share a secret of L bits with a threshold of n we first construct 148 f(x) a polynomial of degree n in the modular field p: 150 f(x) = a0 + a1.x + a2.x2 + ? an.xn 152 where: 154 L Is the length of the secret in bits rounded up to the nearest 155 multiple of 32. 157 n Is the threshold, the number of shares required to reconstitute 158 the secret. 160 a0 Is the integer representation of the secret to be shared. 162 a1 ? an Are randomly chosen integers less than p 164 p Is the largest prime that is smaller than 2(L+1). 166 For L=128, p = 2^129-25. 168 The values of the key shares are the values f(1), f(2),? f(n). 170 Conversion of octet sequences to integer representation uses network 171 byte order (i.e. big-endian). The first byte of the octet stream is 172 the most significant 8 bits of the integer representation and the 173 last byte is the least significant 8 bits. 175 Key shares are encoded as an octet sequence: 177 o Bits 4-7 of the first byte specify the threshold value. 179 o Bits 0-3 of the first byte specify the x value 181 o The remaining bytes specify the key share value in network byte 182 order. 184 For an explanation of how to recover the master secret from the key 185 shares, look up Lagrange basis polynomials on the Web. 187 3.1. Example: Securing a recovery record 189 Alice decides to protect her recovery record using a set of five key 190 shares, three of which will be required to recover the key. 192 Alice's master secret is 193 {Alice.RecoveryMaster} 195 Figure 1 197 The master secret is converted to an integer applying network byte 198 order conventions. Since the master secret is 128 bits, it is 199 guaranteed to be smaller than the modulus. The resulting value 200 becomes the polynomial value a0. 202 Since a threshold of three shares is required, we will need a third 203 order polynomial. The co-efficients of the polynomial a1, a2, a3 are 204 random numbers smaller than the modulus: 206 {Alice.RecoveryPolynomial} 208 Figure 2 210 The master secret is the value f(0). The key shares are the values 211 f(1), f(2)...f(5): 213 {Alice.RecoverySharesHex} 215 Figure 3 217 The key shares in user (Base32) encoding are: 219 {Alice.RecoveryShare0Hex} 221 Figure 4 223 To recover the value f(0) from any three shares, we need to fit a 224 polynomial curve to the three points and use it to calculate the 225 value at x=0. 227 We use the Lagrange polynomial basis method: 229 {Alice.RecoveryLagrange} 231 Figure 5 233 4. Key Co-Generation 235 Public Key Co-Generation is a capability that is used in the Mesh to 236 enable provisioning of application specific private key pairs to 237 connected devices without revealing any information concerning the 238 application private key of the device. 240 For example, Alice provisions the confirmation service to her watch. 241 The provisioning device could generate a signature key for the device 242 and encrypt it under the encryption key of the device. But this 243 means that we cannot attribute signatures to the watch with absolute 244 certainty as the provisioning device has had knowledge of the watch 245 signature key. Nor do we wish to use the device signature key for 246 the confirmation 248 service. 250 Public Key Co-Generation allows an administration device to provision 251 a connected device with an application specific private key that is 252 specific to that application and no other such that the application 253 can determine the public key of the device but has no knowledge of 254 the private key. 256 Provisioning an application private key to a device requires the 257 administration device to: 259 o Generate a new application public key for the device. 261 o Construct and publish whatever application specific credentials 262 the device requires to use the application. 264 o Providing the information required to make use of the private key 265 to the device. 267 Note that while the administration device needs to know the device 268 application public key, it does not require knowledge of the device 269 application private key. 271 4.1. Mechanism 273 The Diffie Hellman key agreement and elliptic curve variants thereof 274 support properties we call the Key Combination Law and the Result 275 Combination Law. 277 Let {X, x}, {Y, y}, {E, e} be {public, private} key pairs. 279 The Key Combination law states that we can define an operator ? such 280 that there is a keypair {Z, z} such that: 282 Z = X ? Y and z = (x + y) mod o (where o is the order of the group) 284 The Result Combination Law states that we can define an operator ? 285 such that: 287 (x ? E) ? (y ? E) = (z ? E) = (e ? Z). 289 For the Diffie Hellman system in a modular field p, o = p-1 and a ? b 290 = a ? b = a.b 292 Proof, 294 By definition, X = ex mod p, Y = ey mod p, Z = ez mod p. 296 Therefore, 298 Z = ez mod p = ex+y mod p = (exey) mod p = ex mod p.ey mod p = X.Y 300 A similar proof may be constructed for the operator ?. 302 4.1.1. Application to Elliptic Curve systems 304 For elliptic curve cryptosystems, the operators ? and ? are point 305 addition. 307 While the point addition function can be defined for any elliptic 308 curve system, it is not necessary to implement point addition to 309 support ECDH key agreement. 311 In particular, point multiplication using the Montgomery ladder 312 technique over Montgomery curves only operate on the x co-ordinate 313 and only require point doubling operations. For this reason, Ed448 314 and Ed25519 are the preferred algorithms for key agreement even 315 though this is not their intended purpose. 317 4.2. Implementation for Ed25519 and Ed 448 319 The data structures used to implement co-generation of public keys 320 are defined in the main Mesh Reference Guide. This document 321 describes only the additional implementation details. 323 Note that the 'private key' described in [RFC8032] is in fact a seed 324 used to generate a 'secret scalar' value that is the value that has 325 the function of being the private key in the ECDH algorithm. 327 To provision a new public key to a device, the provisioning device: 329 1. Obtains the device profile of the device(s) to be provisioned to 330 determine the type of key to perform co-generation for. Let the 331 device {public, private} key be {D, d}. 333 2. Generates a private key m with the specified number of bytes (32 334 or 57]. 336 3. Calculates the corresponding public key M. 338 4. Calculates the Application public key A = D+M where + is point 339 addition. 341 5. Constructs the application device entry containing the private 342 key value m and encrypts under the device encryption key d. 344 On receipt, the device may at its option use its knowledge of the 345 secret scalar corresponding to d and m to calculate the application 346 secret scalar a or alternatively maintain the two secrets separately 347 and make use of the result combination law to perform private key 348 operations. 350 4.3. Example: Provisioning the Confirmation Service 352 For example, Alice provisions the confirmation service to her watch. 353 The device profile of the watch specifies an Ed448 signature key: 355 {Alice.CogenDeviceProfile} 357 Figure 6 359 The provisioning device could generate a signature key for the device 360 and encrypt it under the encryption key of the device. But this 361 means that we cannot attribute signatures to the watch with absolute 362 certainty as the provisioning device has had knowledge of the watch 363 signature key. Nor do we wish to use the device signature key for 364 the confirmation service. 366 Instead, the provisioning device generates a companion keypair. A 367 random seed is generated. 369 {Alice.CoGenerationPrivateSeed} 371 Figure 7 373 A key derrivation function (HKDF) is used to derrive a 256 bit key. 375 {Alice.CoGenerationPrivate2} 377 Figure 8 379 The provisioning device can calculate the public key of the composite 380 keypair by adding the public keys of the device profile and the 381 companion public key: 383 {Alice.CoGenerationPublicComp} 385 Figure 9 387 The provisioning device encrypts the private key of the comanion 388 keypair under the encryption key of the device. 390 {Alice.CoGenerationPrivateEncrypted} 392 Figure 10 394 The provisioning device calculates the private key of the composite 395 keypair by adding the two private key values and verifies that scalar 396 multiplication of the base point returns the composite public key 397 value. 399 5. Recryption 401 A key limitation of most deployed messaging systems is that true end- 402 to-end confidentiality is only achieved for a limited set of 403 communication patterns. Specifically, bilateral communications 404 (Alice sends a message to Bob) or broadcast communications to a known 405 set of recipients (Alice sends a message to Bob, Carol and Doug). 406 These capabilities do not support communication patterns where the 407 set of recipients changes over time or is confidential. Yet such 408 requirements commonly occur in situations such as sending a message 409 to a mailing list whose membership isn?t known to the sender, or 410 creating a spreadsheet whose readership is to be limited to 411 authorized members of the ?accounting? team. 413 Traditional End-to-End Encryption is static. 415 The mathematical approach that makes key co-generation possible may 416 be applied to support a public key encryption mode in which 417 encryption is performed as usual but decryption requires the use of 418 multiple keys. This approach is variously described in the 419 literature as distributed key generation and proxy re- 420 encryption [Blaze98] . 422 The approach specified in this document borrows aspects of both these 423 techniques. This combined approach is called 'recryption'. Using 424 recryption allows a sender to send a message to a group of users 425 whose membership is not known to the sender at the time the message 426 is sent and can change at any time. 428 Recryption supports End-to-End Encryption in dynamic groups. 430 Proxy re-encryption provides a technical capability that meets the 431 needs of such communication patterns. Conventional symmetric key 432 cryptography uses a single key to encrypt and decrypt data. Public 433 key cryptography uses two keys, the key used to encrypt data is 434 separate from the key used to decrypt. Proxy re-encryption 435 introduces a third key (the recryption key) that allows a party to 436 permit an encrypted data packet to be decrypted using a different key 437 without permitting the data to be decrypted. 439 The introduction of a recryption key permits end-to-end 440 confidentiality to be preserved when a communication pattern requires 441 that some part of the communication be supported by a service. 443 The introduction of a third type of key, the recryption key permits 444 two new roles to be established, that of an administrator and 445 recryption service. There are thus four parties: 447 Administrator 449 Holder of Decryption Key, Creator of Recryption Keys 451 Sender 453 Holder of Encryption Key 455 Recryption Service 457 Holder of Recryption keys 459 Receiver 461 Holder of personal decryption key 463 The communication between these parties is shown in Figure X below: 465 Mesh/Recrypt Parties 467 The information stored at the recryption service is necessary but not 468 sufficient to decrypt the message. Thus, no disclosure of the 469 message plaintext occurs even in the event that an attacker gains 470 full knowledge of all the information stored by the recryption 471 service. 473 5.1. Mechanism 475 The mechanism used to support recryption is the same as the mechanism 476 used to support key co-generation except that this time, instead of 477 combining two keys to create one, the private component of a 478 decryption key (i.e. the private key) is split into two parts, a 479 recryption key and a decryption key. 481 Recall that the key combination law for Diffie Hellman crypto-systems 482 states that we can add two private keys to get a third. It follows 483 that we can split the private key portion of a keypair {G, g} into 484 two parts by choosing a random number that is less than the order of 485 the Diffie-Hellman group to be our first key x. Our second key is y 486 = g - r mod o, where o is the order of the group. 488 Having generated x, y, we can use these to perform private key 489 agreement operations on a public key E and then use the result 490 combination law to obtain the same result that we would have obtained 491 using g. 493 One means of applying this mechanism to recryption would be to 494 generate a different random value x for each member of the group and 495 store it at the recryption service and communicate the value y to the 496 member via a secure channel. Applying this approach we can clearly 497 see that the recryption service gains no information about the value 498 of the private key since the only information it holds is a random 499 number which could have been generated without any knowledge of the 500 group private key. 502 [RFC8032] requires that implementations derive the scalar secret by 503 taking a cryptographic digest of the private key. This means that 504 either the client or the service must use a non-compliant 505 implementation. Given this choice, it is preferable to require that 506 the non-standard implementation be required at the service rather 507 than the client. This limits the scope of the non-conformant key 508 derivation approach to the specialist recryption service and ensures 509 that the client enforce the requirement to generate the private key 510 component by means of a digest. 512 5.2. Implementation 514 Implementation of recryption in the Mesh has four parts: 516 o Creation and management of the recryption group. 518 o Provisioning of members to a recryption group. 520 o Message encryption. 522 o Message decryption. 524 These operations are all performed using the same catalog and 525 messaging infrastructure provided by the Mesh for other purposes. 527 Each recryption group has its own independent Mesh account. This has 528 many advantages: 530 o Administration of the recryption group may be spread across 531 multiple Mesh users or transferred from one user to another 532 without requiring specification of a separate management protocol 533 to support these operations. 535 o The recryption account address can be used by Mesh applications 536 such as group messaging, conferencing, etc. as a contact address. 538 o The contact request service can be used to notify members that 539 they have been granted membership in the group. 541 5.2.1. Group Creation 543 Creation of a Recryption group requires the steps of: 545 o Generating the recryption group key pair 547 o Creating the recryption group account 549 o Generating administrator record for each administrator. 551 o Publishing the administrator records to the recryption catalog. 553 Note that in principle, we could make use of the key combination law 554 to enable separation of duties controls on administrators so that 555 provisioning of members required multiple administrators to 556 participate in the process. This is left to future versions. 558 5.2.2. Provisioning a Member 560 To provision a user as a member of the recryption group, the 561 administrator requires their current recryption profile. The 562 administrator MAY obtain this by means of a contact service request. 563 As with any contact service request, this request is subject to 564 access control and MAY require authorization by the intended user 565 before the provisioning can proceed. 567 Having obtained the user's recryption profile, the administration 568 tool generates a decryption private key for the user and encrypts it 569 under the member's key to create the encrypted decryption key entry. 571 The administration tool then computes the secret scalar from the 572 private key and uses this together with the secret scalar of the 573 recryption group to compute the recryption key for the member. This 574 value and the encrypted decryption key entry are combined to form the 575 recryption group membership record which is published to the catalog. 577 5.2.3. Message Encryption and Decryption 579 Encryption of a messages makes use of DARE Message in exactly the 580 same manner as any other encryption. The sole difference being that 581 the recipient entry for the recryption operation MUST specify the 582 recryption group address an not just the key fingerprint. This 583 allows the recipient to determine which recryption service to contact 584 to perform the recryption operation. 586 To decrypt a message, the recipient makes an authenticated recryption 587 request to the specified recryption service specifying: 589 o The recipient entry to be used for decryption 591 o The fingerprint of the decryption key(s) the device would like to 592 make use of. 594 o Whether or not the encrypted decryption key entry should be 595 returned. 597 The recryption service searches the catalog for the corresponding 598 recryption group to find a matching entry. If found and if the 599 recipient and proposed decryption key are dully authorized for the 600 purpose, the service performs the key agreement operation using the 601 recryption key specified in the entry and returns the result to the 602 recipient. 604 The recipient then decrypts the recryption data entry using its 605 device decryption key and uses the group decryption key to calculate 606 the other half of the result. The two halves of the result are then 607 added to obtain the key agreement value that is then used to decrypt 608 the message. 610 5.3. Example: Messaging group 612 Alice creates a recryption group. The group encryption and signature 613 key parameters are: 615 {Alice.RecryptGroup} 617 Figure 11 619 To verify the proper function of the group, Alice creates a test 620 message and encrypts it under the group key. 622 {Alice.RecryptMessagePlaintext} 623 {Alice.RecryptMessageCiphertext} 625 Figure 12 627 Alice decides to add Bob to the group. Bob's recryption profile is: 629 {Bob.RecryptGroup} 631 Figure 13 633 Alice generates a recryption/decryption key entry. The recryption 634 key is a random value smaller than the modulus: 636 {bob.RecryptRecryptionKey} 638 Figure 14 640 The decryption key is group private encryption key minus the 641 recryption key (mod p): 643 {bob.RecryptDecryptionKey} 645 Figure 15 647 The Recryption entry consists of Bob's address, the recryption key 648 and the decryption key encrypted under Bob's encryption key: 650 {bob.RecryptRecryptionEntry} 652 Figure 16 654 Note that the only information available to the server is a random 655 number and a encrypted value only Bob can read. It is therefore 656 impossible for compromise of the service to cause disclosure of any 657 information encrypted under the group key unless Bob's private key is 658 also compromised. 660 The group administration tool creates a notification request to tell 661 Bob that he has been made a member of the new group and signs it 662 using the group signature key. The recryption entry and the 663 notification are then sent to the recryption service: 665 {bob.RecryptRecryptionCreateEntry} 667 Figure 17 669 The notification message contains a link to the test message. When 670 he accepts membership of the group, Bob clicks on the link to test 671 that his membership has been fully provisioned. Providing an 672 explicit test mechanism avoids the problem that might otherwise occur 673 in which the message spool fills up with test messages being posted. 675 Bob's Web browser requests the recryption data for the test message. 676 The request is authenticated and encrypted under Bob's device keys. 677 The plaintext of the message is: 679 {bob.RecryptRecryptionRequest} 681 Figure 18 683 The plaintext of the response contains the additional information 684 Bob's Web browser needs to complete the decryption process: 686 {bob.RecryptRecryptionResponse} 688 Figure 19 690 The Web browser decrypts the private key and uses it to calculate the 691 decryption value: 693 {bob.RecryptDecryptionValue} 695 Figure 20 697 The key agreement value is obtained by point addition of the 698 recryption and decryption values: 700 {bob.RecryptKeyAgreementValue} 702 Figure 21 704 This value allows the test message to be decrypted. 706 6. Quantum Resistant Signatures. 708 Quantum computing has made considerable advances over the past decade 709 and the field has now reached the point where a machine weighing many 710 tons can apply Shor's algorithm to factor numbers as large as 35 711 before decoherence occurs. 713 Should construction of a large-scale device prove practical, it will 714 in principle be possible to break all of the public key cryptosystems 715 currently in use. While public key cryptosystems that resist quantum 716 cryptanalysis are currently in development, none has yet reached a 717 sufficient state of maturity for the field to reach consensus that 718 they are resistant to ordinary cryptanalysis, let alone offer a 719 replacement. 721 The consequence of successful quantum cryptanalysis for encryption 722 systems is that all material encrypted under existing public key 723 systems could be decrypted by a quantum capable attacker. Nor is 724 mitigation of this consequence practical since it is not the adoption 725 of new cryptographic algorithms that make a system more secure, it is 726 the elimination of weak options that provides improvement. 728 The Mesh does not currently provide an infrastructure that is Quantum 729 Resistant but could in principle be used as the basis for deploying a 730 Needham-Schroeder style symmetric key infrastructure or a future PKI 731 based on an as yet undecided quantum cryptanalysis resistant public 732 key algorithm. 734 Mesh profiles MAY include a Quantum Resistant Signature Fingerprint 735 (QRSF). This contains the UDF fingerprint of an XMSS signature 736 public key [RFC8391] together with the parameters used to derive the 737 private key set for the public key from a 256 bit master secret. 739 Should it ever become necessary to make use of the QRSF, the user 740 first recovers the master secret from whatever archival mechanism was 741 used to protect it. The use of secret sharing to protect the secret 742 is RECOMMENDED. The master secret is then used to reconstruct the 743 set of private keys from which the public key set is reconstructed. 744 The profile owner can now authenticate themselves by means of their 745 XMSS public key. 747 6.1. Example: Creating a Quantum Resistant Signature Fingerprint 749 Alice decides to add a QRSF to her Mesh Profile. She creates a 256 750 bit master secret. 752 {Alice.QuantumMaster} 754 Figure 22 756 To enable recovery of the master key, Alice creates five keyshares 757 with a quorum of three: 759 {Alice.QuantumShares} 761 Figure 23 763 Alice uses the master secret to derrive her private key values: 765 {Alice.QuantumXMSSPrivate} 767 Figure 24 769 These values are used to generate the public key value: 771 {Alice.QuantumXMSSPublic} 773 Figure 25 775 The QRSF contains the UDF fingerprint of the public key value plus 776 the XMSS parameters: 778 {Alice.QuantumXMSSUDF} 780 Figure 26 782 Alice adds the QRSF to her profile and publishes it to a Mesh Service 783 that is enrolled in at least one multi-party notary scheme. 785 7. Security Considerations 787 TBS 789 8. IANA Considerations 791 All the IANA considerations for the Mesh documents are specified in 792 this document 794 9. Acknowledgements 796 Thanks are due to Viktor Dukhovni, Damian Weber and an anonymous 797 member of the cryptography@metzdowd.com list for assisting in the 798 compilation of the table of prime values. 800 10. Appendix A: Prime Values for Secret Sharing 802 The following are the prime values to be used for sharing secrets of 803 up to 512 bits. 805 If it is necessary to share larger secrets, the corresponding prime 806 may be found by applying the formula: 808 2^(n+1) - (1 SHL (n+1)) - B(1 SHL (n+1)) 809 +----------------+--------------+ 810 | Number of bits | Prime | 811 +----------------+--------------+ 812 | 32 | 2^33 - 9 | 813 | 64 | 2^65 - 49 | 814 | 96 | 2^97 - 141 | 815 | 128 | 2^129 - 25 | 816 | 160 | 2^161 - 159 | 817 | 192 | 2^193 - 31 | 818 | 224 | 2^225 - 49 | 819 | 256 | 2^257 - 93 | 820 | 288 | 2^289 - 493 | 821 | 320 | 2^321 - 9 | 822 | 352 | 2^353 - 139 | 823 | 384 | 2^385 - 265 | 824 | 416 | 2^417 - 1029 | 825 | 448 | 2^449 - 241 | 826 | 480 | 2^481 - 273 | 827 | 512 | 2^513 - 445 | 828 +----------------+--------------+ 830 Table 1 832 11. References 834 11.1. Normative References 836 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 837 Requirement Levels", BCP 14, RFC 2119, 838 DOI 10.17487/RFC2119, March 1997. 840 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 841 Signature Algorithm (EdDSA)", RFC 8032, 842 DOI 10.17487/RFC8032, January 2017. 844 11.2. Informative References 846 [Blaze98] "[Reference Not Found!]". 848 [draft-hallambaker-mesh-architecture] 849 Hallam-Baker, P., "Mathematical Mesh: Architecture", 850 draft-hallambaker-mesh-architecture-05 (work in progress), 851 August 2018. 853 [draft-hallambaker-mesh-developer] 854 Hallam-Baker, P., "Mathematical Mesh: Reference 855 Implementation", draft-hallambaker-mesh-developer-07 (work 856 in progress), April 2018. 858 [RFC8391] Huelsing, A., Butin, D., Gazdag, S., Rijneveld, J., and A. 859 Mohaisen, "XMSS: eXtended Merkle Signature Scheme", 860 RFC 8391, DOI 10.17487/RFC8391, May 2018. 862 [Shamir79] 863 "[Reference Not Found!]". 865 11.3. URIs 867 [1] http://mathmesh.com/Documents/draft-hallambaker-mesh- 868 advanced.html 870 Author's Address 872 Phillip Hallam-Baker 873 Comodo Group Inc. 875 Email: philliph@comodo.com