idnits 2.17.1 draft-hallambaker-mesh-udf-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 Authors' Addresses Section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 2158 has weird spacing: '... suffix srv/m...' == Line 2497 has weird spacing: '... set of point...' == Line 2498 has weird spacing: '... degree in a...' == Line 2499 has weird spacing: '...o prime to...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: UDF Binary Data Sequence types are either fixed length or variable length. A variable length Binary Data Sequence MUST be truncated for presentation. Fixed length Binary Data Sequences MUST not be truncated. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Since PKIX certificates and CLRs contain security policy information, UDF fingerprints used to identify certificates or CRLs SHOULD be presented with a minimum of 200 bits of precision. PKIX applications MUST not accept UDF fingerprints specified with less than 200 bits of precision for purposes of identifying trust anchors. -- The document date (27 July 2020) is 1369 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '112' on line 1116 -- Looks like a reference, but probably isn't: '113' on line 1118 == Missing Reference: 'This' is mentioned on line 2292, but not defined -- Obsolete informational reference (is this intentional?): RFC 5785 (Obsoleted by RFC 8615) Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 4 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 ThresholdSecrets.com 4 Intended status: Informational 27 July 2020 5 Expires: 28 January 2021 7 Mathematical Mesh 3.0 Part II: Uniform Data Fingerprint. 8 draft-hallambaker-mesh-udf-10 10 Abstract 12 This document describes the naming and addressing schemes used in the 13 Mathematical Mesh. The means of generating Uniform Data Fingerprint 14 (UDF) values and their presentation as text sequences and as URIs are 15 described. 17 A UDF consists of a binary sequence, the initial eight bits of which 18 specify a type identifier code. Type identifier codes have been 19 selected so as to provide a useful mnemonic indicating their purpose 20 when presented in Base32 encoding. 22 Two categories of UDF are described. Data UDFs provide a compact 23 presentation of a fixed length binary data value in a format that is 24 convenient for data entry. A Data UDF may represent a cryptographic 25 key, a nonce value or a share of a secret. Fingerprint UDFs provide 26 a compact presentation of a Message Digest or Message Authentication 27 Code value. 29 A Strong Internet Name (SIN) consists of a DNS name which contains at 30 least one label that is a UDF fingerprint of a policy document 31 controlling interpretation of the name. SINs allow a direct trust 32 model to be applied to achieve end-to-end security in existing 33 Internet applications without the need for trusted third parties. 35 UDFs may be presented as URIs to form either names or locators for 36 use with the UDF location service. An Encrypted Authenticated 37 Resource Locator (EARL) is a UDF locator URI presenting a service 38 from which an encrypted resource may be obtained and a symmetric key 39 that may be used to decrypt the content. EARLs may be presented on 40 paper correspondence as a QR code to securely provide a machine- 41 readable version of the same content. This may be applied to 42 automate processes such as invoicing or to provide accessibility 43 services for the partially sighted. 45 [Note to Readers] 46 Discussion of this draft takes place on the MATHMESH mailing list 47 (mathmesh@ietf.org), which is archived at 48 https://mailarchive.ietf.org/arch/search/?email_list=mathmesh. 50 This document is also available online at 51 http://mathmesh.com/Documents/draft-hallambaker-mesh-udf.html. 53 Status of This Memo 55 This Internet-Draft is submitted in full conformance with the 56 provisions of BCP 78 and BCP 79. 58 Internet-Drafts are working documents of the Internet Engineering 59 Task Force (IETF). Note that other groups may also distribute 60 working documents as Internet-Drafts. The list of current Internet- 61 Drafts is at https://datatracker.ietf.org/drafts/current/. 63 Internet-Drafts are draft documents valid for a maximum of six months 64 and may be updated, replaced, or obsoleted by other documents at any 65 time. It is inappropriate to use Internet-Drafts as reference 66 material or to cite them other than as "work in progress." 68 This Internet-Draft will expire on 28 January 2021. 70 Copyright Notice 72 Copyright (c) 2020 IETF Trust and the persons identified as the 73 document authors. All rights reserved. 75 This document is subject to BCP 78 and the IETF Trust's Legal 76 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 77 license-info) in effect on the date of publication of this document. 78 Please review these documents carefully, as they describe your rights 79 and restrictions with respect to this document. 81 Table of Contents 83 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 84 1.1. UDF Types . . . . . . . . . . . . . . . . . . . . . . . . 5 85 1.1.1. Cryptographic Keys and Nonces . . . . . . . . . . . . 5 86 1.1.2. Fingerprint type UDFS . . . . . . . . . . . . . . . . 6 87 1.2. Using UDFs in URIs . . . . . . . . . . . . . . . . . . . 7 88 1.2.1. Name Form . . . . . . . . . . . . . . . . . . . . . . 7 89 1.2.2. Locator Form . . . . . . . . . . . . . . . . . . . . 7 90 1.3. Secure Internet Names . . . . . . . . . . . . . . . . . . 9 91 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 10 92 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 10 93 2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 10 94 2.3. Related Specifications . . . . . . . . . . . . . . . . . 11 95 2.4. Implementation Status . . . . . . . . . . . . . . . . . . 11 96 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 11 97 3.1. Base32 Presentation . . . . . . . . . . . . . . . . . . . 12 98 3.1.1. Precision Improvement . . . . . . . . . . . . . . . . 12 99 3.2. Type Identifier . . . . . . . . . . . . . . . . . . . . . 12 100 3.3. Content Type Identifier . . . . . . . . . . . . . . . . . 13 101 3.4. Truncation . . . . . . . . . . . . . . . . . . . . . . . 14 102 3.4.1. Compressed presentation . . . . . . . . . . . . . . . 14 103 3.5. Presentation . . . . . . . . . . . . . . . . . . . . . . 15 104 3.6. Alternative Presentations . . . . . . . . . . . . . . . . 15 105 3.6.1. Word Lists . . . . . . . . . . . . . . . . . . . . . 16 106 3.6.2. Image List . . . . . . . . . . . . . . . . . . . . . 16 107 4. Fixed Length UDFs . . . . . . . . . . . . . . . . . . . . . . 16 108 4.1. Nonce Type . . . . . . . . . . . . . . . . . . . . . . . 16 109 4.2. OID Identified Sequence . . . . . . . . . . . . . . . . . 17 110 4.3. Encryption/Authentication Type . . . . . . . . . . . . . 18 111 4.4. Key Pair Derivation . . . . . . . . . . . . . . . . . . . 18 112 4.4.1. Extraction step . . . . . . . . . . . . . . . . . . . 21 113 4.4.2. Elliptic Curve Diffie Hellman Key Pairs type 1-4 . . 23 114 4.4.3. Elliptic Curve Diffie Hellman Key Pairs type 5-7 . . 24 115 4.4.4. RSA Key Pairs . . . . . . . . . . . . . . . . . . . . 26 116 4.4.5. Any Key Algorithm . . . . . . . . . . . . . . . . . . 27 117 4.5. Shamir Shared Secret . . . . . . . . . . . . . . . . . . 28 118 4.5.1. Secret Generation . . . . . . . . . . . . . . . . . . 29 119 4.5.2. Recovery . . . . . . . . . . . . . . . . . . . . . . 30 120 5. Variable Length UDFs . . . . . . . . . . . . . . . . . . . . 31 121 5.1. Content Digest . . . . . . . . . . . . . . . . . . . . . 32 122 5.1.1. Content Digest Value . . . . . . . . . . . . . . . . 32 123 5.1.2. Typed Content Digest Value . . . . . . . . . . . . . 33 124 5.1.3. Content Digest Compression . . . . . . . . . . . . . 33 125 5.1.4. Content Digest Presentation . . . . . . . . . . . . . 33 126 5.1.5. Example Encoding . . . . . . . . . . . . . . . . . . 34 127 5.1.6. Using SHA-2-512 Digest . . . . . . . . . . . . . . . 34 128 5.1.7. Using SHA-3-512 Digest . . . . . . . . . . . . . . . 35 129 5.1.8. Using SHA-2-512 Digest with Compression . . . . . . . 36 130 5.1.9. Using SHA-3-512 Digest with Compression . . . . . . . 37 131 5.2. Authenticator UDF . . . . . . . . . . . . . . . . . . . . 37 132 5.2.1. Authentication Content Digest Value . . . . . . . . . 38 133 5.2.2. Authentication Value . . . . . . . . . . . . . . . . 38 134 5.3. Content Type Values . . . . . . . . . . . . . . . . . . . 40 135 5.3.1. PKIX Certificates and Keys . . . . . . . . . . . . . 41 136 5.3.2. OpenPGP Key . . . . . . . . . . . . . . . . . . . . . 41 137 5.3.3. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 42 138 6. UDF URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 42 139 6.1. Name form URI . . . . . . . . . . . . . . . . . . . . . . 42 140 6.2. Locator form URI . . . . . . . . . . . . . . . . . . . . 43 141 6.2.1. DNS Web service discovery . . . . . . . . . . . . . . 43 142 6.2.2. Content Identifier . . . . . . . . . . . . . . . . . 43 143 6.2.3. Target URI . . . . . . . . . . . . . . . . . . . . . 44 144 6.2.4. Postprocessing . . . . . . . . . . . . . . . . . . . 44 145 6.2.5. Decryption and Authentication . . . . . . . . . . . . 44 146 6.2.6. QR Presentation . . . . . . . . . . . . . . . . . . . 45 147 7. Strong Internet Names . . . . . . . . . . . . . . . . . . . . 45 148 8. Security Considerations . . . . . . . . . . . . . . . . . . . 45 149 8.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . 45 150 8.2. Availability . . . . . . . . . . . . . . . . . . . . . . 45 151 8.3. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 45 152 8.4. Work Factor and Precision . . . . . . . . . . . . . . . . 46 153 8.5. Semantic Substitution . . . . . . . . . . . . . . . . . . 47 154 8.6. QR Code Scanning . . . . . . . . . . . . . . . . . . . . 47 155 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 156 9.1. Protocol Service Name . . . . . . . . . . . . . . . . . . 48 157 9.2. Well Known . . . . . . . . . . . . . . . . . . . . . . . 48 158 9.3. URI Registration . . . . . . . . . . . . . . . . . . . . 49 159 9.4. Media Types Registrations . . . . . . . . . . . . . . . . 49 160 9.4.1. Media Type: application/pkix-keyinfo . . . . . . . . 49 161 9.4.2. Media Type: application/udf-encryption . . . . . . . 50 162 9.4.3. Media Type: application/udf-secret . . . . . . . . . 51 163 9.5. Uniform Data Fingerprint Type Identifier Registry . . . . 52 164 9.5.1. The name of the registry . . . . . . . . . . . . . . 52 165 9.5.2. Required information for registrations . . . . . . . 52 166 9.5.3. Applicable registration policy . . . . . . . . . . . 53 167 9.5.4. Size, format, and syntax of registry entries . . . . 53 168 9.5.5. Initial assignments and reservations . . . . . . . . 53 169 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 53 170 11. Appendix A: Prime Values for Secret Sharing . . . . . . . . . 54 171 12. Recovering Shamir Shared Secret . . . . . . . . . . . . . . . 55 172 13. Normative References . . . . . . . . . . . . . . . . . . . . 58 173 14. Informative References . . . . . . . . . . . . . . . . . . . 60 175 1. Introduction 177 A Uniform Data Fingerprint (UDF) is a generalized format for 178 presenting and interpreting short binary sequences representing 179 cryptographic keys or fingerprints of data of any specified type. 180 The UDF format provides a superset of the OpenPGP [RFC4880] 181 fingerprint encoding capability with greater encoding density and 182 readability. 184 This document describes the syntax and encoding of UDFs, the means of 185 constructing and comparing them and their use in other Internet 186 addressing schemes. 188 1.1. UDF Types 190 Two categories of UDF are described. Data UDFs provide a compact 191 presentation of a fixed length binary data value in a format that is 192 convenient for data entry. A Data UDF may represent a cryptographic 193 key or nonce value or a part share of a key generated using a secret 194 sharing mechanism. Fingerprint UDFs provide a compact presentation 195 of a Message Digest or Message Authentication Code value. 197 Both categories of UDF are encoded as a UDF binary sequence, the 198 first octet of which is a Type Identifier and the remaining octets 199 specify the binary value according to the type identifier and data 200 referenced. 202 UDFs are typically presented to the user as a Base32 encoded sequence 203 in groups of four characters separated by dashes. This format 204 provides a useful balance between compactness and readability. The 205 type identifier codes have been selected so as to provide a useful 206 mnemonic when presented in Base32 encoding. 208 The following are examples of UDF values: 210 NC6X-EVQA-M7FV-F7LJ-FFHY-SMDY-UACA 211 EAML-INHA-2635-5SKT-46SH-XKSL-HAZA 212 SAQH-SBPX-XEXR-RYGS-RCVV-DTPA-JUPD-G 213 MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4 214 KCM5-7VB6-IJXJ-WKHX-NZQF-OKGZ-EWVN 215 ADRU-4UV2-EGB2-7QW5-DKZZ-GDGJ-42YC 216 OAYC-4MAH-AYBS-WZLQ-AUAA-GIYA-AQQD-FCCZ-TFA5-FVHH-TTHZ-4JQH-HD43-SHRB 217 -Y5WA-A4O5-IIE5-TEFW-JTPY-EDI 219 Like email addresses, UDFs are not a Uniform Resource Identifier 220 (URI) but may be expressed in URI form by adding the scheme 221 identifier (UDF) for use in contexts where an identifier in URI 222 syntax is required. A UDF URI MAY contain a domain name component 223 allowing it to be used as a locator 225 1.1.1. Cryptographic Keys and Nonces 227 A Nonce (N) UDF represents a short, fixed length randomly chosen 228 binary value. 230 Nonce UDFs are used within many Mesh protocols and data formats where 231 it is necessary to represent a nonce value in text form. 233 Nonce UDF: 234 NC6X-EVQA-M7FV-F7LJ-FFHY-SMDY-UACA 236 An Encryption/Authentication (E) UDF has the same format as a Random 237 UDF but is identified as being intended to be used as a symmetric key 238 for encryption and/or authentication. 240 KeyValue: 241 18 B4 34 E0 D7 B7 DE C9 53 E7 A4 7B AA 4B 38 32 243 Encryption/Authenticator UDF: 244 EAML-INHA-2635-5SKT-46SH-XKSL-HAZA 246 A Share (S) UDF also represents a short, fixed length binary value 247 but only provides one share in secret sharing scheme. Recovery of 248 the binary value requires a sufficient number of shares. 250 Share UDFs are used in the Mesh to support key and data escrow 251 operations without the need to rely on trusted hardware. A share UDF 252 can be copied by hand or printed in human or machine-readable form 253 (e.g. QR code). 255 Key: EAML-INHA-2635-5SKT-46SH-XKSL-HAZA 256 Share 0: SAQH-SBPX-XEXR-RYGS-RCVV-DTPA-JUPD-G 257 Share 1: SAQ5-SV52-SGDH-TYW3-XVXP-6IAW-J4CD-I 258 Share 2: SARD-TKL5-NHO5-VZHE-6IZK-Y4SM-KDVA-E 260 1.1.2. Fingerprint type UDFS 262 Fingerprint type UDFs contains a fingerprint value calculated over a 263 content data item and an IANA media type. 265 A Content Digest type UDF is a fingerprint type UDF in which the 266 fingerprint is formed using a cryptographic algorithm. Two digest 267 algorithms are currently supported, SHA-2-512 (M, for Merkle Damgard) 268 and SHA-3-512 (K, for Keccak). 270 The inclusion of the media type in the calculation of the UDF value 271 provides protection against semantic substitution attacks in which 272 content that has been found to be trustworthy when interpreted as one 273 content type is presented in a context in which it is interpreted as 274 a different content type in which it is unsafe. 276 SHA-2-512: MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4 277 SHA-3-512: KCM5-7VB6-IJXJ-WKHX-NZQF-OKGZ-EWVN 279 An Authentication UDF (A) is formed in the same manner as a 280 fingerprint but using a Message Authentication Code algorithm and a 281 symmetric key. 283 Authentication UDFs are used to express commitments and to provide a 284 means of blinding fingerprint values within a protocol by means of a 285 nonce. 287 SHA-2-512: ADRU-4UV2-EGB2-7QW5-DKZZ-GDGJ-42YC 289 1.2. Using UDFs in URIs 291 The UDF URI scheme allows use of a UDF in contexts where a URF is 292 expected. The UDF URI scheme has two forms, name and locator. 294 1.2.1. Name Form 296 Name form UDF URIs identify a data resource but do not provide a 297 means of discovery. The URI is simply the scheme ("udf") followed by 298 the UDF value: 300 udf:MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4 302 1.2.2. Locator Form 304 Locator form UDF URIs identify a data resource and provide a hint 305 that MAY provide a means of discovery. If the content is not 306 available from the location indicated, content obtained from a 307 different source that matches the fingerprint MAY be used instead. 309 udf://example.com/MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4 311 UDF locator form URIs presenting a fingerprint type UDF provide a 312 tight binding of the content to the locator. This allows the 313 resolved content to be verified and rejected if it has been modified. 315 UDF locator form URIs presenting an Encryptor/Authenticator type UDF 316 provide a mechanism for identification, discovery and decryption of 317 encrypted content. UDF locators of this type are known as Encrypted/ 318 Authenticated Resource Locators (EARLs). 320 Regardless of the type of the embedded UDF, UDF locator form URIs are 321 resolved by first performing DNS Web Service Discovery to identify 322 the Web Service Endpoint for the mmm-udf service at the specified 323 domain. 325 Resolution is completed by presenting the Content Digest Fingerprint 326 of the UDF value specified in the URI to the specified Web Service 327 Endpoint and performing a GET method request on the result. 329 For example, Alice subscribes to Example.com, a purveyor of cat and 330 kitten images. The company generates paper and electronic invoices 331 on a monthly basis. 333 To generate the paper invoice, Example.com first creates a new 334 encryption key: 336 EBXI-SDDC-QJME-B3DV-DSSR-PP7V-QBVF-EG 338 One or more electronic forms of the invoice are encrypted under the 339 key EBXI-SDDC-QJME-B3DV-DSSR-PP7V-QBVF-EG and placed on the 340 Example.com Web site so that the appropriate version is returned if 341 Alice scans the QR code. 343 The key is then converted to form an EARL for the example.com UDF 344 resolution service: 346 udf://example.com/EBXI-SDDC-QJME-B3DV-DSSR-PP7V-QBVF-EG 348 The EARL is then rendered as a QR code: 350 (Artwork only available as svg: No external link available, see 351 draft-hallambaker-mesh-udf-10.html for artwork.) 353 Figure 1 355 A printable invoice containing the QR code is now generated and sent 356 to Alice. 358 When Alice receives the invoice, she can pay it by simply scanning 359 the invoice with a device that recognizes at least one of the invoice 360 formats supported by Example.com. 362 The UDF EARL locator shown above is resolved by first determining the 363 Web Service Endpoint for the mmm-udf service for the domain 364 example.com. 366 Discover ("example.com", "mmm-udf") = 367 https://example.com/.well-known/mmm-udf/ 369 Next the fingerprint of the source UDF is obtained. 371 UDF (EBXI-SDDC-QJME-B3DV-DSSR-PP7V-QBVF-EG) = 372 MA7I-5WGZ-NT4U-2UXI-KEP7-LYNV-JJUP-YJJB-D5UM-PYA6-PQW5-WTHS-2WD4-BZFN 374 Combining the Web Service Endpoint and the fingerprint of the source 375 UDF provides the URI from which the content is obtained using the 376 normal HTTP GET method: 378 https://example.com/.well-known/mmm-udf/MA7I-5WGZ-NT4U-2UXI-KEP7- 379 LYNV-JJUP-YJJB-D5UM-PYA6-PQW5-WTHS-2WD4-BZFN 381 Having established that Alice can read postal mail sent to a physical 382 address and having delivered a secret to that address, this process 383 might be extended to provide a means of automating the process of 384 enrolment in electronic delivery of future invoices. 386 1.3. Secure Internet Names 388 A SIN is an Internet Identifier that contains a UDF fingerprint of a 389 security policy document that may be used to verify the 390 interpretation of the identifier. This permits traditional forms of 391 Internet address such as URIs and RFC822 email addresses to be used 392 to express a trusted address that is independent of any trusted third 393 party. 395 This document only describes the syntax and interpretation of the 396 identifiers themselves. The means by which the security policy 397 documents bound to an address govern interpretation of the name is 398 discussed separately in [draft-hallambaker-mesh-trust]. 400 For example, Example Inc holds the domain name example.com and has 401 deployed a private CA whose root of trust is a PKIX certificate with 402 the UDF fingerprint MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ. 404 Alice is an employee of Example Inc., she uses three email addresses: 406 alice@example.com A regular email address (not a SIN). 408 alice@mm--mb2gk-6duf5-ygyyl-jny5e-rwshz.example.com A strong email 409 address that is backwards compatible. 411 alice@example.com.mm--mb2gk-6duf5-ygyyl-jny5e-rwshz A strong email 412 address that is backwards incompatible. 414 All three forms of the address are valid RFC822 addresses and may be 415 used in a legacy email client, stored in an address book application, 416 etc. But the ability of a legacy client to make use of the address 417 differs. Addresses of the first type may always be used. Addresses 418 of the second type may only be used if an appropriate MX record is 419 provisioned. Addresses of the third type will always fail unless the 420 resolver understands that it is a SIN requiring special processing. 422 These rules allow Bob to send email to Alice with either 'best 423 effort' security or mandatory security as the circumstances demand. 425 2. Definitions 427 This section presents the related specifications and standard, the 428 terms that are used as terms of art within the documents and the 429 terms used as requirements language. 431 2.1. Requirements Language 433 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 434 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 435 document are to be interpreted as described in [RFC2119]. 437 2.2. Defined Terms 439 Cryptographic Digest Function A hash function that has the 440 properties required for use as a cryptographic hash function. 441 These include collision resistance, first pre-image resistance and 442 second pre-image resistance. 444 Content Type An identifier indicating how a Data Value is to be 445 interpreted as specified in the IANA registry Media Types. 447 Commitment A cryptographic primitive that allows one to commit to a 448 chosen value while keeping it hidden to others, with the ability 449 to reveal the committed value later. 451 Data Value The binary octet stream that is the input to the digest 452 function used to calculate a digest value. 454 Data Object A Data Value and its associated Content Type 456 Digest Algorithm A synonym for Cryptographic Digest Function 458 Digest Value The output of a Cryptographic Digest Function 460 Data Digest Value The output of a Cryptographic Digest Function for 461 a given Data Value input. 463 Fingerprint A presentation of the digest value of a data value or 464 data object. 466 Fingerprint Presentation The representation of at least some part of 467 a fingerprint value in human or machine-readable form. 469 Fingerprint Improvement The practice of recording a higher precision 470 presentation of a fingerprint on successful validation. 472 Fingerprint Work Hardening The practice of generating a sequence of 473 fingerprints until one is found that matches criteria that permit 474 a compressed presentation form to be used. The compressed 475 fingerprint thus being shorter than but presenting the same work 476 factor as an uncompressed one. 478 Hash A function which takes an input and returns a fixed-size 479 output. Ideally, the output of a hash function is unbiased and 480 not correlated to the outputs returned to similar inputs in any 481 predictable fashion. 483 Precision The number of significant bits provided by a Fingerprint 484 Presentation. 486 Work Factor A measure of the computational effort required to 487 perform an attack against some security property. 489 2.3. Related Specifications 491 This specification makes use of Base32 [RFC4648] encoding, SHA-2 492 [SHA-2] and SHA-3 [SHA-3] digest functions in the derivation of basic 493 fingerprints. The derivation of keyed fingerprints additionally 494 requires the use of the HMAC [RFC2014] and HKDF [RFC5869] functions. 496 Resolution of UDF URI Locators makes use of DNS Web Service Discovery 497 [draft-hallambaker-web-service-discovery]. 499 2.4. Implementation Status 501 The implementation status of the reference code base is described in 502 the companion document [draft-hallambaker-mesh-developer]. 504 3. Architecture 506 A Uniform Data Fingerprint (UDF) is a presentation of a UDF Binary 507 Data Sequence. 509 This document specifies seven UDF Binary Data Sequence types and one 510 presentation. 512 The first octet of a UDF Binary Data Sequence identifies the UDF type 513 and is referred to as the Type identifier. 515 UDF Binary Data Sequence types are either fixed length or variable 516 length. A variable length Binary Data Sequence MUST be truncated for 517 presentation. Fixed length Binary Data Sequences MUST not be 518 truncated. 520 3.1. Base32 Presentation 522 The default UDF presentation is Base32 Presentation. 524 Variable length Binary Data Sequences are truncated to an integer 525 multiple of 20 bits that provides the desired precision before 526 conversion to Base32 form. 528 Fixed length Binary Data Sequences are converted to Base32 form 529 without truncation. 531 After conversion to Base32 form, dash '-' characters are inserted 532 between groups of 4 characters to aid reading. This representation 533 improves the accuracy of both data entry and verification. 535 3.1.1. Precision Improvement 537 Precision improvement is the practice of using a high precision UDF 538 (e.g. 260 bits) calculated from content data that has been validated 539 according to a lower precision UDF (e.g. 120 bits). 541 This allows a lower precision UDF to be used in a medium such as a 542 business card where space is constrained without compromising 543 subsequent uses. 545 Applications SHOULD make use of precision improvement wherever 546 possible. 548 3.2. Type Identifier 550 A Version Identifier consists of a single byte. 552 The byte codes have been chosen so that the first character of the 553 Base32 presentation of the UDF provides a mnemonic for its type. A 554 SHA-2 fingerprint UDF will always have M (for Merkle Damgard) as the 555 initial letter, a SHA-3 fingerprint UDF will always have K (for 556 Keccak) as the initial letter, and so on. 558 The following version identifiers are specified in this document: 560 +=========+=========+==========================================+ 561 | Type ID | Initial | Algorithm | 562 +=========+=========+==========================================+ 563 | 0 | A | HMAC-SHA-2-512 | 564 +---------+---------+------------------------------------------+ 565 | 32 | E | HKDF-AES-512 | 566 +---------+---------+------------------------------------------+ 567 | 80 | K | SHA-3-512 | 568 +---------+---------+------------------------------------------+ 569 | 81 | K | SHA-3-512 (20 bits compressed) | 570 +---------+---------+------------------------------------------+ 571 | 82 | K | SHA-3-512 (30 bits compressed) | 572 +---------+---------+------------------------------------------+ 573 | 83 | K | SHA-3-512 (40 bits compressed) | 574 +---------+---------+------------------------------------------+ 575 | 84 | K | SHA-3-512 (50 bits compressed) | 576 +---------+---------+------------------------------------------+ 577 | 96 | M | SHA-2-512 | 578 +---------+---------+------------------------------------------+ 579 | 97 | M | SHA-2-512 (20 bits compressed) | 580 +---------+---------+------------------------------------------+ 581 | 98 | M | SHA-2-512 (30 bits compressed) | 582 +---------+---------+------------------------------------------+ 583 | 99 | M | SHA-2-512 (40 bits compressed) | 584 +---------+---------+------------------------------------------+ 585 | 100 | M | SHA-2-512 (50 bits compressed) | 586 +---------+---------+------------------------------------------+ 587 | 104 | N | Nonce data | 588 +---------+---------+------------------------------------------+ 589 | 112 | O | OID distinguished sequence (DER encoded) | 590 +---------+---------+------------------------------------------+ 591 | 136 | R | Random generation seed | 592 +---------+---------+------------------------------------------+ 593 | 144 | S | Shamir Secret Sharing | 594 +---------+---------+------------------------------------------+ 595 | 200 | Z | Key pair derivation | 596 +---------+---------+------------------------------------------+ 598 Table 1 600 3.3. Content Type Identifier 602 A secure cryptographic digest algorithm provides a unique digest 603 value that is probabilistically unique for a particular byte sequence 604 but does not fix the context in which a byte sequence is interpreted. 605 While such ambiguity may be tolerated in a fingerprint format 606 designed for a single specific field of use, it is not acceptable in 607 a general-purpose format. 609 For example, the SSH and OpenPGP applications both make use of 610 fingerprints as identifiers for the public keys used but using 611 different digest algorithms and data formats for representing the 612 public key data. While no such vulnerability has been demonstrated 613 to date, it is certainly conceivable that a crafty attacker might 614 construct an SSH key in such a fashion that OpenPGP interprets the 615 data in an insecure fashion. If the number of applications making 616 use of fingerprint format that permits such substitutions is 617 sufficiently large, the probability of a semantic substitution 618 vulnerability being possible becomes unacceptably large. 620 A simple control that defeats such attacks is to incorporate a 621 content type identifier within the scope of the data input to the 622 hash function. 624 3.4. Truncation 626 Different applications of fingerprints demand different tradeoffs 627 between compactness of the representation and the number of 628 significant bits. A larger the number of significant bits reduces 629 the risk of collision but at a cost to convenience. 631 Modern cryptographic digest functions such as SHA-2 produce output 632 values of at least 256 bits in length. This is considerably larger 633 than most uses of fingerprints require and certainly greater than can 634 be represented in human readable form on a business card. 636 Since a strong cryptographic digest function produces an output value 637 in which every bit in the input value affects every bit in the output 638 value with equal probability, it follows that truncating the digest 639 value to produce a finger print is at least as strong as any other 640 mechanism if digest algorithm used is strong. 642 Using truncation to reduce the precision of the digest function has 643 the advantage that a lower precision fingerprint of some data content 644 is always a prefix of a higher prefix of the same content. This 645 allows higher precision fingerprints to be converted to a lower 646 precision without the need for special tools. 648 3.4.1. Compressed presentation 650 The Content Digest UDF types make use of work factor compression. 651 Additional type identifiers are used to indicate digest values with 652 20, 30, 40 or 50 trailing zero bits allowing a UDF fingerprint 653 offering the equivalent of up to 150 bits of precision to be 654 expressed in 20 characters instead of 30. 656 To use compressed UDF identifiers, it is necessary to search for 657 content that can be compressed. If the digest algorithm used is 658 secure, this means that by definition, the fastest means of search is 659 brute force. Thus, the reduction in fingerprint size is achieved by 660 transferring the work factor from the attacker to the defender. To 661 maintain a work factor of 2^120 with a 2^80 bits, it is necessary for 662 the content generator to perform a brute force search at a cost of 663 the order of 2^40 operations. 665 For example, the smallest allowable work factor for a UDF 666 presentation of a public key fingerprint is 92 bits. This would 667 normally require a presentation with 20 significant characters. 668 Reducing this to 16 characters requires a brute force search of 669 approximately 10^(6) attempts. Reducing this to 12 characters would 670 require 10^(12) attempts and to 10 characters, 10^(15) attempts. 672 Omission of support for higher levels of compression than 2^(50) is 673 intentional. 675 In addition to allowing use of shorter presentations, work factor 676 compression MAY be used as evidence of proof of work. 678 3.5. Presentation 680 The presentation of a fingerprint is the format in which it is 681 presented to either an application or the user. 683 Base32 encoding is used to produce the preferred text representation 684 of a UDF fingerprint. This encoding uses only the letters of the 685 Latin alphabet with numbers chosen to minimize the risk of ambiguity 686 between numbers and letters (2, 3, 4, 5, 6 and 7). 688 To enhance readability and improve data entry, characters are grouped 689 into groups of four. This means that each block of four characters 690 represents an increase in work factor of approximately one million 691 times. 693 3.6. Alternative Presentations 695 Applications that support UDF MUST support use of the Base32 696 presentation. Applications MAY support alternative presentations. 698 3.6.1. Word Lists 700 The use of a Word List to encode fingerprint values was introduced by 701 Patrick Juola and Philip Zimmerman for the PGPfone application. The 702 PGP Word List is designed to facilitate exchange and verification of 703 fingerprint values in a voice application. To minimize the risk of 704 misinterpretation, two-word lists of 256 values each are used to 705 encode alternative fingerprint bytes. The compact size of the lists 706 used allowed the compilers to curate them so as to maximize the 707 phonetic distance of the words selected. 709 The PGP Word List is designed to achieve a balance between ease of 710 entry and verification. Applications where only verification is 711 required may be better served by a much larger word list, permitting 712 shorter fingerprint encodings. 714 For example, a word list with 16384 entries permits 14 bits of the 715 fingerprint to be encoded at once, 65536 entries permits encoding of 716 16 bits. These encodings allow a 120 bit fingerprint to be encoded 717 in 9 and 8 words respectively. 719 3.6.2. Image List 721 An image list is used in the same manner as a word list affording 722 rapid visual verification of a fingerprint value. For obvious 723 reasons, this approach is not suited to data entry but is preferable 724 for comparison purposes. An image list of 1,048,576 images would 725 provide a 20 bit encoding allowing 120 bit precision fingerprints to 726 be displayed in six images. 728 4. Fixed Length UDFs 730 Fixed length UDFs are used to represent cryptographic keys, nonces 731 and secret shares and have a fixed length determined by their 732 function that cannot be truncated without loss of information. 734 All fixed length Binary Data Sequence values are an integer multiple 735 of eight bits. 737 4.1. Nonce Type 739 A Nonce Type UDF consists of the type identifier octet 104 followed 740 by the Binary Data Sequence value. 742 The Binary Data Sequence value is an integer number of octets that 743 SHOULD have been generated in accordance with processes and 744 procedures that ensure that it is sufficiently unpredictable for the 745 purposes of the protocol in which the value is to be used. 746 Requirements for such processes and procedures are described in 747 [RFC4086]. 749 Nonce Type UDFs are intended for use in contexts where it is 750 necessary for a randomly chosen value to be unpredictable but not 751 secret. For example, the challenge in a challenge/response 752 mechanism. 754 4.2. OID Identified Sequence 756 An OID Identified Sequence Type UDF consists of the type identifier 757 octet 108 followed by the Binary Data Sequence value. 759 The Binary Data Sequence value is an octet sequence that contains the 760 DER encoding of the following ASN.1 data: 762 OIDInfo ::= SEQUENCE { 763 algorithm AlgorithmIdentifier, 764 data BIT STRING } 766 AlgorithmIdentifier ::= SEQUENCE { 767 algorithm OBJECT IDENTIFIER, 768 parameters ANY DEFINED BY algorithm OPTIONAL } 770 OID Identified Sequences are intended to allow arbitrary data 771 sequences to be encoded in the UDF format without exhausting the 772 limited type identifier space. 774 In particular, OID Identified Sequences MAY be used to specify public 775 and private key values. 777 Given the following Ed25519 public key: 779 32 88 59 99 41 D2 D4 E7 9C CF 9E 26 07 38 F9 B9 780 1E 21 C7 6C 00 71 DD 42 09 D9 90 B6 4C DF 82 0D 782 The equivalent DER encoding is: 784 30 2E 30 07 06 03 2B 65 70 05 00 03 23 00 04 20 785 32 88 59 99 41 D2 D4 E7 9C CF 9E 26 07 38 F9 B9 786 1E 21 C7 6C 00 71 DD 42 09 D9 90 B6 4C DF 82 0D 788 To encode this key as a UDF OID sequence we prepend the value OID and 789 convert to Base32: 791 OAYC-4MAH-AYBS-WZLQ-AUAA-GIYA-AQQD-FCCZ-TFA5-FVHH-TTHZ-4JQH-HD43-SHRB 792 -Y5WA-A4O5-IIE5-TEFW-JTPY-EDI 794 The corresponding UDF content digest value is more compact and allows 795 us to identify the key unambiguously but does not provide the value: 797 MABG-IFIZ-EOYV-7EF6-FC54-JOAW-M3GT 799 4.3. Encryption/Authentication Type 801 An Encryption/Authentication Type UDF consists of the type identifier 802 octet 0 followed by the Binary Data Sequence value. 804 The Binary Data Sequence value is an integer number of octets that 805 SHOULD have been generated in accordance with processes and 806 procedures that ensure that it is sufficiently unpredictable and 807 unguessable for the purposes of the protocol in which the value is to 808 be used. Requirements for such processes and procedures are 809 described in [RFC4086]. 811 Encryption/Authentication Type UDFs are intended to be used as a 812 means of specifying secret cryptographic keying material. For 813 example, the input to a Key Derivation Function used to encrypt a 814 document. Accordingly, the identifier UDF corresponding to an 815 Encryption/Authentication type UDF is a UDF fingerprint of the 816 Encryption/Authentication Type UDF in Base32 presentation with 817 content type 'application/udf-encryption'. 819 4.4. Key Pair Derivation 821 The key pair derivation type is used to specify a public key pair 822 value by means of a sufficiently random input to a deterministic key 823 generation function. 825 A key pair derivation Type UDF consists of the type identifier octet 826 200 followed by the Binary Data Sequence value. 828 The first two octets of the Binary Data Sequence value comprise the 829 Key Specifier which specifies the algorithm and key uses for which 830 the private key is to be derived. 832 * Bits 6-7 of the first octet specify the key use. 834 * Bits 0-5 of the first byte and bits 0-7 of the second specify the 835 key algorithm in network byte order. 837 In the unlikely event that this code space is ever exhausted, 838 allocation of a new UDF type code will be required. 840 The following key uses are specified: 842 +======+================+ 843 | Code | Key Use | 844 +======+================+ 845 | 0 | Any | 846 +------+----------------+ 847 | 1 | Encryption | 848 +------+----------------+ 849 | 2 | Signature | 850 +------+----------------+ 851 | 3 | Authentication | 852 +------+----------------+ 854 Table 2 856 Derivation of key pairs for the following algorithms is specified in 857 this document: 859 +======+===========+==============================+ 860 | Code | Algorithm | Description | 861 +======+===========+==============================+ 862 | 0 | Any | Seed MAY be used to generate | 863 | | | keypairs for any algorithm | 864 +------+-----------+------------------------------+ 865 | 1 | X25519 | X25519 keypair as described | 866 | | | in RFC7748 | 867 +------+-----------+------------------------------+ 868 | 2 | X448 | X448 keypair as described in | 869 | | | RFC7748 | 870 +------+-----------+------------------------------+ 871 | 3 | Ed25519 | Ed25519 keypair as described | 872 | | | in RFC8032 | 873 +------+-----------+------------------------------+ 874 | 4 | Ed448 | Ed448 keypair as described | 875 | | | in RFC8032 | 876 +------+-----------+------------------------------+ 877 | 5 | P-256 | NIST curve P-256 | 878 +------+-----------+------------------------------+ 879 | 6 | P-384 | NIST curve P-384 | 880 +------+-----------+------------------------------+ 881 | 7 | P-521 | NIST curve P-521 | 882 +------+-----------+------------------------------+ 883 | 8 | RSA-2048 | 2048 bit RSA keypair | 884 +------+-----------+------------------------------+ 885 | 9 | RSA-3072 | 3072 bit RSA keypair | 886 +------+-----------+------------------------------+ 887 | 10 | RSA-4096 | 4096 bit RSA keypair | 888 +------+-----------+------------------------------+ 890 Table 3 892 It is intended that the key derivation mechanism completely specify 893 all parameters of the keypair generated for all key algorithms other 894 than type 0 which is intended for applications where multiple keys 895 are to be generated. 897 The HKDF function [RFC5869] is used to derive key pairs for all the 898 algorithms specified in this document. Derivation functions for 899 additional key algorithms MAY use a different function for this 900 purpose provided that it meets the applicable security requirements. 902 The HKDF function is specified as a two-step extract-expand process 903 with an optional non-secret value input at both steps. 905 4.4.1. Extraction step 907 The HKDF extraction step calculates a PRK value from a "salt" and 908 "IKM": 910 HKDF-Extract(salt, IKM) -> PRK 912 The IKM value is the binary presentation of the complete Binary Data 913 Sequence as originally specified. 915 The salt value is the 16-bit Key Specifier value specifying the 916 algorithm for which the key pair is to be derived in network byte 917 order. Note that this value MAY differ from the one specified in the 918 Binary Data Sequence by the replacement of algorithm type or key use 919 Any with a specific algorithm or key use. 921 The output from the extraction step forms the input to the expand 922 step: 924 HKDF-Expand(PRK, info, L) -> OKM 926 For cases where the key pair generation requires a single parameter, 927 the value "info" is the null string and it suffices to specify the 928 number of bits required and how they are to be used to generate the 929 algorithm parameter. 931 For cases where the key pair generation requires multiple parameters, 932 a different value of the "info" parameter is required for each. 934 An X25519 key may be derived as follows: 936 Fingerprint = 937 ZAAA-CDJ5-DHPA-DUUW-WIPQ-UXNC-DSAR-U7A 939 IKM = 941 00 01 0D 3D 19 DE 01 D2 96 B2 1F 0A 5D A2 1C 81 942 1A 7C 944 salt = 946 00 01 948 PRK = 950 DA 2E 80 6F 2D B1 54 56 7E 27 B4 91 49 0A 35 3A 951 5D 99 92 AA A2 2F 2D 2A 50 4B 13 5B 87 DF 63 67 952 62 92 67 9C B3 B8 10 47 31 52 A2 42 FA 04 84 39 953 7A 64 15 84 C0 6B 51 F7 19 4A 20 35 BA 2E D1 59 955 OKM = 957 E7 22 39 E1 AB 77 AC 9C B4 6A A0 12 27 68 9E 28 958 14 60 2F A8 76 08 38 5E D5 E6 5D E7 0C C8 42 E8 960 Key = 962 E7 22 39 E1 AB 77 AC 9C B4 6A A0 12 27 68 9E 28 963 14 60 2F A8 76 08 38 5E D5 E6 5D E7 0C C8 42 E8 965 Derivation of an X448 key: 967 Fingerprint = 968 ZAAA-FFQA-3LE5-SAHG-E6K6-HOTN-TVLB-K4A 970 Key = 972 AE 6A 6D 0B CC 48 C3 31 E7 55 0F 52 F9 96 83 C5 973 15 7C 8A 74 80 36 B7 E9 17 24 D7 DD A1 56 76 3C 974 15 00 68 B7 23 F5 DB 32 48 1B 72 C0 2E B0 22 45 975 A3 B8 80 67 B3 88 06 9F 977 Derivation of an Ed25519 key: 979 Fingerprint = 980 ZAAA-GZ5N-PSNF-7LMS-QJZN-3O2X-GJXV-X6I 982 Key = 984 3A 36 00 56 2E EC 2F 24 A7 8C 22 F3 A9 A2 EF 1B 985 6E AF 07 D4 99 28 53 A5 5B 0A CC EE 4C 3B 7D 30 987 Derivation of an Ed448 key: 989 Fingerprint = 990 ZAAA-ILZB-KTQV-YWUK-FO7E-MQVV-EWPR-UPA 992 Key = 994 DF 5A 89 B8 1D 56 92 41 32 D1 B2 C9 4F 74 69 E3 995 C9 E5 5F 23 33 A1 CE 22 54 08 EE 53 46 0F 9B 13 996 9D 54 95 2B F9 D9 77 2A FA 07 3C 9D 89 CC C5 0E 997 7E 86 7E 84 7C 58 5D 89 999 4.4.2. Elliptic Curve Diffie Hellman Key Pairs type 1-4 1001 The generation of key pairs for X25519, X448, Ed25519 and Ed448 is 1002 specified in [RFC7748] and [RFC8032]. In each case, the public and 1003 private key parameters are generated from a string of random octets 1004 whose transformation to the secret scalar function is described in 1005 the document. 1007 Thus, info is the null string and the value L is specified as 1008 follows: 1010 +===========+=====+ 1011 | Algorithm | L | 1012 +===========+=====+ 1013 | X25519 | 256 | 1014 +-----------+-----+ 1015 | X448 | 448 | 1016 +-----------+-----+ 1017 | Ed25519 | 256 | 1018 +-----------+-----+ 1019 | Ed448 | 448 | 1020 +-----------+-----+ 1022 Table 4 1024 4.4.3. Elliptic Curve Diffie Hellman Key Pairs type 5-7 1026 The generation of key pairs for the curves P-256, P-384 and P-521 1027 described in [RFC5903] is not mandated by the specification. FIPS 1028 186-4 specifies two approaches. A modified form of the mechanism Key 1029 Pair Generation Using Extra Random Bits specified in B.4.1 is used as 1030 follows: 1032 The number of random bits L is given by the following table: 1034 +===========+=====+ 1035 | Algorithm | L | 1036 +===========+=====+ 1037 | P-256 | 320 | 1038 +-----------+-----+ 1039 | P-384 | 448 | 1040 +-----------+-----+ 1041 | p-521 | 592 | 1042 +-----------+-----+ 1044 Table 5 1046 Note that this rounds up the number of random bits required to the 1047 nearest integer multiple of 8. 1049 The OKM value is interpreted as an integer in Network Byte Order, 1050 that is the first byte contains the most significant bits, to yield 1051 the parameter "c". 1053 The parameter "c" is reduced modulo the value of the prime field "n" 1054 to yield the secret scalar value d: 1056 d = (c mod (n?1)) + 1. 1058 A P-256 key may be derived as follows: 1060 Fingerprint = 1061 ZAAA-LLBO-4A4E-LFMH-EJ73-XVFG-7PZ5-V7Y 1063 IKM = 1065 00 05 AC 2E E0 38 45 95 87 22 7F BB D4 A6 FB F3 1066 DA FF 1068 salt = 1070 00 05 1072 PRK = 1074 0F 48 0F 0C 93 30 AE EE 41 FD 8F A2 1C C2 C6 CA 1075 3A E1 4B 54 E7 83 C0 25 85 F0 CD 2A 65 3F 18 A7 1076 9F 2A 5A ED 6A E3 64 6A 05 7D 1A 1A B8 68 B3 F3 1077 4F A9 10 9A 05 E1 A4 9A 2C CC 40 43 36 8A 24 C0 1079 OKM = 1081 E2 00 EC 22 63 17 D5 E5 52 F9 CD B6 45 23 A9 8B 1082 EF 32 26 E0 24 A0 E7 2B 7F CB C2 0B CB FA 0F 5C 1083 59 D1 7C 4A D8 12 2E 4C 1085 Key = 1086 82352103978746514619167815909572981157103618409885983602799410986 1087 678676075099 1089 Derivation of a P-384 key: 1091 Fingerprint = 1092 ZAAA-NPLI-G7Z3-WFD2-GBJ6-OONN-ELTO-MHA 1094 Key = 1095 36904921143188906308790025170320747449095307663051394962072923012 1096 683284321458397574918591433311657724460124046828583 1098 Derivation of a P-521 key: 1100 Fingerprint = 1101 ZAAA-PQCC-YFVT-LRWP-7MUZ-GJV3-HLX2-JPQ 1103 Key = 1104 63465426400294013455234274700017867331515038924288212787589996717 1105 9893357080737359910264830086847526999862042693445504370476919 1106 922072068801363203357706689700 1108 4.4.4. RSA Key Pairs 1110 Generation of RSA key pairs requires two parameters, p, q which are 1111 prime. 1113 +===========+=======+========================+ 1114 | Parameter | Info | UTF8 equivalent string | 1115 +===========+=======+========================+ 1116 | p | [112] | "p" | 1117 +-----------+-------+------------------------+ 1118 | q | [113] | "q" | 1119 +-----------+-------+------------------------+ 1121 Table 6 1123 The value of L is the same for generating the OKM values from which q 1124 are derived and is determined by the algorithm identifier: 1126 +===========+======+ 1127 | Algorithm | L | 1128 +===========+======+ 1129 | RSA-2048 | 1024 | 1130 +-----------+------+ 1131 | RSA-3072 | 1536 | 1132 +-----------+------+ 1133 | RSA-4096 | 2048 | 1134 +-----------+------+ 1136 Table 7 1138 The RSA parameter p is the smallest prime integer that is greater 1139 than the OKM value corresponding to the info value "p" interpreted as 1140 an integer in Network Byte Order. 1142 The RSA parameter q is the smallest prime integer that is greater 1143 than the OKM value corresponding to the info value "q" interpreted as 1144 an integer in Network Byte Order. 1146 Note that this algorithm does not mandate a particular method of 1147 primality testing nor does it impose any additional testing on the 1148 values p or q. If an application requires the use of primes with 1149 conditions it will be necessary to attempt multiple key derivations 1150 with different Binary Data Sequence values until parameters with the 1151 desired properties are found. 1153 An RSA-2048 may be derived as follows: 1155 Fingerprint = 1156 ZAAA-RJ5I-OSMI-X2KH-MBHX-KUPB-OC54-NQI 1158 IKM = 1160 00 08 A7 A8 74 98 8B E9 47 60 4F 75 51 E1 70 BB 1161 C6 C1 1163 salt = 1165 00 08 1167 [Generation of the PRK as before] 1169 Info(p) = 1171 70 1173 OKM(p) = 1175 92 D4 DA FA C4 22 DB 17 B0 04 93 C6 F1 D2 7A AF 1176 34 6F 69 98 54 1A F5 F3 E3 ED DA 98 F5 64 EE 6A 1178 Info(q) = 1180 71 1182 OKM(q) = 1184 01 50 07 9F B3 53 70 5A 7E 95 63 BD 19 8D 52 59 1185 2F EE 38 E7 8F D4 46 D9 4C 55 E6 DD 39 CA DB 36 1187 Key P = 1188 66413758812235725334838013235321881586339612574162219539634589986 1189 848279686793 1191 Key Q = 1192 59371323150670971897831168338735525379591827337915650990989572561 1193 8914057069 1195 4.4.5. Any Key Algorithm 1197 The Any key algorithm allows a single UDF value to be used to derive 1198 key pairs for multiple algorithms. The IKM value is the same for 1199 each key pair derived. The salt value is changed according to the 1200 algorithm for which the key is to be derived. 1202 Fingerprint = 1203 ZAAA-A6WP-XMGW-FUOF-2T5L-AHNL-FBPY-RSY 1205 To generate an RSA-2048 key 1207 salt = 1209 00 08 1211 Key P = 1212 18437770556273302343384069787329923965493769166213940128456164676 1213 903354830137 1215 Key Q = 1216 74101698940301025126555268512889815535724251370021060722478350575 1217 007811846521 1219 To generate an X25519 key 1221 salt = 1223 00 08 1225 Key = 1226 System.Byte[] 1228 4.5. Shamir Shared Secret 1230 The UDF format MAY be used to encode shares generated by a secret 1231 sharing mechanism. The only secret sharing mechanism currently 1232 supported is the Shamir Secret Sharing mechanism [Shamir79]. Each 1233 secret share represents a point represents a point _on (x, f(x))_, a 1234 polynomial in a modular field _p_. The secret being shared is an 1235 integer multiple of 32 bits represented by the polynomial value 1236 _f(0)_. 1238 A Shamir Shared Secret Type UDF consists of the type identifier octet 1239 144 followed by the Binary Data Sequence value describing the share 1240 value. 1242 The first octet of the Binary Data Sequence value specifies the 1243 threshold value and the x value of the particular share: 1245 * Bits 4-7 of the first byte specify the threshold value. 1247 * Bits 0-3 of the first byte specify the x value minus 1. 1249 The remaining octets specify the value _f(x)_ in network byte (big- 1250 endian) order with leading padding if necessary so that the share has 1251 the same number of bytes as the secret. 1253 The algorithm requires that the value _p_ be a prime larger than the 1254 integer representing the largest secret being shared. For 1255 compactness of representation we chose _p_ to be the smallest prime 1256 that is greater than 2_^(n)_ where _n_ is an integer multiple of 32. 1257 This approach leaves a small probability that a set of chosen 1258 polynomial parameters cause one or more share values be larger than 1259 2_^(n)_. Since it is the value of the secret rather than the 1260 polynomial parameters that is of important, such parameters MUST NOT 1261 be used. 1263 4.5.1. Secret Generation 1265 To share a secret of _L_ bits with a threshold of _n_ we use a _f(x)_ 1266 a polynomial of degree _n_ in the modular field _p_: 1268 f(x) = a_(0) + a_(1).x + a_(2).x^(2) + ... a_(n).x^(n) 1270 where: 1272 L Is the length of the secret in bits, an integer multiple of 32. 1274 n Is the threshold, the number of shares required to reconstitute 1275 the secret. 1277 a_(0) Is the integer representation of the secret to be shared. 1279 a_(1) ... a_(n) Are randomly chosen integers less than p 1281 p Is the smallest prime that is greater than 2^(L). 1283 For L=128, p = 2^(128)+51. 1285 The values of the key shares are the values _f_(1), _f_(2),..._f_(n). 1287 The most straightforward approach to generation of Shamir secrets is 1288 to generate the set of polynomial coefficients, a_(0), a_(1), ... 1289 a_(n) and use these to generate the share values _f_(1), 1290 _f_(2),..._f_(n). 1292 Note that if this approach is adopted, there is a small probability 1293 that one or more of the values _f_(1), _f_(2),..._f_(n) exceeds the 1294 range of values supported by the encoding. Should this occur, at 1295 least one of the polynomial coefficients MUST be replaced. 1297 An alternative means of generating the set of secrets is to select up 1298 to _n-1_ secret share values and use secret recovery to determine at 1299 least one additional share. If _n_ shares are selected, the shared 1300 secret becomes an output of rather than an input to the process. 1302 4.5.2. Recovery 1304 To recover the value of the shared secret, it is necessary to obtain 1305 sufficient shares to meet the threshold and recover the value _f(0)_ 1306 = a_(0). 1308 Applications MAY employ any approach that returns the correct result. 1309 The use of Lagrange basis polynomials is described in Appendix C. 1311 Alice decides to encrypt an important document and split the 1312 encryption key so that there are five key shares, three of which will 1313 be required to recover the key. 1315 Alice's master secret is 1316 CA 65 A1 30 57 25 91 56 B9 6F 32 D0 17 F0 A2 5A 1318 This has the UDF representation: 1320 EDFG-LIJQ-K4SZ-CVVZ-N4ZN-AF7Q-UJNA 1322 The master secret is converted to an integer applying network byte 1323 order conventions. Since the master secret is 128 bits, it is 1324 guaranteed to be smaller than the modulus. The resulting value 1325 becomes the polynomial value a0. 1327 Since a threshold of three shares is required, we will need a second 1328 order polynomial. The co-efficients of the polynomial a1, a2 are 1329 random numbers smaller than the modulus: 1331 a0 = 269031746429133624973381789488312787546 1332 a1 = 322115533094025657321906342357735266839 1333 a2 = 32658764136027301650768999736923473956 1335 The master secret is the value f(0) = a0. The key shares are the 1336 values f(1), f(2)...f(5): 1338 f(1) = 283523676738248120482682524151203316834 1339 f(2) = 23050768398478755830146650856172582527 1340 f(3) = 168177755251702457942523384466757007639 1341 f(4) = 38339903456042299893063510119420169156 1342 f(5) = 314101946853375208608516242677698490092 1343 The first byte of each share specifies the recovery information 1344 (quorum, x value), the remaining bytes specify the share value in 1345 network byte order: 1347 f(1) = 1348 30 D5 4C AC 84 88 7E AF 0F 3C E4 8B 92 BC 61 44 1349 62 1350 f(2) = 1351 31 11 57 6A A0 65 D7 A1 45 95 07 AE BC D2 44 76 1352 7F 1353 f(3) = 1354 32 7E 85 DB 83 EF 30 67 F9 C1 D8 9C 4E 59 9A 39 1355 17 1356 f(4) = 1357 33 1C D7 FF 2F 24 89 03 2B C3 57 54 47 52 62 8B 1358 C4 1359 f(5) = 1360 34 EC 4D D5 A2 05 E1 72 DB 99 83 D6 A7 BC 9D 6E 1361 EC 1363 The UDF presentation of the key shares is thus: 1365 f(1) = SAYN-KTFM-QSEH-5LYP-HTSI-XEV4-MFCG-E 1366 f(2) = SAYR-CV3K-UBS5-PIKF-SUD2-5PGS-IR3H-6 1367 f(3) = SAZH-5BO3-QPXT-AZ7Z-YHMJ-YTSZ-TI4R-O 1368 f(4) = SAZR-ZV77-F4SI-SAZL-YNLV-IR2S-MKF4-I 1369 f(5) = SA2O-YTOV-UIC6-C4W3-TGB5-NJ54-TVXO-Y 1371 To recover the value f(0) from any three shares, we need to fit a 1372 polynomial curve to the three points and use it to calculate the 1373 value at x=0 using the Lagrange polynomial basis. 1375 5. Variable Length UDFs 1377 Variable length UDFs are used to represent fingerprint values 1378 calculated over a content type identifier and the cryptographic 1379 digest of a content data item. The fingerprint value MAY be 1380 specified at any integer multiple of 20 bits that provides a work 1381 factor sufficient for the intended purpose. 1383 Two types of fingerprint are specified: 1385 Digest fingerprints Are computed with the same cryptographic digest 1386 algorithm used to calculate the digest of the content data. 1388 Message Authentication Code fingerprints Are computed using a 1389 Message Authentication Code. 1391 For a given algorithm (and key, if requires), if two UDF fingerprints 1392 are of the same content data and content type, either the fingerprint 1393 values will be the same or the initial characters of one will be 1394 exactly equal to the other. 1396 5.1. Content Digest 1398 A Content Digest Type UDF consists of the type identifier octet 1399 followed by the Binary Data Sequence value. 1401 The type identifier specifies the digest algorithm used and the 1402 compression level. Two digest algorithms are currently specified 1403 with four compression levels for each making a total of eight 1404 possible type identifiers. 1406 The Content Digest UDF for given content data is generated by the 1407 steps of: 1409 0. Applying the digest algorithm to determine the Content Digest 1410 Value 1412 1. Applying the digest algorithm to determine the Typed Content 1413 Digest Value 1415 2. Determining the compression level from bytes 0-3 of the Typed 1416 Content Digest Value. 1418 3. Determining the Type Identifier octet from the Digest algorithm 1419 identifier and compression level. 1421 4. Truncating bytes 4-63 of the Typed Content Digest Value to 1422 determine the Binary Data Sequence value. 1424 5.1.1. Content Digest Value 1426 The Content Digest Value (CDV) is determined by applying the digest 1427 algorithm to the content data: 1429 CDV = H() 1431 Where 1433 H(x) is the cryptographic digest function 1435 is the binary data. 1437 5.1.2. Typed Content Digest Value 1439 The Typed Content Digest Value (TCDV) is determined by applying the 1440 digest algorithm to the content type identifier and the CDV: 1442 TCDV = H ( + ?:? + CDV) 1444 Where 1446 A + B represents concatenation of the binary sequences A and B. 1448 is the IANA Content Type of the data in UTF8 encoding 1450 The two-step approach to calculating the Type Content Digest Value 1451 allows an application to attempt to match a set of content data 1452 against multiple types without the need to recalculate the value of 1453 the content data digest. 1455 5.1.3. Content Digest Compression 1457 The compression factor is determined according to the number of 1458 trailing zero bits in the first 8 bytes of the Typed Content Digest 1459 Value as follows: 1461 19 or fewer leading zero bits Compression factor = 0 1463 29 or fewer leading zero bits Compression factor = 20 1465 39 or fewer leading zero bits Compression factor = 30 1467 49 or fewer leading zero bits Compression factor = 40 1469 50 or more leading zero bits Compression factor = 50 1471 The least significant bits of each octet are regarded to be 1472 'trailing'. 1474 Applications MUST use compression when creating and comparing UDFs. 1475 Applications MAY support content generation techniques that search 1476 for UDF values that use a compressed representation. Presentation of 1477 a content digest value indicating use of compression MAY be used as 1478 an indicator of 'proof of work'. 1480 5.1.4. Content Digest Presentation 1482 The type identifier is determined by the algorithm and compression 1483 factor as follows: 1485 +=========+=========+===========+=============+ 1486 | Type ID | Initial | Algorithm | Compression | 1487 +=========+=========+===========+=============+ 1488 | 80 | K | SHA-3-512 | 0 | 1489 +---------+---------+-----------+-------------+ 1490 | 81 | K | SHA-3-512 | 20 | 1491 +---------+---------+-----------+-------------+ 1492 | 82 | K | SHA-3-512 | 30 | 1493 +---------+---------+-----------+-------------+ 1494 | 83 | K | SHA-3-512 | 40 | 1495 +---------+---------+-----------+-------------+ 1496 | 84 | K | SHA-3-512 | 50 | 1497 +---------+---------+-----------+-------------+ 1498 | 96 | M | SHA-2-512 | 0 | 1499 +---------+---------+-----------+-------------+ 1500 | 97 | M | SHA-2-512 | 20 | 1501 +---------+---------+-----------+-------------+ 1502 | 98 | M | SHA-2-512 | 30 | 1503 +---------+---------+-----------+-------------+ 1504 | 99 | M | SHA-2-512 | 40 | 1505 +---------+---------+-----------+-------------+ 1506 | 100 | M | SHA-2-512 | 50 | 1507 +---------+---------+-----------+-------------+ 1509 Table 8 1511 The Binary Data Sequence value is taken from the Typed Content Digest 1512 Value starting at the 9^(th) octet and as many additional bytes as 1513 are required to meet the presentation precision. 1515 5.1.5. Example Encoding 1517 In the following examples, is the UTF8 encoding of the 1518 string "text/plain" and is the UTF8 encoding of the string 1519 "UDF Data Value" 1521 Data = 1522 55 44 46 20 44 61 74 61 20 56 61 6C 75 65 1524 ContentType = 1525 74 65 78 74 2F 70 6C 61 69 6E 1527 5.1.6. Using SHA-2-512 Digest 1528 H() = 1529 48 DA 47 CC AB FE A4 5C 76 61 D3 21 BA 34 3E 58 1530 10 87 2A 03 B4 02 9D AB 84 7C CE D2 22 B6 9C AB 1531 02 38 D4 E9 1E 2F 6B 36 A0 9E ED 11 09 8A EA AC 1532 99 D9 E0 BD EA 47 93 15 BD 7A E9 E1 2E AD C4 15 1534 + ':' + H() = 1535 74 65 78 74 2F 70 6C 61 69 6E 3A 48 DA 47 CC AB 1536 FE A4 5C 76 61 D3 21 BA 34 3E 58 10 87 2A 03 B4 1537 02 9D AB 84 7C CE D2 22 B6 9C AB 02 38 D4 E9 1E 1538 2F 6B 36 A0 9E ED 11 09 8A EA AC 99 D9 E0 BD EA 1539 47 93 15 BD 7A E9 E1 2E AD C4 15 1541 H( + ':' + H()) = 1542 C6 AF B7 C0 FE BE 04 E5 AE 94 E3 7B AA 5F 1A 40 1543 5B A3 CE CC 97 4D 55 C0 9E 61 E4 B0 EF 9C AE F9 1544 EB 83 BB 9D 5F 0F 39 F6 5F AA 06 DC 67 2A 67 71 1545 4F FF 8F 83 C4 55 38 36 38 AE 42 7A 82 9C 85 BB 1547 The prefixed Binary Data Sequence is thus 1548 60 C6 AF B7 C0 FE BE 04 E5 AE 94 E3 7B AA 5F 1A 1549 40 5B A3 CE CC 97 4D 55 C0 9E 61 E4 B0 EF 9C AE 1550 F9 EB 83 BB 9D 5F 0F 39 F6 5F AA 06 DC 67 2A 67 1551 71 4F FF 8F 83 C4 55 38 36 38 AE 42 7A 82 9C 85 1553 The 125 bit fingerprint value is MDDK-7N6A-727A-JZNO-STRX-XKS7-DJAF 1555 This fingerprint MAY be specified with higher or lower precision as 1556 appropriate. 1558 100 bit precision MDDK-7N6A-727A-JZNO-STRX 1560 120 bit precision MDDK-7N6A-727A-JZNO-STRX-XKS7 1562 200 bit precision MDDK-7N6A-727A-JZNO-STRX-XKS7-DJAF-XI6O-ZSLU-2VOA 1564 260 bit precision MDDK-7N6A-727A-JZNO-STRX-XKS7-DJAF-XI6O-ZSLU-2VOA- 1565 TZQ6-JMHP-TSXP 1567 5.1.7. Using SHA-3-512 Digest 1568 H() = 1569 6D 2E CF E6 93 5A 0C FC F2 A9 1A 49 E0 0C D8 07 1570 A1 4E 70 AB 72 94 6E CC BB 47 48 F1 8E 41 49 95 1571 07 1D F3 6E 0D 0C 8B 60 39 C1 8E B4 0F 6E C8 08 1572 65 B4 C4 45 9B A2 7E 97 74 7B BE 68 BC A8 C2 17 1574 + ':' + H() = 1575 74 65 78 74 2F 70 6C 61 69 6E 3A 6D 2E CF E6 93 1576 5A 0C FC F2 A9 1A 49 E0 0C D8 07 A1 4E 70 AB 72 1577 94 6E CC BB 47 48 F1 8E 41 49 95 07 1D F3 6E 0D 1578 0C 8B 60 39 C1 8E B4 0F 6E C8 08 65 B4 C4 45 9B 1579 A2 7E 97 74 7B BE 68 BC A8 C2 17 1581 H( + ':' + H()) = 1582 8A 86 8A 06 1C 54 6E 7E 3F 75 5F 39 88 F9 FD 2F 1583 8E C8 45 93 1B 80 A8 2F 29 16 7B A3 BE 21 1F 8A 1584 75 61 88 A1 D5 7F 07 D5 9D 68 A4 2D 17 F4 4D 23 1585 F9 E4 0B B2 1A 8D B9 F5 8D FC EC BD 01 F4 37 7C 1587 The prefixed Binary Data Sequence is thus 1588 50 8A 86 8A 06 1C 54 6E 7E 3F 75 5F 39 88 F9 FD 1589 2F 8E C8 45 93 1B 80 A8 2F 29 16 7B A3 BE 21 1F 1590 8A 75 61 88 A1 D5 7F 07 D5 9D 68 A4 2D 17 F4 4D 1591 23 F9 E4 0B B2 1A 8D B9 F5 8D FC EC BD 01 F4 37 1593 The 125 bit fingerprint value is KCFI-NCQG-DRKG-47R7-OVPT-TCHZ-7UXY 1595 5.1.8. Using SHA-2-512 Digest with Compression 1597 The content data "UDF Compressed Document 4187123" produces a UDF 1598 Content Digest SHA-2-512 binary value with 20 trailing zeros and is 1599 therefore presented using compressed presentation: 1601 Data = " 1602 55 44 46 20 43 6F 6D 70 72 65 73 73 65 64 20 44 1603 6F 63 75 6D 65 6E 74 20 34 31 38 37 31 32 33" 1605 The UTF8 Content Digest is given as: 1607 H() = 1608 36 21 FA 2A C5 D8 62 5C 2D 0B 45 FB 65 93 FC 69 1609 C1 ED F7 00 AE 6F E3 3D 38 13 FE AB 76 AA 74 13 1610 6D 5A 2B 20 DE D6 A5 CF 6C 04 E6 56 3F F3 C0 C7 1611 C4 1D 3F 43 DD DC F1 A5 67 A7 E0 67 9A B0 C6 B7 1613 + ':' + H() = 1614 74 65 78 74 2F 70 6C 61 69 6E 3A 36 21 FA 2A C5 1615 D8 62 5C 2D 0B 45 FB 65 93 FC 69 C1 ED F7 00 AE 1616 6F E3 3D 38 13 FE AB 76 AA 74 13 6D 5A 2B 20 DE 1617 D6 A5 CF 6C 04 E6 56 3F F3 C0 C7 C4 1D 3F 43 DD 1618 DC F1 A5 67 A7 E0 67 9A B0 C6 B7 1620 H( + ':' + H()) = 1621 8E 14 D9 19 4E D6 02 12 C3 30 A7 BB 5F C7 17 6D 1622 AE 9A 56 7C A8 2A 23 1F 96 75 ED 53 10 EC E8 F2 1623 60 14 24 D0 C8 BC 55 3D C0 70 F7 5E 86 38 1A 0B 1624 CB 55 9C B2 87 81 27 FF 3C EC E2 F0 90 A0 00 00 1626 The prefixed Binary Data Sequence is thus 1627 61 8E 14 D9 19 4E D6 02 12 C3 30 A7 BB 5F C7 17 1628 6D AE 9A 56 7C A8 2A 23 1F 96 75 ED 53 10 EC E8 1629 F2 60 14 24 D0 C8 BC 55 3D C0 70 F7 5E 86 38 1A 1630 0B CB 55 9C B2 87 81 27 FF 3C EC E2 F0 90 A0 00 1632 The 125 bit fingerprint value is MGHB-JWIZ-J3LA-EEWD-GCT3-WX6H-C5W2 1634 5.1.9. Using SHA-3-512 Digest with Compression 1636 The content data "UDF Compressed Document 774665" produces a UDF 1637 Content Digest SHA-3-512 binary value with 20 trailing zeros and is 1638 therefore presented using compressed presentation: 1640 Data = 1641 55 44 46 20 43 6F 6D 70 72 65 73 73 65 64 20 44 1642 6F 63 75 6D 65 6E 74 20 37 37 34 36 36 35 1644 The UTF8 SHA-3-512 Content Digest is KEJI-Y225-BDUG-XX22-MXKE-5ITF- 1645 YVYM 1647 5.2. Authenticator UDF 1649 An authenticator Type UDF consists of the type identifier octet 1650 followed by the Binary Data Sequence value. 1652 The type identifier specifies the digest and Message Authentication 1653 Code algorithm. Two algorithm suites are currently specified. Use 1654 of compression is not supported. 1656 The Authenticator UDF for given content data and key is generated by 1657 the steps of: 1659 0. Applying the digest algorithm to determine the Content Digest 1660 Value 1662 1. Applying the MAC algorithm to determine the Authentication value 1664 2. Determining the Type Identifier octet from the Digest algorithm 1665 identifier and compression level. 1667 3. Truncating the Authentication value to determine the Binary Data 1668 Sequence value. 1670 The key used to calculate and Authenticator type UDF is always a 1671 UNICODE string. If use of a binary value as a key is required, the 1672 value MUST be converted to a string format first. For example, by 1673 conversion to an Encryption/Authentication type UDF. 1675 5.2.1. Authentication Content Digest Value 1677 The Content Digest Value (CDV) is determined in the exact same 1678 fashion as for a Content Digest UDF by applying the digest algorithm 1679 to the content data: 1681 CDV = H()) 1683 Where 1685 H(x) is the cryptographic digest function 1687 is the binary data. 1689 5.2.2. Authentication Value 1691 The Authentication Value (AV) is determined by applying the digest 1692 algorithm to the content type identifier and the CDV: 1694 AV = MAC (, ( + ?:? + CDV)) 1696 Where 1698 is the authentication key as specified below 1700 MAC( , ) is the result of applying the Message 1701 Authentication Code algorithm to with Key and data 1703 The value is calculated as follows: 1705 IKM = UTF8 (Key) 1706 PRK = MAC (UTF8 ("KeyedUDFMaster"), IKM) 1707 OKM = HKDF-Expand(PRK, UTF8 ("KeyedUDFExpand"), HashLen) 1709 Where the function UTF8(string) converts a string to the binary UTF8 1710 representation, HKDF-Expand is as defined in [RFC5869] and the 1711 function MAC(k,m) is the HMAC function formed from the specified hash 1712 H(m) as specified in [RFC2014]. 1714 Keyed UDFs are typically used in circumstances where user interaction 1715 requires a cryptographic commitment type functionality 1717 In the following example, is the UTF8 encoding of the 1718 string "text/plain" and is the UTF8 encoding of the string 1719 "Konrad is the traitor". The randomly chosen key is NDD7-6CMX-H2FW- 1720 ISAL-K4VB-DQ3E-PEDM. 1722 Data = 1723 4B 6F 6E 72 61 64 20 69 73 20 74 68 65 20 74 72 1724 61 69 74 6F 72 1726 ContentType = 1727 74 65 78 74 2F 70 6C 61 69 6E 1729 Key = 1730 4E 44 44 37 2D 36 43 4D 58 2D 48 32 46 57 2D 49 1731 53 41 4C 2D 4B 34 56 42 2D 44 51 33 45 2D 50 45 1732 44 4D 1734 Processing is performed in the same manner as an unkeyed fingerprint 1735 except that compression is never used: 1737 H() = 1738 93 FC DA F9 FA FD 1E 26 50 26 C3 C1 28 43 40 73 1739 D8 BC 3D 62 87 73 2B 73 B8 EC 93 B6 DE 80 FF DA 1740 70 0A D1 CE E8 F4 36 68 EF 4E 71 63 41 53 91 5C 1741 CE 8C 5C CE C7 9A 46 94 6A 35 79 F9 33 70 85 01 1743 + ':' + H() = 1744 74 65 78 74 2F 70 6C 61 69 6E 3A 93 FC DA F9 FA 1745 FD 1E 26 50 26 C3 C1 28 43 40 73 D8 BC 3D 62 87 1746 73 2B 73 B8 EC 93 B6 DE 80 FF DA 70 0A D1 CE E8 1747 F4 36 68 EF 4E 71 63 41 53 91 5C CE 8C 5C CE C7 1748 9A 46 94 6A 35 79 F9 33 70 85 01 1750 PRK(Key) = 1751 77 D3 0A 08 39 BD 9D C0 97 44 DA 33 15 0A 42 5E 1752 CD 17 80 03 B3 CF CC 89 7A C7 84 12 B4 51 5B 25 1753 DC 26 F5 E1 1B 20 F3 89 2E 9A 1A 7B 0E 73 23 39 1754 0E C3 4C EF 2D 40 DA 05 B4 70 C6 1C 82 C1 49 33 1756 HKDF(Key) = 1757 BF A9 B4 58 9C 1D 68 D7 9A B7 11 F6 C8 98 59 14 1758 20 D7 82 67 C5 84 22 E5 A0 F9 93 52 B1 C3 87 EB 1759 05 06 CB C4 E4 D6 E6 EE 1F F0 D4 7A 97 68 5E CE 1760 28 1C CA AF D8 B5 D1 24 4A 71 EC E3 AC B5 D2 04 1762 MAC(, + ':' + H()) = 1763 4C C3 7F D3 F9 9E 52 CF 07 90 74 53 84 65 95 BC 1764 1A 2B A5 D1 68 9D 05 6D 06 C5 CA BF 17 CB E0 49 1765 95 39 57 08 79 C4 E5 49 D3 3A 59 A3 32 05 45 A6 1766 30 26 25 AE 8A F4 47 C6 1F B5 33 7F AD 69 A6 30 1768 The prefixed Binary Data Sequence is thus 1769 00 4C C3 7F D3 F9 9E 52 CF 07 90 74 53 84 65 95 1770 BC 1A 2B A5 D1 68 9D 05 6D 06 C5 CA BF 17 CB E0 1771 49 95 39 57 08 79 C4 E5 49 D3 3A 59 A3 32 05 45 1772 A6 30 26 25 AE 8A F4 47 C6 1F B5 33 7F AD 69 A6 1774 The 125 bit fingerprint value is ABGM-G76T-7GPF-FTYH-SB2F-HBDF-SW6B 1776 5.3. Content Type Values 1778 While a UDF fingerprint MAY be used to identify any form of static 1779 data, the use of a UDF fingerprint to identify a public key signature 1780 key provides a level of indirection and thus the ability to identify 1781 dynamic data. The content types used to identify public keys are 1782 thus of particular interest. 1784 As described in the security considerations section, the use of 1785 fingerprints to identify a bare public key and the use of 1786 fingerprints to identify a public key and associated security policy 1787 information are very different. 1789 5.3.1. PKIX Certificates and Keys 1791 UDF fingerprints MAY be used to identify PKIX certificates, CRLs and 1792 public keys in the ASN.1 encoding used in PKIX certificates. 1794 Since PKIX certificates and CLRs contain security policy information, 1795 UDF fingerprints used to identify certificates or CRLs SHOULD be 1796 presented with a minimum of 200 bits of precision. PKIX applications 1797 MUST not accept UDF fingerprints specified with less than 200 bits of 1798 precision for purposes of identifying trust anchors. 1800 PKIX certificates, keys and related content data are identified by 1801 the following content types: 1803 application/pkix-cert A PKIX Certificate 1805 application/pkix-crl A PKIX CRL 1807 application/pkix-keyinfo The SubjectPublicKeyInfo structure defined 1808 in the PKIX certificate specification encoded using DER encoding 1809 rules. 1811 The SubjectPublicKeyInfo structure is defined in [RFC5280] as 1812 follows: 1814 SubjectPublicKeyInfo ::= SEQUENCE { 1815 algorithm AlgorithmIdentifier, 1816 subjectPublicKey BIT STRING } 1818 This schema results in an identical DER encoding to the "OIDInfo" 1819 sequence specified in section XXX. The distinction between these 1820 productions is that the "OIDInfo" schema is intended to be used to 1821 encode arbitrary data while the application/pkix-keyinfo content type 1822 is only intended to be used to describe public keys. 1824 5.3.2. OpenPGP Key 1826 OpenPGPv5 keys and key set content data are identified by the 1827 following content type: 1829 application/pgp-keys An OpenPGP key set. 1831 5.3.3. DNSSEC 1833 DNSSEC record data consists of DNS records which are identified by 1834 the following content type: 1836 application/dns A DNS resource record in binary format 1838 6. UDF URIs 1840 The UDF URI scheme describes a means of constructing URIs from a UDF 1841 value. 1843 Two forms or UDF URI are specified, Name and Locator. In both cases 1844 the URI MUST specify the scheme type ""UDF"", and a UDF fingerprint 1845 and MAY specify a query identifier and/or a fragment identifier. 1847 By definition a Locator form URI contains an "authority" field which 1848 MUST be a DNS domain name. The use of IP address forms for this 1849 purpose is not permitted. 1851 Name Form URIs allow static content data to be identified without 1852 specifying the means by which the content data may be retrieved. 1853 Locator form URIs allow static content data or dynamic network 1854 resources to be identified and the means of retrieval. 1856 The syntax of a UDF URI is a subset of the generic URI syntax 1857 specified in [RFC3986]. The use of userinfo and port numbers is not 1858 supported and the path part of the uri is a UDF in base32 1859 presentation. 1861 URI = "UDF:" udf [ "?" query ] [ "" fragment ] 1863 udf = name-form / locator-form 1865 name-form = udf-value 1866 locator-form = "//" authority "/" udf-value 1868 authority = host 1869 host = reg-name 1871 6.1. Name form URI 1873 Name form UDF URIs provide a means of presenting a UDF value in a 1874 context in which a URI form of a name is required without providing a 1875 means of resolution. 1877 Adding the UDF scheme prefix to a UDF fingerprint does not change the 1878 semantics of the fingerprint itself. The semantics of the name 1879 result from the context in which it is used. 1881 For example, a UDF value of any type MAY be used to give a unique 1882 targetNamespace value in an XML Schema [XMLSchema] 1884 6.2. Locator form URI 1886 The locator form of an unkeyed UDF URI is resolved by the following 1887 steps: 1889 * Use DNS Web service discovery to determine the Web Service 1890 Endpoint. 1892 * Determine the content identifier from the source URI. 1894 * Append the content identifier to the Web Service Endpoint as a 1895 suffix to form the target URI. 1897 * Retrieve content from the Web Service Endpoint by means of a GET 1898 method. 1900 * Perform post processing as specified by the UDF type. 1902 6.2.1. DNS Web service discovery 1904 DNS Web Discovery is performed as specified in 1905 [draft-hallambaker-web-service-discovery] for the service "mmm-udf" 1906 and domain name specified in the URI. For a full description of the 1907 discovery mechanism, consult the referenced specification. 1909 The use of DNS Web Discovery permits service providers to make full 1910 use of the load balancing and service description capabilities 1911 afforded by use of DNS SRV and TXT records in accordance with the 1912 approach described in [RFC6763]. 1914 If no SRV or TXT records are specified, DNS Web Discovery specifies 1915 that the Web Service Endpoint be the Well Known Service [RFC5785] 1916 with the prefix "/.well-known/srv/mmm-udf." 1918 6.2.2. Content Identifier 1920 For all UDF types other than Secret Share, the Content Identifier 1921 value is the UDF SHA-2-512 Content Digest of the canonical form of 1922 the UDF specified in the source URI presented at twice the precision 1923 to a maximum of 440 bits. 1925 If the UDF is of type Secret Share, the shared secret MUST be 1926 recovered before the content identifier can be resolved. The shared 1927 secret is then expressed as a UDF of type Encryption/Authentication 1928 and the Content Identifier determined as for an Encryption/ 1929 Authentication type UDF. 1931 6.2.3. Target URI 1933 The target URI is formed by appending a slash separator '/' and the 1934 Content Identifier value to the Web Service Endpoint. 1936 Since the path portion of a URI is case sensitive, the UDF value MUST 1937 be specified in upper case and MUST include separator marks. 1939 6.2.4. Postprocessing 1941 After retrieving the content data, the resolver MUST perform post 1942 processing as indicated by the content type: 1944 Nonce No additional post processing is required. 1946 Content Digest The resolver MUST verify that the content returned 1947 matches the UDF fingerprint value. 1949 Authenticator The resolver MUST verify that the content returned 1950 matches the UDF fingerprint value. 1952 Encryption/Authentication The content data returned is decrypted and 1953 authenticated using the key specified in the UDF value as the 1954 initial keying material (see below). 1956 Secret Share (set) The content data returned is decrypted and 1957 authenticated using the shared secret as the initial keying 1958 material (see below). 1960 6.2.5. Decryption and Authentication 1962 The steps performed to decode cryptographically enhanced content data 1963 depends on the content type specified in the returned content. Two 1964 formats are currently supported: 1966 * DARE Envelope format as specified in [draft-hallambaker-mesh-dare] 1968 * Cryptographic Message Syntax (CMS) Symmetric Key Package as 1969 specified in [RFC6031] 1971 6.2.6. QR Presentation 1973 Encoding of a UDF URI as a QR code requires only the characters in 1974 alphanumeric encoding, thus achieving compactness with minimal 1975 overhead. 1977 7. Strong Internet Names 1979 A Strong Internet Name is an Internet address that is bound to a 1980 policy governing interpretation of that address by means of a Content 1981 Digest type UDF of the policy expressed as a UDF prefixed DNS label 1982 within the address itself. 1984 The Reserved LDH labels as defined in [RFC5890] that begin with the 1985 prefix "mm--" are reserved for use as Strong Internet Names. The 1986 characters following the prefix are a Content Digest type UDF in 1987 Base32 presentation. 1989 Since DNS labels are limited to 63 characters, the presentation of 1990 the SIN itself is limited to 59 characters and thus 240 bits of 1991 precision. 1993 8. Security Considerations 1995 This section describes security considerations arising from the use 1996 of UDF in general applications. 1998 Additional security considerations for use of UDFs in Mesh services 1999 and applications are described in the Mesh Security Considerations 2000 guide [draft-hallambaker-mesh-security]. 2002 8.1. Confidentiality 2004 Encrypted locator is a bearer token 2006 8.2. Availability 2008 Corruption of a part of a shared secret may prevent recovery 2010 8.3. Integrity 2012 Shared secret parts do not contain context information to specify 2013 which secret they relate to. 2015 8.4. Work Factor and Precision 2017 A given UDF data object has a single fingerprint value that may be 2018 presented at different precisions. The shortest legitimate precision 2019 with which a UDF fingerprint may be presented has 96 significant bits 2021 A UDF fingerprint presents the same work factor as any other 2022 cryptographic digest function. The difficulty of finding a second 2023 data item that matches a given fingerprint is 2^n and the difficulty 2024 or finding two data items that have the same fingerprint is 2^(n/2). 2025 Where n is the precision of the fingerprint. 2027 For the algorithms specified in this document, n = 512 and thus the 2028 work factor for finding collisions is 2^256, a value that is 2029 generally considered to be computationally infeasible. 2031 Since the use of 512 bit fingerprints is impractical in the type of 2032 applications where fingerprints are generally used, truncation is a 2033 practical necessity. The longer a fingerprint is, the less likely it 2034 is that a user will check every character. It is therefore important 2035 to consider carefully whether the security of an application depends 2036 on second pre-image resistance or collision resistance. 2038 In most fingerprint applications, such as the use of fingerprints to 2039 identify public keys, the fact that a malicious party might generate 2040 two keys that have the same fingerprint value is a minor concern. 2041 Combined with a flawed protocol architecture, such a vulnerability 2042 may permit an attacker to construct a document such that the 2043 signature will be accepted as valid by some parties but not by 2044 others. 2046 For example, Alice generates keypairs until two are generated that 2047 have the same 100 bit UDF presentation (typically 2^48 attempts). 2048 She registers one keypair with a merchant and the other with her 2049 bank. This allows Alice to create a payment instrument that will be 2050 accepted as valid by one and rejected by the other. 2052 The ability to generate of two PKIX certificates with the same 2053 fingerprint and different certificate attributes raises very 2054 different and more serious security concerns. For example, an 2055 attacker might generate two certificates with the same key and 2056 different use constraints. This might allow an attacker to present a 2057 highly constrained certificate that does not present a security risk 2058 to an application for purposes of gaining approval and an 2059 unconstrained certificate to request a malicious action. 2061 In general, any use of fingerprints to identify data that has 2062 security policy semantics requires the risk of collision attacks to 2063 be considered. For this reason, the use of short, 'user friendly' 2064 fingerprint presentations (Less than 200 bits) SHOULD only be used 2065 for public key values. 2067 8.5. Semantic Substitution 2069 Many applications record the fact that a data item is trusted, rather 2070 fewer record the circumstances in which the data item is trusted. 2071 This results in a semantic substitution vulnerability which an 2072 attacker may exploit by presenting the trusted data item in the wrong 2073 context. 2075 The UDF format provides protection against high level semantic 2076 substitution attacks by incorporating the content type into the input 2077 to the outermost fingerprint digest function. The work factor for 2078 generating a UDF fingerprint that is valid in both contexts is thus 2079 the same as the work factor for finding a second preimage in the 2080 digest function (2^512 for the specified digest algorithms). 2082 It is thus infeasible to generate a data item such that some 2083 applications will interpret it as a PKIX key and others will accept 2084 as an OpenPGP key. While attempting to parse a PKIX key as an 2085 OpenPGP key is virtually certain to fail to return the correct key 2086 parameters it cannot be assumed that the attempt is guaranteed to 2087 fail with an error message. 2089 The UDF format does not provide protection against semantic 2090 substitution attacks that do not affect the content type. 2092 8.6. QR Code Scanning 2094 The act of scanning a QR code SHOULD be considered equivalent to 2095 clicking on an unlabeled hypertext link. Since QR codes are scanned 2096 in many different contexts, the mere act of scanning a QR code MUST 2097 NOT be interpreted as constituting an affirmative acceptance of terms 2098 or conditions or as creating an electronic signature. 2100 If such semantics are required in the context of an application, 2101 these MUST be established by secondary user actions made subsequent 2102 to the scanning of the QR code. 2104 There is a risk that use of QR codes to automate processes such as 2105 payment will lead to abusive practices such as presentation of 2106 fraudulent invoices for goods not ordered or delivered. It is 2107 therefore important to ensure that such requests are subject to 2108 adequate accountability controls. 2110 9. IANA Considerations 2112 Registrations are requested in the following registries: 2114 * Service Name and Transport Protocol Port Number 2116 * well-known URI registry 2118 * Uniform Resource Identifier (URI) Schemes 2120 * Media Types 2122 In addition, the creation of the following registry is requested: 2123 Uniform Data Fingerprint Type Identifier Registry. 2125 9.1. Protocol Service Name 2127 The following registration is requested in the Service Name and 2128 Transport Protocol Port Number Registry in accordance with [RFC6355] 2130 Service Name (REQUIRED) mmm-udf 2132 Transport Protocol(s) (REQUIRED) TCP 2134 Assignee (REQUIRED) Phillip Hallam-Baker, phill@hallambaker.com 2136 Contact (REQUIRED) Phillip Hallam-Baker, phill@hallambaker.com 2138 Description (REQUIRED) mmm-udf is a Web Service protocol that 2139 resolves Mathematical Mesh Uniform Data Fingerprints (UDF) to 2140 resources. The mmm-udf service name is used in service discovery 2141 to identify a Web Service endpoint to perform resolution of a UDF 2142 presented in URI locator form. 2144 Reference (REQUIRED) [This document] 2146 Port Number (OPTIONAL) None 2148 Service Code (REQUIRED for DCCP only) None 2150 Known Unauthorized Uses (OPTIONAL) None 2152 Assignment Notes (OPTIONAL) None 2154 9.2. Well Known 2156 The following registration is requested in the well-known URI 2157 registry in accordance with [RFC5785] 2158 URI suffix srv/mmm-udf 2160 Change controller Phillip Hallam-Baker, phill@hallambaker.com 2162 Specification document(s): [This document] 2164 Related information 2166 [draft-hallambaker-web-service-discovery] 2168 9.3. URI Registration 2170 The following registration is requested in the Uniform Resource 2171 Identifier (URI) Schemes registry in accordance with [RFC7595] 2173 Scheme name: UDF 2175 Status: Provisional 2177 Applications/protocols that use this scheme name: Mathematical Mesh 2178 Service protocols (mmm) 2180 Contact: Phillip Hallam-Baker mailto:phill@hallambaker.com 2182 Change controller: Phillip Hallam-Baker 2184 References: [This document] 2186 9.4. Media Types Registrations 2188 9.4.1. Media Type: application/pkix-keyinfo 2190 Type name: application 2192 Subtype name: pkix-keyinfo 2194 Required parameters: None 2196 Optional parameters: None 2198 Encoding considerations: Binary 2200 Security considerations: Described in [This] 2202 Interoperability considerations: None 2204 Published specification: [This] 2205 Applications that use this media type: Uniform Data Fingerprint 2207 Fragment identifier considerations: None 2209 Additional information: Deprecated alias names for this type: None 2211 Magic number(s): None 2213 File extension(s): None 2215 Macintosh file type code(s): None 2217 Person & email address to contact for further information: Phillip 2218 Hallam-Baker @hallambaker.com> 2220 Intended usage: Content type identifier to be used in constructing 2221 UDF Content Digests and Authenticators and related cryptographic 2222 purposes. 2224 Restrictions on usage: None 2226 Author: Phillip Hallam-Baker 2228 Change controller: Phillip Hallam-Baker 2230 Provisional registration? (standards tree only): Yes 2232 9.4.2. Media Type: application/udf-encryption 2234 Type name: application 2236 Subtype name: udf-encryption 2238 Required parameters: None 2240 Optional parameters: None 2242 Encoding considerations: None 2244 Security considerations: Described in [This] 2246 Interoperability considerations: None 2248 Published specification: [This] 2250 Applications that use this media type: Uniform Data Fingerprint 2252 Fragment identifier considerations: None 2253 Additional information: Deprecated alias names for this type: None 2255 Magic number(s): None 2257 File extension(s): None 2259 Macintosh file type code(s): None 2261 Person & email address to contact for further information: Phillip 2262 Hallam-Baker @hallambaker.com> 2264 Intended usage: Content type identifier to be used in constructing 2265 UDF Content Digests and Authenticators and related cryptographic 2266 purposes. 2268 Restrictions on usage: None 2270 Author: Phillip Hallam-Baker 2272 Change controller: Phillip Hallam-Baker 2274 Provisional registration? (standards tree only): Yes 2276 9.4.3. Media Type: application/udf-secret 2278 Type name: application 2280 Subtype name: udf- secret 2282 Required parameters: None 2284 Optional parameters: None 2286 Encoding considerations: None 2288 Security considerations: Described in [This] 2290 Interoperability considerations: None 2292 Published specification: [This] 2294 Applications that use this media type: Uniform Data Fingerprint 2296 Fragment identifier considerations: None 2298 Additional information: Deprecated alias names for this type: None 2300 Magic number(s): None 2301 File extension(s): None 2303 Macintosh file type code(s): None 2305 Person & email address to contact for further information: Phillip 2306 Hallam-Baker @hallambaker.com> 2308 Intended usage: Content type identifier to be used in constructing 2309 UDF Content Digests and Authenticators and related cryptographic 2310 purposes. 2312 Restrictions on usage: None 2314 Author: Phillip Hallam-Baker 2316 Change controller: Phillip Hallam-Baker 2318 Provisional registration? (standards tree only): Yes 2320 9.5. Uniform Data Fingerprint Type Identifier Registry 2322 This document describes a new extensible data format employing fixed 2323 length version identifiers for UDF types. 2325 9.5.1. The name of the registry 2327 Uniform Data Fingerprint Type Identifier Registry 2329 9.5.2. Required information for registrations 2331 Registrants must specify the Type identifier code(s) requested, 2332 description and RFC number for the corresponding standards action 2333 document. 2335 The standards document must specify the means of generating and 2336 interpreting the UDF Data Sequence Value and the purpose(s) for which 2337 it is proposed. 2339 Since the initial letter of the Base32 presentation provides a 2340 mnemonic function in UDFs, the standards document must explain why 2341 the proposed Type Identifier and associated initial letter are 2342 appropriate. In cases where a new initial letter is to be created, 2343 there must be an explanation of why this is appropriate. If an 2344 existing initial letter is to be created, there must be an 2345 explanation of why this is appropriate and/or acceptable. 2347 9.5.3. Applicable registration policy 2349 Due to the intended field of use (human data entry), the code space 2350 is severely constrained. Accordingly, it is intended that code point 2351 registrations be as infrequent as possible. 2353 Registration of new digest algorithms is strongly discouraged and 2354 should not occur unless, (1) there is a known security vulnerability 2355 in one of the two schemes specified in the original assignment and 2356 (2) the proposed algorithm has been subjected to rigorous peer 2357 review, preferably in the form of an open, international competition 2358 and (3) the proposed algorithm has been adopted as a preferred 2359 algorithm for use in IETF protocols. 2361 Accordingly, the applicable registration policy is Standards Action. 2363 9.5.4. Size, format, and syntax of registry entries 2365 Each registry entry consists of a single byte code, 2367 9.5.5. Initial assignments and reservations 2369 The following entries should be added to the registry as initial 2370 assignments: 2372 Code Description Reference 2373 --- ------------------- --------- 2374 00 HMAC and SHA-2-512 [This document] 2375 32 HKDF-AES-512 [This document] 2376 80 SHA-3-512 [This document] 2377 81 SHA-3-512 with 20 trailing zeros [This document] 2378 82 SHA-3-512 with 30 trailing zeros [This document] 2379 82 SHA-3-512 with 40 trailing zeros [This document] 2380 83 SHA-3-512 with 50 trailing zeros [This document] 2381 96 SHA-2-512 [This document] 2382 97 SHA-2-512 with 20 trailing zeros [This document] 2383 98 SHA-2-512 with 30 trailing zeros [This document] 2384 99 SHA-2-512 with 40 trailing zeros [This document] 2385 100 SHA-2-512 with 50 trailing zeros [This document] 2386 104 Random nonce [This document] 2387 144 Shamir Secret Share [This document] 2389 10. Acknowledgements 2391 A list of people who have contributed to the design of the Mesh is 2392 presented in [draft-hallambaker-mesh-architecture]. 2394 Thanks are due to Viktor Dukhovni, Damian Weber and an anonymous 2395 member of the cryptography@metzdowd.com list for assisting in the 2396 compilation of the table of prime values. 2398 11. Appendix A: Prime Values for Secret Sharing 2400 The following are the prime values to be used for sharing secrets of 2401 up to 512 bits. 2403 If it is necessary to share larger secrets, the corresponding prime 2404 may be found by choosing a value (2^(32))^(n) that is larger than the 2405 secret to be encoded and determining the next largest number that is 2406 prime. 2408 +================+======================+ 2409 | Number of bits | Offset = Primen - 2n | 2410 +================+======================+ 2411 | 32 | 15 | 2412 +----------------+----------------------+ 2413 | 64 | 13 | 2414 +----------------+----------------------+ 2415 | 96 | 61 | 2416 +----------------+----------------------+ 2417 | 128 | 51 | 2418 +----------------+----------------------+ 2419 | 160 | 7 | 2420 +----------------+----------------------+ 2421 | 192 | 133 | 2422 +----------------+----------------------+ 2423 | 224 | 735 | 2424 +----------------+----------------------+ 2425 | 256 | 297 | 2426 +----------------+----------------------+ 2427 | 288 | 127 | 2428 +----------------+----------------------+ 2429 | 320 | 27 | 2430 +----------------+----------------------+ 2431 | 352 | 55 | 2432 +----------------+----------------------+ 2433 | 384 | 231 | 2434 +----------------+----------------------+ 2435 | 416 | 235 | 2436 +----------------+----------------------+ 2437 | 448 | 211 | 2438 +----------------+----------------------+ 2439 | 480 | 165 | 2440 +----------------+----------------------+ 2441 | 512 | 75 | 2442 +----------------+----------------------+ 2444 Table 9 2446 For example, the prime to be used to share a 128 bit value is 2^(128) 2447 + 51. 2449 12. Recovering Shamir Shared Secret 2451 The value of a Shamir Shared secret may be recovered using Lagrange 2452 basis polynomials. 2454 To share a secret with a threshold of _n_ shares and L bits we 2455 constructed _f(x)_ a polynomial of degree _n_ in the modular field 2456 _p_ where _p_ is the smallest prime greater than 2^(L): 2458 f(x) = a_(0) + a_(1).x + a_(2).x^(2) + ... a_(n).x^(n) 2460 The shared secret is the binary representation of the value a_(0) 2462 Given _n_ shares (_x_(0)_, _y_(0)_), (_x_(1)_, _y_(1)_), ... 2463 (_x_(n-1)_, _y_(n-1)_), The corresponding the Lagrange basis 2464 polynomials _l_(0)_, _l_(1)_, .. _l_(n-1)_ are given by: 2466 lm = ((x - x(m_(0))) / (x(m) - x(m_(0)))) . ((x - x(m_(1))) / (x(m) - 2467 x(m_(1)))) . ... . ((x - x(m_(n-2))) / (x(m) - x(m_(n-2)))) 2469 Where the values m_(0), m_(1), ... m_(n-2), are the integers 0, 1, .. 2470 _n_-1, excluding the value _m_. 2472 These can be used to compute _f(x)_ as follows: 2474 f(x) = y_(0)l_(0) + y_(1)l_(1) + ... y_(n-1)l_(n-1) 2476 Since it is only the value of _f(0)_ that we are interested in, we 2477 compute the Lagrange basis for the value _x_ = 0: 2479 lz_(m) = ((x(m_(1))) / (x(m) - x(m_(1)))) . ((x(m_(2))) / (x(m) - 2480 x(m_(2)))) 2482 Hence, 2484 a_(0) = f(0) = y_(0)lz_(0) + y_(1)lz_(1) + ... y_(n-1)l_(n-1) 2486 The following C# code recovers the values. 2488 using System; 2489 using System.Collections.Generic; 2490 using System.Numerics; 2492 namespace Examples { 2494 class Examples { 2496 /// 2497 /// Combine a set of points (x, f(x)) 2498 /// on a polynomial of degree in a 2499 /// discrete field modulo prime to 2500 /// recover the value f(0) using Lagrange basis polynomials. 2501 /// 2502 /// The values f(x). 2503 /// The values for x. 2504 /// The modulus. 2505 /// The polynomial degree. 2506 /// The value f(0). 2507 static BigInteger CombineNK( 2508 BigInteger[] fx, 2509 int[] x, 2510 BigInteger p, 2511 int n) { 2512 if (fx.Length < n) { 2513 throw new Exception("Insufficient shares"); 2514 } 2516 BigInteger accumulator = 0; 2517 for (var formula = 0; formula < n; formula++) { 2518 var value = fx[formula]; 2520 BigInteger numerator = 1, denominator = 1; 2521 for (var count = 0; count < n; count++) { 2522 if (formula == count) { 2523 continue; // If not the same value 2524 } 2526 var start = x[formula]; 2527 var next = x[count]; 2529 numerator = (numerator * -next) % p; 2530 denominator = (denominator * (start - next)) % p; 2531 } 2533 var InvDenominator = ModInverse(denominator, p); 2535 accumulator = Modulus((accumulator + 2536 (fx[formula] * numerator * InvDenominator)), p); 2537 } 2539 return accumulator; 2540 } 2542 /// 2543 /// Compute the modular multiplicative inverse of the value 2544 /// modulo 2545 /// 2546 /// The value to find the inverse of 2547 /// The modulus. 2548 /// 2549 static BigInteger ModInverse( 2550 BigInteger k, 2551 BigInteger p) { 2552 var m2 = p - 2; 2553 if (k < 0) { 2554 k = k + p; 2555 } 2557 return BigInteger.ModPow(k, m2, p); 2558 } 2560 /// 2561 /// Calculate the modulus of a number with correct handling 2562 /// for negative numbers. 2563 /// 2564 /// Value 2565 /// The modulus. 2566 /// x mod p 2567 public static BigInteger Modulus( 2568 BigInteger x, 2569 BigInteger p) { 2570 var Result = x % p; 2571 return Result.Sign >= 0 ? Result : Result + p; 2572 } 2573 } 2574 } 2576 13. Normative References 2578 [draft-hallambaker-mesh-architecture] 2579 Hallam-Baker, P., "Mathematical Mesh 3.0 Part I: 2580 Architecture Guide", Work in Progress, Internet-Draft, 2581 draft-hallambaker-mesh-architecture-13, 9 March 2020, 2582 . 2585 [draft-hallambaker-mesh-dare] 2586 Hallam-Baker, P., "Mathematical Mesh 3.0 Part III : Data 2587 At Rest Encryption (DARE)", Work in Progress, Internet- 2588 Draft, draft-hallambaker-mesh-dare-07, 9 March 2020, 2589 . 2592 [draft-hallambaker-mesh-security] 2593 Hallam-Baker, P., "Mathematical Mesh 3.0 Part VII: 2594 Security Considerations", Work in Progress, Internet- 2595 Draft, draft-hallambaker-mesh-security-04, 9 March 2020, 2596 . 2599 [draft-hallambaker-web-service-discovery] 2600 Hallam-Baker, P., "DNS Web Service Discovery", Work in 2601 Progress, Internet-Draft, draft-hallambaker-web-service- 2602 discovery-03, 23 October 2019, 2603 . 2606 [RFC2014] Weinrib, A. and J. Postel, "IRTF Research Group Guidelines 2607 and Procedures", BCP 8, RFC 2014, DOI 10.17487/RFC2014, 2608 October 1996, . 2610 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2611 Requirement Levels", BCP 14, RFC 2119, 2612 DOI 10.17487/RFC2119, March 1997, 2613 . 2615 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2616 Resource Identifier (URI): Generic Syntax", STD 66, 2617 RFC 3986, DOI 10.17487/RFC3986, January 2005, 2618 . 2620 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 2621 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 2622 . 2624 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2625 Housley, R., and W. Polk, "Internet X.509 Public Key 2626 Infrastructure Certificate and Certificate Revocation List 2627 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 2628 . 2630 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 2631 Key Derivation Function (HKDF)", RFC 5869, 2632 DOI 10.17487/RFC5869, May 2010, 2633 . 2635 [RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a 2636 Prime (ECP Groups) for IKE and IKEv2", RFC 5903, 2637 DOI 10.17487/RFC5903, June 2010, 2638 . 2640 [RFC6031] Turner, S. and R. Housley, "Cryptographic Message Syntax 2641 (CMS) Symmetric Key Package Content Type", RFC 6031, 2642 DOI 10.17487/RFC6031, December 2010, 2643 . 2645 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 2646 for Security", RFC 7748, DOI 10.17487/RFC7748, January 2647 2016, . 2649 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 2650 Signature Algorithm (EdDSA)", RFC 8032, 2651 DOI 10.17487/RFC8032, January 2017, 2652 . 2654 [SHA-2] NIST, "Secure Hash Standard", August 2015. 2656 [SHA-3] Dworkin, M. J., "SHA-3 Standard: Permutation-Based Hash 2657 and Extendable-Output Functions", August 2015. 2659 14. Informative References 2661 [draft-hallambaker-mesh-developer] 2662 Hallam-Baker, P., "Mathematical Mesh: Reference 2663 Implementation", Work in Progress, Internet-Draft, draft- 2664 hallambaker-mesh-developer-09, 23 October 2019, 2665 . 2668 [draft-hallambaker-mesh-trust] 2669 Hallam-Baker, P., "Mathematical Mesh 3.0 Part VI: The 2670 Trust Mesh", Work in Progress, Internet-Draft, draft- 2671 hallambaker-mesh-trust-05, 9 March 2020, 2672 . 2675 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 2676 "Randomness Requirements for Security", BCP 106, RFC 4086, 2677 DOI 10.17487/RFC4086, June 2005, 2678 . 2680 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 2681 Thayer, "OpenPGP Message Format", RFC 4880, 2682 DOI 10.17487/RFC4880, November 2007, 2683 . 2685 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 2686 Uniform Resource Identifiers (URIs)", RFC 5785, 2687 DOI 10.17487/RFC5785, April 2010, 2688 . 2690 [RFC5890] Klensin, J., "Internationalized Domain Names for 2691 Applications (IDNA): Definitions and Document Framework", 2692 RFC 5890, DOI 10.17487/RFC5890, August 2010, 2693 . 2695 [RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based 2696 DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, 2697 DOI 10.17487/RFC6355, August 2011, 2698 . 2700 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 2701 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 2702 . 2704 [RFC7595] Thaler, D., Hansen, T., and T. Hardie, "Guidelines and 2705 Registration Procedures for URI Schemes", BCP 35, 2706 RFC 7595, DOI 10.17487/RFC7595, June 2015, 2707 . 2709 [Shamir79] Shamir, A., "How to share a secret.", 1979. 2711 [XMLSchema] 2712 Gao, S., Sperberg-McQueen, C. M., Thompson, H. S., 2713 Mendelsohn, N., Beech, D., and M. Maloney, "W3C XML Schema 2714 Definition Language (XSD) 1.1 Part 1: Structures", 5 April 2715 2012.