idnits 2.17.1 draft-hallambaker-mesh-udf-06.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 2 instances of too long lines in the document, the longest one being 26 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 1712 has weird spacing: '... suffix srv/m...' == Line 2035 has weird spacing: '... set of point...' == Line 2036 has weird spacing: '... degree in a...' == Line 2037 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 (August 15, 2019) is 1706 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 2220 -- Looks like a reference, but probably isn't: '2' on line 2222 == Missing Reference: 'This' is mentioned on line 1846, but not defined -- Obsolete informational reference (is this intentional?): RFC 5785 (Obsoleted by RFC 8615) Summary: 2 errors (**), 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 August 15, 2019 4 Intended status: Informational 5 Expires: February 16, 2020 7 Mathematical Mesh 3.0 Part II: Uniform Data Fingerprint. 8 draft-hallambaker-mesh-udf-06 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 February 16, 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. Shamir Shared Secret . . . . . . . . . . . . . . . . . . 18 117 4.4.1. Secret Generation . . . . . . . . . . . . . . . . . . 19 118 4.4.2. Recovery . . . . . . . . . . . . . . . . . . . . . . 19 119 5. Variable Length UDFs . . . . . . . . . . . . . . . . . . . . 21 120 5.1. Content Digest . . . . . . . . . . . . . . . . . . . . . 22 121 5.1.1. Content Digest Value . . . . . . . . . . . . . . . . 22 122 5.1.2. Typed Content Digest Value . . . . . . . . . . . . . 22 123 5.1.3. Compression . . . . . . . . . . . . . . . . . . . . . 23 124 5.1.4. Presentation . . . . . . . . . . . . . . . . . . . . 23 125 5.1.5. Example Encoding . . . . . . . . . . . . . . . . . . 24 126 5.1.6. Using SHA-2-512 Digest . . . . . . . . . . . . . . . 24 127 5.1.7. Using SHA-3-512 Digest . . . . . . . . . . . . . . . 25 128 5.1.8. Using SHA-2-512 Digest with Compression . . . . . . . 26 129 5.1.9. Using SHA-3-512 Digest with Compression . . . . . . . 27 130 5.2. Authenticator UDF . . . . . . . . . . . . . . . . . . . . 27 131 5.2.1. Content Digest Value . . . . . . . . . . . . . . . . 28 132 5.2.2. Authentication Value . . . . . . . . . . . . . . . . 28 133 5.3. Content Type Values . . . . . . . . . . . . . . . . . . . 30 134 5.3.1. PKIX Certificates and Keys . . . . . . . . . . . . . 31 135 5.3.2. OpenPGP Key . . . . . . . . . . . . . . . . . . . . . 31 136 5.3.3. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 32 137 6. UDF URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 32 138 6.1. Name form . . . . . . . . . . . . . . . . . . . . . . . . 32 139 6.2. Locator form . . . . . . . . . . . . . . . . . . . . . . 33 140 6.2.1. DNS Web service discovery . . . . . . . . . . . . . . 33 141 6.2.2. Content Identifier . . . . . . . . . . . . . . . . . 33 142 6.2.3. Target URI . . . . . . . . . . . . . . . . . . . . . 34 143 6.2.4. Postprocessing . . . . . . . . . . . . . . . . . . . 34 144 6.2.5. Decryption and Authentication . . . . . . . . . . . . 34 145 6.2.6. QR Presentation . . . . . . . . . . . . . . . . . . . 35 146 7. Strong Internet Names . . . . . . . . . . . . . . . . . . . . 35 147 8. Security Considerations . . . . . . . . . . . . . . . . . . . 35 148 8.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . 35 149 8.2. Availability . . . . . . . . . . . . . . . . . . . . . . 35 150 8.3. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 35 151 8.4. Work Factor and Precision . . . . . . . . . . . . . . . . 36 152 8.5. Semantic Substitution . . . . . . . . . . . . . . . . . . 37 153 8.6. QR Code Scanning . . . . . . . . . . . . . . . . . . . . 37 154 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 155 9.1. Protocol Service Name . . . . . . . . . . . . . . . . . . 38 156 9.2. Well Known . . . . . . . . . . . . . . . . . . . . . . . 39 157 9.3. URI Registration . . . . . . . . . . . . . . . . . . . . 39 158 9.4. Media Types Registrations . . . . . . . . . . . . . . . . 39 159 9.4.1. Media Type: application/pkix-keyinfo . . . . . . . . 39 160 9.4.2. Media Type: application/udf-encryption . . . . . . . 40 161 9.4.3. Media Type: application/udf-secret . . . . . . . . . 41 162 9.5. Uniform Data Fingerprint Type Identifier Registry . . . . 42 163 9.5.1. The name of the registry . . . . . . . . . . . . . . 42 164 9.5.2. Required information for registrations . . . . . . . 42 165 9.5.3. Applicable registration policy . . . . . . . . . . . 43 166 9.5.4. Size, format, and syntax of registry entries . . . . 43 167 9.5.5. Initial assignments and reservations . . . . . . . . 43 168 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 44 169 11. Appendix A: Prime Values for Secret Sharing . . . . . . . . . 44 170 12. Recovering Shamir Shared Secret . . . . . . . . . . . . . . . 45 171 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 172 13.1. Normative References . . . . . . . . . . . . . . . . . . 47 173 13.2. Informative References . . . . . . . . . . . . . . . . . 48 174 13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 49 175 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 50 177 1. Introduction 179 A Uniform Data Fingerprint (UDF) is a generalized format for 180 presenting and interpreting short binary sequences representing 181 cryptographic keys or fingerprints of data of any specified type. 182 The UDF format provides a superset of the OpenPGP [RFC4880] 183 fingerprint encoding capability with greater encoding density and 184 readability. 186 This document describes the syntax and encoding of UDFs, the means of 187 constructing and comparing them and their use in other Internet 188 addressing schemes. 190 1.1. UDF Types 192 Two categories of UDF are described. Data UDFs provide a compact 193 presentation of a fixed length binary data value in a format that is 194 convenient for data entry. A Data UDF may represent a cryptographic 195 key or nonce value or a part share of a key generated using a secret 196 sharing mechanism. Fingerprint UDFs provide a compact presentation 197 of a Message Digest or Message Authentication Code value. 199 Both categories of UDF are encoded as a UDF binary sequence, the 200 first octet of which is a Type Identifier and the remaining octets 201 specify the binary value according to the type identifier and data 202 referenced. 204 UDFs are typically presented to the user as a Base32 encoded sequence 205 in groups of five characters separated by dashes. This format 206 provides a useful balance between compactness and readability. The 207 type identifier codes have been selected so as to provide a useful 208 mnemonic when presented in Base32 encoding. 210 The following are examples of UDF values: 212 NC6B-EYP6-O3JR-54HY-IE45-FOUU-TIPQ 213 EAR2-UJUY-H7TF-SFLK-CWAW-TKC4-O5HQ 214 SAQG-A7BL-6YQ6-G5K3-HYKQ-I54D-VWHG-C 215 MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4 216 KCM5-7VB6-IJXJ-WKHX-NZQF-OKGZ-EWVN 217 ACXQ-PQRC-54KV-6XXU-L3ZU-W2NZ-QVA5 218 OAYC-4MAH-AYBS-WZLQ-AUAA-GIYA-AQQE-E7UO-6QMY-7EGD-C63V-TROP-P2W5-HX6E-IDBE-YVJW-B4SY-GM5U-T2LF-7HQ 220 Like email addresses, UDFs are not a Uniform Resource Identifier 221 (URI) but may be expressed in URI form by adding the scheme 222 identifier (UDF) for use in contexts where an identifier in URI 223 syntax is required. A UDF URI MAY contain a domain name component 224 allowing it to be used as a locator 226 1.1.1. Cryptographic Keys and Nonces 228 A Nonce (N) UDF represents a short, fixed length randomly chosen 229 binary value. 231 Nonce UDFs are used within many Mesh protocols and data formats where 232 it is necessary to represent a nonce value in text form. 234 Nonce UDF: 235 NC6B-EYP6-O3JR-54HY-IE45-FOUU-TIPQ 237 An Encryption/Authentication (E) UDF has the same format as a Random 238 UDF but is identified as being intended to be used as a symmetric key 239 for encryption and/or authentication. 241 KeyValue: 242 23 AA 26 98 3F E6 59 15 6A 15 81 69 A8 5C 77 4F 244 Encryption/Authenticator UDF: 245 EAR2-UJUY-H7TF-SFLK-CWAW-TKC4-O5HQ 247 A Share (S) UDF also represents a short, fixed length binary value 248 but only provides one share in secret sharing scheme. Recovery of 249 the binary value requires a sufficient number of shares. 251 Share UDFs are used in the Mesh to support key and data escrow 252 operations without the need to rely on trusted hardware. A share UDF 253 can be copied by hand or printed in human or machine-readable form 254 (e.g. QR code). 256 Key: EAR2-UJUY-H7TF-SFLK-CWAW-TKC4-O5HQ 257 Share 0: SAQG-A7BL-6YQ6-G5K3-HYKQ-I54D-VWHG-C 258 Share 1: SAQZ-2TRR-KQB6-BENB-CIKI-PBK6-72SX-G 259 Share 2: SARN-UIBW-WHS5-3LPG-4YKA-VEZ2-J66I-K 261 1.1.2. Fingerprint type UDFS 263 Fingerprint type UDFs contains a fingerprint value calculated over a 264 content data item and an IANA media type. 266 A Content Digest type UDF is a fingerprint type UDF in which the 267 fingerprint is formed using a cryptographic algorithm. Two digest 268 algorithms are currently supported, SHA-2-512 (M, for Merkle Damgard) 269 and SHA-3-512 (K, for Keccak). 271 The inclusion of the media type in the calculation of the UDF value 272 provides protection against semantic substitution attacks in which 273 content that has been found to be trustworthy when interpreted as one 274 content type is presented in a context in which it is interpreted as 275 a different content type in which it is unsafe. 277 SHA-2-512: MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4 278 SHA-3-512: KCM5-7VB6-IJXJ-WKHX-NZQF-OKGZ-EWVN 280 An Authentication UDF (A) is formed in the same manner as a 281 fingerprint but using a Message Authentication Code algorithm and a 282 symmetric key. 284 Authentication UDFs are used to express commitments and to provide a 285 means of blinding fingerprint values within a protocol by means of a 286 nonce. 288 SHA-2-512: ACXQ-PQRC-54KV-6XXU-L3ZU-W2NZ-QVA5 290 1.2. UDF URIs 292 The UDF URI scheme allows use of a UDF in contexts where a URF is 293 expected. The UDF URI scheme has two forms, name and locator. 295 1.2.1. Name Form 297 Name form UDF URIs identify a data resource but do not provide a 298 means of discovery. The URI is simply the scheme (udf) followed by 299 the UDF value: 301 udf:MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4 303 1.2.2. Locator Form 305 Locator form UDF URIs identify a data resource and provide a hint 306 that MAY provide a means of discovery. If the content is not 307 available from the location indicated, content obtained from a 308 different source that matches the fingerprint MAY be used instead. 310 udf://MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4 312 UDF locator form URIs presenting a fingerprint type UDF provide a 313 tight binding of the content to the locator. This allows the 314 resolved content to be verified and rejected if it has been modified. 316 UDF locator form URIs presenting an Encryptor/Authenticator type UDF 317 provide a mechanism for identification, discovery and decryption of 318 encrypted content. UDF locators of this type are known as Encrypted/ 319 Authenticated Resource Locators (EARLs). 321 Regardless of the type of the embedded UDF, UDF locator form URIs are 322 resolved by first performing DNS Web Service Discovery to identify 323 the Web Service Endpoint for the mmm-udf service at the specified 324 domain. 326 Resolution is completed by presenting the Content Digest Fingerprint 327 of the UDF value specified in the URI to the specified Web Service 328 Endpoint and performing a GET method request on the result. 330 For example, Alice subscribes to Example.com, a purveyor of cat and 331 kitten images. The company generates paper and electronic invoices 332 on a monthly basis. 334 To generate the paper invoice, Example.com first creates a new 335 encryption key: 337 EDX6-OS5A-D4LO-IPT5-EVOR-4QFW-AZWE-4Q 339 One or more electronic forms of the invoice are encrypted under the 340 key EDX6-OS5A-D4LO-IPT5-EVOR-4QFW-AZWE-4Q and placed on the 341 Example.com Web site so that the appropriate version is returned if 342 Alice scans the QR code. 344 The key is then converted to form an EARL for the example.com UDF 345 resolution service: 347 udf://example.com/EDX6-OS5A-D4LO-IPT5-EVOR-4QFW-AZWE-4Q 349 The EARL is then rendered as a QR code: 351 [[This figure is not viewable in this format. The figure is 352 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 353 udf.html [2].]] 355 QR Code with embedded decryption and location key 357 A printable invoice containing the QR code is now generated and sent 358 to Alice. 360 When Alice receives the invoice, she can pay it by simply scanning 361 the invoice with a device that recognizes at least one of the invoice 362 formats supported by Example.com. 364 The UDF EARL locator shown above is resolved by first determining the 365 Web Service Endpoint for the mmm-udf service for the domain 366 example.com. 368 Discover ("example.com", "mmm-udf") = 369 https://example.com/.well-known/mmm-udf/ 371 Next the fingerprint of the source UDF is obtained. 373 UDF (EDX6-OS5A-D4LO-IPT5-EVOR-4QFW-AZWE-4Q) = 374 MDWZ-WDB7-FZLG-46QL-UURR-FQ36-UQ2A-6YIX-BG4T-32A2-QHPE-5UPP-MMKA-3YR2 375 Combining the Web Service Endpoint and the fingerprint of the source 376 UDF provides the URI from which the content is obtained using the 377 normal HTTP GET method: 379 https://example.com/.well-known/mmm-udf/MDWZ-WDB7-FZLG-46QL-UURR- 380 FQ36-UQ2A-6YIX-BG4T-32A2-QHPE-5UPP-MMKA-3YR2 382 Having established that Alice can read postal mail sent to a physical 383 address and having delivered a secret to that address, this process 384 might be extended to provide a means of automating the process of 385 enrolment in electronic delivery of future invoices. 387 1.3. Secure Internet Names 389 A SIN is an Internet Identifier that contains a UDF fingerprint of a 390 security policy document that may be used to verify the 391 interpretation of the identifier. This permits traditional forms of 392 Internet address such as URIs and RFC822 email addresses to be used 393 to express a trusted address that is independent of any trusted third 394 party. 396 This document only describes the syntax and interpretation of the 397 identifiers themselves. The means by which the security policy 398 documents bound to an address govern interpretation of the name is 399 discussed separately in [draft-hallambaker-mesh-trust] . 401 For example, Example Inc holds the domain name example.com and has 402 deployed a private CA whose root of trust is a PKIX certificate with 403 the UDF fingerprint MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ. 405 Alice is an employee of Example Inc., she uses three email addresses: 407 alice@example.com A regular email address (not a SIN). 409 alice@mm--mb2gk-6duf5-ygyyl-jny5e-rwshz.example.com A strong email 410 address that is backwards compatible. 412 alice@example.com.mm--mb2gk-6duf5-ygyyl-jny5e-rwshz A strong email 413 address that is backwards incompatible. 415 All three forms of the address are valid RFC822 addresses and may be 416 used in a legacy email client, stored in an address book application, 417 etc. But the ability of a legacy client to make use of the address 418 differs. Addresses of the first type may always be used. Addresses 419 of the second type may only be used if an appropriate MX record is 420 provisioned. Addresses of the third type will always fail unless the 421 resolver understands that it is a SIN requiring special processing. 423 These rules allow Bob to send email to Alice with either 'best 424 effort' security or mandatory security as the circumstances demand. 426 2. Definitions 428 This section presents the related specifications and standard, the 429 terms that are used as terms of art within the documents and the 430 terms used as requirements language. 432 2.1. Requirements Language 434 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 435 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 436 document are to be interpreted as described in [RFC2119] . 438 2.2. Defined Terms 440 Cryptographic Digest Function A hash function that has the 441 properties required for use as a cryptographic hash function. 442 These include collision resistance, first pre-image resistance and 443 second pre-image resistance. 445 Content Type An identifier indicating how a Data Value is to be 446 interpreted as specified in the IANA registry Media Types. 448 Commitment A cryptographic primitive that allows one to commit to a 449 chosen value while keeping it hidden to others, with the ability 450 to reveal the committed value later. 452 Data Value The binary octet stream that is the input to the digest 453 function used to calculate a digest value. 455 Data Object A Data Value and its associated Content Type 457 Digest Algorithm A synonym for Cryptographic Digest Function 459 Digest Value The output of a Cryptographic Digest Function 461 Data Digest Value The output of a Cryptographic Digest Function for 462 a given Data Value input. 464 Fingerprint A presentation of the digest value of a data value or 465 data object. 467 Fingerprint Presentation The representation of at least some part of 468 a fingerprint value in human or machine-readable form. 470 Fingerprint Improvement The practice of recording a higher precision 471 presentation of a fingerprint on successful validation. 473 Fingerprint Work Hardening The practice of generating a sequence of 474 fingerprints until one is found that matches criteria that permit 475 a compressed presentation form to be used. The compressed 476 fingerprint thus being shorter than but presenting the same work 477 factor as an uncompressed one. 479 Hash A function which takes an input and returns a fixed-size 480 output. Ideally, the output of a hash function is unbiased and 481 not correlated to the outputs returned to similar inputs in any 482 predictable fashion. 484 Precision The number of significant bits provided by a Fingerprint 485 Presentation. 487 Work Factor A measure of the computational effort required to 488 perform an attack against some security property. 490 2.3. Related Specifications 492 This specification makes use of Base32 [RFC4648] encoding, SHA-2 493 [SHA-2] and SHA-3 [SHA-3] digest functions in the derivation of basic 494 fingerprints. The derivation of keyed fingerprints additionally 495 requires the use of the HMAC [RFC2014] and HKDF [RFC5869] functions. 497 Resolution of UDF URI Locators makes use of DNS Web Service Discovery 498 [draft-hallambaker-web-service-discovery] . 500 2.4. Implementation Status 502 The implementation status of the reference code base is described in 503 the companion document [draft-hallambaker-mesh-developer] . 505 3. Architecture 507 A Uniform Data Fingerprint (UDF) is a presentation of a UDF Binary 508 Data Sequence. 510 This document specifies seven UDF Binary Data Sequence types and one 511 presentation. 513 The first octet of a UDF Binary Data Sequence identifies the UDF type 514 and is referred to as the Type identifier. 516 UDF Binary Data Sequence types are either fixed length or variable 517 length. A variable length Binary Data Sequence MUST be truncated for 518 presentation. Fixed length Binary Data Sequences MUST not be 519 truncated. 521 3.1. Base32 Presentation 523 The default UDF presentation is Base32 Presentation. 525 Variable length Binary Data Sequences are truncated to an integer 526 multiple of 20 bits that provides the desired precision before 527 conversion to Base32 form. 529 Fixed length Binary Data Sequences are converted to Base32 form 530 without truncation. 532 After conversion to Base32 form, dash '-' characters are inserted 533 between groups of 4 characters to aid reading. This representation 534 improves the accuracy of both data entry and verification. 536 3.1.1. Precision Improvement 538 Precision improvement is the practice of using a high precision UDF 539 (e.g. 260 bits) calculated from content data that has been validated 540 according to a lower precision UDF (e.g. 120 bits). 542 This allows a lower precision UDF to be used in a medium such as a 543 business card where space is constrained without compromising 544 subsequent uses. 546 Applications SHOULD make use of precision improvement wherever 547 possible. 549 3.2. Type Identifier 551 A Version Identifier consists of a single byte. 553 The byte codes have been chosen so that the first character of the 554 Base32 presentation of the UDF provides a mnemonic for its type. A 555 SHA-2 fingerprint UDF will always have M (for Merkle Damgard) as the 556 initial letter, a SHA-3 fingerprint UDF will always have K (for 557 Keccak) as the initial letter, and so on. 559 The following version identifiers are specified in this document: 561 +---------+---------+------------------------------------------+ 562 | Type ID | Initial | Algorithm | 563 +---------+---------+------------------------------------------+ 564 | 0 | A | HMAC-SHA-2-512 | 565 | 32 | E | HKDF-AES-512 | 566 | 80 | K | SHA-3-512 | 567 | 81 | K | SHA-3-512 (20 bits compressed) | 568 | 82 | K | SHA-3-512 (30 bits compressed) | 569 | 83 | K | SHA-3-512 (40 bits compressed) | 570 | 84 | K | SHA-3-512 (50 bits compressed) | 571 | 96 | M | SHA-2-512 | 572 | 97 | M | SHA-2-512 (20 bits compressed) | 573 | 98 | M | SHA-2-512 (30 bits compressed) | 574 | 99 | M | SHA-2-512 (40 bits compressed) | 575 | 100 | M | SHA-2-512 (50 bits compressed) | 576 | 104 | N | Nonce data | 577 | 108 | O | OID distinguished sequence (DER encoded) | 578 | 144 | S | Shamir Secret Sharing | 579 +---------+---------+------------------------------------------+ 581 Table 1 583 3.3. Content Type Identifier 585 A secure cryptographic digest algorithm provides a unique digest 586 value that is probabilistically unique for a particular byte sequence 587 but does not fix the context in which a byte sequence is interpreted. 588 While such ambiguity may be tolerated in a fingerprint format 589 designed for a single specific field of use, it is not acceptable in 590 a general-purpose format. 592 For example, the SSH and OpenPGP applications both make use of 593 fingerprints as identifiers for the public keys used but using 594 different digest algorithms and data formats for representing the 595 public key data. While no such vulnerability has been demonstrated 596 to date, it is certainly conceivable that a crafty attacker might 597 construct an SSH key in such a fashion that OpenPGP interprets the 598 data in an insecure fashion. If the number of applications making 599 use of fingerprint format that permits such substitutions is 600 sufficiently large, the probability of a semantic substitution 601 vulnerability being possible becomes unacceptably large. 603 A simple control that defeats such attacks is to incorporate a 604 content type identifier within the scope of the data input to the 605 hash function. 607 3.4. Truncation 609 Different applications of fingerprints demand different tradeoffs 610 between compactness of the representation and the number of 611 significant bits. A larger the number of significant bits reduces 612 the risk of collision but at a cost to convenience. 614 Modern cryptographic digest functions such as SHA-2 produce output 615 values of at least 256 bits in length. This is considerably larger 616 than most uses of fingerprints require and certainly greater than can 617 be represented in human readable form on a business card. 619 Since a strong cryptographic digest function produces an output value 620 in which every bit in the input value affects every bit in the output 621 value with equal probability, it follows that truncating the digest 622 value to produce a finger print is at least as strong as any other 623 mechanism if digest algorithm used is strong. 625 Using truncation to reduce the precision of the digest function has 626 the advantage that a lower precision fingerprint of some data content 627 is always a prefix of a higher prefix of the same content. This 628 allows higher precision fingerprints to be converted to a lower 629 precision without the need for special tools. 631 3.4.1. Compression 633 The Content Digest UDF types make use of work factor compression. 634 Additional type identifiers are used to indicate digest values with 635 20, 30, 40 or 50 trailing zero bits allowing a UDF fingerprint 636 offering the equivalent of up to 150 bits of precision to be 637 expressed in 20 characters instead of 30. 639 To use compressed UDF identifiers, it is necessary to search for 640 content that can be compressed. If the digest algorithm used is 641 secure, this means that by definition, the fastest means of search is 642 brute force. Thus, the reduction in fingerprint size is achieved by 643 transferring the work factor from the attacker to the defender. To 644 maintain a work factor of 2^120 with a 2^80 bits, it is necessary for 645 the content generator to perform a brute force search at a cost of 646 the order of 2^40 operations. 648 For example, the smallest allowable work factor for a UDF 649 presentation of a public key fingerprint is 92 bits. This would 650 normally require a presentation with 20 significant characters. 651 Reducing this to 16 characters requires a brute force search of 652 approximately 10^6 attempts. Reducing this to 12 characters would 653 require 10^12 attempts and to 10 characters, 10^15 attempts. 655 Omission of support for higher levels of compression than 2^50 is 656 intentional. 658 In addition to allowing use of shorter presentations, work factor 659 compression MAY be used as evidence of proof of work. 661 3.5. Presentation 663 The presentation of a fingerprint is the format in which it is 664 presented to either an application or the user. 666 Base32 encoding is used to produce the preferred text representation 667 of a UDF fingerprint. This encoding uses only the letters of the 668 Latin alphabet with numbers chosen to minimize the risk of ambiguity 669 between numbers and letters (2, 3, 4, 5, 6 and 7). 671 To enhance readability and improve data entry, characters are grouped 672 into groups of four. This means that each block of four characters 673 represents an increase in work factor of approximately one million 674 times. 676 3.6. Alternative Presentations 678 Applications that support UDF MUST support use of the Base32 679 presentation. Applications MAY support alternative presentations. 681 3.6.1. Word Lists 683 The use of a Word List to encode fingerprint values was introduced by 684 Patrick Juola and Philip Zimmerman for the PGPfone application. The 685 PGP Word List is designed to facilitate exchange and verification of 686 fingerprint values in a voice application. To minimize the risk of 687 misinterpretation, two-word lists of 256 values each are used to 688 encode alternative fingerprint bytes. The compact size of the lists 689 used allowed the compilers to curate them so as to maximize the 690 phonetic distance of the words selected. 692 The PGP Word List is designed to achieve a balance between ease of 693 entry and verification. Applications where only verification is 694 required may be better served by a much larger word list, permitting 695 shorter fingerprint encodings. 697 For example, a word list with 16384 entries permits 14 bits of the 698 fingerprint to be encoded at once, 65536 entries permits encoding of 699 16 bits. These encodings allow a 120 bit fingerprint to be encoded 700 in 9 and 8 words respectively. 702 3.6.2. Image List 704 An image list is used in the same manner as a word list affording 705 rapid visual verification of a fingerprint value. For obvious 706 reasons, this approach is not suited to data entry but is preferable 707 for comparison purposes. An image list of 1,048,576 images would 708 provide a 20 bit encoding allowing 120 bit precision fingerprints to 709 be displayed in six images. 711 4. Fixed Length UDFs 713 Fixed length UDFs are used to represent cryptographic keys, nonces 714 and secret shares and have a fixed length determined by their 715 function that cannot be truncated without loss of information. 717 All fixed length Binary Data Sequence values are an integer multiple 718 of eight bits. 720 4.1. Nonce Type 722 A Nonce Type UDF consists of the type identifier octet 104 followed 723 by the Binary Data Sequence value. 725 The Binary Data Sequence value is an integer number of octets that 726 SHOULD have been generated in accordance with processes and 727 procedures that ensure that it is sufficiently unpredictable for the 728 purposes of the protocol in which the value is to be used. 729 Requirements for such processes and procedures are described in 730 [RFC4086] . 732 Nonce Type UDFs are intended for use in contexts where it is 733 necessary for a randomly chosen value to be unpredictable but not 734 secret. For example, the challenge in a challenge/response 735 mechanism. 737 4.2. OID Identified Sequence 739 An OID Identified Sequence Type UDF consists of the type identifier 740 octet 108 followed by the Binary Data Sequence value. 742 The Binary Data Sequence value is an octet sequence that contains the 743 DER encoding of the following ASN.1 data: 745 OIDInfo ::= SEQUENCE { 746 algorithm AlgorithmIdentifier, 747 data BIT STRING } 749 AlgorithmIdentifier ::= SEQUENCE { 750 algorithm OBJECT IDENTIFIER, 751 parameters ANY DEFINED BY algorithm OPTIONAL } 753 OID Identified Sequences are intended to allow arbitrary data 754 sequences to be encoded in the UDF format without exhausting the 755 limited type identifier space. 757 In particular, OID Identified Sequences MAY be used to specify public 758 and private key values. 760 Given the following Ed25519 public key: 762 42 7E 8E F4 19 8F 90 C3 17 B7 59 C5 CF 7E AD D3 763 DF C4 40 C2 4C 55 36 0F 25 83 33 B4 9E 96 5F 9E 765 The equivalent DER encoding is: 767 30 2E 30 07 06 03 2B 65 70 05 00 03 23 00 04 20 768 42 7E 8E F4 19 8F 90 C3 17 B7 59 C5 CF 7E AD D3 769 DF C4 40 C2 4C 55 36 0F 25 83 33 B4 9E 96 5F 9E 771 To encode this key as a UDF OID sequence we prepend the value OID and 772 convert to Base32: 774 OAYC-4MAH-AYBS-WZLQ-AUAA-GIYA-AQQE-E7UO-6QMY-7EGD-C63V-TROP-P2W5-HX6E-IDBE-YVJW-B4SY-GM5U-T2LF-7HQ 776 The corresponding UDF content digest value is more compact and allows 777 us to identify the key unambiguously but does not provide the value: 779 MD7J-UW6O-EUSZ-UWKO-JQTB-JFKY-EF5S 781 4.3. Encryption/Authentication Type 783 An Encryption/Authentication Type UDF consists of the type identifier 784 octet 0 followed by the Binary Data Sequence value. 786 The Binary Data Sequence value is an integer number of octets that 787 SHOULD have been generated in accordance with processes and 788 procedures that ensure that it is sufficiently unpredictable and 789 unguessable for the purposes of the protocol in which the value is to 790 be used. Requirements for such processes and procedures are 791 described in [RFC4086] . 793 Encryption/Authentication Type UDFs are intended to be used as a 794 means of specifying secret cryptographic keying material. For 795 example, the input to a Key Derivation Function used to encrypt a 796 document. Accordingly, the identifier UDF corresponding to an 797 Encryption/Authentication type UDF is a UDF fingerprint of the 798 Encryption/Authentication Type UDF in Base32 presentation with 799 content type 'application/udf-encryption'. 801 4.4. Shamir Shared Secret 803 The UDF format MAY be used to encode shares generated by a secret 804 sharing mechanism. The only secret sharing mechanism currently 805 supported is the Shamir Secret Sharing mechanism [Shamir79] . Each 806 secret share represents a point represents a point on (x, f(x)), a 807 polynomial in a modular field p. The secret being shared is an 808 integer multiple of 32 bits represented by the polynomial value f(0). 810 A Shamir Shared Secret Type UDF consists of the type identifier octet 811 144 followed by the Binary Data Sequence value describing the share 812 value. 814 The first octet of the Binary Data Sequence value specifies the 815 threshold value and the x value of the particular share: 817 o Bits 4-7 of the first byte specify the threshold value. 819 o Bits 0-3 of the first byte specify the x value minus 1. 821 The remaining octets specify the value f(x) in network byte (big- 822 endian) order with leading padding if necessary so that the share has 823 the same number of bytes as the secret. 825 The algorithm requires that the value p be a prime larger than the 826 integer representing the largest secret being shared. For 827 compactness of representation we chose p to be the smallest prime 828 that is greater than 2^n where n is an integer multiple of 32. This 829 approach leaves a small probability that a set of chosen polynomial 830 parameters cause one or more share values be larger than 2^n. Since 831 it is the value of the secret rather than the polynomial parameters 832 that is of important, such parameters MUST NOT be used. 834 4.4.1. Secret Generation 836 To share a secret of L bits with a threshold of n we use a f(x) a 837 polynomial of degree n in the modular field p: 839 f(x) = a_0 + a_1.x + a_2.x^2 + ... a_n.x^n 841 where: 843 L Is the length of the secret in bits, an integer multiple of 32. 845 n Is the threshold, the number of shares required to reconstitute 846 the secret. 848 a0 Is the integer representation of the secret to be shared. 850 a1 ... an Are randomly chosen integers less than p 852 p Is the smallest prime that is greater than 2^L. 854 For L=128, p = 2^128+51. 856 The values of the key shares are the values f(1), f(2),... f(n). 858 The most straightforward approach to generation of Shamir secrets is 859 to generate the set of polynomial coefficients, a_0, a_1, ... a_n and 860 use these to generate the share values f(1), f(2),... f(n). 862 Note that if this approach is adopted, there is a small probability 863 that one or more of the values f(1), f(2),... f(n) exceeds the range 864 of values supported by the encoding. Should this occur, at least one 865 of the polynomial coefficients MUST be replaced. 867 An alternative means of generating the set of secrets is to select up 868 to n-1 secret share values and use secret recovery to determine at 869 least one additional share. If n shares are selected, the shared 870 secret becomes an output of rather than an input to the process. 872 4.4.2. Recovery 874 To recover the value of the shared secret, it is necessary to obtain 875 sufficient shares to meet the threshold and recover the value f(0) = 876 a_0. 878 Applications MAY employ any approach that returns the correct result. 879 The use of Lagrange basis polynomials is described in Appendix C. 881 Alice decides to encrypt an important document and split the 882 encryption key so that there are five key shares, three of which will 883 be required to recover the key. 885 Alice's master secret is 886 97 BE C3 8C EC 32 E3 A8 14 BE 38 AC 49 B3 58 D0 888 This has the UDF representation: 890 ECL3-5Q4M-5QZO-HKAU-XY4K-YSNT-LDIA 892 The master secret is converted to an integer applying network byte 893 order conventions. Since the master secret is 128 bits, it is 894 guaranteed to be smaller than the modulus. The resulting value 895 becomes the polynomial value a0. 897 Since a threshold of three shares is required, we will need a second 898 order polynomial. The co-efficients of the polynomial a1, a2 are 899 random numbers smaller than the modulus: 901 a0 = 201703930001559361817193071124445092048 902 a1 = 150940799172659682039015718883035617571 903 a2 = 86155479518555634547489350117128484052 905 The master secret is the value f(0) = a0. The key shares are the 906 values f(1), f(2)...f(5): 908 f(1) = 98517841771836214940323532692840982164 909 f(2) = 167642712579224337158432694495493840384 910 f(3) = 68796175502785265008145949100635455201 911 f(4) = 142260597463457461952837903940034038122 912 f(5) = 47753611540302464529133951581921377640 914 The first byte of each share specifies the recovery information 915 (quorum, x value), the remaining bytes specify the share value in 916 network byte order: 918 f(1) = 919 30 4A 1D D8 9D 72 E5 BC D3 C8 0C 4F A6 96 F3 26 920 94 921 f(2) = 922 31 7E 1E CF DF FB B5 F1 FB 6F 25 E1 68 DC 85 5E 923 00 924 f(3) = 925 32 33 C1 A9 54 86 A3 83 1F 0A 0A ED F3 1A 69 FE 926 E1 927 f(4) = 928 33 6B 06 64 FB 13 AE 70 3E 98 BB 75 45 50 A1 09 929 6A 930 f(5) = 931 34 23 ED 02 D3 A2 D6 B9 5A 1B 37 77 5F 7F 2A 7D 932 68 934 The UDF presentation of the key shares is thus: 936 f(1) = SAYE-UHOY-TVZO-LPGT-ZAGE-7JUW-6MTJ-I 937 f(2) = SAYX-4HWP-3753-L4P3-N4S6-C2G4-QVPA-A 938 f(3) = SAZD-HQNJ-KSDK-HAY7-BIFO-34Y2-NH7O-C 939 f(4) = SAZW-WBTE-7MJ2-44B6-TC5X-KRKQ-UEEW-U 940 f(5) = SA2C-H3IC-2ORN-NOK2-DM3X-OX37-FJ6W-Q 942 To recover the value f(0) from any three shares, we need to fit a 943 polynomial curve to the three points and use it to calculate the 944 value at x=0 using the Lagrange polynomial basis. 946 5. Variable Length UDFs 948 Variable length UDFs are used to represent fingerprint values 949 calculated over a content type identifier and the cryptographic 950 digest of a content data item. The fingerprint value MAY be 951 specified at any integer multiple of 20 bits that provides a work 952 factor sufficient for the intended purpose. 954 Two types of fingerprint are specified: 956 Digest fingerprints Are computed with the same cryptographic digest 957 algorithm used to calculate the digest of the content data. 959 Message Authentication Code fingerprints Are computed using a 960 Message Authentication Code. 962 For a given algorithm (and key, if requires), if two UDF fingerprints 963 are of the same content data and content type, either the fingerprint 964 values will be the same or the initial characters of one will be 965 exactly equal to the other. 967 5.1. Content Digest 969 A Content Digest Type UDF consists of the type identifier octet 970 followed by the Binary Data Sequence value. 972 The type identifier specifies the digest algorithm used and the 973 compression level. Two digest algorithms are currently specified 974 with four compression levels for each making a total of eight 975 possible type identifiers. 977 The Content Digest UDF for given content data is generated by the 978 steps of: 980 1. Applying the digest algorithm to determine the Content Digest 981 Value 983 2. Applying the digest algorithm to determine the Typed Content 984 Digest Value 986 3. Determining the compression level from bytes 0-3 of the Typed 987 Content Digest Value. 989 4. Determining the Type Identifier octet from the Digest algorithm 990 identifier and compression level. 992 5. Truncating bytes 4-63 of the Typed Content Digest Value to 993 determine the Binary Data Sequence value. 995 5.1.1. Content Digest Value 997 The Content Digest Value (CDV) is determined by applying the digest 998 algorithm to the content data: 1000 CDV = H()) 1002 Where 1004 H(x) is the cryptographic digest function 1006 is the binary data. 1008 5.1.2. Typed Content Digest Value 1010 The Typed Content Digest Value (TCDV) is determined by applying the 1011 digest algorithm to the content type identifier and the CDV: 1013 TCDV = H ( + ?:? + CDV) 1014 Where 1016 A + B represents concatenation of the binary sequences A and B. 1018 is the IANA Content Type of the data in UTF8 encoding 1020 The two-step approach to calculating the Type Content Digest Value 1021 allows an application to attempt to match a set of content data 1022 against multiple types without the need to recalculate the value of 1023 the content data digest. 1025 5.1.3. Compression 1027 The compression factor is determined according to the number of 1028 trailing zero bits in the first 8 bytes of the Typed Content Digest 1029 Value as follows: 1031 19 or fewer leading zero bits Compression factor = 0 1033 29 or fewer leading zero bits Compression factor = 20 1035 39 or fewer leading zero bits Compression factor = 30 1037 49 or fewer leading zero bits Compression factor = 40 1039 50 or more leading zero bits Compression factor = 50 1041 The least significant bits of each octet are regarded to be 1042 'trailing'. 1044 Applications MUST use compression when creating and comparing UDFs. 1045 Applications MAY support content generation techniques that search 1046 for UDF values that use a compressed representation. Presentation of 1047 a content digest value indicating use of compression MAY be used as 1048 an indicator of 'proof of work'. 1050 5.1.4. Presentation 1052 The type identifier is determined by the algorithm and compression 1053 factor as follows: 1055 +---------+---------+-----------+-------------+ 1056 | Type ID | Initial | Algorithm | Compression | 1057 +---------+---------+-----------+-------------+ 1058 | 80 | K | SHA-3-512 | 0 | 1059 | 81 | K | SHA-3-512 | 20 | 1060 | 82 | K | SHA-3-512 | 30 | 1061 | 83 | K | SHA-3-512 | 40 | 1062 | 84 | K | SHA-3-512 | 50 | 1063 | 96 | M | SHA-2-512 | 0 | 1064 | 97 | M | SHA-2-512 | 20 | 1065 | 98 | M | SHA-2-512 | 30 | 1066 | 99 | M | SHA-2-512 | 40 | 1067 | 100 | M | SHA-2-512 | 50 | 1068 +---------+---------+-----------+-------------+ 1070 Table 2 1072 The Binary Data Sequence value is taken from the Typed Content Digest 1073 Value starting at the 9^th octet and as many additional bytes as are 1074 required to meet the presentation precision. 1076 5.1.5. Example Encoding 1078 In the following examples, is the UTF8 encoding of the 1079 string "text/plain" and is the UTF8 encoding of the string 1080 "UDF Data Value" 1082 Data = 1083 55 44 46 20 44 61 74 61 20 56 61 6C 75 65 1085 ContentType = 1086 74 65 78 74 2F 70 6C 61 69 6E 1088 5.1.6. Using SHA-2-512 Digest 1089 H() = 1090 48 DA 47 CC AB FE A4 5C 76 61 D3 21 BA 34 3E 58 1091 10 87 2A 03 B4 02 9D AB 84 7C CE D2 22 B6 9C AB 1092 02 38 D4 E9 1E 2F 6B 36 A0 9E ED 11 09 8A EA AC 1093 99 D9 E0 BD EA 47 93 15 BD 7A E9 E1 2E AD C4 15 1095 + ':' + H() = 1096 74 65 78 74 2F 70 6C 61 69 6E 3A 48 DA 47 CC AB 1097 FE A4 5C 76 61 D3 21 BA 34 3E 58 10 87 2A 03 B4 1098 02 9D AB 84 7C CE D2 22 B6 9C AB 02 38 D4 E9 1E 1099 2F 6B 36 A0 9E ED 11 09 8A EA AC 99 D9 E0 BD EA 1100 47 93 15 BD 7A E9 E1 2E AD C4 15 1102 H( + ':' + H()) = 1103 C6 AF B7 C0 FE BE 04 E5 AE 94 E3 7B AA 5F 1A 40 1104 5B A3 CE CC 97 4D 55 C0 9E 61 E4 B0 EF 9C AE F9 1105 EB 83 BB 9D 5F 0F 39 F6 5F AA 06 DC 67 2A 67 71 1106 4F FF 8F 83 C4 55 38 36 38 AE 42 7A 82 9C 85 BB 1108 The prefixed Binary Data Sequence is thus 1109 60 C6 AF B7 C0 FE BE 04 E5 AE 94 E3 7B AA 5F 1A 1110 40 5B 1112 The 125 bit fingerprint value is MDDK-7N6A-727A-JZNO-STRX-XKS7-DJAF 1114 This fingerprint MAY be specified with higher or lower precision as 1115 appropriate. 1117 100 bit precision MDDK-7N6A-727A-JZNO-STRX 1119 120 bit precision MDDK-7N6A-727A-JZNO-STRX-XKS7 1121 200 bit precision MDDK-7N6A-727A-JZNO-STRX-XKS7-DJAF-XI6O-ZSLU-2VOA 1123 260 bit precision MDDK-7N6A-727A-JZNO-STRX-XKS7-DJAF-XI6O-ZSLU-2VOA- 1124 TZQ6-JMHP-TSXP 1126 5.1.7. Using SHA-3-512 Digest 1127 H() = 1128 6D 2E CF E6 93 5A 0C FC F2 A9 1A 49 E0 0C D8 07 1129 A1 4E 70 AB 72 94 6E CC BB 47 48 F1 8E 41 49 95 1130 07 1D F3 6E 0D 0C 8B 60 39 C1 8E B4 0F 6E C8 08 1131 65 B4 C4 45 9B A2 7E 97 74 7B BE 68 BC A8 C2 17 1133 + ':' + H() = 1134 74 65 78 74 2F 70 6C 61 69 6E 3A 6D 2E CF E6 93 1135 5A 0C FC F2 A9 1A 49 E0 0C D8 07 A1 4E 70 AB 72 1136 94 6E CC BB 47 48 F1 8E 41 49 95 07 1D F3 6E 0D 1137 0C 8B 60 39 C1 8E B4 0F 6E C8 08 65 B4 C4 45 9B 1138 A2 7E 97 74 7B BE 68 BC A8 C2 17 1140 H( + ':' + H()) = 1141 8A 86 8A 06 1C 54 6E 7E 3F 75 5F 39 88 F9 FD 2F 1142 8E C8 45 93 1B 80 A8 2F 29 16 7B A3 BE 21 1F 8A 1143 75 61 88 A1 D5 7F 07 D5 9D 68 A4 2D 17 F4 4D 23 1144 F9 E4 0B B2 1A 8D B9 F5 8D FC EC BD 01 F4 37 7C 1146 The prefixed Binary Data Sequence is thus 1147 50 8A 86 8A 06 1C 54 6E 7E 3F 75 5F 39 88 F9 FD 1148 2F 8E 1150 The 125 bit fingerprint value is KCFI-NCQG-DRKG-47R7-OVPT-TCHZ-7UXY 1152 5.1.8. Using SHA-2-512 Digest with Compression 1154 The content data "UDF Compressed Document 4187123" produces a UDF 1155 Content Digest SHA-2-512 binary value with 20 trailing zeros and is 1156 therefore presented using compressed presentation: 1158 Data = " 1159 55 44 46 20 43 6F 6D 70 72 65 73 73 65 64 20 44 1160 6F 63 75 6D 65 6E 74 20 34 31 38 37 31 32 33" 1162 The UTF8 Content Digest is given as: 1164 H() = 1165 36 21 FA 2A C5 D8 62 5C 2D 0B 45 FB 65 93 FC 69 1166 C1 ED F7 00 AE 6F E3 3D 38 13 FE AB 76 AA 74 13 1167 6D 5A 2B 20 DE D6 A5 CF 6C 04 E6 56 3F F3 C0 C7 1168 C4 1D 3F 43 DD DC F1 A5 67 A7 E0 67 9A B0 C6 B7 1170 + ':' + H() = 1171 74 65 78 74 2F 70 6C 61 69 6E 3A 36 21 FA 2A C5 1172 D8 62 5C 2D 0B 45 FB 65 93 FC 69 C1 ED F7 00 AE 1173 6F E3 3D 38 13 FE AB 76 AA 74 13 6D 5A 2B 20 DE 1174 D6 A5 CF 6C 04 E6 56 3F F3 C0 C7 C4 1D 3F 43 DD 1175 DC F1 A5 67 A7 E0 67 9A B0 C6 B7 1177 H( + ':' + H()) = 1178 8E 14 D9 19 4E D6 02 12 C3 30 A7 BB 5F C7 17 6D 1179 AE 9A 56 7C A8 2A 23 1F 96 75 ED 53 10 EC E8 F2 1180 60 14 24 D0 C8 BC 55 3D C0 70 F7 5E 86 38 1A 0B 1181 CB 55 9C B2 87 81 27 FF 3C EC E2 F0 90 A0 00 00 1183 The prefixed Binary Data Sequence is thus 1184 61 8E 14 D9 19 4E D6 02 12 C3 30 A7 BB 5F C7 17 1185 6D AE 1187 The 125 bit fingerprint value is MGHB-JWIZ-J3LA-EEWD-GCT3-WX6H-C5W2 1189 5.1.9. Using SHA-3-512 Digest with Compression 1191 The content data "UDF Compressed Document 774665" produces a UDF 1192 Content Digest SHA-3-512 binary value with 20 trailing zeros and is 1193 therefore presented using compressed presentation: 1195 Data = 1196 55 44 46 20 43 6F 6D 70 72 65 73 73 65 64 20 44 1197 6F 63 75 6D 65 6E 74 20 37 37 34 36 36 35 1199 The UTF8 SHA-3-512 Content Digest is KEJI-Y225-BDUG-XX22-MXKE-5ITF- 1200 YVYM 1202 5.2. Authenticator UDF 1204 An authenticator Type UDF consists of the type identifier octet 1205 followed by the Binary Data Sequence value. 1207 The type identifier specifies the digest and Message Authentication 1208 Code algorithm. Two algorithm suites are currently specified. Use 1209 of compression is not supported. 1211 The Authenticator UDF for given content data and key is generated by 1212 the steps of: 1214 1. Applying the digest algorithm to determine the Content Digest 1215 Value 1217 2. Applying the MAC algorithm to determine the Authentication value 1219 3. Determining the Type Identifier octet from the Digest algorithm 1220 identifier and compression level. 1222 4. Truncating the Authentication value to determine the Binary Data 1223 Sequence value. 1225 The key used to calculate and Authenticator type UDF is always a 1226 UNICODE string. If use of a binary value as a key is required, the 1227 value MUST be converted to a string format first. For example, by 1228 conversion to an Encryption/Authentication type UDF. 1230 5.2.1. Content Digest Value 1232 The Content Digest Value (CDV) is determined in the exact same 1233 fashion as for a Content Digest UDF by applying the digest algorithm 1234 to the content data: 1236 CDV = H()) 1238 Where 1240 H(x) is the cryptographic digest function 1242 is the binary data. 1244 5.2.2. Authentication Value 1246 The Authentication Value (AV) is determined by applying the digest 1247 algorithm to the content type identifier and the CDV: 1249 AV = MAC (, ( + ?:? + CDV)) 1251 Where 1253 is the authentication key as specified below 1255 MAC( , ) is the result of applying the Message 1256 Authentication Code algorithm to with Key and data 1258 The value is calculated as follows: 1260 IKM = UTF8 (Key) 1261 PRK = MAC (UTF8 ("KeyedUDFMaster"), IKM) 1262 OKM = HKDF-Expand(PRK, UTF8 ("KeyedUDFExpand"), HashLen) 1264 Where the function UTF8(string) converts a string to the binary UTF8 1265 representation, HKDF-Expand is as defined in [RFC5869] and the 1266 function MAC(k,m) is the HMAC function formed from the specified hash 1267 H(m) as specified in [RFC2014] . 1269 Keyed UDFs are typically used in circumstances where user interaction 1270 requires a cryptographic commitment type functionality 1272 In the following example, is the UTF8 encoding of the 1273 string "text/plain" and is the UTF8 encoding of the string 1274 "Konrad is the traitor". The randomly chosen key is NDD7-6CMX-H2FW- 1275 ISAL-K4VB-DQ3E-PEDM. 1277 Data = 1278 4B 6F 6E 72 61 64 20 69 73 20 74 68 65 20 74 72 1279 61 69 74 6F 72 1281 ContentType = 1282 74 65 78 74 2F 70 6C 61 69 6E 1284 Key = 1285 4E 44 44 37 2D 36 43 4D 58 2D 48 32 46 57 2D 49 1286 53 41 4C 2D 4B 34 56 42 2D 44 51 33 45 2D 50 45 1287 44 4D 1289 Processing is performed in the same manner as an unkeyed fingerprint 1290 except that compression is never used: 1292 H() = 1293 93 FC DA F9 FA FD 1E 26 50 26 C3 C1 28 43 40 73 1294 D8 BC 3D 62 87 73 2B 73 B8 EC 93 B6 DE 80 FF DA 1295 70 0A D1 CE E8 F4 36 68 EF 4E 71 63 41 53 91 5C 1296 CE 8C 5C CE C7 9A 46 94 6A 35 79 F9 33 70 85 01 1298 + ':' + H() = 1299 74 65 78 74 2F 70 6C 61 69 6E 3A 93 FC DA F9 FA 1300 FD 1E 26 50 26 C3 C1 28 43 40 73 D8 BC 3D 62 87 1301 73 2B 73 B8 EC 93 B6 DE 80 FF DA 70 0A D1 CE E8 1302 F4 36 68 EF 4E 71 63 41 53 91 5C CE 8C 5C CE C7 1303 9A 46 94 6A 35 79 F9 33 70 85 01 1305 PRK(Key) = 1306 77 D3 0A 08 39 BD 9D C0 97 44 DA 33 15 0A 42 5E 1307 CD 17 80 03 B3 CF CC 89 7A C7 84 12 B4 51 5B 25 1308 DC 26 F5 E1 1B 20 F3 89 2E 9A 1A 7B 0E 73 23 39 1309 0E C3 4C EF 2D 40 DA 05 B4 70 C6 1C 82 C1 49 33 1311 HKDF(Key) = 1312 BF A9 B4 58 9C 1D 68 D7 9A B7 11 F6 C8 98 59 14 1313 20 D7 82 67 C5 84 22 E5 A0 F9 93 52 B1 C3 87 EB 1314 05 06 CB C4 E4 D6 E6 EE 1F F0 D4 7A 97 68 5E CE 1315 28 1C CA AF D8 B5 D1 24 4A 71 EC E3 AC B5 D2 04 1317 MAC(, + ':' + H()) = 1318 4C C3 7F D3 F9 9E 52 CF 07 90 74 53 84 65 95 BC 1319 1A 2B A5 D1 68 9D 05 6D 06 C5 CA BF 17 CB E0 49 1320 95 39 57 08 79 C4 E5 49 D3 3A 59 A3 32 05 45 A6 1321 30 26 25 AE 8A F4 47 C6 1F B5 33 7F AD 69 A6 30 1323 The prefixed Binary Data Sequence is thus 1324 00 4C C3 7F D3 F9 9E 52 CF 07 90 74 53 84 65 95 1325 BC 1A 1327 The 125 bit fingerprint value is ABGM-G76T-7GPF-FTYH-SB2F-HBDF-SW6B 1329 5.3. Content Type Values 1331 While a UDF fingerprint MAY be used to identify any form of static 1332 data, the use of a UDF fingerprint to identify a public key signature 1333 key provides a level of indirection and thus the ability to identify 1334 dynamic data. The content types used to identify public keys are 1335 thus of particular interest. 1337 As described in the security considerations section, the use of 1338 fingerprints to identify a bare public key and the use of 1339 fingerprints to identify a public key and associated security policy 1340 information are very different. 1342 5.3.1. PKIX Certificates and Keys 1344 UDF fingerprints MAY be used to identify PKIX certificates, CRLs and 1345 public keys in the ASN.1 encoding used in PKIX certificates. 1347 Since PKIX certificates and CLRs contain security policy information, 1348 UDF fingerprints used to identify certificates or CRLs SHOULD be 1349 presented with a minimum of 200 bits of precision. PKIX applications 1350 MUST not accept UDF fingerprints specified with less than 200 bits of 1351 precision for purposes of identifying trust anchors. 1353 PKIX certificates, keys and related content data are identified by 1354 the following content types: 1356 application/pkix-cert A PKIX Certificate 1358 application/pkix-crl A PKIX CRL 1360 application/pkix-keyinfo The SubjectPublicKeyInfo structure defined 1361 in the PKIX certificate specification encoded using DER encoding 1362 rules. 1364 The SubjectPublicKeyInfo structure is defined in [RFC5280] as 1365 follows: 1367 SubjectPublicKeyInfo ::= SEQUENCE { 1368 algorithm AlgorithmIdentifier, 1369 subjectPublicKey BIT STRING } 1371 This schema results in an identical DER encoding to the OIDInfo 1372 sequence specified in section XXX. The distinction between these 1373 productions is that the OIDInfo schema is intended to be used to 1374 encode arbitrary data while the application/pkix-keyinfo content type 1375 is only intended to be used to describe public keys. 1377 5.3.2. OpenPGP Key 1379 OpenPGPv5 keys and key set content data are identified by the 1380 following content type: 1382 application/pgp-keys An OpenPGP key set. 1384 5.3.3. DNSSEC 1386 DNSSEC record data consists of DNS records which are identified by 1387 the following content type: 1389 application/dns A DNS resource record in binary format 1391 6. UDF URIs 1393 The UDF URI scheme describes a means of constructing URIs from a UDF 1394 value. 1396 Two forms or UDF URI are specified, Name and Locator. In both cases 1397 the URI MUST specify the scheme type "UDF", and a UDF fingerprint and 1398 MAY specify a query identifier and/or a fragment identifier. 1400 By definition a Locator form URI contains an authority field which 1401 MUST be a DNS domain name. The use of IP address forms for this 1402 purpose is not permitted. 1404 Name Form URIs allow static content data to be identified without 1405 specifying the means by which the content data may be retrieved. 1406 Locator form URIs allow static content data or dynamic network 1407 resources to be identified and the means of retrieval. 1409 The syntax of a UDF URI is a subset of the generic URI syntax 1410 specified in [RFC3986] . The use of userinfo and port numbers is not 1411 supported and the path part of the uri is a UDF in base32 1412 presentation. 1414 URI = "UDF:" udf [ "?" query ] [ "" fragment ] 1416 udf = name-form / locator-form 1418 name-form = udf-value 1419 locator-form = "//" authority "/" udf-value 1421 authority = host 1422 host = reg-name 1424 6.1. Name form 1426 Name form UDF URIs provide a means of presenting a UDF value in a 1427 context in which a URI form of a name is required without providing a 1428 means of resolution. 1430 Adding the UDF scheme prefix to a UDF fingerprint does not change the 1431 semantics of the fingerprint itself. The semantics of the name 1432 result from the context in which it is used. 1434 For example, a UDF value of any type MAY be used to give a unique 1435 targetNamespace value in an XML Schema [XMLSchema] 1437 6.2. Locator form 1439 The locator form of an unkeyed UDF URI is resolved by the following 1440 steps: 1442 o Use DNS Web service discovery to determine the Web Service 1443 Endpoint. 1445 o Determine the content identifier from the source URI. 1447 o Append the content identifier to the Web Service Endpoint as a 1448 suffix to form the target URI. 1450 o Retrieve content from the Web Service Endpoint by means of a GET 1451 method. 1453 o Perform post processing as specified by the UDF type. 1455 6.2.1. DNS Web service discovery 1457 DNS Web Discovery is performed as specified in 1458 [draft-hallambaker-web-service-discovery] for the service mmm-udf and 1459 domain name specified in the URI. For a full description of the 1460 discovery mechanism, consult the referenced specification. 1462 The use of DNS Web Discovery permits service providers to make full 1463 use of the load balancing and service description capabilities 1464 afforded by use of DNS SRV and TXT records in accordance with the 1465 approach described in [RFC6763] . 1467 If no SRV or TXT records are specified, DNS Web Discovery specifies 1468 that the Web Service Endpoint be the Well Known Service [RFC5785] 1469 with the prefix /.well-known/srv/mmm-udf. 1471 6.2.2. Content Identifier 1473 For all UDF types other than Secret Share, the Content Identifier 1474 value is the UDF SHA-2-512 Content Digest of the canonical form of 1475 the UDF specified in the source URI presented at twice the precision 1476 to a maximum of 440 bits. 1478 If the UDF is of type Secret Share, the shared secret MUST be 1479 recovered before the content identifier can be resolved. The shared 1480 secret is then expressed as a UDF of type Encryption/Authentication 1481 and the Content Identifier determined as for an Encryption/ 1482 Authentication type UDF. 1484 6.2.3. Target URI 1486 The target URI is formed by appending a slash separator '/' and the 1487 Content Identifier value to the Web Service Endpoint. 1489 Since the path portion of a URI is case sensitive, the UDF value MUST 1490 be specified in upper case and MUST include separator marks. 1492 6.2.4. Postprocessing 1494 After retrieving the content data, the resolver MUST perform post 1495 processing as indicated by the content type: 1497 Nonce No additional post processing is required. 1499 Content Digest The resolver MUST verify that the content returned 1500 matches the UDF fingerprint value. 1502 Authenticator The resolver MUST verify that the content returned 1503 matches the UDF fingerprint value. 1505 Encryption/Authentication The content data returned is decrypted and 1506 authenticated using the key specified in the UDF value as the 1507 initial keying material (see below). 1509 Secret Share (set) The content data returned is decrypted and 1510 authenticated using the shared secret as the initial keying 1511 material (see below). 1513 6.2.5. Decryption and Authentication 1515 The steps performed to decode cryptographically enhanced content data 1516 depends on the content type specified in the returned content. Two 1517 formats are currently supported: 1519 o DARE Envelope format as specified in [draft-hallambaker-mesh-dare] 1521 o Cryptographic Message Syntax (CMS) Symmetric Key Package as 1522 specified in [RFC6031] 1524 6.2.6. QR Presentation 1526 Encoding of a UDF URI as a QR code requires only the characters in 1527 alphanumeric encoding, thus achieving compactness with minimal 1528 overhead. 1530 7. Strong Internet Names 1532 A Strong Internet Name is an Internet address that is bound to a 1533 policy governing interpretation of that address by means of a Content 1534 Digest type UDF of the policy expressed as a UDF prefixed DNS label 1535 within the address itself. 1537 The Reserved LDH labels as defined in [RFC5890] that begin with the 1538 prefix mm-- are reserved for use as Strong Internet Names. The 1539 characters following the prefix are a Content Digest type UDF in 1540 Base32 presentation. 1542 Since DNS labels are limited to 63 characters, the presentation of 1543 the SIN itself is limited to 59 characters and thus 240 bits of 1544 precision. 1546 8. Security Considerations 1548 This section describes security considerations arising from the use 1549 of UDF in general applications. 1551 Additional security considerations for use of UDFs in Mesh services 1552 and applications are described in the Mesh Security Considerations 1553 guide [draft-hallambaker-mesh-security] . 1555 8.1. Confidentiality 1557 Encrypted locator is a bearer token 1559 8.2. Availability 1561 Corruption of a part of a shared secret may prevent recovery 1563 8.3. Integrity 1565 Shared secret parts do not contain context information to specify 1566 which secret they relate to. 1568 8.4. Work Factor and Precision 1570 A given UDF data object has a single fingerprint value that may be 1571 presented at different precisions. The shortest legitimate precision 1572 with which a UDF fingerprint may be presented has 96 significant bits 1574 A UDF fingerprint presents the same work factor as any other 1575 cryptographic digest function. The difficulty of finding a second 1576 data item that matches a given fingerprint is 2^n and the difficulty 1577 or finding two data items that have the same fingerprint is 2^(n/2). 1578 Where n is the precision of the fingerprint. 1580 For the algorithms specified in this document, n = 512 and thus the 1581 work factor for finding collisions is 2^256, a value that is 1582 generally considered to be computationally infeasible. 1584 Since the use of 512 bit fingerprints is impractical in the type of 1585 applications where fingerprints are generally used, truncation is a 1586 practical necessity. The longer a fingerprint is, the less likely it 1587 is that a user will check every character. It is therefore important 1588 to consider carefully whether the security of an application depends 1589 on second pre-image resistance or collision resistance. 1591 In most fingerprint applications, such as the use of fingerprints to 1592 identify public keys, the fact that a malicious party might generate 1593 two keys that have the same fingerprint value is a minor concern. 1594 Combined with a flawed protocol architecture, such a vulnerability 1595 may permit an attacker to construct a document such that the 1596 signature will be accepted as valid by some parties but not by 1597 others. 1599 For example, Alice generates keypairs until two are generated that 1600 have the same 100 bit UDF presentation (typically 2^48 attempts). 1601 She registers one keypair with a merchant and the other with her 1602 bank. This allows Alice to create a payment instrument that will be 1603 accepted as valid by one and rejected by the other. 1605 The ability to generate of two PKIX certificates with the same 1606 fingerprint and different certificate attributes raises very 1607 different and more serious security concerns. For example, an 1608 attacker might generate two certificates with the same key and 1609 different use constraints. This might allow an attacker to present a 1610 highly constrained certificate that does not present a security risk 1611 to an application for purposes of gaining approval and an 1612 unconstrained certificate to request a malicious action. 1614 In general, any use of fingerprints to identify data that has 1615 security policy semantics requires the risk of collision attacks to 1616 be considered. For this reason, the use of short, 'user friendly' 1617 fingerprint presentations (Less than 200 bits) SHOULD only be used 1618 for public key values. 1620 8.5. Semantic Substitution 1622 Many applications record the fact that a data item is trusted, rather 1623 fewer record the circumstances in which the data item is trusted. 1624 This results in a semantic substitution vulnerability which an 1625 attacker may exploit by presenting the trusted data item in the wrong 1626 context. 1628 The UDF format provides protection against high level semantic 1629 substitution attacks by incorporating the content type into the input 1630 to the outermost fingerprint digest function. The work factor for 1631 generating a UDF fingerprint that is valid in both contexts is thus 1632 the same as the work factor for finding a second preimage in the 1633 digest function (2^512 for the specified digest algorithms). 1635 It is thus infeasible to generate a data item such that some 1636 applications will interpret it as a PKIX key and others will accept 1637 as an OpenPGP key. While attempting to parse a PKIX key as an 1638 OpenPGP key is virtually certain to fail to return the correct key 1639 parameters it cannot be assumed that the attempt is guaranteed to 1640 fail with an error message. 1642 The UDF format does not provide protection against semantic 1643 substitution attacks that do not affect the content type. 1645 8.6. QR Code Scanning 1647 The act of scanning a QR code SHOULD be considered equivalent to 1648 clicking on an unlabeled hypertext link. Since QR codes are scanned 1649 in many different contexts, the mere act of scanning a QR code MUST 1650 NOT be interpreted as constituting an affirmative acceptance of terms 1651 or conditions or as creating an electronic signature. 1653 If such semantics are required in the context of an application, 1654 these MUST be established by secondary user actions made subsequent 1655 to the scanning of the QR code. 1657 There is a risk that use of QR codes to automate processes such as 1658 payment will lead to abusive practices such as presentation of 1659 fraudulent invoices for goods not ordered or delivered. It is 1660 therefore important to ensure that such requests are subject to 1661 adequate accountability controls. 1663 9. IANA Considerations 1665 Registrations are requested in the following registries: 1667 o Service Name and Transport Protocol Port Number 1669 o well-known URI registry 1671 o Uniform Resource Identifier (URI) Schemes 1673 o Media Types 1675 In addition, the creation of the following registry is requested: 1676 Uniform Data Fingerprint Type Identifier Registry. 1678 9.1. Protocol Service Name 1680 The following registration is requested in the Service Name and 1681 Transport Protocol Port Number Registry in accordance with [RFC6355] 1683 Service Name (REQUIRED) mmm-udf 1685 Transport Protocol(s) (REQUIRED) TCP 1687 Assignee (REQUIRED) Phillip Hallam-Baker, phill@hallambaker.com 1689 Contact (REQUIRED) Phillip Hallam-Baker, phill@hallambaker.com 1691 Description (REQUIRED) mmm-udf is a Web Service protocol that 1692 resolves Mathematical Mesh Uniform Data Fingerprints (UDF) to 1693 resources. The mmm-udf service name is used in service discovery 1694 to identify a Web Service endpoint to perform resolution of a UDF 1695 presented in URI locator form. 1697 Reference (REQUIRED) [This document] 1699 Port Number (OPTIONAL) None 1701 Service Code (REQUIRED for DCCP only) None 1703 Known Unauthorized Uses (OPTIONAL) None 1705 Assignment Notes (OPTIONAL) None 1707 9.2. Well Known 1709 The following registration is requested in the well-known URI 1710 registry in accordance with [RFC5785] 1712 URI suffix srv/mmm-udf 1714 Change controller Phillip Hallam-Baker, phill@hallambaker.com 1716 Specification document(s): [This document] 1718 Related information 1720 [draft-hallambaker-web-service-discovery] 1722 9.3. URI Registration 1724 The following registration is requested in the Uniform Resource 1725 Identifier (URI) Schemes registry in accordance with [RFC7595] 1727 Scheme name: UDF 1729 Status: Provisional 1731 Applications/protocols that use this scheme name: Mathematical Mesh 1732 Service protocols (mmm) 1734 Contact: Phillip Hallam-Baker mailto:phill@hallambaker.com 1736 Change controller: Phillip Hallam-Baker 1738 References: [This document] 1740 9.4. Media Types Registrations 1742 9.4.1. Media Type: application/pkix-keyinfo 1744 Type name: application 1746 Subtype name: pkix-keyinfo 1748 Required parameters: None 1750 Optional parameters: None 1752 Encoding considerations: Binary 1754 Security considerations: Described in [This] 1755 Interoperability considerations: None 1757 Published specification: [This] 1759 Applications that use this media type: Uniform Data Fingerprint 1761 Fragment identifier considerations: None 1763 Additional information: Deprecated alias names for this type: None 1765 Magic number(s): None 1767 File extension(s): None 1769 Macintosh file type code(s): None 1771 Person & email address to contact for further information: 1772 Phillip Hallam-Baker @hallambaker.com> 1774 Intended usage: Content type identifier to be used in constructing 1775 UDF Content Digests and Authenticators and related cryptographic 1776 purposes. 1778 Restrictions on usage: None 1780 Author: Phillip Hallam-Baker 1782 Change controller: Phillip Hallam-Baker 1784 Provisional registration? (standards tree only): Yes 1786 9.4.2. Media Type: application/udf-encryption 1788 Type name: application 1790 Subtype name: udf-encryption 1792 Required parameters: None 1794 Optional parameters: None 1796 Encoding considerations: None 1798 Security considerations: Described in [This] 1800 Interoperability considerations: None 1802 Published specification: [This] 1803 Applications that use this media type: Uniform Data Fingerprint 1805 Fragment identifier considerations: None 1807 Additional information: Deprecated alias names for this type: None 1809 Magic number(s): None 1811 File extension(s): None 1813 Macintosh file type code(s): None 1815 Person & email address to contact for further information: 1816 Phillip Hallam-Baker @hallambaker.com> 1818 Intended usage: Content type identifier to be used in constructing 1819 UDF Content Digests and Authenticators and related cryptographic 1820 purposes. 1822 Restrictions on usage: None 1824 Author: Phillip Hallam-Baker 1826 Change controller: Phillip Hallam-Baker 1828 Provisional registration? (standards tree only): Yes 1830 9.4.3. Media Type: application/udf-secret 1832 Type name: application 1834 Subtype name: udf- secret 1836 Required parameters: None 1838 Optional parameters: None 1840 Encoding considerations: None 1842 Security considerations: Described in [This] 1844 Interoperability considerations: None 1846 Published specification: [This] 1848 Applications that use this media type: Uniform Data Fingerprint 1850 Fragment identifier considerations: None 1851 Additional information: Deprecated alias names for this type: None 1853 Magic number(s): None 1855 File extension(s): None 1857 Macintosh file type code(s): None 1859 Person & email address to contact for further information: 1860 Phillip Hallam-Baker @hallambaker.com> 1862 Intended usage: Content type identifier to be used in constructing 1863 UDF Content Digests and Authenticators and related cryptographic 1864 purposes. 1866 Restrictions on usage: None 1868 Author: Phillip Hallam-Baker 1870 Change controller: Phillip Hallam-Baker 1872 Provisional registration? (standards tree only): Yes 1874 9.5. Uniform Data Fingerprint Type Identifier Registry 1876 This document describes a new extensible data format employing fixed 1877 length version identifiers for UDF types. 1879 9.5.1. The name of the registry 1881 Uniform Data Fingerprint Type Identifier Registry 1883 9.5.2. Required information for registrations 1885 Registrants must specify the Type identifier code(s) requested, 1886 description and RFC number for the corresponding standards action 1887 document. 1889 The standards document must specify the means of generating and 1890 interpreting the UDF Data Sequence Value and the purpose(s) for which 1891 it is proposed. 1893 Since the initial letter of the Base32 presentation provides a 1894 mnemonic function in UDFs, the standards document must explain why 1895 the proposed Type Identifier and associated initial letter are 1896 appropriate. In cases where a new initial letter is to be created, 1897 there must be an explanation of why this is appropriate. If an 1898 existing initial letter is to be created, there must be an 1899 explanation of why this is appropriate and/or acceptable. 1901 9.5.3. Applicable registration policy 1903 Due to the intended field of use (human data entry), the code space 1904 is severely constrained. Accordingly, it is intended that code point 1905 registrations be as infrequent as possible. 1907 Registration of new digest algorithms is strongly discouraged and 1908 should not occur unless, (1) there is a known security vulnerability 1909 in one of the two schemes specified in the original assignment and 1910 (2) the proposed algorithm has been subjected to rigorous peer 1911 review, preferably in the form of an open, international competition 1912 and (3) the proposed algorithm has been adopted as a preferred 1913 algorithm for use in IETF protocols. 1915 Accordingly, the applicable registration policy is Standards Action. 1917 9.5.4. Size, format, and syntax of registry entries 1919 Each registry entry consists of a single byte code, 1921 9.5.5. Initial assignments and reservations 1923 The following entries should be added to the registry as initial 1924 assignments: 1926 Code Description Reference 1927 --- ------------------- --------- 1928 00 HMAC and SHA-2-512 [This document] 1929 32 HKDF-AES-512 [This document] 1930 80 SHA-3-512 [This document] 1931 81 SHA-3-512 with 20 trailing zeros [This document] 1932 82 SHA-3-512 with 30 trailing zeros [This document] 1933 82 SHA-3-512 with 40 trailing zeros [This document] 1934 83 SHA-3-512 with 50 trailing zeros [This document] 1935 96 SHA-2-512 [This document] 1936 97 SHA-2-512 with 20 trailing zeros [This document] 1937 98 SHA-2-512 with 30 trailing zeros [This document] 1938 99 SHA-2-512 with 40 trailing zeros [This document] 1939 100 SHA-2-512 with 50 trailing zeros [This document] 1940 104 Random nonce [This document] 1941 144 Shamir Secret Share [This document] 1943 10. Acknowledgements 1945 A list of people who have contributed to the design of the Mesh is 1946 presented in [draft-hallambaker-mesh-architecture] . 1948 Thanks are due to Viktor Dukhovni, Damian Weber and an anonymous 1949 member of the cryptography@metzdowd.com list for assisting in the 1950 compilation of the table of prime values. 1952 11. Appendix A: Prime Values for Secret Sharing 1954 The following are the prime values to be used for sharing secrets of 1955 up to 512 bits. 1957 If it is necessary to share larger secrets, the corresponding prime 1958 may be found by choosing a value (2^32)^n that is larger than the 1959 secret to be encoded and determining the next largest number that is 1960 prime. 1962 +----------------+----------------------+ 1963 | Number of bits | Offset = Primen - 2n | 1964 +----------------+----------------------+ 1965 | 32 | 15 | 1966 | 64 | 13 | 1967 | 96 | 61 | 1968 | 128 | 51 | 1969 | 160 | 7 | 1970 | 192 | 133 | 1971 | 224 | 735 | 1972 | 256 | 297 | 1973 | 288 | 127 | 1974 | 320 | 27 | 1975 | 352 | 55 | 1976 | 384 | 231 | 1977 | 416 | 235 | 1978 | 448 | 211 | 1979 | 480 | 165 | 1980 | 512 | 75 | 1981 +----------------+----------------------+ 1983 Table 3 1985 For example, the prime to be used to share a 128 bit value is 2^128 + 1986 51. 1988 12. Recovering Shamir Shared Secret 1990 The value of a Shamir Shared secret may be recovered using Lagrange 1991 basis polynomials. 1993 To share a secret with a threshold of n shares and L bits we 1994 constructed f(x) a polynomial of degree n in the modular field p 1995 where p is the smallest prime greater than 2^L: 1997 f(x) = a_0 + a_1.x + a_2.x^2 + ... a_n.x^n 1999 The shared secret is the binary representation of the value a_0 2001 Given n shares (x_0, y_0), (x_1, y_1), ... (x_n-1, y_n-1), The 2002 corresponding the Lagrange basis polynomials l_0, l_1, .. l_n-1 are 2003 given by: 2005 lm = ((x - x(m_0)) / (x(m) - x(m_0))) . ((x - x(m_1)) / (x(m) - 2006 x(m_1))) . ... . ((x - x(m_n-2)) / (x(m) - x(m_n-2))) 2008 Where the values m_0, m_1, ... m_n-2, are the integers 0, 1, .. n-1, 2009 excluding the value m. 2011 These can be used to compute f(x) as follows: 2013 f(x) = y_0l_0 + y_1l_1 + ... y_n-1l_n-1 2015 Since it is only the value of f(0) that we are interested in, we 2016 compute the Lagrange basis for the value x = 0: 2018 lz_m = ((x(m_1)) / (x(m) - x(m_1))) . ((x(m_2)) / (x(m) - x(m_2))) 2020 Hence, 2022 a_0 = f(0) = y_0lz_0 + y_1lz_1 + ... y_n-1l_n-1 2024 The following C# code recovers the values. 2026 using System; 2027 using System.Collections.Generic; 2028 using System.Numerics; 2030 namespace Examples { 2032 class Examples { 2034 /// 2035 /// Combine a set of points (x, f(x)) 2036 /// on a polynomial of degree in a 2037 /// discrete field modulo prime to 2038 /// recover the value f(0) using Lagrange basis polynomials. 2039 /// 2040 /// The values f(x). 2041 /// The values for x. 2042 /// The modulus. 2043 /// The polynomial degree. 2044 /// The value f(0). 2045 static BigInteger CombineNK( 2046 BigInteger[] fx, 2047 int[] x, 2048 BigInteger p, 2049 int n) { 2050 if (fx.Length < n) { 2051 throw new Exception("Insufficient shares"); 2052 } 2054 BigInteger accumulator = 0; 2055 for (var formula = 0; formula < n; formula++) { 2056 var value = fx[formula]; 2058 BigInteger numerator = 1, denominator = 1; 2059 for (var count = 0; count < n; count++) { 2060 if (formula == count) { 2061 continue; // If not the same value 2062 } 2064 var start = x[formula]; 2065 var next = x[count]; 2067 numerator = (numerator * -next) % p; 2068 denominator = (denominator * (start - next)) % p; 2069 } 2071 var InvDenominator = ModInverse(denominator, p); 2073 accumulator = Modulus((accumulator + 2074 (fx[formula] * numerator * InvDenominator)), p); 2075 } 2077 return accumulator; 2078 } 2080 /// 2081 /// Compute the modular multiplicative inverse of the value 2082 /// modulo 2083 /// 2084 /// The value to find the inverse of 2085 /// The modulus. 2086 /// 2087 static BigInteger ModInverse( 2088 BigInteger k, 2089 BigInteger p) { 2090 var m2 = p - 2; 2091 if (k < 0) { 2092 k = k + p; 2093 } 2095 return BigInteger.ModPow(k, m2, p); 2096 } 2098 /// 2099 /// Calculate the modulus of a number with correct handling 2100 /// for negative numbers. 2101 /// 2102 /// Value 2103 /// The modulus. 2104 /// x mod p 2105 public static BigInteger Modulus( 2106 BigInteger x, 2107 BigInteger p) { 2108 var Result = x % p; 2109 return Result.Sign >= 0 ? Result : Result + p; 2110 } 2111 } 2112 } 2114 13. References 2116 13.1. Normative References 2118 [draft-hallambaker-mesh-architecture] 2119 Hallam-Baker, P., "Mathematical Mesh 3.0 Part I: 2120 Architecture Guide", draft-hallambaker-mesh- 2121 architecture-10 (work in progress), August 2019. 2123 [draft-hallambaker-mesh-dare] 2124 Hallam-Baker, P., "Mathematical Mesh 3.0 Part III : Data 2125 At Rest Encryption (DARE)", draft-hallambaker-mesh-dare-04 2126 (work in progress), August 2019. 2128 [draft-hallambaker-mesh-security] 2129 Hallam-Baker, P., "Mathematical Mesh Part VII: Security 2130 Considerations", draft-hallambaker-mesh-security-01 (work 2131 in progress), July 2019. 2133 [draft-hallambaker-web-service-discovery] 2134 Hallam-Baker, P., "DNS Web Service Discovery", draft- 2135 hallambaker-web-service-discovery-02 (work in progress), 2136 April 2019. 2138 [RFC2014] Weinrib, A. and J. Postel, "IRTF Research Group Guidelines 2139 and Procedures", BCP 8, RFC 2014, DOI 10.17487/RFC2014, 2140 October 1996. 2142 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2143 Requirement Levels", BCP 14, RFC 2119, 2144 DOI 10.17487/RFC2119, March 1997. 2146 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2147 Resource Identifier (URI): Generic Syntax", STD 66, 2148 RFC 3986, DOI 10.17487/RFC3986, January 2005. 2150 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 2151 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006. 2153 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2154 Housley, R., and W. Polk, "Internet X.509 Public Key 2155 Infrastructure Certificate and Certificate Revocation List 2156 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008. 2158 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 2159 Key Derivation Function (HKDF)", RFC 5869, 2160 DOI 10.17487/RFC5869, May 2010. 2162 [RFC6031] Turner, S. and R. Housley, "Cryptographic Message Syntax 2163 (CMS) Symmetric Key Package Content Type", RFC 6031, 2164 DOI 10.17487/RFC6031, December 2010. 2166 [SHA-2] NIST, "Secure Hash Standard", August 2015. 2168 [SHA-3] Dworkin, M., "SHA-3 Standard: Permutation-Based Hash and 2169 Extendable-Output Functions", August 2015. 2171 13.2. Informative References 2173 [draft-hallambaker-mesh-developer] 2174 Hallam-Baker, P., "Mathematical Mesh: Reference 2175 Implementation", draft-hallambaker-mesh-developer-08 (work 2176 in progress), April 2019. 2178 [draft-hallambaker-mesh-trust] 2179 Hallam-Baker, P., "Mathematical Mesh Part VI: The Trust 2180 Mesh", draft-hallambaker-mesh-trust-02 (work in progress), 2181 July 2019. 2183 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 2184 "Randomness Requirements for Security", BCP 106, RFC 4086, 2185 DOI 10.17487/RFC4086, June 2005. 2187 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 2188 Thayer, "OpenPGP Message Format", RFC 4880, 2189 DOI 10.17487/RFC4880, November 2007. 2191 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 2192 Uniform Resource Identifiers (URIs)", RFC 5785, 2193 DOI 10.17487/RFC5785, April 2010. 2195 [RFC5890] Klensin, J., "Internationalized Domain Names for 2196 Applications (IDNA): Definitions and Document Framework", 2197 RFC 5890, DOI 10.17487/RFC5890, August 2010. 2199 [RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based 2200 DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, 2201 DOI 10.17487/RFC6355, August 2011. 2203 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 2204 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013. 2206 [RFC7595] Thaler, D., Hansen, T., and T. Hardie, "Guidelines and 2207 Registration Procedures for URI Schemes", BCP 35, 2208 RFC 7595, DOI 10.17487/RFC7595, June 2015. 2210 [Shamir79] 2211 "[Reference Not Found!]". 2213 [XMLSchema] 2214 Gao, S., Sperberg-McQueen, C., Thompson, H., Mendelsohn, 2215 N., Beech, D., and M. Maloney, "W3C XML Schema Definition 2216 Language (XSD) 1.1 Part 1: Structures", April 2012. 2218 13.3. URIs 2220 [1] http://mathmesh.com/Documents/draft-hallambaker-mesh-udf.html 2222 [2] http://mathmesh.com/Documents/draft-hallambaker-mesh-udf.html 2224 Author's Address 2226 Phillip Hallam-Baker 2228 Email: phill@hallambaker.com