idnits 2.17.1 draft-hallambaker-mesh-udf-07.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 : ---------------------------------------------------------------------------- ** There are 9 instances of too long lines in the document, the longest one being 89 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 2096 has weird spacing: '... suffix srv/m...' == Line 2419 has weird spacing: '... set of point...' == Line 2420 has weird spacing: '... degree in a...' == Line 2421 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 (October 18, 2019) is 1645 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 2616 -- Looks like a reference, but probably isn't: '2' on line 2618 -- Looks like a reference, but probably isn't: '112' on line 1080 -- Looks like a reference, but probably isn't: '113' on line 1081 == Missing Reference: 'This' is mentioned on line 2230, but not defined -- Obsolete informational reference (is this intentional?): RFC 5785 (Obsoleted by RFC 8615) Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hallam-Baker 3 Internet-Draft October 18, 2019 4 Intended status: Informational 5 Expires: April 20, 2020 7 Mathematical Mesh 3.0 Part II: Uniform Data Fingerprint. 8 draft-hallambaker-mesh-udf-07 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 [1] . 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 April 20, 2020. 70 Copyright Notice 72 Copyright (c) 2019 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 77 (https://trustee.ietf.org/license-info) in effect on the date of 78 publication of this document. Please review these documents 79 carefully, as they describe your rights and restrictions with respect 80 to this document. Code Components extracted from this document must 81 include Simplified BSD License text as described in Section 4.e of 82 the Trust Legal Provisions and are provided without warranty as 83 described in the Simplified BSD License. 85 Table of Contents 87 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 88 1.1. UDF Types . . . . . . . . . . . . . . . . . . . . . . . . 5 89 1.1.1. Cryptographic Keys and Nonces . . . . . . . . . . . . 5 90 1.1.2. Fingerprint type UDFS . . . . . . . . . . . . . . . . 6 91 1.2. UDF URIs . . . . . . . . . . . . . . . . . . . . . . . . 7 92 1.2.1. Name Form . . . . . . . . . . . . . . . . . . . . . . 7 93 1.2.2. Locator Form . . . . . . . . . . . . . . . . . . . . 7 95 1.3. Secure Internet Names . . . . . . . . . . . . . . . . . . 9 96 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 10 97 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 10 98 2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 10 99 2.3. Related Specifications . . . . . . . . . . . . . . . . . 11 100 2.4. Implementation Status . . . . . . . . . . . . . . . . . . 11 101 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 11 102 3.1. Base32 Presentation . . . . . . . . . . . . . . . . . . . 12 103 3.1.1. Precision Improvement . . . . . . . . . . . . . . . . 12 104 3.2. Type Identifier . . . . . . . . . . . . . . . . . . . . . 12 105 3.3. Content Type Identifier . . . . . . . . . . . . . . . . . 13 106 3.4. Truncation . . . . . . . . . . . . . . . . . . . . . . . 14 107 3.4.1. Compression . . . . . . . . . . . . . . . . . . . . . 14 108 3.5. Presentation . . . . . . . . . . . . . . . . . . . . . . 15 109 3.6. Alternative Presentations . . . . . . . . . . . . . . . . 15 110 3.6.1. Word Lists . . . . . . . . . . . . . . . . . . . . . 15 111 3.6.2. Image List . . . . . . . . . . . . . . . . . . . . . 16 112 4. Fixed Length UDFs . . . . . . . . . . . . . . . . . . . . . . 16 113 4.1. Nonce Type . . . . . . . . . . . . . . . . . . . . . . . 16 114 4.2. OID Identified Sequence . . . . . . . . . . . . . . . . . 16 115 4.3. Encryption/Authentication Type . . . . . . . . . . . . . 17 116 4.4. Key Pair Derivation . . . . . . . . . . . . . . . . . . . 18 117 4.4.1. Extraction step . . . . . . . . . . . . . . . . . . . 19 118 4.4.2. Elliptic Curve Diffie Hellman Key Pairs type 1-4 . . 21 119 4.4.3. Elliptic Curve Diffie Hellman Key Pairs type 5-7 . . 22 120 4.4.4. RSA Key Pairs . . . . . . . . . . . . . . . . . . . . 24 121 4.4.5. Any Key Algorithm . . . . . . . . . . . . . . . . . . 25 122 4.5. Shamir Shared Secret . . . . . . . . . . . . . . . . . . 26 123 4.5.1. Secret Generation . . . . . . . . . . . . . . . . . . 27 124 4.5.2. Recovery . . . . . . . . . . . . . . . . . . . . . . 28 125 5. Variable Length UDFs . . . . . . . . . . . . . . . . . . . . 29 126 5.1. Content Digest . . . . . . . . . . . . . . . . . . . . . 30 127 5.1.1. Content Digest Value . . . . . . . . . . . . . . . . 30 128 5.1.2. Typed Content Digest Value . . . . . . . . . . . . . 30 129 5.1.3. Compression . . . . . . . . . . . . . . . . . . . . . 31 130 5.1.4. Presentation . . . . . . . . . . . . . . . . . . . . 31 131 5.1.5. Example Encoding . . . . . . . . . . . . . . . . . . 32 132 5.1.6. Using SHA-2-512 Digest . . . . . . . . . . . . . . . 32 133 5.1.7. Using SHA-3-512 Digest . . . . . . . . . . . . . . . 33 134 5.1.8. Using SHA-2-512 Digest with Compression . . . . . . . 34 135 5.1.9. Using SHA-3-512 Digest with Compression . . . . . . . 35 136 5.2. Authenticator UDF . . . . . . . . . . . . . . . . . . . . 35 137 5.2.1. Content Digest Value . . . . . . . . . . . . . . . . 36 138 5.2.2. Authentication Value . . . . . . . . . . . . . . . . 36 139 5.3. Content Type Values . . . . . . . . . . . . . . . . . . . 38 140 5.3.1. PKIX Certificates and Keys . . . . . . . . . . . . . 39 141 5.3.2. OpenPGP Key . . . . . . . . . . . . . . . . . . . . . 39 142 5.3.3. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 40 144 6. UDF URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 40 145 6.1. Name form . . . . . . . . . . . . . . . . . . . . . . . . 40 146 6.2. Locator form . . . . . . . . . . . . . . . . . . . . . . 41 147 6.2.1. DNS Web service discovery . . . . . . . . . . . . . . 41 148 6.2.2. Content Identifier . . . . . . . . . . . . . . . . . 41 149 6.2.3. Target URI . . . . . . . . . . . . . . . . . . . . . 42 150 6.2.4. Postprocessing . . . . . . . . . . . . . . . . . . . 42 151 6.2.5. Decryption and Authentication . . . . . . . . . . . . 42 152 6.2.6. QR Presentation . . . . . . . . . . . . . . . . . . . 43 153 7. Strong Internet Names . . . . . . . . . . . . . . . . . . . . 43 154 8. Security Considerations . . . . . . . . . . . . . . . . . . . 43 155 8.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . 43 156 8.2. Availability . . . . . . . . . . . . . . . . . . . . . . 43 157 8.3. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 43 158 8.4. Work Factor and Precision . . . . . . . . . . . . . . . . 44 159 8.5. Semantic Substitution . . . . . . . . . . . . . . . . . . 45 160 8.6. QR Code Scanning . . . . . . . . . . . . . . . . . . . . 45 161 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 162 9.1. Protocol Service Name . . . . . . . . . . . . . . . . . . 46 163 9.2. Well Known . . . . . . . . . . . . . . . . . . . . . . . 47 164 9.3. URI Registration . . . . . . . . . . . . . . . . . . . . 47 165 9.4. Media Types Registrations . . . . . . . . . . . . . . . . 47 166 9.4.1. Media Type: application/pkix-keyinfo . . . . . . . . 47 167 9.4.2. Media Type: application/udf-encryption . . . . . . . 48 168 9.4.3. Media Type: application/udf-secret . . . . . . . . . 49 169 9.5. Uniform Data Fingerprint Type Identifier Registry . . . . 50 170 9.5.1. The name of the registry . . . . . . . . . . . . . . 50 171 9.5.2. Required information for registrations . . . . . . . 50 172 9.5.3. Applicable registration policy . . . . . . . . . . . 51 173 9.5.4. Size, format, and syntax of registry entries . . . . 51 174 9.5.5. Initial assignments and reservations . . . . . . . . 51 175 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 52 176 11. Appendix A: Prime Values for Secret Sharing . . . . . . . . . 52 177 12. Recovering Shamir Shared Secret . . . . . . . . . . . . . . . 53 178 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 55 179 13.1. Normative References . . . . . . . . . . . . . . . . . . 55 180 13.2. Informative References . . . . . . . . . . . . . . . . . 57 181 13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 58 182 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 58 184 1. Introduction 186 A Uniform Data Fingerprint (UDF) is a generalized format for 187 presenting and interpreting short binary sequences representing 188 cryptographic keys or fingerprints of data of any specified type. 189 The UDF format provides a superset of the OpenPGP [RFC4880] 190 fingerprint encoding capability with greater encoding density and 191 readability. 193 This document describes the syntax and encoding of UDFs, the means of 194 constructing and comparing them and their use in other Internet 195 addressing schemes. 197 1.1. UDF Types 199 Two categories of UDF are described. Data UDFs provide a compact 200 presentation of a fixed length binary data value in a format that is 201 convenient for data entry. A Data UDF may represent a cryptographic 202 key or nonce value or a part share of a key generated using a secret 203 sharing mechanism. Fingerprint UDFs provide a compact presentation 204 of a Message Digest or Message Authentication Code value. 206 Both categories of UDF are encoded as a UDF binary sequence, the 207 first octet of which is a Type Identifier and the remaining octets 208 specify the binary value according to the type identifier and data 209 referenced. 211 UDFs are typically presented to the user as a Base32 encoded sequence 212 in groups of five characters separated by dashes. This format 213 provides a useful balance between compactness and readability. The 214 type identifier codes have been selected so as to provide a useful 215 mnemonic when presented in Base32 encoding. 217 The following are examples of UDF values: 219 NCBK-3L4L-5FCU-Z7XQ-YXLW-YLNX-3XDA 220 EASQ-52VB-VDJY-XBXW-2BVQ-PVJD-XPKQ 221 SAQC-GKXI-6DTJ-COKM-4HBF-CZJJ-BO6G-I 222 MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4 223 KCM5-7VB6-IJXJ-WKHX-NZQF-OKGZ-EWVN 224 AAPM-DJQ6-HQZE-F5RL-RPKS-X6MK-YVNQ 225 OAYC-4MAH-AYBS-WZLQ-AUAA-GIYA-AQQD-MY6I-J5EC-OJ6A-TGDK-YGML-XX3M-N6WZ-3O6L-OSBV-J2FU-VCTT-SGVF-QVA 227 Like email addresses, UDFs are not a Uniform Resource Identifier 228 (URI) but may be expressed in URI form by adding the scheme 229 identifier (UDF) for use in contexts where an identifier in URI 230 syntax is required. A UDF URI MAY contain a domain name component 231 allowing it to be used as a locator 233 1.1.1. Cryptographic Keys and Nonces 235 A Nonce (N) UDF represents a short, fixed length randomly chosen 236 binary value. 238 Nonce UDFs are used within many Mesh protocols and data formats where 239 it is necessary to represent a nonce value in text form. 241 Nonce UDF: 242 NCBK-3L4L-5FCU-Z7XQ-YXLW-YLNX-3XDA 244 An Encryption/Authentication (E) UDF has the same format as a Random 245 UDF but is identified as being intended to be used as a symmetric key 246 for encryption and/or authentication. 248 KeyValue: 249 25 0E EA A1 A8 D3 8B 86 F6 D0 6B 07 D5 23 BB D5 251 Encryption/Authenticator UDF: 252 EASQ-52VB-VDJY-XBXW-2BVQ-PVJD-XPKQ 254 A Share (S) UDF also represents a short, fixed length binary value 255 but only provides one share in secret sharing scheme. Recovery of 256 the binary value requires a sufficient number of shares. 258 Share UDFs are used in the Mesh to support key and data escrow 259 operations without the need to rely on trusted hardware. A share UDF 260 can be copied by hand or printed in human or machine-readable form 261 (e.g. QR code). 263 Key: EASQ-52VB-VDJY-XBXW-2BVQ-PVJD-XPKQ 264 Share 0: SAQC-GKXI-6DTJ-COKM-4HBF-CZJJ-BO6G-I 265 Share 1: SAQS-CRXH-IASE-5ZYS-ZS2D-PQT4-6O6P-G 266 Share 2: SARB-6YXF-R5RA-ZFGY-W6TB-4H6Q-3O6Y-E 268 1.1.2. Fingerprint type UDFS 270 Fingerprint type UDFs contains a fingerprint value calculated over a 271 content data item and an IANA media type. 273 A Content Digest type UDF is a fingerprint type UDF in which the 274 fingerprint is formed using a cryptographic algorithm. Two digest 275 algorithms are currently supported, SHA-2-512 (M, for Merkle Damgard) 276 and SHA-3-512 (K, for Keccak). 278 The inclusion of the media type in the calculation of the UDF value 279 provides protection against semantic substitution attacks in which 280 content that has been found to be trustworthy when interpreted as one 281 content type is presented in a context in which it is interpreted as 282 a different content type in which it is unsafe. 284 SHA-2-512: MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4 285 SHA-3-512: KCM5-7VB6-IJXJ-WKHX-NZQF-OKGZ-EWVN 286 An Authentication UDF (A) is formed in the same manner as a 287 fingerprint but using a Message Authentication Code algorithm and a 288 symmetric key. 290 Authentication UDFs are used to express commitments and to provide a 291 means of blinding fingerprint values within a protocol by means of a 292 nonce. 294 SHA-2-512: AAPM-DJQ6-HQZE-F5RL-RPKS-X6MK-YVNQ 296 1.2. UDF URIs 298 The UDF URI scheme allows use of a UDF in contexts where a URF is 299 expected. The UDF URI scheme has two forms, name and locator. 301 1.2.1. Name Form 303 Name form UDF URIs identify a data resource but do not provide a 304 means of discovery. The URI is simply the scheme (udf) followed by 305 the UDF value: 307 udf:MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4 309 1.2.2. Locator Form 311 Locator form UDF URIs identify a data resource and provide a hint 312 that MAY provide a means of discovery. If the content is not 313 available from the location indicated, content obtained from a 314 different source that matches the fingerprint MAY be used instead. 316 udf://example.com/MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4 318 UDF locator form URIs presenting a fingerprint type UDF provide a 319 tight binding of the content to the locator. This allows the 320 resolved content to be verified and rejected if it has been modified. 322 UDF locator form URIs presenting an Encryptor/Authenticator type UDF 323 provide a mechanism for identification, discovery and decryption of 324 encrypted content. UDF locators of this type are known as Encrypted/ 325 Authenticated Resource Locators (EARLs). 327 Regardless of the type of the embedded UDF, UDF locator form URIs are 328 resolved by first performing DNS Web Service Discovery to identify 329 the Web Service Endpoint for the mmm-udf service at the specified 330 domain. 332 Resolution is completed by presenting the Content Digest Fingerprint 333 of the UDF value specified in the URI to the specified Web Service 334 Endpoint and performing a GET method request on the result. 336 For example, Alice subscribes to Example.com, a purveyor of cat and 337 kitten images. The company generates paper and electronic invoices 338 on a monthly basis. 340 To generate the paper invoice, Example.com first creates a new 341 encryption key: 343 ECAW-6G6I-4HYJ-KD6L-WJDX-R6IJ-AQT5-3P 345 One or more electronic forms of the invoice are encrypted under the 346 key ECAW-6G6I-4HYJ-KD6L-WJDX-R6IJ-AQT5-3P and placed on the 347 Example.com Web site so that the appropriate version is returned if 348 Alice scans the QR code. 350 The key is then converted to form an EARL for the example.com UDF 351 resolution service: 353 udf://example.com/ECAW-6G6I-4HYJ-KD6L-WJDX-R6IJ-AQT5-3P 355 The EARL is then rendered as a QR code: 357 [[This figure is not viewable in this format. The figure is 358 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 359 udf.html [2].]] 361 QR Code with embedded decryption and location key 363 A printable invoice containing the QR code is now generated and sent 364 to Alice. 366 When Alice receives the invoice, she can pay it by simply scanning 367 the invoice with a device that recognizes at least one of the invoice 368 formats supported by Example.com. 370 The UDF EARL locator shown above is resolved by first determining the 371 Web Service Endpoint for the mmm-udf service for the domain 372 example.com. 374 Discover ("example.com", "mmm-udf") = 375 https://example.com/.well-known/mmm-udf/ 377 Next the fingerprint of the source UDF is obtained. 379 UDF (ECAW-6G6I-4HYJ-KD6L-WJDX-R6IJ-AQT5-3P) = 380 MAOO-D45B-PDED-VQFN-SLJB-BCVP-ZBXO-HWOP-BTDC-7CAM-SUYW-5JUU-OL6X-YTFF 382 Combining the Web Service Endpoint and the fingerprint of the source 383 UDF provides the URI from which the content is obtained using the 384 normal HTTP GET method: 386 https://example.com/.well-known/mmm-udf/MAOO-D45B-PDED-VQFN-SLJB- 387 BCVP-ZBXO-HWOP-BTDC-7CAM-SUYW-5JUU-OL6X-YTFF 389 Having established that Alice can read postal mail sent to a physical 390 address and having delivered a secret to that address, this process 391 might be extended to provide a means of automating the process of 392 enrolment in electronic delivery of future invoices. 394 1.3. Secure Internet Names 396 A SIN is an Internet Identifier that contains a UDF fingerprint of a 397 security policy document that may be used to verify the 398 interpretation of the identifier. This permits traditional forms of 399 Internet address such as URIs and RFC822 email addresses to be used 400 to express a trusted address that is independent of any trusted third 401 party. 403 This document only describes the syntax and interpretation of the 404 identifiers themselves. The means by which the security policy 405 documents bound to an address govern interpretation of the name is 406 discussed separately in [draft-hallambaker-mesh-trust] . 408 For example, Example Inc holds the domain name example.com and has 409 deployed a private CA whose root of trust is a PKIX certificate with 410 the UDF fingerprint MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ. 412 Alice is an employee of Example Inc., she uses three email addresses: 414 alice@example.com A regular email address (not a SIN). 416 alice@mm--mb2gk-6duf5-ygyyl-jny5e-rwshz.example.com A strong email 417 address that is backwards compatible. 419 alice@example.com.mm--mb2gk-6duf5-ygyyl-jny5e-rwshz A strong email 420 address that is backwards incompatible. 422 All three forms of the address are valid RFC822 addresses and may be 423 used in a legacy email client, stored in an address book application, 424 etc. But the ability of a legacy client to make use of the address 425 differs. Addresses of the first type may always be used. Addresses 426 of the second type may only be used if an appropriate MX record is 427 provisioned. Addresses of the third type will always fail unless the 428 resolver understands that it is a SIN requiring special processing. 430 These rules allow Bob to send email to Alice with either 'best 431 effort' security or mandatory security as the circumstances demand. 433 2. Definitions 435 This section presents the related specifications and standard, the 436 terms that are used as terms of art within the documents and the 437 terms used as requirements language. 439 2.1. Requirements Language 441 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 442 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 443 document are to be interpreted as described in [RFC2119] . 445 2.2. Defined Terms 447 Cryptographic Digest Function A hash function that has the 448 properties required for use as a cryptographic hash function. 449 These include collision resistance, first pre-image resistance and 450 second pre-image resistance. 452 Content Type An identifier indicating how a Data Value is to be 453 interpreted as specified in the IANA registry Media Types. 455 Commitment A cryptographic primitive that allows one to commit to a 456 chosen value while keeping it hidden to others, with the ability 457 to reveal the committed value later. 459 Data Value The binary octet stream that is the input to the digest 460 function used to calculate a digest value. 462 Data Object A Data Value and its associated Content Type 464 Digest Algorithm A synonym for Cryptographic Digest Function 466 Digest Value The output of a Cryptographic Digest Function 468 Data Digest Value The output of a Cryptographic Digest Function for 469 a given Data Value input. 471 Fingerprint A presentation of the digest value of a data value or 472 data object. 474 Fingerprint Presentation The representation of at least some part of 475 a fingerprint value in human or machine-readable form. 477 Fingerprint Improvement The practice of recording a higher precision 478 presentation of a fingerprint on successful validation. 480 Fingerprint Work Hardening The practice of generating a sequence of 481 fingerprints until one is found that matches criteria that permit 482 a compressed presentation form to be used. The compressed 483 fingerprint thus being shorter than but presenting the same work 484 factor as an uncompressed one. 486 Hash A function which takes an input and returns a fixed-size 487 output. Ideally, the output of a hash function is unbiased and 488 not correlated to the outputs returned to similar inputs in any 489 predictable fashion. 491 Precision The number of significant bits provided by a Fingerprint 492 Presentation. 494 Work Factor A measure of the computational effort required to 495 perform an attack against some security property. 497 2.3. Related Specifications 499 This specification makes use of Base32 [RFC4648] encoding, SHA-2 500 [SHA-2] and SHA-3 [SHA-3] digest functions in the derivation of basic 501 fingerprints. The derivation of keyed fingerprints additionally 502 requires the use of the HMAC [RFC2014] and HKDF [RFC5869] functions. 504 Resolution of UDF URI Locators makes use of DNS Web Service Discovery 505 [draft-hallambaker-web-service-discovery] . 507 2.4. Implementation Status 509 The implementation status of the reference code base is described in 510 the companion document [draft-hallambaker-mesh-developer] . 512 3. Architecture 514 A Uniform Data Fingerprint (UDF) is a presentation of a UDF Binary 515 Data Sequence. 517 This document specifies seven UDF Binary Data Sequence types and one 518 presentation. 520 The first octet of a UDF Binary Data Sequence identifies the UDF type 521 and is referred to as the Type identifier. 523 UDF Binary Data Sequence types are either fixed length or variable 524 length. A variable length Binary Data Sequence MUST be truncated for 525 presentation. Fixed length Binary Data Sequences MUST not be 526 truncated. 528 3.1. Base32 Presentation 530 The default UDF presentation is Base32 Presentation. 532 Variable length Binary Data Sequences are truncated to an integer 533 multiple of 20 bits that provides the desired precision before 534 conversion to Base32 form. 536 Fixed length Binary Data Sequences are converted to Base32 form 537 without truncation. 539 After conversion to Base32 form, dash '-' characters are inserted 540 between groups of 4 characters to aid reading. This representation 541 improves the accuracy of both data entry and verification. 543 3.1.1. Precision Improvement 545 Precision improvement is the practice of using a high precision UDF 546 (e.g. 260 bits) calculated from content data that has been validated 547 according to a lower precision UDF (e.g. 120 bits). 549 This allows a lower precision UDF to be used in a medium such as a 550 business card where space is constrained without compromising 551 subsequent uses. 553 Applications SHOULD make use of precision improvement wherever 554 possible. 556 3.2. Type Identifier 558 A Version Identifier consists of a single byte. 560 The byte codes have been chosen so that the first character of the 561 Base32 presentation of the UDF provides a mnemonic for its type. A 562 SHA-2 fingerprint UDF will always have M (for Merkle Damgard) as the 563 initial letter, a SHA-3 fingerprint UDF will always have K (for 564 Keccak) as the initial letter, and so on. 566 The following version identifiers are specified in this document: 568 +---------+---------+------------------------------------------+ 569 | Type ID | Initial | Algorithm | 570 +---------+---------+------------------------------------------+ 571 | 0 | A | HMAC-SHA-2-512 | 572 | 32 | E | HKDF-AES-512 | 573 | 80 | K | SHA-3-512 | 574 | 81 | K | SHA-3-512 (20 bits compressed) | 575 | 82 | K | SHA-3-512 (30 bits compressed) | 576 | 83 | K | SHA-3-512 (40 bits compressed) | 577 | 84 | K | SHA-3-512 (50 bits compressed) | 578 | 96 | M | SHA-2-512 | 579 | 97 | M | SHA-2-512 (20 bits compressed) | 580 | 98 | M | SHA-2-512 (30 bits compressed) | 581 | 99 | M | SHA-2-512 (40 bits compressed) | 582 | 100 | M | SHA-2-512 (50 bits compressed) | 583 | 104 | N | Nonce data | 584 | 112 | O | OID distinguished sequence (DER encoded) | 585 | 136 | R | Random generation seed | 586 | 144 | S | Shamir Secret Sharing | 587 | 200 | Z | Key pair derivation | 588 +---------+---------+------------------------------------------+ 590 Table 1 592 3.3. Content Type Identifier 594 A secure cryptographic digest algorithm provides a unique digest 595 value that is probabilistically unique for a particular byte sequence 596 but does not fix the context in which a byte sequence is interpreted. 597 While such ambiguity may be tolerated in a fingerprint format 598 designed for a single specific field of use, it is not acceptable in 599 a general-purpose format. 601 For example, the SSH and OpenPGP applications both make use of 602 fingerprints as identifiers for the public keys used but using 603 different digest algorithms and data formats for representing the 604 public key data. While no such vulnerability has been demonstrated 605 to date, it is certainly conceivable that a crafty attacker might 606 construct an SSH key in such a fashion that OpenPGP interprets the 607 data in an insecure fashion. If the number of applications making 608 use of fingerprint format that permits such substitutions is 609 sufficiently large, the probability of a semantic substitution 610 vulnerability being possible becomes unacceptably large. 612 A simple control that defeats such attacks is to incorporate a 613 content type identifier within the scope of the data input to the 614 hash function. 616 3.4. Truncation 618 Different applications of fingerprints demand different tradeoffs 619 between compactness of the representation and the number of 620 significant bits. A larger the number of significant bits reduces 621 the risk of collision but at a cost to convenience. 623 Modern cryptographic digest functions such as SHA-2 produce output 624 values of at least 256 bits in length. This is considerably larger 625 than most uses of fingerprints require and certainly greater than can 626 be represented in human readable form on a business card. 628 Since a strong cryptographic digest function produces an output value 629 in which every bit in the input value affects every bit in the output 630 value with equal probability, it follows that truncating the digest 631 value to produce a finger print is at least as strong as any other 632 mechanism if digest algorithm used is strong. 634 Using truncation to reduce the precision of the digest function has 635 the advantage that a lower precision fingerprint of some data content 636 is always a prefix of a higher prefix of the same content. This 637 allows higher precision fingerprints to be converted to a lower 638 precision without the need for special tools. 640 3.4.1. Compression 642 The Content Digest UDF types make use of work factor compression. 643 Additional type identifiers are used to indicate digest values with 644 20, 30, 40 or 50 trailing zero bits allowing a UDF fingerprint 645 offering the equivalent of up to 150 bits of precision to be 646 expressed in 20 characters instead of 30. 648 To use compressed UDF identifiers, it is necessary to search for 649 content that can be compressed. If the digest algorithm used is 650 secure, this means that by definition, the fastest means of search is 651 brute force. Thus, the reduction in fingerprint size is achieved by 652 transferring the work factor from the attacker to the defender. To 653 maintain a work factor of 2^120 with a 2^80 bits, it is necessary for 654 the content generator to perform a brute force search at a cost of 655 the order of 2^40 operations. 657 For example, the smallest allowable work factor for a UDF 658 presentation of a public key fingerprint is 92 bits. This would 659 normally require a presentation with 20 significant characters. 660 Reducing this to 16 characters requires a brute force search of 661 approximately 10^6 attempts. Reducing this to 12 characters would 662 require 10^12 attempts and to 10 characters, 10^15 attempts. 664 Omission of support for higher levels of compression than 2^50 is 665 intentional. 667 In addition to allowing use of shorter presentations, work factor 668 compression MAY be used as evidence of proof of work. 670 3.5. Presentation 672 The presentation of a fingerprint is the format in which it is 673 presented to either an application or the user. 675 Base32 encoding is used to produce the preferred text representation 676 of a UDF fingerprint. This encoding uses only the letters of the 677 Latin alphabet with numbers chosen to minimize the risk of ambiguity 678 between numbers and letters (2, 3, 4, 5, 6 and 7). 680 To enhance readability and improve data entry, characters are grouped 681 into groups of four. This means that each block of four characters 682 represents an increase in work factor of approximately one million 683 times. 685 3.6. Alternative Presentations 687 Applications that support UDF MUST support use of the Base32 688 presentation. Applications MAY support alternative presentations. 690 3.6.1. Word Lists 692 The use of a Word List to encode fingerprint values was introduced by 693 Patrick Juola and Philip Zimmerman for the PGPfone application. The 694 PGP Word List is designed to facilitate exchange and verification of 695 fingerprint values in a voice application. To minimize the risk of 696 misinterpretation, two-word lists of 256 values each are used to 697 encode alternative fingerprint bytes. The compact size of the lists 698 used allowed the compilers to curate them so as to maximize the 699 phonetic distance of the words selected. 701 The PGP Word List is designed to achieve a balance between ease of 702 entry and verification. Applications where only verification is 703 required may be better served by a much larger word list, permitting 704 shorter fingerprint encodings. 706 For example, a word list with 16384 entries permits 14 bits of the 707 fingerprint to be encoded at once, 65536 entries permits encoding of 708 16 bits. These encodings allow a 120 bit fingerprint to be encoded 709 in 9 and 8 words respectively. 711 3.6.2. Image List 713 An image list is used in the same manner as a word list affording 714 rapid visual verification of a fingerprint value. For obvious 715 reasons, this approach is not suited to data entry but is preferable 716 for comparison purposes. An image list of 1,048,576 images would 717 provide a 20 bit encoding allowing 120 bit precision fingerprints to 718 be displayed in six images. 720 4. Fixed Length UDFs 722 Fixed length UDFs are used to represent cryptographic keys, nonces 723 and secret shares and have a fixed length determined by their 724 function that cannot be truncated without loss of information. 726 All fixed length Binary Data Sequence values are an integer multiple 727 of eight bits. 729 4.1. Nonce Type 731 A Nonce Type UDF consists of the type identifier octet 104 followed 732 by the Binary Data Sequence value. 734 The Binary Data Sequence value is an integer number of octets that 735 SHOULD have been generated in accordance with processes and 736 procedures that ensure that it is sufficiently unpredictable for the 737 purposes of the protocol in which the value is to be used. 738 Requirements for such processes and procedures are described in 739 [RFC4086] . 741 Nonce Type UDFs are intended for use in contexts where it is 742 necessary for a randomly chosen value to be unpredictable but not 743 secret. For example, the challenge in a challenge/response 744 mechanism. 746 4.2. OID Identified Sequence 748 An OID Identified Sequence Type UDF consists of the type identifier 749 octet 108 followed by the Binary Data Sequence value. 751 The Binary Data Sequence value is an octet sequence that contains the 752 DER encoding of the following ASN.1 data: 754 OIDInfo ::= SEQUENCE { 755 algorithm AlgorithmIdentifier, 756 data BIT STRING } 758 AlgorithmIdentifier ::= SEQUENCE { 759 algorithm OBJECT IDENTIFIER, 760 parameters ANY DEFINED BY algorithm OPTIONAL } 762 OID Identified Sequences are intended to allow arbitrary data 763 sequences to be encoded in the UDF format without exhausting the 764 limited type identifier space. 766 In particular, OID Identified Sequences MAY be used to specify public 767 and private key values. 769 Given the following Ed25519 public key: 771 36 63 C8 4F 48 27 27 C0 99 86 AC 19 8B BD F6 C6 772 FA D9 DB BC B7 48 35 4E 8B 4A 8A 73 91 AA 58 54 774 The equivalent DER encoding is: 776 30 2E 30 07 06 03 2B 65 70 05 00 03 23 00 04 20 777 36 63 C8 4F 48 27 27 C0 99 86 AC 19 8B BD F6 C6 778 FA D9 DB BC B7 48 35 4E 8B 4A 8A 73 91 AA 58 54 780 To encode this key as a UDF OID sequence we prepend the value OID and 781 convert to Base32: 783 OAYC-4MAH-AYBS-WZLQ-AUAA-GIYA-AQQD-MY6I-J5EC-OJ6A-TGDK-YGML-XX3M-N6WZ-3O6L-OSBV-J2FU-VCTT-SGVF-QVA 785 The corresponding UDF content digest value is more compact and allows 786 us to identify the key unambiguously but does not provide the value: 788 MBP6-OFLY-YWEO-JINL-JJ63-KFAZ-X6DK 790 4.3. Encryption/Authentication Type 792 An Encryption/Authentication Type UDF consists of the type identifier 793 octet 0 followed by the Binary Data Sequence value. 795 The Binary Data Sequence value is an integer number of octets that 796 SHOULD have been generated in accordance with processes and 797 procedures that ensure that it is sufficiently unpredictable and 798 unguessable for the purposes of the protocol in which the value is to 799 be used. Requirements for such processes and procedures are 800 described in [RFC4086] . 802 Encryption/Authentication Type UDFs are intended to be used as a 803 means of specifying secret cryptographic keying material. For 804 example, the input to a Key Derivation Function used to encrypt a 805 document. Accordingly, the identifier UDF corresponding to an 806 Encryption/Authentication type UDF is a UDF fingerprint of the 807 Encryption/Authentication Type UDF in Base32 presentation with 808 content type 'application/udf-encryption'. 810 4.4. Key Pair Derivation 812 The key pair derivation type is used to specify a public key pair 813 value by means of a sufficiently random input to a deterministic key 814 generation function. 816 A key pair derivation Type UDF consists of the type identifier octet 817 200 followed by the Binary Data Sequence value. 819 The first two octets of the Binary Data Sequence value comprise the 820 Key Specifier which specifies the algorithm and key uses for which 821 the private key is to be derived. 823 o Bits 6-7 of the first octet specify the key use. 825 o Bits 0-5 of the first byte and bits 0-7 of the second specify the 826 key algorithm in network byte order. 828 In the unlikely event that this code space is ever exhausted, 829 allocation of a new UDF type code will be required. 831 The following key uses are specified: 833 +------+----------------+ 834 | Code | Key Use | 835 +------+----------------+ 836 | 0 | Any | 837 | 1 | Encryption | 838 | 2 | Signature | 839 | 3 | Authentication | 840 +------+----------------+ 842 Table 2 844 Derivation of key pairs for the following algorithms is specified in 845 this document: 847 +------+-----------+------------------------------------------------+ 848 | Code | Algorithm | Description | 849 +------+-----------+------------------------------------------------+ 850 | 0 | Any | Seed MAY be used to generate keypairs for any | 851 | | | algorithm | 852 | 1 | X25519 | X25519 keypair as described in RFC7748 | 853 | 2 | X448 | X448 keypair as described in RFC7748 | 854 | 3 | Ed25519 | Ed25519 keypair as described in RFC8032 | 855 | 4 | Ed448 | Ed448 keypair as described in RFC8032 | 856 | 5 | P-256 | NIST curve P-256 | 857 | 6 | P-384 | NIST curve P-384 | 858 | 7 | P-521 | NIST curve P-521 | 859 | 8 | RSA-2048 | 2048 bit RSA keypair | 860 | 9 | RSA-3072 | 3072 bit RSA keypair | 861 | 10 | RSA-4096 | 4096 bit RSA keypair | 862 +------+-----------+------------------------------------------------+ 864 Table 3 866 It is intended that the key derivation mechanism completely specify 867 all parameters of the keypair generated for all key algorithms other 868 than type 0 which is intended for applications where multiple keys 869 are to be generated. 871 The HKDF function [RFC5869] is used to derive key pairs for all the 872 algorithms specified in this document. Derivation functions for 873 additional key algorithms MAY use a different function for this 874 purpose provided that it meets the applicable security requirements. 876 The HKDF function is specified as a two-step extract-expand process 877 with an optional non-secret value input at both steps. 879 4.4.1. Extraction step 881 The HKDF extraction step calculates a PRK value from a salt and IKM: 883 HKDF-Extract(salt, IKM) -> PRK 885 The IKM value is the binary presentation of the complete Binary Data 886 Sequence as originally specified. 888 The salt value is the 16-bit Key Specifier value specifying the 889 algorithm for which the key pair is to be derived in network byte 890 order. Note that this value MAY differ from the one specified in the 891 Binary Data Sequence by the replacement of algorithm type or key use 892 Any with a specific algorithm or key use. 894 The output from the extraction step forms the input to the expand 895 step: 897 HKDF-Expand(PRK, info, L) -> OKM 899 For cases where the key pair generation requires a single parameter, 900 the value info is the null string and it suffices to specify the 901 number of bits required and how they are to be used to generate the 902 algorithm parameter. 904 For cases where the key pair generation requires multiple parameters, 905 a different value of the info parameter is required for each. 907 An X25519 key may be derived as follows: 909 Fingerprint = 910 ZAAQ-AWMQ-6Z4O-RRMM-Y72J-CGWI-ZC7L-V5Y 912 IKM = 914 01 00 59 90 F6 78 E8 C5 8C C7 F4 91 1A C8 C8 BE 915 BA F7 917 salt = 919 00 01 921 PRK = 923 77 10 30 58 FD BD 73 F2 9C AE 54 32 CE F7 7F 62 924 8E 30 73 5D FB 36 F1 D7 D5 AF 86 8A E8 E4 AD AD 925 36 A3 EA 74 9D 35 71 AE 9B 59 D8 57 04 A2 38 DE 926 AE AF 5E 1C EF 9B EC F6 5C 17 F5 ED 72 09 16 8E 928 OKM = 930 FD AF F9 15 55 C1 BD F2 21 AA DD 1F 1E B9 DB 29 931 4D 5F 6C C6 60 84 89 DA 25 8F F0 94 D7 0D 80 4E 933 Key = 935 FD AF F9 15 55 C1 BD F2 21 AA DD 1F 1E B9 DB 29 936 4D 5F 6C C6 60 84 89 DA 25 8F F0 94 D7 0D 80 4E 938 Derivation of an X448 key: 940 Fingerprint = 941 ZABA-AWMQ-6Z4O-RRMM-Y72J-CGWI-ZC7L-V5Y 943 Key = 945 EF 92 B1 E1 D7 F6 2C D1 54 D8 34 02 E1 7A F1 CD 946 C5 B7 6F 6D 16 0B B0 35 31 27 D0 ED 8D F2 83 08 947 BA 89 0D 02 44 D3 00 4D 22 51 F8 F6 12 9C C2 B9 948 F9 94 8D E8 BF 27 E1 0D 950 Derivation of an Ed25519 key: 952 Fingerprint = 953 ZABQ-AWMQ-6Z4O-RRMM-Y72J-CGWI-ZC7L-V5Y 955 Key = 957 5F 9E 2B 35 31 43 1E 82 27 63 9B B5 31 3F 4C 63 958 97 AD C1 57 0C 77 39 87 3D 48 80 15 5C 4A 9C 5A 960 Derivation of an Ed448 key: 962 Fingerprint = 963 ZACA-AWMQ-6Z4O-RRMM-Y72J-CGWI-ZC7L-V5Y 965 Key = 967 10 71 CF 00 BC 1E 44 FC 6F FA 42 26 8F 3C 9B 2A 968 E0 99 75 11 63 7A 58 A8 F9 10 44 CA 03 6D 74 3F 969 6E 63 B1 76 CF 4F 50 87 B1 4C DF 24 77 5C 01 B4 970 18 5C E7 4B B2 55 B4 3F 972 4.4.2. Elliptic Curve Diffie Hellman Key Pairs type 1-4 974 The generation of key pairs for X25519, X448, Ed25519 and Ed448 is 975 specified in [RFC7748] and [RFC8032] . In each case, the public and 976 private key parameters are generated from a string of random octets 977 whose transformation to the secret scalar function is described in 978 the document. 980 Thus, info is the null string and the value L is specified as 981 follows: 983 +-----------+-----+ 984 | Algorithm | L | 985 +-----------+-----+ 986 | X25519 | 256 | 987 | X448 | 448 | 988 | Ed25519 | 256 | 989 | Ed448 | 448 | 990 +-----------+-----+ 992 Table 4 994 4.4.3. Elliptic Curve Diffie Hellman Key Pairs type 5-7 996 The generation of key pairs for the curves P-256, P-384 and P-521 997 described in [RFC5903] is not mandated by the specification. FIPS 998 186-4 specifies two approaches. A modified form of the mechanism Key 999 Pair Generation Using Extra Random Bits specified in B.4.1 is used as 1000 follows: 1002 The number of random bits L is given by the following table: 1004 +-----------+-----+ 1005 | Algorithm | L | 1006 +-----------+-----+ 1007 | P-256 | 320 | 1008 | P-384 | 448 | 1009 | p-521 | 592 | 1010 +-----------+-----+ 1012 Table 5 1014 Note that this rounds up the number of random bits required to the 1015 nearest integer multiple of 8. 1017 The OKM value is interpreted as an integer in Network Byte Order, 1018 that is the first byte contains the most significant bits, to yield 1019 the parameter c. 1021 The parameter c is reduced modulo the value of the prime field n to 1022 yield the secret scalar value d: 1024 d = (c mod (n?1)) + 1. 1026 A P-256 key may be derived as follows: 1028 Fingerprint = 1029 ZACQ-AWMQ-6Z4O-RRMM-Y72J-CGWI-ZC7L-V5Y 1031 IKM = 1033 05 00 59 90 F6 78 E8 C5 8C C7 F4 91 1A C8 C8 BE 1034 BA F7 1036 salt = 1038 00 05 1040 PRK = 1042 2F F8 A6 0C 93 EE 5D 95 16 A1 A5 DF 14 23 DF EE 1043 9C 37 00 E3 70 15 67 C4 CB A7 C8 FD 60 6E 1E A5 1044 7A 8B FA A4 4D 9F 1C B3 5A 65 1A F0 13 CF 51 4A 1045 39 91 DC 3A F0 0F BF B9 46 B8 0B 39 F8 A7 9D 73 1047 OKM = 1049 20 4D 6B 02 50 95 2B A3 F0 AD 52 99 06 BF 35 EF 1050 A2 CC 29 DE B6 81 FC E8 7A 8C 61 3B B7 E1 BC 03 1051 46 FD 4E 3F 8A 9B E9 9F 1053 Key = 1054 29517818317606474424731106944963059094051184474659666357738150602666768668396 1056 Derivation of a P-384 key: 1058 Fingerprint = 1059 ZADA-AWMQ-6Z4O-RRMM-Y72J-CGWI-ZC7L-V5Y 1061 Key = 1062 7538639555333381362543748198716074550331744026645576164768364237981855441321415337444893114648720307648878992264274 1064 Derivation of a P-521 key: 1066 Fingerprint = 1067 ZADQ-AWMQ-6Z4O-RRMM-Y72J-CGWI-ZC7L-V5Y 1069 Key = 1070 4254438653806856039628887219107862462489155968475891405519695204965744942170843002142398305299586332566652756662550951341287293544107186308002274931076131802 1072 4.4.4. RSA Key Pairs 1074 Generation of RSA key pairs requires two parameters, p, q which are 1075 prime. 1077 +-----------+-------+------------------------+ 1078 | Parameter | Info | UTF8 equivalent string | 1079 +-----------+-------+------------------------+ 1080 | p | [112] | "p" | 1081 | q | [113] | "q" | 1082 +-----------+-------+------------------------+ 1084 Table 6 1086 The value of L is the same for generating the OKM values from which q 1087 are derived and is determined by the algorithm identifier: 1089 +-----------+------+ 1090 | Algorithm | L | 1091 +-----------+------+ 1092 | RSA-2048 | 1024 | 1093 | RSA-3072 | 1536 | 1094 | RSA-4096 | 2048 | 1095 +-----------+------+ 1097 Table 7 1099 The RSA parameter p is the smallest prime integer that is greater 1100 than the OKM value corresponding to the info value "p" interpreted as 1101 an integer in Network Byte Order. 1103 The RSA parameter q is the smallest prime integer that is greater 1104 than the OKM value corresponding to the info value "q" interpreted as 1105 an integer in Network Byte Order. 1107 Note that this algorithm does not mandate a particular method of 1108 primality testing nor does it impose any additional testing on the 1109 values p or q. If an application requires the use of primes with 1110 conditions it will be necessary to attempt multiple key derivations 1111 with different Binary Data Sequence values until parameters with the 1112 desired properties are found. 1114 An RSA-2048 may be derived as follows: 1116 Fingerprint = 1117 ZAEA-AWMQ-6Z4O-RRMM-Y72J-CGWI-ZC7L-V5Y 1119 IKM = 1121 08 00 59 90 F6 78 E8 C5 8C C7 F4 91 1A C8 C8 BE 1122 BA F7 1124 salt = 1126 00 08 1128 [Generation of the PRK as before] 1130 Info(p) = 1132 70 1134 OKM(p) = 1136 AF 9D 7F 33 1D FE AF 0E 1B 71 EE 79 D2 1E 48 5C 1137 0B E2 A8 0E 2D 0D DA D5 A3 C5 77 E6 E5 B7 24 54 1139 Info(q) = 1141 71 1143 OKM(q) = 1145 A4 64 D7 26 7C 8F 2C 58 4E 3E 48 76 CF 16 D9 23 1146 8B 37 1E 36 D7 1C E6 A9 42 0F 5D 6C 70 64 4C 3E 1148 Key P = 1149 79433021391143974031848114647364330348076405717070618206927737940721928709413 1151 Key Q = 1152 74357476787193681663524847034529980056457535777237022280922167274988363861059 1154 4.4.5. Any Key Algorithm 1156 The Any key algorithm allows a single UDF value to be used to derive 1157 key pairs for multiple algorithms. The IKM value is the same for 1158 each key pair derived. The salt value is changed according to the 1159 algorithm for which the key is to be derived. 1161 Fingerprint = 1162 ZAAA-AWMQ-6Z4O-RRMM-Y72J-CGWI-ZC7L-V5Y 1164 To generate an RSA-2048 key 1166 salt = 1168 00 08 1170 Key P = 1171 718967314252336962889032843079409376014265174888666187297957420072241741179 1173 Key Q = 1174 25068450812307283086472594076816116535331330421640150562982140290624673177047 1176 To generate an X25519 key 1178 salt = 1180 00 08 1182 Key = 1183 System.Byte[] 1185 4.5. Shamir Shared Secret 1187 The UDF format MAY be used to encode shares generated by a secret 1188 sharing mechanism. The only secret sharing mechanism currently 1189 supported is the Shamir Secret Sharing mechanism [Shamir79] . Each 1190 secret share represents a point represents a point on (x, f(x)), a 1191 polynomial in a modular field p. The secret being shared is an 1192 integer multiple of 32 bits represented by the polynomial value f(0). 1194 A Shamir Shared Secret Type UDF consists of the type identifier octet 1195 144 followed by the Binary Data Sequence value describing the share 1196 value. 1198 The first octet of the Binary Data Sequence value specifies the 1199 threshold value and the x value of the particular share: 1201 o Bits 4-7 of the first byte specify the threshold value. 1203 o Bits 0-3 of the first byte specify the x value minus 1. 1205 The remaining octets specify the value f(x) in network byte (big- 1206 endian) order with leading padding if necessary so that the share has 1207 the same number of bytes as the secret. 1209 The algorithm requires that the value p be a prime larger than the 1210 integer representing the largest secret being shared. For 1211 compactness of representation we chose p to be the smallest prime 1212 that is greater than 2^n where n is an integer multiple of 32. This 1213 approach leaves a small probability that a set of chosen polynomial 1214 parameters cause one or more share values be larger than 2^n. Since 1215 it is the value of the secret rather than the polynomial parameters 1216 that is of important, such parameters MUST NOT be used. 1218 4.5.1. Secret Generation 1220 To share a secret of L bits with a threshold of n we use a f(x) a 1221 polynomial of degree n in the modular field p: 1223 f(x) = a_0 + a_1.x + a_2.x^2 + ... a_n.x^n 1225 where: 1227 L Is the length of the secret in bits, an integer multiple of 32. 1229 n Is the threshold, the number of shares required to reconstitute 1230 the secret. 1232 a0 Is the integer representation of the secret to be shared. 1234 a1 ... an Are randomly chosen integers less than p 1236 p Is the smallest prime that is greater than 2^L. 1238 For L=128, p = 2^128+51. 1240 The values of the key shares are the values f(1), f(2),... f(n). 1242 The most straightforward approach to generation of Shamir secrets is 1243 to generate the set of polynomial coefficients, a_0, a_1, ... a_n and 1244 use these to generate the share values f(1), f(2),... f(n). 1246 Note that if this approach is adopted, there is a small probability 1247 that one or more of the values f(1), f(2),... f(n) exceeds the range 1248 of values supported by the encoding. Should this occur, at least one 1249 of the polynomial coefficients MUST be replaced. 1251 An alternative means of generating the set of secrets is to select up 1252 to n-1 secret share values and use secret recovery to determine at 1253 least one additional share. If n shares are selected, the shared 1254 secret becomes an output of rather than an input to the process. 1256 4.5.2. Recovery 1258 To recover the value of the shared secret, it is necessary to obtain 1259 sufficient shares to meet the threshold and recover the value f(0) = 1260 a_0. 1262 Applications MAY employ any approach that returns the correct result. 1263 The use of Lagrange basis polynomials is described in Appendix C. 1265 Alice decides to encrypt an important document and split the 1266 encryption key so that there are five key shares, three of which will 1267 be required to recover the key. 1269 Alice's master secret is 1270 5B 6C 65 6A 9F 4B 96 48 FF 28 22 61 DA 0B E6 C6 1272 This has the UDF representation: 1274 EBNW-YZLK-T5FZ-MSH7-FARG-DWQL-43DA 1276 The master secret is converted to an integer applying network byte 1277 order conventions. Since the master secret is 128 bits, it is 1278 guaranteed to be smaller than the modulus. The resulting value 1279 becomes the polynomial value a0. 1281 Since a threshold of three shares is required, we will need a second 1282 order polynomial. The co-efficients of the polynomial a1, a2 are 1283 random numbers smaller than the modulus: 1285 a0 = 121522572648003796848449289828724106950 1286 a1 = 26159740382122769271430827014393154562 1287 a2 = 158425778207454554551874765737306746629 1289 The master secret is the value f(0) = a0. The key shares are the 1290 values f(1), f(2)...f(5): 1292 f(1) = 306108091237581120671754882580424008141 1293 f(2) = 126980432400190626672060791943200979576 1294 f(3) = 264704329977709241776116232780591444269 1295 f(4) = 38715050128260039057171990229058979206 1296 f(5) = 129577326693719945441977279152140007401 1298 The first byte of each share specifies the recovery information 1299 (quorum, x value), the remaining bytes specify the share value in 1300 network byte order: 1302 f(1) = 1303 30 E6 4A 46 1F 2F BC 6F 4B FE E7 22 A7 1C 69 A1 1304 CD 1305 f(2) = 1306 31 5F 87 8A AD 93 BE 01 38 B7 E1 3E 61 0B 73 3A 1307 78 1308 f(3) = 1309 32 C7 24 33 15 CB 50 4C 0F 2A 16 75 8F A7 28 B1 1310 2D 1311 f(4) = 1312 33 1D 20 3F 57 D6 73 4F CF 55 86 C8 32 EF 8A 05 1313 86 1314 f(5) = 1315 34 61 7B AF 73 B5 27 0C 79 3A 32 36 4A E4 97 37 1316 E9 1318 The UDF presentation of the key shares is thus: 1320 f(1) = SAYO-MSSG-D4X3-Y32L-73TS-FJY4-NGQ4-2 1321 f(2) = SAYV-7B4K-VWJ3-4AJY-W7QT-4YIL-OM5H-Q 1322 f(3) = SAZM-OJBT-CXFV-ATAP-FILH-LD5H-FCYS-2 1323 f(4) = SAZR-2IB7-K7LH-GT6P-KWDM-QMXP-RICY-M 1324 f(5) = SA2G-C65P-OO2S-ODDZ-HIZD-MSXE-S436-S 1326 To recover the value f(0) from any three shares, we need to fit a 1327 polynomial curve to the three points and use it to calculate the 1328 value at x=0 using the Lagrange polynomial basis. 1330 5. Variable Length UDFs 1332 Variable length UDFs are used to represent fingerprint values 1333 calculated over a content type identifier and the cryptographic 1334 digest of a content data item. The fingerprint value MAY be 1335 specified at any integer multiple of 20 bits that provides a work 1336 factor sufficient for the intended purpose. 1338 Two types of fingerprint are specified: 1340 Digest fingerprints Are computed with the same cryptographic digest 1341 algorithm used to calculate the digest of the content data. 1343 Message Authentication Code fingerprints Are computed using a 1344 Message Authentication Code. 1346 For a given algorithm (and key, if requires), if two UDF fingerprints 1347 are of the same content data and content type, either the fingerprint 1348 values will be the same or the initial characters of one will be 1349 exactly equal to the other. 1351 5.1. Content Digest 1353 A Content Digest Type UDF consists of the type identifier octet 1354 followed by the Binary Data Sequence value. 1356 The type identifier specifies the digest algorithm used and the 1357 compression level. Two digest algorithms are currently specified 1358 with four compression levels for each making a total of eight 1359 possible type identifiers. 1361 The Content Digest UDF for given content data is generated by the 1362 steps of: 1364 1. Applying the digest algorithm to determine the Content Digest 1365 Value 1367 2. Applying the digest algorithm to determine the Typed Content 1368 Digest Value 1370 3. Determining the compression level from bytes 0-3 of the Typed 1371 Content Digest Value. 1373 4. Determining the Type Identifier octet from the Digest algorithm 1374 identifier and compression level. 1376 5. Truncating bytes 4-63 of the Typed Content Digest Value to 1377 determine the Binary Data Sequence value. 1379 5.1.1. Content Digest Value 1381 The Content Digest Value (CDV) is determined by applying the digest 1382 algorithm to the content data: 1384 CDV = H() 1386 Where 1388 H(x) is the cryptographic digest function 1390 is the binary data. 1392 5.1.2. Typed Content Digest Value 1394 The Typed Content Digest Value (TCDV) is determined by applying the 1395 digest algorithm to the content type identifier and the CDV: 1397 TCDV = H ( + ?:? + CDV) 1398 Where 1400 A + B represents concatenation of the binary sequences A and B. 1402 is the IANA Content Type of the data in UTF8 encoding 1404 The two-step approach to calculating the Type Content Digest Value 1405 allows an application to attempt to match a set of content data 1406 against multiple types without the need to recalculate the value of 1407 the content data digest. 1409 5.1.3. Compression 1411 The compression factor is determined according to the number of 1412 trailing zero bits in the first 8 bytes of the Typed Content Digest 1413 Value as follows: 1415 19 or fewer leading zero bits Compression factor = 0 1417 29 or fewer leading zero bits Compression factor = 20 1419 39 or fewer leading zero bits Compression factor = 30 1421 49 or fewer leading zero bits Compression factor = 40 1423 50 or more leading zero bits Compression factor = 50 1425 The least significant bits of each octet are regarded to be 1426 'trailing'. 1428 Applications MUST use compression when creating and comparing UDFs. 1429 Applications MAY support content generation techniques that search 1430 for UDF values that use a compressed representation. Presentation of 1431 a content digest value indicating use of compression MAY be used as 1432 an indicator of 'proof of work'. 1434 5.1.4. Presentation 1436 The type identifier is determined by the algorithm and compression 1437 factor as follows: 1439 +---------+---------+-----------+-------------+ 1440 | Type ID | Initial | Algorithm | Compression | 1441 +---------+---------+-----------+-------------+ 1442 | 80 | K | SHA-3-512 | 0 | 1443 | 81 | K | SHA-3-512 | 20 | 1444 | 82 | K | SHA-3-512 | 30 | 1445 | 83 | K | SHA-3-512 | 40 | 1446 | 84 | K | SHA-3-512 | 50 | 1447 | 96 | M | SHA-2-512 | 0 | 1448 | 97 | M | SHA-2-512 | 20 | 1449 | 98 | M | SHA-2-512 | 30 | 1450 | 99 | M | SHA-2-512 | 40 | 1451 | 100 | M | SHA-2-512 | 50 | 1452 +---------+---------+-----------+-------------+ 1454 Table 8 1456 The Binary Data Sequence value is taken from the Typed Content Digest 1457 Value starting at the 9^th octet and as many additional bytes as are 1458 required to meet the presentation precision. 1460 5.1.5. Example Encoding 1462 In the following examples, is the UTF8 encoding of the 1463 string "text/plain" and is the UTF8 encoding of the string 1464 "UDF Data Value" 1466 Data = 1467 55 44 46 20 44 61 74 61 20 56 61 6C 75 65 1469 ContentType = 1470 74 65 78 74 2F 70 6C 61 69 6E 1472 5.1.6. Using SHA-2-512 Digest 1473 H() = 1474 48 DA 47 CC AB FE A4 5C 76 61 D3 21 BA 34 3E 58 1475 10 87 2A 03 B4 02 9D AB 84 7C CE D2 22 B6 9C AB 1476 02 38 D4 E9 1E 2F 6B 36 A0 9E ED 11 09 8A EA AC 1477 99 D9 E0 BD EA 47 93 15 BD 7A E9 E1 2E AD C4 15 1479 + ':' + H() = 1480 74 65 78 74 2F 70 6C 61 69 6E 3A 48 DA 47 CC AB 1481 FE A4 5C 76 61 D3 21 BA 34 3E 58 10 87 2A 03 B4 1482 02 9D AB 84 7C CE D2 22 B6 9C AB 02 38 D4 E9 1E 1483 2F 6B 36 A0 9E ED 11 09 8A EA AC 99 D9 E0 BD EA 1484 47 93 15 BD 7A E9 E1 2E AD C4 15 1486 H( + ':' + H()) = 1487 C6 AF B7 C0 FE BE 04 E5 AE 94 E3 7B AA 5F 1A 40 1488 5B A3 CE CC 97 4D 55 C0 9E 61 E4 B0 EF 9C AE F9 1489 EB 83 BB 9D 5F 0F 39 F6 5F AA 06 DC 67 2A 67 71 1490 4F FF 8F 83 C4 55 38 36 38 AE 42 7A 82 9C 85 BB 1492 The prefixed Binary Data Sequence is thus 1493 60 C6 AF B7 C0 FE BE 04 E5 AE 94 E3 7B AA 5F 1A 1494 40 5B 1496 The 125 bit fingerprint value is MDDK-7N6A-727A-JZNO-STRX-XKS7-DJAF 1498 This fingerprint MAY be specified with higher or lower precision as 1499 appropriate. 1501 100 bit precision MDDK-7N6A-727A-JZNO-STRX 1503 120 bit precision MDDK-7N6A-727A-JZNO-STRX-XKS7 1505 200 bit precision MDDK-7N6A-727A-JZNO-STRX-XKS7-DJAF-XI6O-ZSLU-2VOA 1507 260 bit precision MDDK-7N6A-727A-JZNO-STRX-XKS7-DJAF-XI6O-ZSLU-2VOA- 1508 TZQ6-JMHP-TSXP 1510 5.1.7. Using SHA-3-512 Digest 1511 H() = 1512 6D 2E CF E6 93 5A 0C FC F2 A9 1A 49 E0 0C D8 07 1513 A1 4E 70 AB 72 94 6E CC BB 47 48 F1 8E 41 49 95 1514 07 1D F3 6E 0D 0C 8B 60 39 C1 8E B4 0F 6E C8 08 1515 65 B4 C4 45 9B A2 7E 97 74 7B BE 68 BC A8 C2 17 1517 + ':' + H() = 1518 74 65 78 74 2F 70 6C 61 69 6E 3A 6D 2E CF E6 93 1519 5A 0C FC F2 A9 1A 49 E0 0C D8 07 A1 4E 70 AB 72 1520 94 6E CC BB 47 48 F1 8E 41 49 95 07 1D F3 6E 0D 1521 0C 8B 60 39 C1 8E B4 0F 6E C8 08 65 B4 C4 45 9B 1522 A2 7E 97 74 7B BE 68 BC A8 C2 17 1524 H( + ':' + H()) = 1525 8A 86 8A 06 1C 54 6E 7E 3F 75 5F 39 88 F9 FD 2F 1526 8E C8 45 93 1B 80 A8 2F 29 16 7B A3 BE 21 1F 8A 1527 75 61 88 A1 D5 7F 07 D5 9D 68 A4 2D 17 F4 4D 23 1528 F9 E4 0B B2 1A 8D B9 F5 8D FC EC BD 01 F4 37 7C 1530 The prefixed Binary Data Sequence is thus 1531 50 8A 86 8A 06 1C 54 6E 7E 3F 75 5F 39 88 F9 FD 1532 2F 8E 1534 The 125 bit fingerprint value is KCFI-NCQG-DRKG-47R7-OVPT-TCHZ-7UXY 1536 5.1.8. Using SHA-2-512 Digest with Compression 1538 The content data "UDF Compressed Document 4187123" produces a UDF 1539 Content Digest SHA-2-512 binary value with 20 trailing zeros and is 1540 therefore presented using compressed presentation: 1542 Data = " 1543 55 44 46 20 43 6F 6D 70 72 65 73 73 65 64 20 44 1544 6F 63 75 6D 65 6E 74 20 34 31 38 37 31 32 33" 1546 The UTF8 Content Digest is given as: 1548 H() = 1549 36 21 FA 2A C5 D8 62 5C 2D 0B 45 FB 65 93 FC 69 1550 C1 ED F7 00 AE 6F E3 3D 38 13 FE AB 76 AA 74 13 1551 6D 5A 2B 20 DE D6 A5 CF 6C 04 E6 56 3F F3 C0 C7 1552 C4 1D 3F 43 DD DC F1 A5 67 A7 E0 67 9A B0 C6 B7 1554 + ':' + H() = 1555 74 65 78 74 2F 70 6C 61 69 6E 3A 36 21 FA 2A C5 1556 D8 62 5C 2D 0B 45 FB 65 93 FC 69 C1 ED F7 00 AE 1557 6F E3 3D 38 13 FE AB 76 AA 74 13 6D 5A 2B 20 DE 1558 D6 A5 CF 6C 04 E6 56 3F F3 C0 C7 C4 1D 3F 43 DD 1559 DC F1 A5 67 A7 E0 67 9A B0 C6 B7 1561 H( + ':' + H()) = 1562 8E 14 D9 19 4E D6 02 12 C3 30 A7 BB 5F C7 17 6D 1563 AE 9A 56 7C A8 2A 23 1F 96 75 ED 53 10 EC E8 F2 1564 60 14 24 D0 C8 BC 55 3D C0 70 F7 5E 86 38 1A 0B 1565 CB 55 9C B2 87 81 27 FF 3C EC E2 F0 90 A0 00 00 1567 The prefixed Binary Data Sequence is thus 1568 61 8E 14 D9 19 4E D6 02 12 C3 30 A7 BB 5F C7 17 1569 6D AE 1571 The 125 bit fingerprint value is MGHB-JWIZ-J3LA-EEWD-GCT3-WX6H-C5W2 1573 5.1.9. Using SHA-3-512 Digest with Compression 1575 The content data "UDF Compressed Document 774665" produces a UDF 1576 Content Digest SHA-3-512 binary value with 20 trailing zeros and is 1577 therefore presented using compressed presentation: 1579 Data = 1580 55 44 46 20 43 6F 6D 70 72 65 73 73 65 64 20 44 1581 6F 63 75 6D 65 6E 74 20 37 37 34 36 36 35 1583 The UTF8 SHA-3-512 Content Digest is KEJI-Y225-BDUG-XX22-MXKE-5ITF- 1584 YVYM 1586 5.2. Authenticator UDF 1588 An authenticator Type UDF consists of the type identifier octet 1589 followed by the Binary Data Sequence value. 1591 The type identifier specifies the digest and Message Authentication 1592 Code algorithm. Two algorithm suites are currently specified. Use 1593 of compression is not supported. 1595 The Authenticator UDF for given content data and key is generated by 1596 the steps of: 1598 1. Applying the digest algorithm to determine the Content Digest 1599 Value 1601 2. Applying the MAC algorithm to determine the Authentication value 1603 3. Determining the Type Identifier octet from the Digest algorithm 1604 identifier and compression level. 1606 4. Truncating the Authentication value to determine the Binary Data 1607 Sequence value. 1609 The key used to calculate and Authenticator type UDF is always a 1610 UNICODE string. If use of a binary value as a key is required, the 1611 value MUST be converted to a string format first. For example, by 1612 conversion to an Encryption/Authentication type UDF. 1614 5.2.1. Content Digest Value 1616 The Content Digest Value (CDV) is determined in the exact same 1617 fashion as for a Content Digest UDF by applying the digest algorithm 1618 to the content data: 1620 CDV = H()) 1622 Where 1624 H(x) is the cryptographic digest function 1626 is the binary data. 1628 5.2.2. Authentication Value 1630 The Authentication Value (AV) is determined by applying the digest 1631 algorithm to the content type identifier and the CDV: 1633 AV = MAC (, ( + ?:? + CDV)) 1635 Where 1637 is the authentication key as specified below 1639 MAC( , ) is the result of applying the Message 1640 Authentication Code algorithm to with Key and data 1642 The value is calculated as follows: 1644 IKM = UTF8 (Key) 1645 PRK = MAC (UTF8 ("KeyedUDFMaster"), IKM) 1646 OKM = HKDF-Expand(PRK, UTF8 ("KeyedUDFExpand"), HashLen) 1648 Where the function UTF8(string) converts a string to the binary UTF8 1649 representation, HKDF-Expand is as defined in [RFC5869] and the 1650 function MAC(k,m) is the HMAC function formed from the specified hash 1651 H(m) as specified in [RFC2014] . 1653 Keyed UDFs are typically used in circumstances where user interaction 1654 requires a cryptographic commitment type functionality 1656 In the following example, is the UTF8 encoding of the 1657 string "text/plain" and is the UTF8 encoding of the string 1658 "Konrad is the traitor". The randomly chosen key is NDD7-6CMX-H2FW- 1659 ISAL-K4VB-DQ3E-PEDM. 1661 Data = 1662 4B 6F 6E 72 61 64 20 69 73 20 74 68 65 20 74 72 1663 61 69 74 6F 72 1665 ContentType = 1666 74 65 78 74 2F 70 6C 61 69 6E 1668 Key = 1669 4E 44 44 37 2D 36 43 4D 58 2D 48 32 46 57 2D 49 1670 53 41 4C 2D 4B 34 56 42 2D 44 51 33 45 2D 50 45 1671 44 4D 1673 Processing is performed in the same manner as an unkeyed fingerprint 1674 except that compression is never used: 1676 H() = 1677 93 FC DA F9 FA FD 1E 26 50 26 C3 C1 28 43 40 73 1678 D8 BC 3D 62 87 73 2B 73 B8 EC 93 B6 DE 80 FF DA 1679 70 0A D1 CE E8 F4 36 68 EF 4E 71 63 41 53 91 5C 1680 CE 8C 5C CE C7 9A 46 94 6A 35 79 F9 33 70 85 01 1682 + ':' + H() = 1683 74 65 78 74 2F 70 6C 61 69 6E 3A 93 FC DA F9 FA 1684 FD 1E 26 50 26 C3 C1 28 43 40 73 D8 BC 3D 62 87 1685 73 2B 73 B8 EC 93 B6 DE 80 FF DA 70 0A D1 CE E8 1686 F4 36 68 EF 4E 71 63 41 53 91 5C CE 8C 5C CE C7 1687 9A 46 94 6A 35 79 F9 33 70 85 01 1689 PRK(Key) = 1690 77 D3 0A 08 39 BD 9D C0 97 44 DA 33 15 0A 42 5E 1691 CD 17 80 03 B3 CF CC 89 7A C7 84 12 B4 51 5B 25 1692 DC 26 F5 E1 1B 20 F3 89 2E 9A 1A 7B 0E 73 23 39 1693 0E C3 4C EF 2D 40 DA 05 B4 70 C6 1C 82 C1 49 33 1695 HKDF(Key) = 1696 BF A9 B4 58 9C 1D 68 D7 9A B7 11 F6 C8 98 59 14 1697 20 D7 82 67 C5 84 22 E5 A0 F9 93 52 B1 C3 87 EB 1698 05 06 CB C4 E4 D6 E6 EE 1F F0 D4 7A 97 68 5E CE 1699 28 1C CA AF D8 B5 D1 24 4A 71 EC E3 AC B5 D2 04 1701 MAC(, + ':' + H()) = 1702 4C C3 7F D3 F9 9E 52 CF 07 90 74 53 84 65 95 BC 1703 1A 2B A5 D1 68 9D 05 6D 06 C5 CA BF 17 CB E0 49 1704 95 39 57 08 79 C4 E5 49 D3 3A 59 A3 32 05 45 A6 1705 30 26 25 AE 8A F4 47 C6 1F B5 33 7F AD 69 A6 30 1707 The prefixed Binary Data Sequence is thus 1708 00 4C C3 7F D3 F9 9E 52 CF 07 90 74 53 84 65 95 1709 BC 1A 1711 The 125 bit fingerprint value is ABGM-G76T-7GPF-FTYH-SB2F-HBDF-SW6B 1713 5.3. Content Type Values 1715 While a UDF fingerprint MAY be used to identify any form of static 1716 data, the use of a UDF fingerprint to identify a public key signature 1717 key provides a level of indirection and thus the ability to identify 1718 dynamic data. The content types used to identify public keys are 1719 thus of particular interest. 1721 As described in the security considerations section, the use of 1722 fingerprints to identify a bare public key and the use of 1723 fingerprints to identify a public key and associated security policy 1724 information are very different. 1726 5.3.1. PKIX Certificates and Keys 1728 UDF fingerprints MAY be used to identify PKIX certificates, CRLs and 1729 public keys in the ASN.1 encoding used in PKIX certificates. 1731 Since PKIX certificates and CLRs contain security policy information, 1732 UDF fingerprints used to identify certificates or CRLs SHOULD be 1733 presented with a minimum of 200 bits of precision. PKIX applications 1734 MUST not accept UDF fingerprints specified with less than 200 bits of 1735 precision for purposes of identifying trust anchors. 1737 PKIX certificates, keys and related content data are identified by 1738 the following content types: 1740 application/pkix-cert A PKIX Certificate 1742 application/pkix-crl A PKIX CRL 1744 application/pkix-keyinfo The SubjectPublicKeyInfo structure defined 1745 in the PKIX certificate specification encoded using DER encoding 1746 rules. 1748 The SubjectPublicKeyInfo structure is defined in [RFC5280] as 1749 follows: 1751 SubjectPublicKeyInfo ::= SEQUENCE { 1752 algorithm AlgorithmIdentifier, 1753 subjectPublicKey BIT STRING } 1755 This schema results in an identical DER encoding to the OIDInfo 1756 sequence specified in section XXX. The distinction between these 1757 productions is that the OIDInfo schema is intended to be used to 1758 encode arbitrary data while the application/pkix-keyinfo content type 1759 is only intended to be used to describe public keys. 1761 5.3.2. OpenPGP Key 1763 OpenPGPv5 keys and key set content data are identified by the 1764 following content type: 1766 application/pgp-keys An OpenPGP key set. 1768 5.3.3. DNSSEC 1770 DNSSEC record data consists of DNS records which are identified by 1771 the following content type: 1773 application/dns A DNS resource record in binary format 1775 6. UDF URIs 1777 The UDF URI scheme describes a means of constructing URIs from a UDF 1778 value. 1780 Two forms or UDF URI are specified, Name and Locator. In both cases 1781 the URI MUST specify the scheme type "UDF", and a UDF fingerprint and 1782 MAY specify a query identifier and/or a fragment identifier. 1784 By definition a Locator form URI contains an authority field which 1785 MUST be a DNS domain name. The use of IP address forms for this 1786 purpose is not permitted. 1788 Name Form URIs allow static content data to be identified without 1789 specifying the means by which the content data may be retrieved. 1790 Locator form URIs allow static content data or dynamic network 1791 resources to be identified and the means of retrieval. 1793 The syntax of a UDF URI is a subset of the generic URI syntax 1794 specified in [RFC3986] . The use of userinfo and port numbers is not 1795 supported and the path part of the uri is a UDF in base32 1796 presentation. 1798 URI = "UDF:" udf [ "?" query ] [ "" fragment ] 1800 udf = name-form / locator-form 1802 name-form = udf-value 1803 locator-form = "//" authority "/" udf-value 1805 authority = host 1806 host = reg-name 1808 6.1. Name form 1810 Name form UDF URIs provide a means of presenting a UDF value in a 1811 context in which a URI form of a name is required without providing a 1812 means of resolution. 1814 Adding the UDF scheme prefix to a UDF fingerprint does not change the 1815 semantics of the fingerprint itself. The semantics of the name 1816 result from the context in which it is used. 1818 For example, a UDF value of any type MAY be used to give a unique 1819 targetNamespace value in an XML Schema [XMLSchema] 1821 6.2. Locator form 1823 The locator form of an unkeyed UDF URI is resolved by the following 1824 steps: 1826 o Use DNS Web service discovery to determine the Web Service 1827 Endpoint. 1829 o Determine the content identifier from the source URI. 1831 o Append the content identifier to the Web Service Endpoint as a 1832 suffix to form the target URI. 1834 o Retrieve content from the Web Service Endpoint by means of a GET 1835 method. 1837 o Perform post processing as specified by the UDF type. 1839 6.2.1. DNS Web service discovery 1841 DNS Web Discovery is performed as specified in 1842 [draft-hallambaker-web-service-discovery] for the service mmm-udf and 1843 domain name specified in the URI. For a full description of the 1844 discovery mechanism, consult the referenced specification. 1846 The use of DNS Web Discovery permits service providers to make full 1847 use of the load balancing and service description capabilities 1848 afforded by use of DNS SRV and TXT records in accordance with the 1849 approach described in [RFC6763] . 1851 If no SRV or TXT records are specified, DNS Web Discovery specifies 1852 that the Web Service Endpoint be the Well Known Service [RFC5785] 1853 with the prefix /.well-known/srv/mmm-udf. 1855 6.2.2. Content Identifier 1857 For all UDF types other than Secret Share, the Content Identifier 1858 value is the UDF SHA-2-512 Content Digest of the canonical form of 1859 the UDF specified in the source URI presented at twice the precision 1860 to a maximum of 440 bits. 1862 If the UDF is of type Secret Share, the shared secret MUST be 1863 recovered before the content identifier can be resolved. The shared 1864 secret is then expressed as a UDF of type Encryption/Authentication 1865 and the Content Identifier determined as for an Encryption/ 1866 Authentication type UDF. 1868 6.2.3. Target URI 1870 The target URI is formed by appending a slash separator '/' and the 1871 Content Identifier value to the Web Service Endpoint. 1873 Since the path portion of a URI is case sensitive, the UDF value MUST 1874 be specified in upper case and MUST include separator marks. 1876 6.2.4. Postprocessing 1878 After retrieving the content data, the resolver MUST perform post 1879 processing as indicated by the content type: 1881 Nonce No additional post processing is required. 1883 Content Digest The resolver MUST verify that the content returned 1884 matches the UDF fingerprint value. 1886 Authenticator The resolver MUST verify that the content returned 1887 matches the UDF fingerprint value. 1889 Encryption/Authentication The content data returned is decrypted and 1890 authenticated using the key specified in the UDF value as the 1891 initial keying material (see below). 1893 Secret Share (set) The content data returned is decrypted and 1894 authenticated using the shared secret as the initial keying 1895 material (see below). 1897 6.2.5. Decryption and Authentication 1899 The steps performed to decode cryptographically enhanced content data 1900 depends on the content type specified in the returned content. Two 1901 formats are currently supported: 1903 o DARE Envelope format as specified in [draft-hallambaker-mesh-dare] 1905 o Cryptographic Message Syntax (CMS) Symmetric Key Package as 1906 specified in [RFC6031] 1908 6.2.6. QR Presentation 1910 Encoding of a UDF URI as a QR code requires only the characters in 1911 alphanumeric encoding, thus achieving compactness with minimal 1912 overhead. 1914 7. Strong Internet Names 1916 A Strong Internet Name is an Internet address that is bound to a 1917 policy governing interpretation of that address by means of a Content 1918 Digest type UDF of the policy expressed as a UDF prefixed DNS label 1919 within the address itself. 1921 The Reserved LDH labels as defined in [RFC5890] that begin with the 1922 prefix mm-- are reserved for use as Strong Internet Names. The 1923 characters following the prefix are a Content Digest type UDF in 1924 Base32 presentation. 1926 Since DNS labels are limited to 63 characters, the presentation of 1927 the SIN itself is limited to 59 characters and thus 240 bits of 1928 precision. 1930 8. Security Considerations 1932 This section describes security considerations arising from the use 1933 of UDF in general applications. 1935 Additional security considerations for use of UDFs in Mesh services 1936 and applications are described in the Mesh Security Considerations 1937 guide [draft-hallambaker-mesh-security] . 1939 8.1. Confidentiality 1941 Encrypted locator is a bearer token 1943 8.2. Availability 1945 Corruption of a part of a shared secret may prevent recovery 1947 8.3. Integrity 1949 Shared secret parts do not contain context information to specify 1950 which secret they relate to. 1952 8.4. Work Factor and Precision 1954 A given UDF data object has a single fingerprint value that may be 1955 presented at different precisions. The shortest legitimate precision 1956 with which a UDF fingerprint may be presented has 96 significant bits 1958 A UDF fingerprint presents the same work factor as any other 1959 cryptographic digest function. The difficulty of finding a second 1960 data item that matches a given fingerprint is 2^n and the difficulty 1961 or finding two data items that have the same fingerprint is 2^(n/2). 1962 Where n is the precision of the fingerprint. 1964 For the algorithms specified in this document, n = 512 and thus the 1965 work factor for finding collisions is 2^256, a value that is 1966 generally considered to be computationally infeasible. 1968 Since the use of 512 bit fingerprints is impractical in the type of 1969 applications where fingerprints are generally used, truncation is a 1970 practical necessity. The longer a fingerprint is, the less likely it 1971 is that a user will check every character. It is therefore important 1972 to consider carefully whether the security of an application depends 1973 on second pre-image resistance or collision resistance. 1975 In most fingerprint applications, such as the use of fingerprints to 1976 identify public keys, the fact that a malicious party might generate 1977 two keys that have the same fingerprint value is a minor concern. 1978 Combined with a flawed protocol architecture, such a vulnerability 1979 may permit an attacker to construct a document such that the 1980 signature will be accepted as valid by some parties but not by 1981 others. 1983 For example, Alice generates keypairs until two are generated that 1984 have the same 100 bit UDF presentation (typically 2^48 attempts). 1985 She registers one keypair with a merchant and the other with her 1986 bank. This allows Alice to create a payment instrument that will be 1987 accepted as valid by one and rejected by the other. 1989 The ability to generate of two PKIX certificates with the same 1990 fingerprint and different certificate attributes raises very 1991 different and more serious security concerns. For example, an 1992 attacker might generate two certificates with the same key and 1993 different use constraints. This might allow an attacker to present a 1994 highly constrained certificate that does not present a security risk 1995 to an application for purposes of gaining approval and an 1996 unconstrained certificate to request a malicious action. 1998 In general, any use of fingerprints to identify data that has 1999 security policy semantics requires the risk of collision attacks to 2000 be considered. For this reason, the use of short, 'user friendly' 2001 fingerprint presentations (Less than 200 bits) SHOULD only be used 2002 for public key values. 2004 8.5. Semantic Substitution 2006 Many applications record the fact that a data item is trusted, rather 2007 fewer record the circumstances in which the data item is trusted. 2008 This results in a semantic substitution vulnerability which an 2009 attacker may exploit by presenting the trusted data item in the wrong 2010 context. 2012 The UDF format provides protection against high level semantic 2013 substitution attacks by incorporating the content type into the input 2014 to the outermost fingerprint digest function. The work factor for 2015 generating a UDF fingerprint that is valid in both contexts is thus 2016 the same as the work factor for finding a second preimage in the 2017 digest function (2^512 for the specified digest algorithms). 2019 It is thus infeasible to generate a data item such that some 2020 applications will interpret it as a PKIX key and others will accept 2021 as an OpenPGP key. While attempting to parse a PKIX key as an 2022 OpenPGP key is virtually certain to fail to return the correct key 2023 parameters it cannot be assumed that the attempt is guaranteed to 2024 fail with an error message. 2026 The UDF format does not provide protection against semantic 2027 substitution attacks that do not affect the content type. 2029 8.6. QR Code Scanning 2031 The act of scanning a QR code SHOULD be considered equivalent to 2032 clicking on an unlabeled hypertext link. Since QR codes are scanned 2033 in many different contexts, the mere act of scanning a QR code MUST 2034 NOT be interpreted as constituting an affirmative acceptance of terms 2035 or conditions or as creating an electronic signature. 2037 If such semantics are required in the context of an application, 2038 these MUST be established by secondary user actions made subsequent 2039 to the scanning of the QR code. 2041 There is a risk that use of QR codes to automate processes such as 2042 payment will lead to abusive practices such as presentation of 2043 fraudulent invoices for goods not ordered or delivered. It is 2044 therefore important to ensure that such requests are subject to 2045 adequate accountability controls. 2047 9. IANA Considerations 2049 Registrations are requested in the following registries: 2051 o Service Name and Transport Protocol Port Number 2053 o well-known URI registry 2055 o Uniform Resource Identifier (URI) Schemes 2057 o Media Types 2059 In addition, the creation of the following registry is requested: 2060 Uniform Data Fingerprint Type Identifier Registry. 2062 9.1. Protocol Service Name 2064 The following registration is requested in the Service Name and 2065 Transport Protocol Port Number Registry in accordance with [RFC6355] 2067 Service Name (REQUIRED) mmm-udf 2069 Transport Protocol(s) (REQUIRED) TCP 2071 Assignee (REQUIRED) Phillip Hallam-Baker, phill@hallambaker.com 2073 Contact (REQUIRED) Phillip Hallam-Baker, phill@hallambaker.com 2075 Description (REQUIRED) mmm-udf is a Web Service protocol that 2076 resolves Mathematical Mesh Uniform Data Fingerprints (UDF) to 2077 resources. The mmm-udf service name is used in service discovery 2078 to identify a Web Service endpoint to perform resolution of a UDF 2079 presented in URI locator form. 2081 Reference (REQUIRED) [This document] 2083 Port Number (OPTIONAL) None 2085 Service Code (REQUIRED for DCCP only) None 2087 Known Unauthorized Uses (OPTIONAL) None 2089 Assignment Notes (OPTIONAL) None 2091 9.2. Well Known 2093 The following registration is requested in the well-known URI 2094 registry in accordance with [RFC5785] 2096 URI suffix srv/mmm-udf 2098 Change controller Phillip Hallam-Baker, phill@hallambaker.com 2100 Specification document(s): [This document] 2102 Related information 2104 [draft-hallambaker-web-service-discovery] 2106 9.3. URI Registration 2108 The following registration is requested in the Uniform Resource 2109 Identifier (URI) Schemes registry in accordance with [RFC7595] 2111 Scheme name: UDF 2113 Status: Provisional 2115 Applications/protocols that use this scheme name: Mathematical Mesh 2116 Service protocols (mmm) 2118 Contact: Phillip Hallam-Baker mailto:phill@hallambaker.com 2120 Change controller: Phillip Hallam-Baker 2122 References: [This document] 2124 9.4. Media Types Registrations 2126 9.4.1. Media Type: application/pkix-keyinfo 2128 Type name: application 2130 Subtype name: pkix-keyinfo 2132 Required parameters: None 2134 Optional parameters: None 2136 Encoding considerations: Binary 2138 Security considerations: Described in [This] 2139 Interoperability considerations: None 2141 Published specification: [This] 2143 Applications that use this media type: Uniform Data Fingerprint 2145 Fragment identifier considerations: None 2147 Additional information: Deprecated alias names for this type: None 2149 Magic number(s): None 2151 File extension(s): None 2153 Macintosh file type code(s): None 2155 Person & email address to contact for further information: 2156 Phillip Hallam-Baker @hallambaker.com> 2158 Intended usage: Content type identifier to be used in constructing 2159 UDF Content Digests and Authenticators and related cryptographic 2160 purposes. 2162 Restrictions on usage: None 2164 Author: Phillip Hallam-Baker 2166 Change controller: Phillip Hallam-Baker 2168 Provisional registration? (standards tree only): Yes 2170 9.4.2. Media Type: application/udf-encryption 2172 Type name: application 2174 Subtype name: udf-encryption 2176 Required parameters: None 2178 Optional parameters: None 2180 Encoding considerations: None 2182 Security considerations: Described in [This] 2184 Interoperability considerations: None 2186 Published specification: [This] 2187 Applications that use this media type: Uniform Data Fingerprint 2189 Fragment identifier considerations: None 2191 Additional information: Deprecated alias names for this type: None 2193 Magic number(s): None 2195 File extension(s): None 2197 Macintosh file type code(s): None 2199 Person & email address to contact for further information: 2200 Phillip Hallam-Baker @hallambaker.com> 2202 Intended usage: Content type identifier to be used in constructing 2203 UDF Content Digests and Authenticators and related cryptographic 2204 purposes. 2206 Restrictions on usage: None 2208 Author: Phillip Hallam-Baker 2210 Change controller: Phillip Hallam-Baker 2212 Provisional registration? (standards tree only): Yes 2214 9.4.3. Media Type: application/udf-secret 2216 Type name: application 2218 Subtype name: udf- secret 2220 Required parameters: None 2222 Optional parameters: None 2224 Encoding considerations: None 2226 Security considerations: Described in [This] 2228 Interoperability considerations: None 2230 Published specification: [This] 2232 Applications that use this media type: Uniform Data Fingerprint 2234 Fragment identifier considerations: None 2235 Additional information: Deprecated alias names for this type: None 2237 Magic number(s): None 2239 File extension(s): None 2241 Macintosh file type code(s): None 2243 Person & email address to contact for further information: 2244 Phillip Hallam-Baker @hallambaker.com> 2246 Intended usage: Content type identifier to be used in constructing 2247 UDF Content Digests and Authenticators and related cryptographic 2248 purposes. 2250 Restrictions on usage: None 2252 Author: Phillip Hallam-Baker 2254 Change controller: Phillip Hallam-Baker 2256 Provisional registration? (standards tree only): Yes 2258 9.5. Uniform Data Fingerprint Type Identifier Registry 2260 This document describes a new extensible data format employing fixed 2261 length version identifiers for UDF types. 2263 9.5.1. The name of the registry 2265 Uniform Data Fingerprint Type Identifier Registry 2267 9.5.2. Required information for registrations 2269 Registrants must specify the Type identifier code(s) requested, 2270 description and RFC number for the corresponding standards action 2271 document. 2273 The standards document must specify the means of generating and 2274 interpreting the UDF Data Sequence Value and the purpose(s) for which 2275 it is proposed. 2277 Since the initial letter of the Base32 presentation provides a 2278 mnemonic function in UDFs, the standards document must explain why 2279 the proposed Type Identifier and associated initial letter are 2280 appropriate. In cases where a new initial letter is to be created, 2281 there must be an explanation of why this is appropriate. If an 2282 existing initial letter is to be created, there must be an 2283 explanation of why this is appropriate and/or acceptable. 2285 9.5.3. Applicable registration policy 2287 Due to the intended field of use (human data entry), the code space 2288 is severely constrained. Accordingly, it is intended that code point 2289 registrations be as infrequent as possible. 2291 Registration of new digest algorithms is strongly discouraged and 2292 should not occur unless, (1) there is a known security vulnerability 2293 in one of the two schemes specified in the original assignment and 2294 (2) the proposed algorithm has been subjected to rigorous peer 2295 review, preferably in the form of an open, international competition 2296 and (3) the proposed algorithm has been adopted as a preferred 2297 algorithm for use in IETF protocols. 2299 Accordingly, the applicable registration policy is Standards Action. 2301 9.5.4. Size, format, and syntax of registry entries 2303 Each registry entry consists of a single byte code, 2305 9.5.5. Initial assignments and reservations 2307 The following entries should be added to the registry as initial 2308 assignments: 2310 Code Description Reference 2311 --- ------------------- --------- 2312 00 HMAC and SHA-2-512 [This document] 2313 32 HKDF-AES-512 [This document] 2314 80 SHA-3-512 [This document] 2315 81 SHA-3-512 with 20 trailing zeros [This document] 2316 82 SHA-3-512 with 30 trailing zeros [This document] 2317 82 SHA-3-512 with 40 trailing zeros [This document] 2318 83 SHA-3-512 with 50 trailing zeros [This document] 2319 96 SHA-2-512 [This document] 2320 97 SHA-2-512 with 20 trailing zeros [This document] 2321 98 SHA-2-512 with 30 trailing zeros [This document] 2322 99 SHA-2-512 with 40 trailing zeros [This document] 2323 100 SHA-2-512 with 50 trailing zeros [This document] 2324 104 Random nonce [This document] 2325 144 Shamir Secret Share [This document] 2327 10. Acknowledgements 2329 A list of people who have contributed to the design of the Mesh is 2330 presented in [draft-hallambaker-mesh-architecture] . 2332 Thanks are due to Viktor Dukhovni, Damian Weber and an anonymous 2333 member of the cryptography@metzdowd.com list for assisting in the 2334 compilation of the table of prime values. 2336 11. Appendix A: Prime Values for Secret Sharing 2338 The following are the prime values to be used for sharing secrets of 2339 up to 512 bits. 2341 If it is necessary to share larger secrets, the corresponding prime 2342 may be found by choosing a value (2^32)^n that is larger than the 2343 secret to be encoded and determining the next largest number that is 2344 prime. 2346 +----------------+----------------------+ 2347 | Number of bits | Offset = Primen - 2n | 2348 +----------------+----------------------+ 2349 | 32 | 15 | 2350 | 64 | 13 | 2351 | 96 | 61 | 2352 | 128 | 51 | 2353 | 160 | 7 | 2354 | 192 | 133 | 2355 | 224 | 735 | 2356 | 256 | 297 | 2357 | 288 | 127 | 2358 | 320 | 27 | 2359 | 352 | 55 | 2360 | 384 | 231 | 2361 | 416 | 235 | 2362 | 448 | 211 | 2363 | 480 | 165 | 2364 | 512 | 75 | 2365 +----------------+----------------------+ 2367 Table 9 2369 For example, the prime to be used to share a 128 bit value is 2^128 + 2370 51. 2372 12. Recovering Shamir Shared Secret 2374 The value of a Shamir Shared secret may be recovered using Lagrange 2375 basis polynomials. 2377 To share a secret with a threshold of n shares and L bits we 2378 constructed f(x) a polynomial of degree n in the modular field p 2379 where p is the smallest prime greater than 2^L: 2381 f(x) = a_0 + a_1.x + a_2.x^2 + ... a_n.x^n 2383 The shared secret is the binary representation of the value a_0 2385 Given n shares (x_0, y_0), (x_1, y_1), ... (x_n-1, y_n-1), The 2386 corresponding the Lagrange basis polynomials l_0, l_1, .. l_n-1 are 2387 given by: 2389 lm = ((x - x(m_0)) / (x(m) - x(m_0))) . ((x - x(m_1)) / (x(m) - 2390 x(m_1))) . ... . ((x - x(m_n-2)) / (x(m) - x(m_n-2))) 2392 Where the values m_0, m_1, ... m_n-2, are the integers 0, 1, .. n-1, 2393 excluding the value m. 2395 These can be used to compute f(x) as follows: 2397 f(x) = y_0l_0 + y_1l_1 + ... y_n-1l_n-1 2399 Since it is only the value of f(0) that we are interested in, we 2400 compute the Lagrange basis for the value x = 0: 2402 lz_m = ((x(m_1)) / (x(m) - x(m_1))) . ((x(m_2)) / (x(m) - x(m_2))) 2404 Hence, 2406 a_0 = f(0) = y_0lz_0 + y_1lz_1 + ... y_n-1l_n-1 2408 The following C# code recovers the values. 2410 using System; 2411 using System.Collections.Generic; 2412 using System.Numerics; 2414 namespace Examples { 2416 class Examples { 2418 /// 2419 /// Combine a set of points (x, f(x)) 2420 /// on a polynomial of degree in a 2421 /// discrete field modulo prime to 2422 /// recover the value f(0) using Lagrange basis polynomials. 2423 /// 2424 /// The values f(x). 2425 /// The values for x. 2426 /// The modulus. 2427 /// The polynomial degree. 2428 /// The value f(0). 2429 static BigInteger CombineNK( 2430 BigInteger[] fx, 2431 int[] x, 2432 BigInteger p, 2433 int n) { 2434 if (fx.Length < n) { 2435 throw new Exception("Insufficient shares"); 2436 } 2438 BigInteger accumulator = 0; 2439 for (var formula = 0; formula < n; formula++) { 2440 var value = fx[formula]; 2442 BigInteger numerator = 1, denominator = 1; 2443 for (var count = 0; count < n; count++) { 2444 if (formula == count) { 2445 continue; // If not the same value 2446 } 2448 var start = x[formula]; 2449 var next = x[count]; 2451 numerator = (numerator * -next) % p; 2452 denominator = (denominator * (start - next)) % p; 2453 } 2455 var InvDenominator = ModInverse(denominator, p); 2457 accumulator = Modulus((accumulator + 2458 (fx[formula] * numerator * InvDenominator)), p); 2459 } 2461 return accumulator; 2462 } 2464 /// 2465 /// Compute the modular multiplicative inverse of the value 2466 /// modulo 2467 /// 2468 /// The value to find the inverse of 2469 /// The modulus. 2470 /// 2471 static BigInteger ModInverse( 2472 BigInteger k, 2473 BigInteger p) { 2474 var m2 = p - 2; 2475 if (k < 0) { 2476 k = k + p; 2477 } 2479 return BigInteger.ModPow(k, m2, p); 2480 } 2482 /// 2483 /// Calculate the modulus of a number with correct handling 2484 /// for negative numbers. 2485 /// 2486 /// Value 2487 /// The modulus. 2488 /// x mod p 2489 public static BigInteger Modulus( 2490 BigInteger x, 2491 BigInteger p) { 2492 var Result = x % p; 2493 return Result.Sign >= 0 ? Result : Result + p; 2494 } 2495 } 2496 } 2498 13. References 2500 13.1. Normative References 2502 [draft-hallambaker-mesh-architecture] 2503 Hallam-Baker, P., "Mathematical Mesh 3.0 Part I: 2504 Architecture Guide", draft-hallambaker-mesh- 2505 architecture-10 (work in progress), August 2019. 2507 [draft-hallambaker-mesh-dare] 2508 Hallam-Baker, P., "Mathematical Mesh 3.0 Part III : Data 2509 At Rest Encryption (DARE)", draft-hallambaker-mesh-dare-04 2510 (work in progress), August 2019. 2512 [draft-hallambaker-mesh-security] 2513 Hallam-Baker, P., "Mathematical Mesh Part VII: Security 2514 Considerations", draft-hallambaker-mesh-security-01 (work 2515 in progress), July 2019. 2517 [draft-hallambaker-web-service-discovery] 2518 Hallam-Baker, P., "DNS Web Service Discovery", draft- 2519 hallambaker-web-service-discovery-02 (work in progress), 2520 April 2019. 2522 [RFC2014] Weinrib, A. and J. Postel, "IRTF Research Group Guidelines 2523 and Procedures", BCP 8, RFC 2014, DOI 10.17487/RFC2014, 2524 October 1996. 2526 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2527 Requirement Levels", BCP 14, RFC 2119, 2528 DOI 10.17487/RFC2119, March 1997. 2530 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2531 Resource Identifier (URI): Generic Syntax", STD 66, 2532 RFC 3986, DOI 10.17487/RFC3986, January 2005. 2534 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 2535 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006. 2537 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2538 Housley, R., and W. Polk, "Internet X.509 Public Key 2539 Infrastructure Certificate and Certificate Revocation List 2540 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008. 2542 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 2543 Key Derivation Function (HKDF)", RFC 5869, 2544 DOI 10.17487/RFC5869, May 2010. 2546 [RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a 2547 Prime (ECP Groups) for IKE and IKEv2", RFC 5903, 2548 DOI 10.17487/RFC5903, June 2010. 2550 [RFC6031] Turner, S. and R. Housley, "Cryptographic Message Syntax 2551 (CMS) Symmetric Key Package Content Type", RFC 6031, 2552 DOI 10.17487/RFC6031, December 2010. 2554 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 2555 for Security", RFC 7748, DOI 10.17487/RFC7748, January 2556 2016. 2558 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 2559 Signature Algorithm (EdDSA)", RFC 8032, 2560 DOI 10.17487/RFC8032, January 2017. 2562 [SHA-2] NIST, "Secure Hash Standard", August 2015. 2564 [SHA-3] Dworkin, M., "SHA-3 Standard: Permutation-Based Hash and 2565 Extendable-Output Functions", August 2015. 2567 13.2. Informative References 2569 [draft-hallambaker-mesh-developer] 2570 Hallam-Baker, P., "Mathematical Mesh: Reference 2571 Implementation", draft-hallambaker-mesh-developer-08 (work 2572 in progress), April 2019. 2574 [draft-hallambaker-mesh-trust] 2575 Hallam-Baker, P., "Mathematical Mesh Part VI: The Trust 2576 Mesh", draft-hallambaker-mesh-trust-02 (work in progress), 2577 July 2019. 2579 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 2580 "Randomness Requirements for Security", BCP 106, RFC 4086, 2581 DOI 10.17487/RFC4086, June 2005. 2583 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 2584 Thayer, "OpenPGP Message Format", RFC 4880, 2585 DOI 10.17487/RFC4880, November 2007. 2587 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 2588 Uniform Resource Identifiers (URIs)", RFC 5785, 2589 DOI 10.17487/RFC5785, April 2010. 2591 [RFC5890] Klensin, J., "Internationalized Domain Names for 2592 Applications (IDNA): Definitions and Document Framework", 2593 RFC 5890, DOI 10.17487/RFC5890, August 2010. 2595 [RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based 2596 DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, 2597 DOI 10.17487/RFC6355, August 2011. 2599 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 2600 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013. 2602 [RFC7595] Thaler, D., Hansen, T., and T. Hardie, "Guidelines and 2603 Registration Procedures for URI Schemes", BCP 35, 2604 RFC 7595, DOI 10.17487/RFC7595, June 2015. 2606 [Shamir79] 2607 "[Reference Not Found!]". 2609 [XMLSchema] 2610 Gao, S., Sperberg-McQueen, C., Thompson, H., Mendelsohn, 2611 N., Beech, D., and M. Maloney, "W3C XML Schema Definition 2612 Language (XSD) 1.1 Part 1: Structures", April 2012. 2614 13.3. URIs 2616 [1] http://mathmesh.com/Documents/draft-hallambaker-mesh-udf.html 2618 [2] http://mathmesh.com/Documents/draft-hallambaker-mesh-udf.html 2620 Author's Address 2622 Phillip Hallam-Baker 2624 Email: phill@hallambaker.com