idnits 2.17.1 draft-hallambaker-mesh-udf-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1646 has weird spacing: '... suffix srv/m...' == Line 1970 has weird spacing: '... set of point...' == Line 1971 has weird spacing: '... degree in a...' == Line 1972 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 (July 3, 2019) is 1751 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 2150 -- Looks like a reference, but probably isn't: '2' on line 2152 == Missing Reference: 'This' is mentioned on line 1780, but not defined -- Obsolete informational reference (is this intentional?): RFC 5785 (Obsoleted by RFC 8615) Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hallam-Baker 3 Internet-Draft July 3, 2019 4 Intended status: Informational 5 Expires: January 4, 2020 7 Mathematical Mesh 3.0 Part II: Uniform Data Fingerprint. 8 draft-hallambaker-mesh-udf-03 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 This document is also available online at 46 http://mathmesh.com/Documents/draft-hallambaker-mesh-udf.html [1] . 48 Status of This Memo 50 This Internet-Draft is submitted in full conformance with the 51 provisions of BCP 78 and BCP 79. 53 Internet-Drafts are working documents of the Internet Engineering 54 Task Force (IETF). Note that other groups may also distribute 55 working documents as Internet-Drafts. The list of current Internet- 56 Drafts is at https://datatracker.ietf.org/drafts/current/. 58 Internet-Drafts are draft documents valid for a maximum of six months 59 and may be updated, replaced, or obsoleted by other documents at any 60 time. It is inappropriate to use Internet-Drafts as reference 61 material or to cite them other than as "work in progress." 63 This Internet-Draft will expire on January 4, 2020. 65 Copyright Notice 67 Copyright (c) 2019 IETF Trust and the persons identified as the 68 document authors. All rights reserved. 70 This document is subject to BCP 78 and the IETF Trust's Legal 71 Provisions Relating to IETF Documents 72 (https://trustee.ietf.org/license-info) in effect on the date of 73 publication of this document. Please review these documents 74 carefully, as they describe your rights and restrictions with respect 75 to this document. Code Components extracted from this document must 76 include Simplified BSD License text as described in Section 4.e of 77 the Trust Legal Provisions and are provided without warranty as 78 described in the Simplified BSD License. 80 Table of Contents 82 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 83 1.1. UDF Types . . . . . . . . . . . . . . . . . . . . . . . . 4 84 1.1.1. Cryptographic Keys and Nonces . . . . . . . . . . . . 5 85 1.1.2. Fingerprint type UDFS . . . . . . . . . . . . . . . . 6 86 1.2. UDF URIs . . . . . . . . . . . . . . . . . . . . . . . . 6 87 1.2.1. Name Form . . . . . . . . . . . . . . . . . . . . . . 7 88 1.2.2. Locator Form . . . . . . . . . . . . . . . . . . . . 7 89 1.3. Secure Internet Names . . . . . . . . . . . . . . . . . . 9 90 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 9 91 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 10 92 2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 10 93 2.3. Related Specifications . . . . . . . . . . . . . . . . . 11 94 2.4. Implementation Status . . . . . . . . . . . . . . . . . . 11 95 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 11 96 3.1. Base32 Presentation . . . . . . . . . . . . . . . . . . . 11 97 3.1.1. Precision Improvement . . . . . . . . . . . . . . . . 12 98 3.2. Type Identifier . . . . . . . . . . . . . . . . . . . . . 12 99 3.3. Content Type Identifier . . . . . . . . . . . . . . . . . 13 100 3.4. Truncation . . . . . . . . . . . . . . . . . . . . . . . 14 101 3.4.1. Compression . . . . . . . . . . . . . . . . . . . . . 14 102 3.5. Presentation . . . . . . . . . . . . . . . . . . . . . . 15 103 3.6. Alternative Presentations . . . . . . . . . . . . . . . . 15 104 3.6.1. Word Lists . . . . . . . . . . . . . . . . . . . . . 15 105 3.6.2. Image List . . . . . . . . . . . . . . . . . . . . . 16 106 4. Fixed Length UDFs . . . . . . . . . . . . . . . . . . . . . . 16 107 4.1. Nonce Type . . . . . . . . . . . . . . . . . . . . . . . 16 108 4.2. Encryption/Authentication Type . . . . . . . . . . . . . 16 109 4.3. Shamir Shared Secret . . . . . . . . . . . . . . . . . . 17 110 4.3.1. Secret Generation . . . . . . . . . . . . . . . . . . 17 111 4.3.2. Recovery . . . . . . . . . . . . . . . . . . . . . . 18 112 5. Variable Length UDFs . . . . . . . . . . . . . . . . . . . . 20 113 5.1. Content Digest . . . . . . . . . . . . . . . . . . . . . 20 114 5.1.1. Content Digest Value . . . . . . . . . . . . . . . . 21 115 5.1.2. Typed Content Digest Value . . . . . . . . . . . . . 21 116 5.1.3. Compression . . . . . . . . . . . . . . . . . . . . . 21 117 5.1.4. Presentation . . . . . . . . . . . . . . . . . . . . 22 118 5.1.5. Example Encoding . . . . . . . . . . . . . . . . . . 23 119 5.1.6. Using SHA-2-512 Digest . . . . . . . . . . . . . . . 23 120 5.1.7. Using SHA-3-512 Digest . . . . . . . . . . . . . . . 24 121 5.1.8. Using SHA-2-512 Digest with Compression . . . . . . . 24 122 5.1.9. Using SHA-3-512 Digest with Compression . . . . . . . 25 123 5.2. Authenticator UDF . . . . . . . . . . . . . . . . . . . . 25 124 5.2.1. Content Digest Value . . . . . . . . . . . . . . . . 26 125 5.2.2. Authentication Value . . . . . . . . . . . . . . . . 26 126 5.3. Content Type Values . . . . . . . . . . . . . . . . . . . 28 127 5.3.1. PKIX Certificates and Keys . . . . . . . . . . . . . 29 128 5.3.2. OpenPGP Key . . . . . . . . . . . . . . . . . . . . . 29 129 5.3.3. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 29 130 6. UDF URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 29 131 6.1. Name form . . . . . . . . . . . . . . . . . . . . . . . . 30 132 6.2. Locator form . . . . . . . . . . . . . . . . . . . . . . 30 133 6.2.1. DNS Web service discovery . . . . . . . . . . . . . . 31 134 6.2.2. Content Identifier . . . . . . . . . . . . . . . . . 31 135 6.2.3. Target URI . . . . . . . . . . . . . . . . . . . . . 31 136 6.2.4. Postprocessing . . . . . . . . . . . . . . . . . . . 32 137 6.2.5. Decryption and Authentication . . . . . . . . . . . . 32 138 6.2.6. QR Presentation . . . . . . . . . . . . . . . . . . . 32 139 7. Strong Internet Names . . . . . . . . . . . . . . . . . . . . 32 140 8. Security Considerations . . . . . . . . . . . . . . . . . . . 33 141 8.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . 33 142 8.2. Availability . . . . . . . . . . . . . . . . . . . . . . 33 143 8.3. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 33 144 8.4. Work Factor and Precision . . . . . . . . . . . . . . . . 33 145 8.5. Semantic Substitution . . . . . . . . . . . . . . . . . . 34 146 8.6. QR Code Scanning . . . . . . . . . . . . . . . . . . . . 35 147 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 148 9.1. Protocol Service Name . . . . . . . . . . . . . . . . . . 35 149 9.2. Well Known . . . . . . . . . . . . . . . . . . . . . . . 36 150 9.3. URI Registration . . . . . . . . . . . . . . . . . . . . 36 151 9.4. Media Types Registrations . . . . . . . . . . . . . . . . 37 152 9.4.1. Media Type: application/pkix-keyinfo . . . . . . . . 37 153 9.4.2. Media Type: application/udf-encryption . . . . . . . 38 154 9.4.3. Media Type: application/udf-secret . . . . . . . . . 39 155 9.5. Uniform Data Fingerprint Type Identifier Registry . . . . 40 156 9.5.1. The name of the registry . . . . . . . . . . . . . . 40 157 9.5.2. Required information for registrations . . . . . . . 40 158 9.5.3. Applicable registration policy . . . . . . . . . . . 40 159 9.5.4. Size, format, and syntax of registry entries . . . . 40 160 9.5.5. Initial assignments and reservations . . . . . . . . 41 161 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41 162 11. Appendix A: Prime Values for Secret Sharing . . . . . . . . . 41 163 12. Recovering Shamir Shared Secret . . . . . . . . . . . . . . . 42 164 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 165 13.1. Normative References . . . . . . . . . . . . . . . . . . 45 166 13.2. Informative References . . . . . . . . . . . . . . . . . 46 167 13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 47 168 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 47 170 1. Introduction 172 A Uniform Data Fingerprint (UDF) is a generalized format for 173 presenting and interpreting short binary sequences representing 174 cryptographic keys or fingerprints of data of any specified type. 175 The UDF format provides a superset of the OpenPGP [RFC4880] 176 fingerprint encoding capability with greater encoding density and 177 readability. 179 This document describes the syntax and encoding of UDFs, the means of 180 constructing and comparing them and their use in other Internet 181 addressing schemes. 183 1.1. UDF Types 185 Two categories of UDF are described. Data UDFs provide a compact 186 presentation of a fixed length binary data value in a format that is 187 convenient for data entry. A Data UDF may represent a cryptographic 188 key or nonce value or a part share of a key generated using a secret 189 sharing mechanism. Fingerprint UDFs provide a compact presentation 190 of a Message Digest or Message Authentication Code value. 192 Both categories of UDF are encoded as a UDF binary sequence, the 193 first octet of which is a Type Identifier and the remaining octets 194 specify the binary value according to the type identifier and data 195 referenced. 197 UDFs are typically presented to the user as a Base32 encoded sequence 198 in groups of five characters separated by dashes. This format 199 provides a useful balance between compactness and readability. The 200 type identifier codes have been selected so as to provide a useful 201 mnemonic when presented in Base32 encoding. 203 The following are examples of UDF values: 205 NBLC-XNXJ-JEYQ-U3MK-JN2R-Q5U4-SSBQ 206 EAEO-XJC5-33UX-4VS6-6RCR-N7OI-EI6A 207 SAQE-KWFO-YAMT-TAIA-PV66-36X4-RBHN-M 208 MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4 209 KCM5-7VB6-IJXJ-WKHX-NZQF-OKGZ-EWVN 210 AD2H-V6AG-KC5B-6DYX-DZR4-IBD5-4734 212 Like email addresses, UDFs are not a Uniform Resource Identifier 213 (URI) but may be expressed in URI form by adding the scheme 214 identifier (UDF) for use in contexts where an identifier in URI 215 syntax is required. A UDF URI MAY contain a domain name component 216 allowing it to be used as a locator 218 1.1.1. Cryptographic Keys and Nonces 220 A Nonce (N) UDF represents a short, fixed length randomly chosen 221 binary value. 223 Nonce UDFs are used within many Mesh protocols and data formats where 224 it is necessary to represent a nonce value in text form. 226 Nonce UDF: 227 NBLC-XNXJ-JEYQ-U3MK-JN2R-Q5U4-SSBQ 229 An Encryption/Authentication (E) UDF has the same format as a Random 230 UDF but is identified as being intended to be used as a symmetric key 231 for encryption and/or authentication. 233 KeyValue: 234 08 EB A4 5D DE E9 7E 56 5E F4 45 16 FD C8 22 3C 236 Encryption/Authenticator UDF: 237 EAEO-XJC5-33UX-4VS6-6RCR-N7OI-EI6A 239 A Share (S) UDF also represents a short, fixed length binary value 240 but only provides one share in secret sharing scheme. Recovery of 241 the binary value requires a sufficient number of shares. 243 Share UDFs are used in the Mesh to support key and data escrow 244 operations without the need to rely on trusted hardware. A share UDF 245 can be copied by hand or printed in human or machine-readable form 246 (e.g. QR code). 248 Key: EAEO-XJC5-33UX-4VS6-6RCR-N7OI-EI6A 249 Share 0: SAQE-KWFO-YAMT-TAIA-PV66-36X4-RBHN-M 250 Share 1: SAQY-DRNZ-EJJY-TA5K-TQDZ-NXX3-JB5X-A 251 Share 2: SARL-4MWD-QSG5-TBSU-XKIT-7QX2-BCUA-U 253 1.1.2. Fingerprint type UDFS 255 Fingerprint type UDFs contains a fingerprint value calculated over a 256 content data item and an IANA media type. 258 A Content Digest type UDF is a fingerprint type UDF in which the 259 fingerprint is formed using a cryptographic algorithm. Two digest 260 algorithms are currently supported, SHA-2-512 (M, for Merkle Damgard) 261 and SHA-3-512 (K, for Keccak). 263 The inclusion of the media type in the calculation of the UDF value 264 provides protection against semantic substitution attacks in which 265 content that has been found to be trustworthy when interpreted as one 266 content type is presented in a context in which it is interpreted as 267 a different content type in which it is unsafe. 269 SHA-2-512: MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4 270 SHA-3-512: KCM5-7VB6-IJXJ-WKHX-NZQF-OKGZ-EWVN 272 An Authentication UDF (A) is formed in the same manner as a 273 fingerprint but using a Message Authentication Code algorithm and a 274 symmetric key. 276 Authentication UDFs are used to express commitments and to provide a 277 means of blinding fingerprint values within a protocol by means of a 278 nonce. 280 SHA-2-512: AD2H-V6AG-KC5B-6DYX-DZR4-IBD5-4734 282 1.2. UDF URIs 284 The UDF URI scheme allows use of a UDF in contexts where a URF is 285 expected. The UDF URI scheme has two forms, name and locator. 287 1.2.1. Name Form 289 Name form UDF URIs identify a data resource but do not provide a 290 means of discovery. The URI is simply the scheme (udf) followed by 291 the UDF value: 293 udf:MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4 295 1.2.2. Locator Form 297 Locator form UDF URIs identify a data resource and provide a hint 298 that MAY provide a means of discovery. If the content is not 299 available from the location indicated, content obtained from a 300 different source that matches the fingerprint MAY be used instead. 302 udf://MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4 304 UDF locator form URIs presenting a fingerprint type UDF provide a 305 tight binding of the content to the locator. This allows the 306 resolved content to be verified and rejected if it has been modified. 308 UDF locator form URIs presenting an Encryptor/Authenticator type UDF 309 provide a mechanism for identification, discovery and decryption of 310 encrypted content. UDF locators of this type are known as Encrypted/ 311 Authenticated Resource Locators (EARLs). 313 Regardless of the type of the embedded UDF, UDF locator form URIs are 314 resolved by first performing DNS Web Service Discovery to identify 315 the Web Service Endpoint for the mmm-udf service at the specified 316 domain. 318 Resolution is completed by presenting the Content Digest Fingerprint 319 of the UDF value specified in the URI to the specified Web Service 320 Endpoint and performing a GET method request on the result. 322 For example, Alice subscribes to Example.com, a purveyor of cat and 323 kitten images. The company generates paper and electronic invoices 324 on a monthly basis. 326 To generate the paper invoice, Example.com first creates a new 327 encryption key: 329 EB3J-ZV2F-M5C3-MZHS-2CFF-JHQY-Q3G3-MH 331 One or more electronic forms of the invoice are encrypted under the 332 key EB3J-ZV2F-M5C3-MZHS-2CFF-JHQY-Q3G3-MH and placed on the 333 Example.com Web site so that the appropriate version is returned if 334 Alice scans the QR code. 336 The key is then converted to form an EARL for the example.com UDF 337 resolution service: 339 udf://example.com/EB3J-ZV2F-M5C3-MZHS-2CFF-JHQY-Q3G3-MH 341 The EARL is then rendered as a QR code: 343 [[This figure is not viewable in this format. The figure is 344 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 345 udf.html [2].]] 347 QR Code with embedded decryption and location key 349 A printable invoice containing the QR code is now generated and sent 350 to Alice. 352 When Alice receives the invoice, she can pay it by simply scanning 353 the invoice with a device that recognizes at least one of the invoice 354 formats supported by Example.com. 356 The UDF EARL locator shown above is resolved by first determining the 357 Web Service Endpoint for the mmm-udf service for the domain 358 example.com. 360 Discover ("example.com", "mmm-udf") = 361 https://example.com/.well-known/mmm-udf/ 363 Next the fingerprint of the source UDF is obtained. 365 UDF (EB3J-ZV2F-M5C3-MZHS-2CFF-JHQY-Q3G3-MH) = 366 MAI3-3253-XSCV-A575-WB27-XM7J-KQ5Z-TA3D-NPZT-UQED-PS6U-KTCP-YQFR-XECC 368 Combining the Web Service Endpoint and the fingerprint of the source 369 UDF provides the URI from which the content is obtained using the 370 normal HTTP GET method: 372 https://example.com/.well-known/mmm-udf/MAI3-3253-XSCV-A575-WB27- 373 XM7J-KQ5Z-TA3D-NPZT-UQED-PS6U-KTCP-YQFR-XECC 375 Having established that Alice can read postal mail sent to a physical 376 address and having delivered a secret to that address, this process 377 might be extended to provide a means of automating the process of 378 enrolment in electronic delivery of future invoices. 380 1.3. Secure Internet Names 382 A SIN is an Internet Identifier that contains a UDF fingerprint of a 383 security policy document that may be used to verify the 384 interpretation of the identifier. This permits traditional forms of 385 Internet address such as URIs and RFC822 email addresses to be used 386 to express a trusted address that is independent of any trusted third 387 party. 389 This document only describes the syntax and interpretation of the 390 identifiers themselves. The means by which the security policy 391 documents bound to an address govern interpretation of the name is 392 discussed separately in [draft-hallambaker-mesh-trust] . 394 For example, Example Inc holds the domain name example.com and has 395 deployed a private CA whose root of trust is a PKIX certificate with 396 the UDF fingerprint MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ. 398 Alice is an employee of Example Inc., she uses three email addresses: 400 alice@example.com A regular email address (not a SIN). 402 alice@mm--mb2gk-6duf5-ygyyl-jny5e-rwshz.example.com A strong email 403 address that is backwards compatible. 405 alice@example.com.mm--mb2gk-6duf5-ygyyl-jny5e-rwshz A strong email 406 address that is backwards incompatible. 408 All three forms of the address are valid RFC822 addresses and may be 409 used in a legacy email client, stored in an address book application, 410 etc. But the ability of a legacy client to make use of the address 411 differs. Addresses of the first type may always be used. Addresses 412 of the second type may only be used if an appropriate MX record is 413 provisioned. Addresses of the third type will always fail unless the 414 resolver understands that it is a SIN requiring special processing. 416 These rules allow Bob to send email to Alice with either 'best 417 effort' security or mandatory security as the circumstances demand. 419 2. Definitions 421 This section presents the related specifications and standard, the 422 terms that are used as terms of art within the documents and the 423 terms used as requirements language. 425 2.1. Requirements Language 427 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 428 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 429 document are to be interpreted as described in [RFC2119] . 431 2.2. Defined Terms 433 Cryptographic Digest Function A hash function that has the 434 properties required for use as a cryptographic hash function. 435 These include collision resistance, first pre-image resistance and 436 second pre-image resistance. 438 Content Type An identifier indicating how a Data Value is to be 439 interpreted as specified in the IANA registry Media Types. 441 Commitment A cryptographic primitive that allows one to commit to a 442 chosen value while keeping it hidden to others, with the ability 443 to reveal the committed value later. 445 Data Value The binary octet stream that is the input to the digest 446 function used to calculate a digest value. 448 Data Object A Data Value and its associated Content Type 450 Digest Algorithm A synonym for Cryptographic Digest Function 452 Digest Value The output of a Cryptographic Digest Function 454 Data Digest Value The output of a Cryptographic Digest Function for 455 a given Data Value input. 457 Fingerprint A presentation of the digest value of a data value or 458 data object. 460 Fingerprint Presentation The representation of at least some part of 461 a fingerprint value in human or machine-readable form. 463 Fingerprint Improvement The practice of recording a higher precision 464 presentation of a fingerprint on successful validation. 466 Fingerprint Work Hardening The practice of generating a sequence of 467 fingerprints until one is found that matches criteria that permit 468 a compressed presentation form to be used. The compressed 469 fingerprint thus being shorter than but presenting the same work 470 factor as an uncompressed one. 472 Hash A function which takes an input and returns a fixed-size 473 output. Ideally, the output of a hash function is unbiased and 474 not correlated to the outputs returned to similar inputs in any 475 predictable fashion. 477 Precision The number of significant bits provided by a Fingerprint 478 Presentation. 480 Work Factor A measure of the computational effort required to 481 perform an attack against some security property. 483 2.3. Related Specifications 485 This specification makes use of Base32 [RFC4648] encoding, SHA-2 486 [SHA-2] and SHA-3 [SHA-3] digest functions in the derivation of basic 487 fingerprints. The derivation of keyed fingerprints additionally 488 requires the use of the HMAC [RFC2014] and HKDF [RFC5869] functions. 490 Resolution of UDF URI Locators makes use of DNS Web Service Discovery 491 [draft-hallambaker-web-service-discovery] . 493 2.4. Implementation Status 495 The implementation status of the reference code base is described in 496 the companion document [draft-hallambaker-mesh-developer] . 498 3. Architecture 500 A Uniform Data Fingerprint (UDF) is a presentation of a UDF Binary 501 Data Sequence. 503 This document specifies seven UDF Binary Data Sequence types and one 504 presentation. 506 The first octet of a UDF Binary Data Sequence identifies the UDF type 507 and is referred to as the Type identifier. 509 UDF Binary Data Sequence types are either fixed length or variable 510 length. A variable length Binary Data Sequence MUST be truncated for 511 presentation. Fixed length Binary Data Sequences MUST not be 512 truncated. 514 3.1. Base32 Presentation 516 The default UDF presentation is Base32 Presentation. 518 Variable length Binary Data Sequences are truncated to an integer 519 multiple of 20 bits that provides the desired precision before 520 conversion to Base32 form. 522 Fixed length Binary Data Sequences are converted to Base32 form 523 without truncation. 525 After conversion to Base32 form, dash '-' characters are inserted 526 between groups of 4 characters to aid reading. This representation 527 improves the accuracy of both data entry and verification. 529 3.1.1. Precision Improvement 531 Precision improvement is the practice of using a high precision UDF 532 (e.g. 260 bits) calculated from content data that has been validated 533 according to a lower precision UDF (e.g. 120 bits). 535 This allows a lower precision UDF to be used in a medium such as a 536 business card where space is constrained without compromising 537 subsequent uses. 539 Applications SHOULD make use of precision improvement wherever 540 possible. 542 3.2. Type Identifier 544 A Version Identifier consists of a single byte. 546 The byte codes have been chosen so that the first character of the 547 Base32 presentation of the UDF provides a mnemonic for its type. A 548 SHA-2 fingerprint UDF will always have M (for Merkle Damgard) as the 549 initial letter, a SHA-3 fingerprint UDF will always have K (for 550 Keccak) as the initial letter, and so on. 552 The following version identifiers are specified in this document: 554 +---------+---------+--------------------------------+ 555 | Type ID | Initial | Algorithm | 556 +---------+---------+--------------------------------+ 557 | 0 | A | HMAC-SHA-2-512 | 558 | 32 | E | HKDF-AES-512 | 559 | 80 | K | SHA-3-512 | 560 | 81 | K | SHA-3-512 (20 bits compressed) | 561 | 82 | K | SHA-3-512 (30 bits compressed) | 562 | 83 | K | SHA-3-512 (40 bits compressed) | 563 | 84 | K | SHA-3-512 (50 bits compressed) | 564 | 96 | M | SHA-2-512 | 565 | 97 | M | SHA-2-512 (20 bits compressed) | 566 | 98 | M | SHA-2-512 (30 bits compressed) | 567 | 99 | M | SHA-2-512 (40 bits compressed) | 568 | 100 | M | SHA-2-512 (50 bits compressed) | 569 | 104 | N | Nonce data | 570 | 144 | S | Shamir Secret Sharing | 571 +---------+---------+--------------------------------+ 573 Table 1 575 3.3. Content Type Identifier 577 A secure cryptographic digest algorithm provides a unique digest 578 value that is probabilistically unique for a particular byte sequence 579 but does not fix the context in which a byte sequence is interpreted. 580 While such ambiguity may be tolerated in a fingerprint format 581 designed for a single specific field of use, it is not acceptable in 582 a general-purpose format. 584 For example, the SSH and OpenPGP applications both make use of 585 fingerprints as identifiers for the public keys used but using 586 different digest algorithms and data formats for representing the 587 public key data. While no such vulnerability has been demonstrated 588 to date, it is certainly conceivable that a crafty attacker might 589 construct an SSH key in such a fashion that OpenPGP interprets the 590 data in an insecure fashion. If the number of applications making 591 use of fingerprint format that permits such substitutions is 592 sufficiently large, the probability of a semantic substitution 593 vulnerability being possible becomes unacceptably large. 595 A simple control that defeats such attacks is to incorporate a 596 content type identifier within the scope of the data input to the 597 hash function. 599 3.4. Truncation 601 Different applications of fingerprints demand different tradeoffs 602 between compactness of the representation and the number of 603 significant bits. A larger the number of significant bits reduces 604 the risk of collision but at a cost to convenience. 606 Modern cryptographic digest functions such as SHA-2 produce output 607 values of at least 256 bits in length. This is considerably larger 608 than most uses of fingerprints require and certainly greater than can 609 be represented in human readable form on a business card. 611 Since a strong cryptographic digest function produces an output value 612 in which every bit in the input value affects every bit in the output 613 value with equal probability, it follows that truncating the digest 614 value to produce a finger print is at least as strong as any other 615 mechanism if digest algorithm used is strong. 617 Using truncation to reduce the precision of the digest function has 618 the advantage that a lower precision fingerprint of some data content 619 is always a prefix of a higher prefix of the same content. This 620 allows higher precision fingerprints to be converted to a lower 621 precision without the need for special tools. 623 3.4.1. Compression 625 The Content Digest UDF types make use of work factor compression. 626 Additional type identifiers are used to indicate digest values with 627 20, 30, 40 or 50 trailing zero bits allowing a UDF fingerprint 628 offering the equivalent of up to 150 bits of precision to be 629 expressed in 20 characters instead of 30. 631 To use compressed UDF identifiers, it is necessary to search for 632 content that can be compressed. If the digest algorithm used is 633 secure, this means that by definition, the fastest means of search is 634 brute force. Thus, the reduction in fingerprint size is achieved by 635 transferring the work factor from the attacker to the defender. To 636 maintain a work factor of 2^120 with a 2^80 bits, it is necessary for 637 the content generator to perform a brute force search at a cost of 638 the order of 2^40 operations. 640 For example, the smallest allowable work factor for a UDF 641 presentation of a public key fingerprint is 92 bits. This would 642 normally require a presentation with 20 significant characters. 643 Reducing this to 16 characters requires a brute force search of 644 approximately 10^6 attempts. Reducing this to 12 characters would 645 require 10^12 attempts and to 10 characters, 10^15 attempts. 647 Omission of support for higher levels of compression than 2^50 is 648 intentional. 650 In addition to allowing use of shorter presentations, work factor 651 compression MAY be used as evidence of proof of work. 653 3.5. Presentation 655 The presentation of a fingerprint is the format in which it is 656 presented to either an application or the user. 658 Base32 encoding is used to produce the preferred text representation 659 of a UDF fingerprint. This encoding uses only the letters of the 660 Latin alphabet with numbers chosen to minimize the risk of ambiguity 661 between numbers and letters (2, 3, 4, 5, 6 and 7). 663 To enhance readability and improve data entry, characters are grouped 664 into groups of four. This means that each block of four characters 665 represents an increase in work factor of approximately one million 666 times. 668 3.6. Alternative Presentations 670 Applications that support UDF MUST support use of the Base32 671 presentation. Applications MAY support alternative presentations. 673 3.6.1. Word Lists 675 The use of a Word List to encode fingerprint values was introduced by 676 Patrick Juola and Philip Zimmerman for the PGPfone application. The 677 PGP Word List is designed to facilitate exchange and verification of 678 fingerprint values in a voice application. To minimize the risk of 679 misinterpretation, two-word lists of 256 values each are used to 680 encode alternative fingerprint bytes. The compact size of the lists 681 used allowed the compilers to curate them so as to maximize the 682 phonetic distance of the words selected. 684 The PGP Word List is designed to achieve a balance between ease of 685 entry and verification. Applications where only verification is 686 required may be better served by a much larger word list, permitting 687 shorter fingerprint encodings. 689 For example, a word list with 16384 entries permits 14 bits of the 690 fingerprint to be encoded at once, 65536 entries permits encoding of 691 16 bits. These encodings allow a 120 bit fingerprint to be encoded 692 in 9 and 8 words respectively. 694 3.6.2. Image List 696 An image list is used in the same manner as a word list affording 697 rapid visual verification of a fingerprint value. For obvious 698 reasons, this approach is not suited to data entry but is preferable 699 for comparison purposes. An image list of 1,048,576 images would 700 provide a 20 bit encoding allowing 120 bit precision fingerprints to 701 be displayed in six images. 703 4. Fixed Length UDFs 705 Fixed length UDFs are used to represent cryptographic keys, nonces 706 and secret shares and have a fixed length determined by their 707 function that cannot be truncated without loss of information. 709 All fixed length Binary Data Sequence values are an integer multiple 710 of eight bits. 712 4.1. Nonce Type 714 A Nonce Type UDF consists of the type identifier octet 136 followed 715 by the Binary Data Sequence value. 717 The Binary Data Sequence value is an integer number of octets that 718 SHOULD have been generated in accordance with processes and 719 procedures that ensure that it is sufficiently unpredictable for the 720 purposes of the protocol in which the value is to be used. 721 Requirements for such processes and procedures are described in 722 [RFC4086] . 724 Nonce Type UDFs are intended for use in contexts where it is 725 necessary for a randomly chosen value to be unpredictable but not 726 secret. For example, the challenge in a challenge/response 727 mechanism. 729 4.2. Encryption/Authentication Type 731 An Encryption/Authentication Type UDF consists of the type identifier 732 octet 104 followed 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 and 737 unguessable for the purposes of the protocol in which the value is to 738 be used. Requirements for such processes and procedures are 739 described in [RFC4086] . 741 Encryption/Authentication Type UDFs are intended to be used as a 742 means of specifying secret cryptographic keying material. For 743 example, the input to a Key Derivation Function used to encrypt a 744 document. Accordingly, the identifier UDF corresponding to an 745 Encryption/Authentication type UDF is a UDF fingerprint of the 746 Encryption/Authentication Type UDF in Base32 presentation with 747 content type 'application/udf-encryption'. 749 4.3. Shamir Shared Secret 751 The UDF format MAY be used to encode shares generated by a secret 752 sharing mechanism. The only secret sharing mechanism currently 753 supported is the Shamir Secret Sharing mechanism [Shamir79] . Each 754 secret share represents a point represents a point on (x, f(x)), a 755 polynomial in a modular field p. The secret being shared is an 756 integer multiple of 32 bits represented by the polynomial value f(0). 758 A Shamir Shared Secret Type UDF consists of the type identifier octet 759 144 followed by the Binary Data Sequence value describing the share 760 value. 762 The first octet of the Binary Data Sequence value specifies the 763 threshold value and the x value of the particular share: 765 o Bits 4-7 of the first byte specify the threshold value. 767 o Bits 0-3 of the first byte specify the x value minus 1. 769 The remaining octets specify the value f(x) in network byte (big- 770 endian) order with leading padding if necessary so that the share has 771 the same number of bytes as the secret. 773 The algorithm requires that the value p be a prime larger than the 774 integer representing the largest secret being shared. For 775 compactness of representation we chose p to be the smallest prime 776 that is greater than 2^n where n is an integer multiple of 32. This 777 approach leaves a small probability that a set of chosen polynomial 778 parameters cause one or more share values be larger than 2^n. Since 779 it is the value of the secret rather than the polynomial parameters 780 that is of important, such parameters MUST NOT be used. 782 4.3.1. Secret Generation 784 To share a secret of L bits with a threshold of n we use a f(x) a 785 polynomial of degree n in the modular field p: 787 f(x) = a_0 + a_1.x + a_2.x^2 + ... a_n.x^n 788 where: 790 L Is the length of the secret in bits, an integer multiple of 32. 792 n Is the threshold, the number of shares required to reconstitute 793 the secret. 795 a0 Is the integer representation of the secret to be shared. 797 a1 ... an Are randomly chosen integers less than p 799 p Is the smallest prime that is greater than 2^L. 801 For L=128, p = 2^128+51. 803 The values of the key shares are the values f(1), f(2),... f(n). 805 The most straightforward approach to generation of Shamir secrets is 806 to generate the set of polynomial coefficients, a_0, a_1, ... a_n and 807 use these to generate the share values f(1), f(2),... f(n). 809 Note that if this approach is adopted, there is a small probability 810 that one or more of the values f(1), f(2),... f(n) exceeds the range 811 of values supported by the encoding. Should this occur, at least one 812 of the polynomial coefficients MUST be replaced. 814 An alternative means of generating the set of secrets is to select up 815 to n-1 secret share values and use secret recovery to determine at 816 least one additional share. If n shares are selected, the shared 817 secret becomes an output of rather than an input to the process. 819 4.3.2. Recovery 821 To recover the value of the shared secret, it is necessary to obtain 822 sufficient shares to meet the threshold and recover the value f(0) = 823 a_0. 825 Applications MAY employ any approach that returns the correct result. 826 The use of Lagrange basis polynomials is described in Appendix C. 828 Alice decides to encrypt an important document and split the 829 encryption key so that there are five key shares, three of which will 830 be required to recover the key. 832 Alice's master secret is 833 12 33 5C BF C8 28 C8 C6 EF E9 74 51 37 A9 B2 BD 835 This has the UDF representation: 837 EAJD-GXF7-ZAUM-RRXP-5F2F-CN5J-WK6Q 839 The master secret is converted to an integer applying network byte 840 order conventions. Since the master secret is 128 bits, it is 841 guaranteed to be smaller than the modulus. The resulting value 842 becomes the polynomial value a0. 844 Since a threshold of three shares is required, we will need a second 845 order polynomial. The co-efficients of the polynomial a1, a2 are 846 random numbers smaller than the modulus: 848 a0 = 24192792240122645239584041884141073085 849 a1 = 275645827829392714511516865247251935089 850 a2 = 338825755595477295605531041247661976348 852 The master secret is the value f(0) = a0. The key shares are the 853 values f(1), f(2)...f(5): 855 f(1) = 298382008744054191893257340947286773015 856 f(2) = 229375635676124939367868900210451791120 857 f(3) = 157456039957273351126793327105404338907 858 f(4) = 82623221587499427170030621632144416376 859 f(5) = 4877180566803167497580783790672023527 861 The first byte of each share specifies the recovery information 862 (quorum, x value), the remaining bytes specify the share value in 863 network byte order: 865 f(1) = 866 30 E0 7A 48 D8 4F DD 9B 38 7B B0 95 8A 9C 64 CD 867 17 868 f(2) = 869 31 AC 90 23 F9 85 95 22 B7 00 9E F1 69 2E 79 BD 870 10 871 f(3) = 872 32 76 74 EE 23 69 4F 5F 42 7E B4 87 EC ED E8 82 873 DB 874 f(4) = 875 33 3E 28 A7 55 FB 0C 50 DA F5 F1 59 15 DA B1 1E 876 78 877 f(5) = 878 34 03 AB 4F 91 3A CB F7 80 66 55 64 E3 F4 D3 8F 879 E7 881 The UDF presentation of the key shares is thus: 883 f(1) = SAYO-A6SI-3BH5-3GZY-POYJ-LCU4-MTGR-O 884 f(2) = SAY2-ZEBD-7GCZ-KIVX-ACPP-C2JO-PG6R-A 885 f(3) = SAZH-M5HO-ENUU-6X2C-P22I-P3HN-5CBN-W 886 f(4) = SAZT-4KFH-KX5Q-YUG2-6XYV-SFO2-WEPH-Q 887 f(5) = SA2A-HK2P-SE5M-X54A-MZKW-JY7U-2OH6-O 889 To recover the value f(0) from any three shares, we need to fit a 890 polynomial curve to the three points and use it to calculate the 891 value at x=0 using the Lagrange polynomial basis. 893 5. Variable Length UDFs 895 Variable length UDFs are used to represent fingerprint values 896 calculated over a content type identifier and the cryptographic 897 digest of a content data item. The fingerprint value MAY be 898 specified at any integer multiple of 20 bits that provides a work 899 factor sufficient for the intended purpose. 901 Two types of fingerprint are specified: 903 Digest fingerprints Are computed with the same cryptographic digest 904 algorithm used to calculate the digest of the content data. 906 Message Authentication Code fingerprints Are computed using a 907 Message Authentication Code. 909 For a given algorithm (and key, if requires), if two UDF fingerprints 910 are of the same content data and content type, either the fingerprint 911 values will be the same or the initial characters of one will be 912 exactly equal to the other. 914 5.1. Content Digest 916 A Content Digest Type UDF consists of the type identifier octet 917 followed by the Binary Data Sequence value. 919 The type identifier specifies the digest algorithm used and the 920 compression level. Two digest algorithms are currently specified 921 with four compression levels for each making a total of eight 922 possible type identifiers. 924 The Content Digest UDF for given content data is generated by the 925 steps of: 927 1. Applying the digest algorithm to determine the Content Digest 928 Value 930 2. Applying the digest algorithm to determine the Typed Content 931 Digest Value 933 3. Determining the compression level from bytes 0-3 of the Typed 934 Content Digest Value. 936 4. Determining the Type Identifier octet from the Digest algorithm 937 identifier and compression level. 939 5. Truncating bytes 4-63 of the Typed Content Digest Value to 940 determine the Binary Data Sequence value. 942 5.1.1. Content Digest Value 944 The Content Digest Value (CDV) is determined by applying the digest 945 algorithm to the content data: 947 CDV = H()) 949 Where 951 H(x) is the cryptographic digest function 953 is the binary data. 955 5.1.2. Typed Content Digest Value 957 The Typed Content Digest Value (TCDV) is determined by applying the 958 digest algorithm to the content type identifier and the CDV: 960 TCDV = H ( + ?:? + CDV) 962 Where 964 A + B represents concatenation of the binary sequences A and B. 966 is the IANA Content Type of the data in UTF8 encoding 968 The two-step approach to calculating the Type Content Digest Value 969 allows an application to attempt to match a set of content data 970 against multiple types without the need to recalculate the value of 971 the content data digest. 973 5.1.3. Compression 975 The compression factor is determined according to the number of 976 trailing zero bits in the first 8 bytes of the Typed Content Digest 977 Value as follows: 979 19 or fewer leading zero bits Compression factor = 0 981 29 or fewer leading zero bits Compression factor = 20 983 39 or fewer leading zero bits Compression factor = 30 985 49 or fewer leading zero bits Compression factor = 40 987 50 or more leading zero bits Compression factor = 50 989 The least significant bits of each octet are regarded to be 990 'trailing'. 992 Applications MUST use compression when creating and comparing UDFs. 993 Applications MAY support content generation techniques that search 994 for UDF values that use a compressed representation. Presentation of 995 a content digest value indicating use of compression MAY be used as 996 an indicator of 'proof of work'. 998 5.1.4. Presentation 1000 The type identifier is determined by the algorithm and compression 1001 factor as follows: 1003 +---------+---------+-----------+-------------+ 1004 | Type ID | Initial | Algorithm | Compression | 1005 +---------+---------+-----------+-------------+ 1006 | 80 | K | SHA-3-512 | 0 | 1007 | 81 | K | SHA-3-512 | 20 | 1008 | 82 | K | SHA-3-512 | 30 | 1009 | 83 | K | SHA-3-512 | 40 | 1010 | 84 | K | SHA-3-512 | 50 | 1011 | 96 | M | SHA-2-512 | 0 | 1012 | 97 | M | SHA-2-512 | 20 | 1013 | 98 | M | SHA-2-512 | 30 | 1014 | 99 | M | SHA-2-512 | 40 | 1015 | 100 | M | SHA-2-512 | 50 | 1016 +---------+---------+-----------+-------------+ 1018 Table 2 1020 The Binary Data Sequence value is taken from the Typed Content Digest 1021 Value starting at the 9^th octet and as many additional bytes as are 1022 required to meet the presentation precision. 1024 5.1.5. Example Encoding 1026 In the following examples, is the UTF8 encoding of the 1027 string "text/plain" and is the UTF8 encoding of the string 1028 "UDF Data Value" 1030 Data = 1031 55 44 46 20 44 61 74 61 20 56 61 6C 75 65 1033 ContentType = 1034 74 65 78 74 2F 70 6C 61 69 6E 1036 5.1.6. Using SHA-2-512 Digest 1038 H() = 1039 48 DA 47 CC AB FE A4 5C 76 61 D3 21 BA 34 3E 58 1040 10 87 2A 03 B4 02 9D AB 84 7C CE D2 22 B6 9C AB 1041 02 38 D4 E9 1E 2F 6B 36 A0 9E ED 11 09 8A EA AC 1042 99 D9 E0 BD EA 47 93 15 BD 7A E9 E1 2E AD C4 15 1044 + ':' + H() = 1045 74 65 78 74 2F 70 6C 61 69 6E 3A 48 DA 47 CC AB 1046 FE A4 5C 76 61 D3 21 BA 34 3E 58 10 87 2A 03 B4 1047 02 9D AB 84 7C CE D2 22 B6 9C AB 02 38 D4 E9 1E 1048 2F 6B 36 A0 9E ED 11 09 8A EA AC 99 D9 E0 BD EA 1049 47 93 15 BD 7A E9 E1 2E AD C4 15 1051 H( + ':' + H()) = 1052 C6 AF B7 C0 FE BE 04 E5 AE 94 E3 7B AA 5F 1A 40 1053 5B A3 CE CC 97 4D 55 C0 9E 61 E4 B0 EF 9C AE F9 1054 EB 83 BB 9D 5F 0F 39 F6 5F AA 06 DC 67 2A 67 71 1055 4F FF 8F 83 C4 55 38 36 38 AE 42 7A 82 9C 85 BB 1057 The prefixed Binary Data Sequence is thus 1058 60 C6 AF B7 C0 FE BE 04 E5 AE 94 E3 7B AA 5F 1A 1059 40 5B 1061 The 125 bit fingerprint value is MDDK-7N6A-727A-JZNO-STRX-XKS7-DJAF 1063 This fingerprint MAY be specified with higher or lower precision as 1064 appropriate. 1066 100 bit precision MDDK-7N6A-727A-JZNO-STRX 1068 120 bit precision MDDK-7N6A-727A-JZNO-STRX-XKS7 1070 200 bit precision MDDK-7N6A-727A-JZNO-STRX-XKS7-DJAF-XI6O-ZSLU-2VOA 1071 260 bit precision MDDK-7N6A-727A-JZNO-STRX-XKS7-DJAF-XI6O-ZSLU-2VOA- 1072 TZQ6-JMHP-TSXP 1074 5.1.7. Using SHA-3-512 Digest 1076 H() = 1077 6D 2E CF E6 93 5A 0C FC F2 A9 1A 49 E0 0C D8 07 1078 A1 4E 70 AB 72 94 6E CC BB 47 48 F1 8E 41 49 95 1079 07 1D F3 6E 0D 0C 8B 60 39 C1 8E B4 0F 6E C8 08 1080 65 B4 C4 45 9B A2 7E 97 74 7B BE 68 BC A8 C2 17 1082 + ':' + H() = 1083 74 65 78 74 2F 70 6C 61 69 6E 3A 6D 2E CF E6 93 1084 5A 0C FC F2 A9 1A 49 E0 0C D8 07 A1 4E 70 AB 72 1085 94 6E CC BB 47 48 F1 8E 41 49 95 07 1D F3 6E 0D 1086 0C 8B 60 39 C1 8E B4 0F 6E C8 08 65 B4 C4 45 9B 1087 A2 7E 97 74 7B BE 68 BC A8 C2 17 1089 H( + ':' + H()) = 1090 8A 86 8A 06 1C 54 6E 7E 3F 75 5F 39 88 F9 FD 2F 1091 8E C8 45 93 1B 80 A8 2F 29 16 7B A3 BE 21 1F 8A 1092 75 61 88 A1 D5 7F 07 D5 9D 68 A4 2D 17 F4 4D 23 1093 F9 E4 0B B2 1A 8D B9 F5 8D FC EC BD 01 F4 37 7C 1095 The prefixed Binary Data Sequence is thus 1096 50 8A 86 8A 06 1C 54 6E 7E 3F 75 5F 39 88 F9 FD 1097 2F 8E 1099 The 125 bit fingerprint value is KCFI-NCQG-DRKG-47R7-OVPT-TCHZ-7UXY 1101 5.1.8. Using SHA-2-512 Digest with Compression 1103 The content data "UDF Compressed Document 4187123" produces a UDF 1104 Content Digest SHA-2-512 binary value with 20 trailing zeros and is 1105 therefore presented using compressed presentation: 1107 Data = " 1108 55 44 46 20 43 6F 6D 70 72 65 73 73 65 64 20 44 1109 6F 63 75 6D 65 6E 74 20 34 31 38 37 31 32 33" 1111 The UTF8 Content Digest is given as: 1113 H() = 1114 36 21 FA 2A C5 D8 62 5C 2D 0B 45 FB 65 93 FC 69 1115 C1 ED F7 00 AE 6F E3 3D 38 13 FE AB 76 AA 74 13 1116 6D 5A 2B 20 DE D6 A5 CF 6C 04 E6 56 3F F3 C0 C7 1117 C4 1D 3F 43 DD DC F1 A5 67 A7 E0 67 9A B0 C6 B7 1119 + ':' + H() = 1120 74 65 78 74 2F 70 6C 61 69 6E 3A 36 21 FA 2A C5 1121 D8 62 5C 2D 0B 45 FB 65 93 FC 69 C1 ED F7 00 AE 1122 6F E3 3D 38 13 FE AB 76 AA 74 13 6D 5A 2B 20 DE 1123 D6 A5 CF 6C 04 E6 56 3F F3 C0 C7 C4 1D 3F 43 DD 1124 DC F1 A5 67 A7 E0 67 9A B0 C6 B7 1126 H( + ':' + H()) = 1127 8E 14 D9 19 4E D6 02 12 C3 30 A7 BB 5F C7 17 6D 1128 AE 9A 56 7C A8 2A 23 1F 96 75 ED 53 10 EC E8 F2 1129 60 14 24 D0 C8 BC 55 3D C0 70 F7 5E 86 38 1A 0B 1130 CB 55 9C B2 87 81 27 FF 3C EC E2 F0 90 A0 00 00 1132 The prefixed Binary Data Sequence is thus 1133 61 8E 14 D9 19 4E D6 02 12 C3 30 A7 BB 5F C7 17 1134 6D AE 1136 The 125 bit fingerprint value is MGHB-JWIZ-J3LA-EEWD-GCT3-WX6H-C5W2 1138 5.1.9. Using SHA-3-512 Digest with Compression 1140 The content data "UDF Compressed Document 774665" produces a UDF 1141 Content Digest SHA-3-512 binary value with 20 trailing zeros and is 1142 therefore presented using compressed presentation: 1144 Data = 1145 55 44 46 20 43 6F 6D 70 72 65 73 73 65 64 20 44 1146 6F 63 75 6D 65 6E 74 20 37 37 34 36 36 35 1148 The UTF8 SHA-3-512 Content Digest is KEJI-Y225-BDUG-XX22-MXKE-5ITF- 1149 YVYM 1151 5.2. Authenticator UDF 1153 An authenticator Type UDF consists of the type identifier octet 1154 followed by the Binary Data Sequence value. 1156 The type identifier specifies the digest and Message Authentication 1157 Code algorithm. Two algorithm suites are currently specified. Use 1158 of compression is not supported. 1160 The Authenticator UDF for given content data and key is generated by 1161 the steps of: 1163 1. Applying the digest algorithm to determine the Content Digest 1164 Value 1166 2. Applying the MAC algorithm to determine the Authentication value 1168 3. Determining the Type Identifier octet from the Digest algorithm 1169 identifier and compression level. 1171 4. Truncating the Authentication value to determine the Binary Data 1172 Sequence value. 1174 The key used to calculate and Authenticator type UDF is always a 1175 UNICODE string. If use of a binary value as a key is required, the 1176 value MUST be converted to a string format first. For example, by 1177 conversion to an Encryption/Authentication type UDF. 1179 5.2.1. Content Digest Value 1181 The Content Digest Value (CDV) is determined in the exact same 1182 fashion as for a Content Digest UDF by applying the digest algorithm 1183 to the content data: 1185 CDV = H()) 1187 Where 1189 H(x) is the cryptographic digest function 1191 is the binary data. 1193 5.2.2. Authentication Value 1195 The Authentication Value (AV) is determined by applying the digest 1196 algorithm to the content type identifier and the CDV: 1198 AV = MAC (, ( + ?:? + CDV)) 1200 Where 1202 is the authentication key as specified below 1204 MAC( , ) is the result of applying the Message 1205 Authentication Code algorithm to with Key and data 1207 The value is calculated as follows: 1209 IKM = UTF8 (Key) 1210 PRK = MAC (UTF8 ("KeyedUDFMaster"), IKM) 1211 OKM = HKDF-Expand(PRK, UTF8 ("KeyedUDFExpand"), HashLen) 1213 Where the function UTF8(string) converts a string to the binary UTF8 1214 representation, HKDF-Expand is as defined in [RFC5869] and the 1215 function MAC(k,m) is the HMAC function formed from the specified hash 1216 H(m) as specified in [RFC2014] . 1218 Keyed UDFs are typically used in circumstances where user interaction 1219 requires a cryptographic commitment type functionality 1221 In the following example, is the UTF8 encoding of the 1222 string "text/plain" and is the UTF8 encoding of the string 1223 "Konrad is the traitor". The randomly chosen key is NDD7-6CMX-H2FW- 1224 ISAL-K4VB-DQ3E-PEDM. 1226 Data = 1227 4B 6F 6E 72 61 64 20 69 73 20 74 68 65 20 74 72 1228 61 69 74 6F 72 1230 ContentType = 1231 74 65 78 74 2F 70 6C 61 69 6E 1233 Key = 1234 4E 44 44 37 2D 36 43 4D 58 2D 48 32 46 57 2D 49 1235 53 41 4C 2D 4B 34 56 42 2D 44 51 33 45 2D 50 45 1236 44 4D 1238 Processing is performed in the same manner as an unkeyed fingerprint 1239 except that compression is never used: 1241 H() = 1242 93 FC DA F9 FA FD 1E 26 50 26 C3 C1 28 43 40 73 1243 D8 BC 3D 62 87 73 2B 73 B8 EC 93 B6 DE 80 FF DA 1244 70 0A D1 CE E8 F4 36 68 EF 4E 71 63 41 53 91 5C 1245 CE 8C 5C CE C7 9A 46 94 6A 35 79 F9 33 70 85 01 1247 + ':' + H() = 1248 74 65 78 74 2F 70 6C 61 69 6E 3A 93 FC DA F9 FA 1249 FD 1E 26 50 26 C3 C1 28 43 40 73 D8 BC 3D 62 87 1250 73 2B 73 B8 EC 93 B6 DE 80 FF DA 70 0A D1 CE E8 1251 F4 36 68 EF 4E 71 63 41 53 91 5C CE 8C 5C CE C7 1252 9A 46 94 6A 35 79 F9 33 70 85 01 1254 PRK(Key) = 1255 77 D3 0A 08 39 BD 9D C0 97 44 DA 33 15 0A 42 5E 1256 CD 17 80 03 B3 CF CC 89 7A C7 84 12 B4 51 5B 25 1257 DC 26 F5 E1 1B 20 F3 89 2E 9A 1A 7B 0E 73 23 39 1258 0E C3 4C EF 2D 40 DA 05 B4 70 C6 1C 82 C1 49 33 1260 HKDF(Key) = 1261 BF A9 B4 58 9C 1D 68 D7 9A B7 11 F6 C8 98 59 14 1262 20 D7 82 67 C5 84 22 E5 A0 F9 93 52 B1 C3 87 EB 1263 05 06 CB C4 E4 D6 E6 EE 1F F0 D4 7A 97 68 5E CE 1264 28 1C CA AF D8 B5 D1 24 4A 71 EC E3 AC B5 D2 04 1266 MAC(, + ':' + H()) = 1267 4C C3 7F D3 F9 9E 52 CF 07 90 74 53 84 65 95 BC 1268 1A 2B A5 D1 68 9D 05 6D 06 C5 CA BF 17 CB E0 49 1269 95 39 57 08 79 C4 E5 49 D3 3A 59 A3 32 05 45 A6 1270 30 26 25 AE 8A F4 47 C6 1F B5 33 7F AD 69 A6 30 1272 The prefixed Binary Data Sequence is thus 1273 00 4C C3 7F D3 F9 9E 52 CF 07 90 74 53 84 65 95 1274 BC 1A 1276 The 125 bit fingerprint value is ABGM-G76T-7GPF-FTYH-SB2F-HBDF-SW6B 1278 5.3. Content Type Values 1280 While a UDF fingerprint MAY be used to identify any form of static 1281 data, the use of a UDF fingerprint to identify a public key signature 1282 key provides a level of indirection and thus the ability to identify 1283 dynamic data. The content types used to identify public keys are 1284 thus of particular interest. 1286 As described in the security considerations section, the use of 1287 fingerprints to identify a bare public key and the use of 1288 fingerprints to identify a public key and associated security policy 1289 information are very different. 1291 5.3.1. PKIX Certificates and Keys 1293 UDF fingerprints MAY be used to identify PKIX certificates, CRLs and 1294 public keys in the ASN.1 encoding used in PKIX certificates. 1296 Since PKIX certificates and CLRs contain security policy information, 1297 UDF fingerprints used to identify certificates or CRLs SHOULD be 1298 presented with a minimum of 200 bits of precision. PKIX applications 1299 MUST not accept UDF fingerprints specified with less than 200 bits of 1300 precision for purposes of identifying trust anchors. 1302 PKIX certificates, keys and related content data are identified by 1303 the following content types: 1305 application/pkix-cert A PKIX Certificate 1307 application/pkix-crl A PKIX CRL 1309 application/pkix-keyinfo The KeyInfo structure defined in the PKIX 1310 certificate specification. 1312 5.3.2. OpenPGP Key 1314 OpenPGPv5 keys and key set content data are identified by the 1315 following content type: 1317 application/pgp-keys An OpenPGP key set. 1319 5.3.3. DNSSEC 1321 DNSSEC record data consists of DNS records which are identified by 1322 the following content type: 1324 application/dns A DNS resource record in binary format 1326 6. UDF URIs 1328 The UDF URI scheme describes a means of constructing URIs from a UDF 1329 value. 1331 Two forms or UDF URI are specified, Name and Locator. In both cases 1332 the URI MUST specify the scheme type "UDF", and a UDF fingerprint and 1333 MAY specify a query identifier and/or a fragment identifier. 1335 By definition a Locator form URI contains an authority field which 1336 MUST be a DNS domain name. The use of IP address forms for this 1337 purpose is not permitted. 1339 Name Form URIs allow static content data to be identified without 1340 specifying the means by which the content data may be retrieved. 1341 Locator form URIs allow static content data or dynamic network 1342 resources to be identified and the means of retrieval. 1344 The syntax of a UDF URI is a subset of the generic URI syntax 1345 specified in [RFC3986] . The use of userinfo and port numbers is not 1346 supported and the path part of the uri is a UDF in base32 1347 presentation. 1349 URI = "UDF:" udf [ "?" query ] [ "" fragment ] 1351 udf = name-form / locator-form 1353 name-form = udf-value 1354 locator-form = "//" authority "/" udf-value 1356 authority = host 1357 host = reg-name 1359 6.1. Name form 1361 Name form UDF URIs provide a means of presenting a UDF value in a 1362 context in which a URI form of a name is required without providing a 1363 means of resolution. 1365 Adding the UDF scheme prefix to a UDF fingerprint does not change the 1366 semantics of the fingerprint itself. The semantics of the name 1367 result from the context in which it is used. 1369 For example, a UDF value of any type MAY be used to give a unique 1370 targetNamespace value in an XML Schema [XMLSchema] 1372 6.2. Locator form 1374 The locator form of an unkeyed UDF URI is resolved by the following 1375 steps: 1377 o Use DNS Web service discovery to determine the Web Service 1378 Endpoint. 1380 o Determine the content identifier from the source URI. 1382 o Append the content identifier to the Web Service Endpoint as a 1383 suffix to form the target URI. 1385 o Retrieve content from the Web Service Endpoint by means of a GET 1386 method. 1388 o Perform post processing as specified by the UDF type. 1390 6.2.1. DNS Web service discovery 1392 DNS Web Discovery is performed as specified in 1393 [draft-hallambaker-web-service-discovery] for the service mmm-udf and 1394 domain name specified in the URI. For a full description of the 1395 discovery mechanism, consult the referenced specification. 1397 The use of DNS Web Discovery permits service providers to make full 1398 use of the load balancing and service description capabilities 1399 afforded by use of DNS SRV and TXT records in accordance with the 1400 approach described in [RFC6763] . 1402 If no SRV or TXT records are specified, DNS Web Discovery specifies 1403 that the Web Service Endpoint be the Well Known Service [RFC5785] 1404 with the prefix /.well-known/srv/mmm-udf. 1406 6.2.2. Content Identifier 1408 For all UDF types other than Secret Share, the Content Identifier 1409 value is the UDF SHA-2-512 Content Digest of the canonical form of 1410 the UDF specified in the source URI presented at twice the precision 1411 to a maximum of 440 bits. 1413 If the UDF is of type Secret Share, the shared secret MUST be 1414 recovered before the content identifier can be resolved. The shared 1415 secret is then expressed as a UDF of type Encryption/Authentication 1416 and the Content Identifier determined as for an Encryption/ 1417 Authentication type UDF. 1419 6.2.3. Target URI 1421 The target URI is formed by appending a slash separator '/' and the 1422 Content Identifier value to the Web Service Endpoint. 1424 Since the path portion of a URI is case sensitive, the UDF value MUST 1425 be specified in upper case and MUST include separator marks. 1427 6.2.4. Postprocessing 1429 After retrieving the content data, the resolver MUST perform post 1430 processing as indicated by the content type: 1432 Nonce No additional post processing is required. 1434 Content Digest The resolver MUST verify that the content returned 1435 matches the UDF fingerprint value. 1437 Authenticator The resolver MUST verify that the content returned 1438 matches the UDF fingerprint value. 1440 Encryption/Authentication The content data returned is decrypted and 1441 authenticated using the key specified in the UDF value as the 1442 initial keying material (see below). 1444 Secret Share (set) The content data returned is decrypted and 1445 authenticated using the shared secret as the initial keying 1446 material (see below). 1448 6.2.5. Decryption and Authentication 1450 The steps performed to decode cryptographically enhanced content data 1451 depends on the content type specified in the returned content. Two 1452 formats are currently supported: 1454 o DARE Envelope format as specified in [draft-hallambaker-mesh-dare] 1456 o Cryptographic Message Syntax (CMS) Symmetric Key Package as 1457 specified in [RFC6031] 1459 6.2.6. QR Presentation 1461 Encoding of a UDF URI as a QR code requires only the characters in 1462 alphanumeric encoding, thus achieving compactness with minimal 1463 overhead. 1465 7. Strong Internet Names 1467 A Strong Internet Name is an Internet address that is bound to a 1468 policy governing interpretation of that address by means of a Content 1469 Digest type UDF of the policy expressed as a UDF prefixed DNS label 1470 within the address itself. 1472 The Reserved LDH labels as defined in [RFC5890] that begin with the 1473 prefix mm-- are reserved for use as Strong Internet Names. The 1474 characters following the prefix are a Content Digest type UDF in 1475 Base32 presentation. 1477 Since DNS labels are limited to 63 characters, the presentation of 1478 the SIN itself is limited to 59 characters and thus 240 bits of 1479 precision. 1481 8. Security Considerations 1483 This section describes security considerations arising from the use 1484 of UDF in general applications. 1486 Additional security considerations for use of UDFs in Mesh services 1487 and applications are described in the Mesh Security Considerations 1488 guide [draft-hallambaker-mesh-security] . 1490 8.1. Confidentiality 1492 Encrypted locator is a bearer token 1494 8.2. Availability 1496 Corruption of a part of a shared secret may prevent recovery 1498 8.3. Integrity 1500 Shared secret parts do not contain context information to specify 1501 which secret they relate to. 1503 8.4. Work Factor and Precision 1505 A given UDF data object has a single fingerprint value that may be 1506 presented at different precisions. The shortest legitimate precision 1507 with which a UDF fingerprint may be presented has 96 significant bits 1509 A UDF fingerprint presents the same work factor as any other 1510 cryptographic digest function. The difficulty of finding a second 1511 data item that matches a given fingerprint is 2^n and the difficulty 1512 or finding two data items that have the same fingerprint is 2^(n/2). 1513 Where n is the precision of the fingerprint. 1515 For the algorithms specified in this document, n = 512 and thus the 1516 work factor for finding collisions is 2^256, a value that is 1517 generally considered to be computationally infeasible. 1519 Since the use of 512 bit fingerprints is impractical in the type of 1520 applications where fingerprints are generally used, truncation is a 1521 practical necessity. The longer a fingerprint is, the less likely it 1522 is that a user will check every character. It is therefore important 1523 to consider carefully whether the security of an application depends 1524 on second pre-image resistance or collision resistance. 1526 In most fingerprint applications, such as the use of fingerprints to 1527 identify public keys, the fact that a malicious party might generate 1528 two keys that have the same fingerprint value is a minor concern. 1529 Combined with a flawed protocol architecture, such a vulnerability 1530 may permit an attacker to construct a document such that the 1531 signature will be accepted as valid by some parties but not by 1532 others. 1534 For example, Alice generates keypairs until two are generated that 1535 have the same 100 bit UDF presentation (typically 2^48 attempts). 1536 She registers one keypair with a merchant and the other with her 1537 bank. This allows Alice to create a payment instrument that will be 1538 accepted as valid by one and rejected by the other. 1540 The ability to generate of two PKIX certificates with the same 1541 fingerprint and different certificate attributes raises very 1542 different and more serious security concerns. For example, an 1543 attacker might generate two certificates with the same key and 1544 different use constraints. This might allow an attacker to present a 1545 highly constrained certificate that does not present a security risk 1546 to an application for purposes of gaining approval and an 1547 unconstrained certificate to request a malicious action. 1549 In general, any use of fingerprints to identify data that has 1550 security policy semantics requires the risk of collision attacks to 1551 be considered. For this reason, the use of short, 'user friendly' 1552 fingerprint presentations (Less than 200 bits) SHOULD only be used 1553 for public key values. 1555 8.5. Semantic Substitution 1557 Many applications record the fact that a data item is trusted, rather 1558 fewer record the circumstances in which the data item is trusted. 1559 This results in a semantic substitution vulnerability which an 1560 attacker may exploit by presenting the trusted data item in the wrong 1561 context. 1563 The UDF format provides protection against high level semantic 1564 substitution attacks by incorporating the content type into the input 1565 to the outermost fingerprint digest function. The work factor for 1566 generating a UDF fingerprint that is valid in both contexts is thus 1567 the same as the work factor for finding a second preimage in the 1568 digest function (2^512 for the specified digest algorithms). 1570 It is thus infeasible to generate a data item such that some 1571 applications will interpret it as a PKIX key and others will accept 1572 as an OpenPGP key. While attempting to parse a PKIX key as an 1573 OpenPGP key is virtually certain to fail to return the correct key 1574 parameters it cannot be assumed that the attempt is guaranteed to 1575 fail with an error message. 1577 The UDF format does not provide protection against semantic 1578 substitution attacks that do not affect the content type. 1580 8.6. QR Code Scanning 1582 The act of scanning a QR code SHOULD be considered equivalent to 1583 clicking on an unlabeled hypertext link. Since QR codes are scanned 1584 in many different contexts, the mere act of scanning a QR code MUST 1585 NOT be interpreted as constituting an affirmative acceptance of terms 1586 or conditions or as creating an electronic signature. 1588 If such semantics are required in the context of an application, 1589 these MUST be established by secondary user actions made subsequent 1590 to the scanning of the QR code. 1592 There is a risk that use of QR codes to automate processes such as 1593 payment will lead to abusive practices such as presentation of 1594 fraudulent invoices for goods not ordered or delivered. It is 1595 therefore important to ensure that such requests are subject to 1596 adequate accountability controls. 1598 9. IANA Considerations 1600 Registrations are requested in the following registries: 1602 o Service Name and Transport Protocol Port Number 1604 o well-known URI registry 1606 o Uniform Resource Identifier (URI) Schemes 1608 o Media Types 1610 In addition, the creation of the following registry is requested: 1611 Uniform Data Fingerprint Type Identifier Registry. 1613 9.1. Protocol Service Name 1615 The following registration is requested in the Service Name and 1616 Transport Protocol Port Number Registry in accordance with [RFC6355] 1617 Service Name (REQUIRED) mmm-udf 1619 Transport Protocol(s) (REQUIRED) TCP 1621 Assignee (REQUIRED) Phillip Hallam-Baker, phill@hallambaker.com 1623 Contact (REQUIRED) Phillip Hallam-Baker, phill@hallambaker.com 1625 Description (REQUIRED) mmm-udf is a Web Service protocol that 1626 resolves Mathematical Mesh Uniform Data Fingerprints (UDF) to 1627 resources. The mmm-udf service name is used in service discovery 1628 to identify a Web Service endpoint to perform resolution of a UDF 1629 presented in URI locator form. 1631 Reference (REQUIRED) [This document] 1633 Port Number (OPTIONAL) None 1635 Service Code (REQUIRED for DCCP only) None 1637 Known Unauthorized Uses (OPTIONAL) None 1639 Assignment Notes (OPTIONAL) None 1641 9.2. Well Known 1643 The following registration is requested in the well-known URI 1644 registry in accordance with [RFC5785] 1646 URI suffix srv/mmm-udf 1648 Change controller Phillip Hallam-Baker, phill@hallambaker.com 1650 Specification document(s): [This document] 1652 Related information 1654 [draft-hallambaker-web-service-discovery] 1656 9.3. URI Registration 1658 The following registration is requested in the Uniform Resource 1659 Identifier (URI) Schemes registry in accordance with [RFC7595] 1661 Scheme name: UDF 1663 Status: Provisional 1664 Applications/protocols that use this scheme name: Mathematical Mesh 1665 Service protocols (mmm) 1667 Contact: Phillip Hallam-Baker mailto:phill@hallambaker.com 1669 Change controller: Phillip Hallam-Baker 1671 References: [This document] 1673 9.4. Media Types Registrations 1675 9.4.1. Media Type: application/pkix-keyinfo 1677 Type name: application 1679 Subtype name: pkix-keyinfo 1681 Required parameters: None 1683 Optional parameters: None 1685 Encoding considerations: None 1687 Security considerations: Described in [This] 1689 Interoperability considerations: None 1691 Published specification: [This] 1693 Applications that use this media type: Uniform Data Fingerprint 1695 Fragment identifier considerations: None 1697 Additional information: Deprecated alias names for this type: None 1699 Magic number(s): None 1701 File extension(s): None 1703 Macintosh file type code(s): None 1705 Person & email address to contact for further information: 1706 Phillip Hallam-Baker @hallambaker.com> 1708 Intended usage: Content type identifier to be used in constructing 1709 UDF Content Digests and Authenticators and related cryptographic 1710 purposes. 1712 Restrictions on usage: None 1714 Author: Phillip Hallam-Baker 1716 Change controller: Phillip Hallam-Baker 1718 Provisional registration? (standards tree only): Yes 1720 9.4.2. Media Type: application/udf-encryption 1722 Type name: application 1724 Subtype name: udf-encryption 1726 Required parameters: None 1728 Optional parameters: None 1730 Encoding considerations: None 1732 Security considerations: Described in [This] 1734 Interoperability considerations: None 1736 Published specification: [This] 1738 Applications that use this media type: Uniform Data Fingerprint 1740 Fragment identifier considerations: None 1742 Additional information: Deprecated alias names for this type: None 1744 Magic number(s): None 1746 File extension(s): None 1748 Macintosh file type code(s): None 1750 Person & email address to contact for further information: 1751 Phillip Hallam-Baker @hallambaker.com> 1753 Intended usage: Content type identifier to be used in constructing 1754 UDF Content Digests and Authenticators and related cryptographic 1755 purposes. 1757 Restrictions on usage: None 1759 Author: Phillip Hallam-Baker 1760 Change controller: Phillip Hallam-Baker 1762 Provisional registration? (standards tree only): Yes 1764 9.4.3. Media Type: application/udf-secret 1766 Type name: application 1768 Subtype name: udf- secret 1770 Required parameters: None 1772 Optional parameters: None 1774 Encoding considerations: None 1776 Security considerations: Described in [This] 1778 Interoperability considerations: None 1780 Published specification: [This] 1782 Applications that use this media type: Uniform Data Fingerprint 1784 Fragment identifier considerations: None 1786 Additional information: Deprecated alias names for this type: None 1788 Magic number(s): None 1790 File extension(s): None 1792 Macintosh file type code(s): None 1794 Person & email address to contact for further information: 1795 Phillip Hallam-Baker @hallambaker.com> 1797 Intended usage: Content type identifier to be used in constructing 1798 UDF Content Digests and Authenticators and related cryptographic 1799 purposes. 1801 Restrictions on usage: None 1803 Author: Phillip Hallam-Baker 1805 Change controller: Phillip Hallam-Baker 1807 Provisional registration? (standards tree only): Yes 1809 9.5. Uniform Data Fingerprint Type Identifier Registry 1811 This document describes a new extensible data format employing fixed 1812 length version identifiers for UDF types. 1814 9.5.1. The name of the registry 1816 Uniform Data Fingerprint Type Identifier Registry 1818 9.5.2. Required information for registrations 1820 Registrants must specify the Type identifier code(s) requested, 1821 description and RFC number for the corresponding standards action 1822 document. 1824 The standards document must specify the means of generating and 1825 interpreting the UDF Data Sequence Value and the purpose(s) for which 1826 it is proposed. 1828 Since the initial letter of the Base32 presentation provides a 1829 mnemonic function in UDFs, the standards document must explain why 1830 the proposed Type Identifier and associated initial letter are 1831 appropriate. In cases where a new initial letter is to be created, 1832 there must be an explanation of why this is appropriate. If an 1833 existing initial letter is to be created, there must be an 1834 explanation of why this is appropriate and/or acceptable. 1836 9.5.3. Applicable registration policy 1838 Due to the intended field of use (human data entry), the code space 1839 is severely constrained. Accordingly, it is intended that code point 1840 registrations be as infrequent as possible. 1842 Registration of new digest algorithms is strongly discouraged and 1843 should not occur unless, (1) there is a known security vulnerability 1844 in one of the two schemes specified in the original assignment and 1845 (2) the proposed algorithm has been subjected to rigorous peer 1846 review, preferably in the form of an open, international competition 1847 and (3) the proposed algorithm has been adopted as a preferred 1848 algorithm for use in IETF protocols. 1850 Accordingly, the applicable registration policy is Standards Action. 1852 9.5.4. Size, format, and syntax of registry entries 1854 Each registry entry consists of a single byte code, 1856 9.5.5. Initial assignments and reservations 1858 The following entries should be added to the registry as initial 1859 assignments: 1861 Code Description Reference 1862 --- ------------------- --------- 1863 00 HMAC and SHA-2-512 [This document] 1864 32 HKDF-AES-512 [This document] 1865 80 SHA-3-512 [This document] 1866 81 SHA-3-512 with 20 trailing zeros [This document] 1867 82 SHA-3-512 with 30 trailing zeros [This document] 1868 82 SHA-3-512 with 40 trailing zeros [This document] 1869 83 SHA-3-512 with 50 trailing zeros [This document] 1870 96 SHA-2-512 [This document] 1871 97 SHA-2-512 with 20 trailing zeros [This document] 1872 98 SHA-2-512 with 30 trailing zeros [This document] 1873 99 SHA-2-512 with 40 trailing zeros [This document] 1874 100 SHA-2-512 with 50 trailing zeros [This document] 1875 104 Random nonce [This document] 1876 144 Shamir Secret Share [This document] 1878 10. Acknowledgements 1880 A list of people who have contributed to the design of the Mesh is 1881 presented in [draft-hallambaker-mesh-architecture] . 1883 Thanks are due to Viktor Dukhovni, Damian Weber and an anonymous 1884 member of the cryptography@metzdowd.com list for assisting in the 1885 compilation of the table of prime values. 1887 11. Appendix A: Prime Values for Secret Sharing 1889 The following are the prime values to be used for sharing secrets of 1890 up to 512 bits. 1892 If it is necessary to share larger secrets, the corresponding prime 1893 may be found by choosing a value (2^32)^n that is larger than the 1894 secret to be encoded and determining the next largest number that is 1895 prime. 1897 +----------------+----------------------+ 1898 | Number of bits | Offset = Primen - 2n | 1899 +----------------+----------------------+ 1900 | 32 | 15 | 1901 | 64 | 13 | 1902 | 96 | 61 | 1903 | 128 | 51 | 1904 | 160 | 7 | 1905 | 192 | 133 | 1906 | 224 | 735 | 1907 | 256 | 297 | 1908 | 288 | 127 | 1909 | 320 | 27 | 1910 | 352 | 55 | 1911 | 384 | 231 | 1912 | 416 | 235 | 1913 | 448 | 211 | 1914 | 480 | 165 | 1915 | 512 | 75 | 1916 +----------------+----------------------+ 1918 Table 3 1920 For example, the prime to be used to share a 128 bit value is 2^128 + 1921 51. 1923 12. Recovering Shamir Shared Secret 1925 The value of a Shamir Shared secret may be recovered using Lagrange 1926 basis polynomials. 1928 To share a secret with a threshold of n shares and L bits we 1929 constructed f(x) a polynomial of degree n in the modular field p 1930 where p is the smallest prime greater than 2^L: 1932 f(x) = a_0 + a_1.x + a_2.x^2 + ... a_n.x^n 1934 The shared secret is the binary representation of the value a_0 1936 Given n shares (x_0, y_0), (x_1, y_1), ... (x_n-1, y_n-1), The 1937 corresponding the Lagrange basis polynomials l_0, l_1, .. l_n-1 are 1938 given by: 1940 lm = ((x - x(m_0)) / (x(m) - x(m_0))) . ((x - x(m_1)) / (x(m) - 1941 x(m_1))) . ... . ((x - x(m_n-2)) / (x(m) - x(m_n-2))) 1943 Where the values m_0, m_1, ... m_n-2, are the integers 0, 1, .. n-1, 1944 excluding the value m. 1946 These can be used to compute f(x) as follows: 1948 f(x) = y_0l_0 + y_1l_1 + ... y_n-1l_n-1 1950 Since it is only the value of f(0) that we are interested in, we 1951 compute the Lagrange basis for the value x = 0: 1953 lz_m = ((x(m_1)) / (x(m) - x(m_1))) . ((x(m_2)) / (x(m) - x(m_2))) 1955 Hence, 1957 a_0 = f(0) = y_0lz_0 + y_1lz_1 + ... y_n-1l_n-1 1959 The following C# code recovers the values. 1961 using System; 1962 using System.Collections.Generic; 1963 using System.Numerics; 1965 namespace Examples { 1967 class Examples { 1969 /// 1970 /// Combine a set of points (x, f(x)) 1971 /// on a polynomial of degree in a 1972 /// discrete field modulo prime to 1973 /// recover the value f(0) using Lagrange basis polynomials. 1974 /// 1975 /// The values f(x). 1976 /// The values for x. 1977 /// The modulus. 1978 /// The polynomial degree. 1979 /// The value f(0). 1980 static BigInteger CombineNK( 1981 BigInteger[] fx, 1982 int[] x, 1983 BigInteger p, 1984 int n) { 1985 if (fx.Length < n) { 1986 throw new Exception("Insufficient shares"); 1987 } 1989 BigInteger accumulator = 0; 1990 for (var formula = 0; formula < n; formula++) { 1991 var value = fx[formula]; 1993 BigInteger numerator = 1, denominator = 1; 1994 for (var count = 0; count < n; count++) { 1995 if (formula == count) { 1996 continue; // If not the same value 1997 } 1999 var start = x[formula]; 2000 var next = x[count]; 2002 numerator = (numerator * -next) % p; 2003 denominator = (denominator * (start - next)) % p; 2004 } 2006 var InvDenominator = ModInverse(denominator, p); 2008 accumulator = Modulus((accumulator + 2009 (fx[formula] * numerator * InvDenominator)), p); 2010 } 2012 return accumulator; 2013 } 2015 /// 2016 /// Compute the modular multiplicative inverse of the value 2017 /// modulo 2018 /// 2019 /// The value to find the inverse of 2020 /// The modulus. 2021 /// 2022 static BigInteger ModInverse( 2023 BigInteger k, 2024 BigInteger p) { 2025 var m2 = p - 2; 2026 if (k < 0) { 2027 k = k + p; 2028 } 2030 return BigInteger.ModPow(k, m2, p); 2031 } 2033 /// 2034 /// Calculate the modulus of a number with correct handling 2035 /// for negative numbers. 2036 /// 2037 /// Value 2038 /// The modulus. 2039 /// x mod p 2040 public static BigInteger Modulus( 2041 BigInteger x, 2042 BigInteger p) { 2043 var Result = x % p; 2044 return Result.Sign >= 0 ? Result : Result + p; 2045 } 2046 } 2047 } 2049 13. References 2051 13.1. Normative References 2053 [draft-hallambaker-mesh-architecture] 2054 Hallam-Baker, P., "Mathematical Mesh Part I: Architecture 2055 Guide", draft-hallambaker-mesh-architecture-07 (work in 2056 progress), April 2019. 2058 [draft-hallambaker-mesh-dare] 2059 Hallam-Baker, P., "Mathematical Mesh Part III : Data At 2060 Rest Encryption (DARE)", draft-hallambaker-mesh-dare-01 2061 (work in progress), April 2019. 2063 [draft-hallambaker-mesh-security] 2064 Hallam-Baker, P., "Mathematical Mesh Part VII: Security 2065 Considerations", draft-hallambaker-mesh-security-00 (work 2066 in progress), April 2019. 2068 [draft-hallambaker-web-service-discovery] 2069 Hallam-Baker, P., "DNS Web Service Discovery", draft- 2070 hallambaker-web-service-discovery-02 (work in progress), 2071 April 2019. 2073 [RFC2014] Weinrib, A. and J. Postel, "IRTF Research Group Guidelines 2074 and Procedures", BCP 8, RFC 2014, DOI 10.17487/RFC2014, 2075 October 1996. 2077 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2078 Requirement Levels", BCP 14, RFC 2119, 2079 DOI 10.17487/RFC2119, March 1997. 2081 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2082 Resource Identifier (URI): Generic Syntax", STD 66, 2083 RFC 3986, DOI 10.17487/RFC3986, January 2005. 2085 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 2086 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006. 2088 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 2089 Key Derivation Function (HKDF)", RFC 5869, 2090 DOI 10.17487/RFC5869, May 2010. 2092 [RFC6031] Turner, S. and R. Housley, "Cryptographic Message Syntax 2093 (CMS) Symmetric Key Package Content Type", RFC 6031, 2094 DOI 10.17487/RFC6031, December 2010. 2096 [SHA-2] NIST, "Secure Hash Standard", August 2015. 2098 [SHA-3] Dworkin, M., "SHA-3 Standard: Permutation-Based Hash and 2099 Extendable-Output Functions", August 2015. 2101 13.2. Informative References 2103 [draft-hallambaker-mesh-developer] 2104 Hallam-Baker, P., "Mathematical Mesh: Reference 2105 Implementation", draft-hallambaker-mesh-developer-08 (work 2106 in progress), April 2019. 2108 [draft-hallambaker-mesh-trust] 2109 Hallam-Baker, P., "Mathematical Mesh Part VI: The Trust 2110 Mesh", draft-hallambaker-mesh-trust-01 (work in progress), 2111 April 2019. 2113 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 2114 "Randomness Requirements for Security", BCP 106, RFC 4086, 2115 DOI 10.17487/RFC4086, June 2005. 2117 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 2118 Thayer, "OpenPGP Message Format", RFC 4880, 2119 DOI 10.17487/RFC4880, November 2007. 2121 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 2122 Uniform Resource Identifiers (URIs)", RFC 5785, 2123 DOI 10.17487/RFC5785, April 2010. 2125 [RFC5890] Klensin, J., "Internationalized Domain Names for 2126 Applications (IDNA): Definitions and Document Framework", 2127 RFC 5890, DOI 10.17487/RFC5890, August 2010. 2129 [RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based 2130 DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, 2131 DOI 10.17487/RFC6355, August 2011. 2133 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 2134 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013. 2136 [RFC7595] Thaler, D., Hansen, T., and T. Hardie, "Guidelines and 2137 Registration Procedures for URI Schemes", BCP 35, 2138 RFC 7595, DOI 10.17487/RFC7595, June 2015. 2140 [Shamir79] 2141 "[Reference Not Found!]". 2143 [XMLSchema] 2144 Gao, S., Sperberg-McQueen, C., Thompson, H., Mendelsohn, 2145 N., Beech, D., and M. Maloney, "W3C XML Schema Definition 2146 Language (XSD) 1.1 Part 1: Structures", April 2012. 2148 13.3. URIs 2150 [1] http://mathmesh.com/Documents/draft-hallambaker-mesh-udf.html 2152 [2] http://mathmesh.com/Documents/draft-hallambaker-mesh-udf.html 2154 Author's Address 2156 Phillip Hallam-Baker 2158 Email: phill@hallambaker.com