Mathematical Mesh 3.0 Part II: Uniform Data Fingerprint.

1.1.1. Cryptographic Keys and Nonces

A Nonce (N) UDF represents a short, fixed length randomly chosen binary value.¶

Nonce UDFs are used within many Mesh protocols and data formats where it is necessary to represent a nonce value in text form.¶

Nonce UDF:
  ND5L-BTJE-W372-4TUS-E23N-FIXU-6ARA

An Encryption/Authentication (E) UDF has the same format as a Random UDF but is identified as being intended to be used as a symmetric key for encryption and/or authentication.¶

KeyValue:
  DE BB 13 26  28 7A 83 5B  58 65 38 B1  48 8C 7C

Encryption/Authenticator UDF:
  UXPL-WEZG-FB5I-GW2Y-MU4L-CSEM-PQ

A Share (S) UDF also represents a short, fixed length binary value but only provides one share in secret sharing scheme. Recovery of the binary value requires a sufficient number of shares.¶

Share UDFs are used in the Mesh to support key and data escrow operations without the need to rely on trusted hardware. A share UDF can be copied by hand or printed in human or machine-readable form (e.g. QR code).¶

Key:     UXPL-WEZG-FB5I-GW2Y-MU4L-CSEM-PQ
Share 0: SAQF-K5LV-2HDO-PSY5-YQBN-CPMS-7MXM-K
Share 1: SAQQ-KDBQ-SBT2-OG5Y-FSWT-2QTU-VXIQ-4
Share 2: SARL-JIXL-J4EG-M3CS-SVL2-SR2W-MBZY-U

1.1.2. Fingerprint type UDFS

Fingerprint type UDFs contains a fingerprint value calculated over a content data item and an IANA media type.¶

A Content Digest type UDF is a fingerprint type UDF in which the fingerprint is formed using a cryptographic algorithm. Two digest algorithms are currently supported, SHA-2-512 (M, for Merkle Damgard) and SHA-3-512 (K, for Keccak).¶

The inclusion of the media type in the calculation of the UDF value provides protection against semantic substitution attacks in which content that has been found to be trustworthy when interpreted as one content type is presented in a context in which it is interpreted as a different content type in which it is unsafe.¶

SHA-2-512: MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4
SHA-3-512: KCM5-7VB6-IJXJ-WKHX-NZQF-OKGZ-EWVN

An Authentication UDF (A) is formed in the same manner as a fingerprint but using a Message Authentication Code algorithm and a symmetric key.¶

Authentication UDFs are used to express commitments and to provide a means of blinding fingerprint values within a protocol by means of a nonce.¶

SHA-2-512: ABIR-Y75D-WV63-P5WC-KR3F-VA57-YZ6I

1.2.1. Name Form

Name form UDF URIs identify a data resource but do not provide a means of discovery. The URI is simply the scheme (udf) followed by the UDF value:¶

udf:MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4

1.2.2. Locator Form

Locator form UDF URIs identify a data resource and provide a hint that MAY provide a means of discovery. If the content is not available from the location indicated, content obtained from a different source that matches the fingerprint MAY be used instead.¶

udf://example.com/MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4

UDF locator form URIs presenting a fingerprint type UDF provide a tight binding of the content to the locator. This allows the resolved content to be verified and rejected if it has been modified.¶

UDF locator form URIs presenting an Encryptor/Authenticator type UDF provide a mechanism for identification, discovery and decryption of encrypted content. UDF locators of this type are known as Encrypted/Authenticated Resource Locators (EARLs).¶

Regardless of the type of the embedded UDF, UDF locator form URIs are resolved by first performing DNS Web Service Discovery to identify the Web Service Endpoint for the mmm-udf service at the specified domain.¶

Resolution is completed by presenting the Content Digest Fingerprint of the UDF value specified in the URI to the specified Web Service Endpoint and performing a GET method request on the result.¶

For example, Alice subscribes to Example.com, a purveyor of cat and kitten images. The company generates paper and electronic invoices on a monthly basis.¶

To generate the paper invoice, Example.com first creates a new encryption key:¶

EA2L-PABQ-ZUIO-UR2U-KLMP-YFYK-XI5U-6Z¶

One or more electronic forms of the invoice are encrypted under the key EA2L-PABQ-ZUIO-UR2U-KLMP-YFYK-XI5U-6Z and placed on the Example.com Web site so that the appropriate version is returned if Alice scans the QR code.¶

The key is then converted to form an EARL for the example.com UDF resolution service:¶

udf://example.com/EA2L-PABQ-ZUIO-UR2U-KLMP-YFYK-XI5U-6Z¶

The EARL is then rendered as a QR code:¶

A printable invoice containing the QR code is now generated and sent to Alice.¶

When Alice receives the invoice, she can pay it by simply scanning the invoice with a device that recognizes at least one of the invoice formats supported by Example.com.¶

The UDF EARL locator shown above is resolved by first determining the Web Service Endpoint for the mmm-udf service for the domain example.com.¶

Discover ("example.com", "mmm-udf") =
https://example.com/.well-known/mmm-udf/

Next the fingerprint of the source UDF is obtained.¶

UDF (EA2L-PABQ-ZUIO-UR2U-KLMP-YFYK-XI5U-6Z) =
MBUC-DFHR-NRPA-ZLHR-CZRT-75CV-VWL2-OSIC-2YUH-QJ7C-3WWA-7CLC-W4X7-YNBO

Combining the Web Service Endpoint and the fingerprint of the source UDF provides the URI from which the content is obtained using the normal HTTP GET method:¶

https://example.com/.well-known/mmm-udf/MBUC-DFHR-NRPA-ZLHR-CZRT-75CV-VWL2-OSIC-2YUH-QJ7C-3WWA-7CLC-W4X7-YNBO¶

Having established that Alice can read postal mail sent to a physical address and having delivered a secret to that address, this process might be extended to provide a means of automating the process of enrolment in electronic delivery of future invoices.¶

3.1.1. Precision Improvement

Precision improvement is the practice of using a high precision UDF (e.g. 260 bits) calculated from content data that has been validated according to a lower precision UDF (e.g. 120 bits).¶

This allows a lower precision UDF to be used in a medium such as a business card where space is constrained without compromising subsequent uses.¶

Applications SHOULD make use of precision improvement wherever possible.¶

3.4.1. Compressed presentation

The Content Digest UDF types make use of work factor compression. Additional type identifiers are used to indicate digest values with 20, 30, 40 or 50 trailing zero bits allowing a UDF fingerprint offering the equivalent of up to 150 bits of precision to be expressed in 20 characters instead of 30.¶

To use compressed UDF identifiers, it is necessary to search for content that can be compressed. If the digest algorithm used is secure, this means that by definition, the fastest means of search is brute force. Thus, the reduction in fingerprint size is achieved by transferring the work factor from the attacker to the defender. To maintain a work factor of 2¹²⁰ with an identifier of 2⁸⁰ bits, it is necessary for the content generator to perform a brute force search at a cost of the order of 2⁴⁰ operations.¶

For example, the smallest allowable work factor for a UDF presentation of a public key fingerprint is 92 bits. This would normally require a presentation with 20 significant characters. Reducing this to 16 characters requires a brute force search of approximately 10⁶ attempts. Reducing this to 12 characters would require 10¹² attempts and to 10 characters, 10¹⁵ attempts.¶

Omission of support for higher levels of compression than 2⁵⁰ is intentional.¶

In addition to allowing use of shorter presentations, work factor compression MAY be used as evidence of proof of work.¶

3.6.1. Word Lists

The use of a Word List to encode fingerprint values was introduced by Patrick Juola and Philip Zimmerman for the PGPfone application. The PGP Word List is designed to facilitate exchange and verification of fingerprint values in a voice application. To minimize the risk of misinterpretation, two-word lists of 256 values each are used to encode alternative fingerprint bytes. The compact size of the lists used allowed the compilers to curate them so as to maximize the phonetic distance of the words selected.¶

The PGP Word List is designed to achieve a balance between ease of entry and verification. Applications where only verification is required may be better served by a much larger word list, permitting shorter fingerprint encodings.¶

For example, a word list with 16384 entries permits 14 bits of the fingerprint to be encoded at once, 65536 entries permit encoding of 16 bits. These encodings allow a 120-bit fingerprint to be encoded in 9 and 8 words respectively.¶

3.6.2. Image List

An image list is used in the same manner as a word list affording rapid visual verification of a fingerprint value. For obvious reasons, this approach is not suited to data entry but is preferable for comparison purposes. An image list of 1,048,576 images would provide a 20-bit encoding allowing 120 bit precision fingerprints to be displayed in six images.¶

4.4.1. Extraction step

The HKDF extraction step calculates a PRK value from a salt and IKM:¶

HKDF-Extract(salt, IKM) -> PRK

The IKM value is the binary presentation of the complete Binary Data Sequence as originally specified. The salt value is null.¶

The output from the extraction step forms the input to the expand step:¶

HKDF-Expand(PRK, info, L) -> OKM

The info parameter of the HKDF function is the concatenation of alg, param and the UTF8 binary representation of keyname.¶

info = alg + param + keyname.UTF8()

An X25519 key may be derived as follows:¶

Fingerprint =
    ZAAA-CDJ5-DHPA-DUUW-WIPQ-UXNC-DSAR-U7A

IKM =
  00 01 0D 3D  19 DE 01 D2  96 B2 1F 0A  5D A2 1C 81
  1A 7C

salt =
  00 01

PRK =
  DA 2E 80 6F  2D B1 54 56  7E 27 B4 91  49 0A 35 3A
  5D 99 92 AA  A2 2F 2D 2A  50 4B 13 5B  87 DF 63 67
  62 92 67 9C  B3 B8 10 47  31 52 A2 42  FA 04 84 39
  7A 64 15 84  C0 6B 51 F7  19 4A 20 35  BA 2E D1 59

OKM =
  E7 22 39 E1  AB 77 AC 9C  B4 6A A0 12  27 68 9E 28
  14 60 2F A8  76 08 38 5E  D5 E6 5D E7  0C C8 42 E8

Key =
  E7 22 39 E1  AB 77 AC 9C  B4 6A A0 12  27 68 9E 28
  14 60 2F A8  76 08 38 5E  D5 E6 5D E7  0C C8 42 E8

Derivation of an X448 key:¶

Fingerprint =
    ZAAA-FFQA-3LE5-SAHG-E6K6-HOTN-TVLB-K4A

Key =
  AE 6A 6D 0B  CC 48 C3 31  E7 55 0F 52  F9 96 83 C5
  15 7C 8A 74  80 36 B7 E9  17 24 D7 DD  A1 56 76 3C
  15 00 68 B7  23 F5 DB 32  48 1B 72 C0  2E B0 22 45
  A3 B8 80 67  B3 88 06 9F

Derivation of an Ed25519 key:¶

Fingerprint =
    ZAAA-GZ5N-PSNF-7LMS-QJZN-3O2X-GJXV-X6I

Key =
  3A 36 00 56  2E EC 2F 24  A7 8C 22 F3  A9 A2 EF 1B
  6E AF 07 D4  99 28 53 A5  5B 0A CC EE  4C 3B 7D 30

Derivation of an Ed448 key:¶

Fingerprint =
    ZAAA-ILZB-KTQV-YWUK-FO7E-MQVV-EWPR-UPA

Key =
  DF 5A 89 B8  1D 56 92 41  32 D1 B2 C9  4F 74 69 E3
  C9 E5 5F 23  33 A1 CE 22  54 08 EE 53  46 0F 9B 13
  9D 54 95 2B  F9 D9 77 2A  FA 07 3C 9D  89 CC C5 0E
  7E 86 7E 84  7C 58 5D 89

4.4.2. Elliptic Curve Diffie Hellman Key Pairs type 1-4

The generation of key pairs for X25519, X448, Ed25519 and Ed448 is specified in [RFC7748] and [RFC8032]. In each case, the public and private key parameters are generated from a string of random octets whose transformation to the secret scalar function is described in the document.¶

Thus, info is the null string and the value L is specified as follows:¶

4.4.3. Elliptic Curve Diffie Hellman Key Pairs type 5-7

The generation of key pairs for the curves P-256, P-384 and P-521 described in [RFC5903] is not mandated by the specification. FIPS 186-4 specifies two approaches. A modified form of the mechanism Key Pair Generation Using Extra Random Bits specified in B.4.1 is used as follows:¶

The number of random bits L is given by the following table:¶

Note that this rounds up the number of random bits required to the nearest integer multiple of 8.¶

The OKM value is interpreted as an integer in Network Byte Order, that is the first byte contains the most significant bits, to yield the parameter c.¶

The parameter c is reduced modulo the value of the prime field n to yield the secret scalar value d:¶

d = (c mod (n?1)) + 1.¶

A P-256 key may be derived as follows:¶

Fingerprint =
    ZAAA-LLBO-4A4E-LFMH-EJ73-XVFG-7PZ5-V7Y

IKM =
  00 05 AC 2E  E0 38 45 95  87 22 7F BB  D4 A6 FB F3
  DA FF

salt =
  00 05

PRK =
  0F 48 0F 0C  93 30 AE EE  41 FD 8F A2  1C C2 C6 CA
  3A E1 4B 54  E7 83 C0 25  85 F0 CD 2A  65 3F 18 A7
  9F 2A 5A ED  6A E3 64 6A  05 7D 1A 1A  B8 68 B3 F3
  4F A9 10 9A  05 E1 A4 9A  2C CC 40 43  36 8A 24 C0

OKM =
  E2 00 EC 22  63 17 D5 E5  52 F9 CD B6  45 23 A9 8B
  EF 32 26 E0  24 A0 E7 2B  7F CB C2 0B  CB FA 0F 5C
  59 D1 7C 4A  D8 12 2E 4C


Key =   823521039787465146191678159095729811571036184098859836027994
            10986678676075099

Derivation of a P-384 key:¶

Fingerprint =
    ZAAA-NPLI-G7Z3-WFD2-GBJ6-OONN-ELTO-MHA

Key =   369049211431889063087900251703207474490953076630513949620729
            23012683284321458397574918591433311657724460124046828583

Derivation of a P-521 key:¶

Fingerprint =
    ZAAA-PQCC-YFVT-LRWP-7MUZ-GJV3-HLX2-JPQ

Key =   634654264002940134552342747000178673315150389242882127875899
            96717989335708073735991026483008684752699986204269344550
            4370476919922072068801363203357706689700

4.4.4. RSA Key Pairs

Generation of RSA key pairs requires two parameters, p, q which are prime.¶

The value of the param input used to calculate info is the value of the key identifier value with one of the following tag values concatenated to the end.¶

The value of L is the same for generating the OKM values from which q are derived and is determined by the algorithm identifier:¶

The RSA parameter p is the smallest prime integer that is greater than the OKM value corresponding to the info value "p" interpreted as an integer in Network Byte Order.¶

The RSA parameter q is the smallest prime integer that is greater than the OKM value corresponding to the info value "q" interpreted as an integer in Network Byte Order.¶

Note that this algorithm does not mandate a particular method of primality testing nor does it impose any additional testing on the values p or q. If an application requires the use of primes with conditions it will be necessary to attempt multiple key derivations with different Binary Data Sequence values until parameters with the desired properties are found.¶

An RSA-2048 may be derived as follows:¶

Fingerprint =
    ZAAA-RJ5I-OSMI-X2KH-MBHX-KUPB-OC54-NQI

IKM =
  00 08 A7 A8  74 98 8B E9  47 60 4F 75  51 E1 70 BB
  C6 C1

salt =
  00 08

[Generation of the PRK as before]

Info(p) =
  70

OKM(p) =
  92 D4 DA FA  C4 22 DB 17  B0 04 93 C6  F1 D2 7A AF
  34 6F 69 98  54 1A F5 F3  E3 ED DA 98  F5 64 EE 6A

Info(q) =
  71

OKM(q) =
  01 50 07 9F  B3 53 70 5A  7E 95 63 BD  19 8D 52 59
  2F EE 38 E7  8F D4 46 D9  4C 55 E6 DD  39 CA DB 36

Key P = 664137588122357253348380132353218815863396125741622195396345
            89986848279686793

Key Q = 593713231506709718978311683387355253795918273379156509909895
            725618914057069

4.4.5. Any Key Algorithm

The Any key algorithm allows a single UDF value to be used to derive key pairs for multiple algorithms. The IKM value is the same for each key pair derived. The salt value is changed according to the algorithm for which the key is to be derived.¶

Fingerprint =
    ZAAA-A6WP-XMGW-FUOF-2T5L-AHNL-FBPY-RSY

To generate an RSA-2048 key

salt =
  00 08

Key P = 184377705562733023433840697873299239654937691662139401284561
            64676903354830137

Key Q = 741016989403010251265552685128898155357242513700210607224783
            50575007811846521

To generate an X25519 key

salt =
  00 08

Key =
    System.Byte[]

4.5.1. Secret Generation

To share a secret of L bits with a threshold of n we use a f(x) a polynomial of degree n in the modular field p:¶

f(x) = a₀ + a₁.x + a₂.x² + ... a_n.xⁿ¶

where:¶

L

Is the length of the secret in bits, an integer multiple of 32.¶

n

Is the threshold, the number of shares required to reconstitute the secret.¶

a₀

Is the integer representation of the secret to be shared.¶

a₁ ... a_n

Are randomly chosen integers less than p¶

p

Is the smallest prime that is greater than 2^L.¶

For L=128, p = 2¹²⁸+51.¶

The values of the key shares are the values f(1), f(2),... f(n).¶

The most straightforward approach to generation of Shamir secrets is to generate the set of polynomial coefficients, a₀, a₁, ... a_n and use these to generate the share values f(1), f(2),... f(n).¶

Note that if this approach is adopted, there is a small probability that one or more of the values f(1), f(2),... f(n) exceeds the range of values supported by the encoding. Should this occur, at least one of the polynomial coefficients MUST be replaced.¶

An alternative means of generating the set of secrets is to select up to n-1 secret share values and use secret recovery to determine at least one additional share. If n shares are selected, the shared secret becomes an output of rather than an input to the process.¶

4.5.2. Recovery

To recover the value of the shared secret, it is necessary to obtain sufficient shares to meet the threshold and recover the value f(0) = a₀.¶

Applications MAY employ any approach that returns the correct result. The use of Lagrange basis polynomials is described in Appendix C.¶

Alice decides to encrypt an important document and split the encryption key so that there are five key shares, three of which will be required to recover the key.¶

Alice's master secret is
  12 0A C3 1B  FF 09 CD 86  CD 3E 6B 4B  CF BA 91 8D

This has the UDF representation:¶

CIFM-GG77-BHGY-NTJ6-NNF4-7OUR-RU¶

The master secret is converted to an integer applying network byte order conventions. Since the master secret is 128 bits, it is guaranteed to be smaller than the modulus. The resulting value becomes the polynomial value a0.¶

Since a threshold of three shares is required, we will need a second order polynomial. The co-efficients of the polynomial a1, a2 are random numbers smaller than the modulus:¶

a0 = 23981984180677462358025211329449202061
a1 = 217449633820028444820075594055263988236
a2 = 299283543253615188179136358544176182525

The master secret is the value f(0) = a0. The key shares are the values f(1), f(2)...f(5):¶

f(1) = 200432794333382631893862556497121161315
f(2) = 294885957151441250861223403889609062605
f(3) = 307341472634853319260107753506912905931
f(4) = 237799340783618837090515605349032691293
f(5) = 86259561597737804352446959415968418691

The first byte of each share specifies the recovery information (quorum, x value), the remaining bytes specify the share value in network byte order:¶

f(1) =
  30 96 C9 F3  B9 2E 52 75  AE C9 C5 75  B1 93 D0 B0
  63
f(2) =
  31 DD D8 F8  31 86 F7 0B  B9 E2 74 52  07 3E 2A B8
  CD
f(3) =
  32 E7 37 D0  85 08 F7 8F  A8 17 4B 00  4C CE C8 AA
  CB
f(4) =
  33 B2 E6 7C  B3 B4 54 01  79 68 49 80  82 45 AA 86
  5D
f(5) =
  34 40 E4 FC  BD 89 0C 61  2D D5 6F D2  A7 A2 D0 4B
  83

The UDF presentation of the key shares is thus:¶

f(1) = SAYJ-NSPT-XEXF-E5NO-ZHCX-LMMT-2CYG-G
f(2) = SAY5-3WHY-GGDP-OC5Z-4J2F-EBZ6-FK4M-2
f(3) = SAZO-ON6Q-QUEP-PD5I-C5FQ-ATGO-ZCVM-W
f(4) = SAZ3-FZT4-WO2F-IALZ-NBEY-BASF-VKDF-2
f(5) = SA2E-BZH4-XWEQ-YYJN-2VX5-FJ5C-2BFY-G

To recover the value f(0) from any three shares, we need to fit a polynomial curve to the three points and use it to calculate the value at x=0 using the Lagrange polynomial basis.¶

5.1.1. Content Digest Value

The Content Digest Value (CDV) is determined by applying the digest algorithm to the content data:¶

CDV = H(<Data>)

Where¶

H(x) is the cryptographic digest function¶

<Data> is the binary data.¶

5.1.2. Typed Content Digest Value

The Typed Content Digest Value (TCDV) is determined by applying the digest algorithm to the content type identifier and the CDV:¶

TCDV = H (<Content-ID> + ?:? + CDV)

Where¶

A + B represents concatenation of the binary sequences A and B.¶

<Content-ID> is the IANA Content Type of the data in UTF8 encoding¶

The two-step approach to calculating the Type Content Digest Value allows an application to attempt to match a set of content data against multiple types without the need to recalculate the value of the content data digest.¶

5.1.3. Content Digest Compression

The compression factor is determined according to the number of trailing zero bits in the first 8 bytes of the Typed Content Digest Value as follows:¶

19 or fewer trailing zero bits

Compression factor = 0¶

29 or fewer trailing zero bits

Compression factor = 20¶

39 or fewer trailing zero bits

Compression factor = 30¶

49 or fewer trailing zero bits

Compression factor = 40¶

50 or more trailing zero bits

Compression factor = 50¶

The least significant bits of each octet are regarded to be 'trailing'.¶

Applications MUST use compression when creating and comparing UDFs. Applications MAY support content generation techniques that search for UDF values that use a compressed representation. Presentation of a content digest value indicating use of compression MAY be used as an indicator of 'proof of work'.¶

5.1.4. Content Digest Presentation

The type identifier is determined by the algorithm and compression factor as specified above.¶

The Binary Data Sequence value is taken from the Typed Content Digest Value starting at the 9^th octet and as many additional bytes as are required to meet the presentation precision.¶

5.1.5. Example Encoding

In the following examples, <Content-ID> is the UTF8 encoding of the string "text/plain" and <Data> is the UTF8 encoding of the string "UDF Data Value"¶

Data =
  55 44 46 20  44 61 74 61  20 56 61 6C  75 65

ContentType =
  74 65 78 74  2F 70 6C 61  69 6E

5.1.6. Using SHA-2-512 Digest

H(<Data>) =
  48 DA 47 CC  AB FE A4 5C  76 61 D3 21  BA 34 3E 58
  10 87 2A 03  B4 02 9D AB  84 7C CE D2  22 B6 9C AB
  02 38 D4 E9  1E 2F 6B 36  A0 9E ED 11  09 8A EA AC
  99 D9 E0 BD  EA 47 93 15  BD 7A E9 E1  2E AD C4 15

<Content-ID> + ':' + H(<Data>) =
  74 65 78 74  2F 70 6C 61  69 6E 3A 48  DA 47 CC AB
  FE A4 5C 76  61 D3 21 BA  34 3E 58 10  87 2A 03 B4
  02 9D AB 84  7C CE D2 22  B6 9C AB 02  38 D4 E9 1E
  2F 6B 36 A0  9E ED 11 09  8A EA AC 99  D9 E0 BD EA
  47 93 15 BD  7A E9 E1 2E  AD C4 15

H(<Content-ID> + ':' + H(<Data>)) =
  C6 AF B7 C0  FE BE 04 E5  AE 94 E3 7B  AA 5F 1A 40
  5B A3 CE CC  97 4D 55 C0  9E 61 E4 B0  EF 9C AE F9
  EB 83 BB 9D  5F 0F 39 F6  5F AA 06 DC  67 2A 67 71
  4F FF 8F 83  C4 55 38 36  38 AE 42 7A  82 9C 85 BB

The prefixed Binary Data Sequence is thus
  60 C6 AF B7  C0 FE BE 04  E5 AE 94 E3  7B AA 5F 1A
  40 5B A3 CE  CC 97 4D 55  C0 9E 61 E4  B0 EF 9C AE
  F9 EB 83 BB  9D 5F 0F 39  F6 5F AA 06  DC 67 2A 67
  71 4F FF 8F  83 C4 55 38  36 38 AE 42  7A 82 9C 85

The 125 bit fingerprint value is MDDK-7N6A-727A-JZNO-STRX-XKS7-DJAF¶

This fingerprint MAY be specified with higher or lower precision as appropriate.¶

100 bit precision

MDDK-7N6A-727A-JZNO-STRX¶

120 bit precision

MDDK-7N6A-727A-JZNO-STRX-XKS7¶

200 bit precision

MDDK-7N6A-727A-JZNO-STRX-XKS7-DJAF-XI6O-ZSLU-2VOA¶

260 bit precision

MDDK-7N6A-727A-JZNO-STRX-XKS7-DJAF-XI6O-ZSLU-2VOA-TZQ6-JMHP-TSXP¶

5.1.7. Using SHA-3-512 Digest

H(<Data>) =
  6D 2E CF E6  93 5A 0C FC  F2 A9 1A 49  E0 0C D8 07
  A1 4E 70 AB  72 94 6E CC  BB 47 48 F1  8E 41 49 95
  07 1D F3 6E  0D 0C 8B 60  39 C1 8E B4  0F 6E C8 08
  65 B4 C4 45  9B A2 7E 97  74 7B BE 68  BC A8 C2 17

<Content-ID> + ':' + H(<Data>) =
  74 65 78 74  2F 70 6C 61  69 6E 3A 6D  2E CF E6 93
  5A 0C FC F2  A9 1A 49 E0  0C D8 07 A1  4E 70 AB 72
  94 6E CC BB  47 48 F1 8E  41 49 95 07  1D F3 6E 0D
  0C 8B 60 39  C1 8E B4 0F  6E C8 08 65  B4 C4 45 9B
  A2 7E 97 74  7B BE 68 BC  A8 C2 17

H(<Content-ID> + ':' + H(<Data>)) =
  8A 86 8A 06  1C 54 6E 7E  3F 75 5F 39  88 F9 FD 2F
  8E C8 45 93  1B 80 A8 2F  29 16 7B A3  BE 21 1F 8A
  75 61 88 A1  D5 7F 07 D5  9D 68 A4 2D  17 F4 4D 23
  F9 E4 0B B2  1A 8D B9 F5  8D FC EC BD  01 F4 37 7C

The prefixed Binary Data Sequence is thus
  50 8A 86 8A  06 1C 54 6E  7E 3F 75 5F  39 88 F9 FD
  2F 8E C8 45  93 1B 80 A8  2F 29 16 7B  A3 BE 21 1F
  8A 75 61 88  A1 D5 7F 07  D5 9D 68 A4  2D 17 F4 4D
  23 F9 E4 0B  B2 1A 8D B9  F5 8D FC EC  BD 01 F4 37

The 125 bit fingerprint value is KCFI-NCQG-DRKG-47R7-OVPT-TCHZ-7UXY¶

5.1.8. Using SHA-2-512 Digest with Compression

The content data "UDF Compressed Document 4187123" produces a UDF Content Digest SHA-2-512 binary value with 20 trailing zeros and is therefore presented using compressed presentation:¶

Data = "
  55 44 46 20  43 6F 6D 70  72 65 73 73  65 64 20 44
  6F 63 75 6D  65 6E 74 20  34 31 38 37  31 32 33"

The UTF8 Content Digest is given as:¶

H(<Data>) =
  36 21 FA 2A  C5 D8 62 5C  2D 0B 45 FB  65 93 FC 69
  C1 ED F7 00  AE 6F E3 3D  38 13 FE AB  76 AA 74 13
  6D 5A 2B 20  DE D6 A5 CF  6C 04 E6 56  3F F3 C0 C7
  C4 1D 3F 43  DD DC F1 A5  67 A7 E0 67  9A B0 C6 B7

<Content-ID> + ':' + H(<Data>) =
  74 65 78 74  2F 70 6C 61  69 6E 3A 36  21 FA 2A C5
  D8 62 5C 2D  0B 45 FB 65  93 FC 69 C1  ED F7 00 AE
  6F E3 3D 38  13 FE AB 76  AA 74 13 6D  5A 2B 20 DE
  D6 A5 CF 6C  04 E6 56 3F  F3 C0 C7 C4  1D 3F 43 DD
  DC F1 A5 67  A7 E0 67 9A  B0 C6 B7

H(<Content-ID> + ':' + H(<Data>)) =
  8E 14 D9 19  4E D6 02 12  C3 30 A7 BB  5F C7 17 6D
  AE 9A 56 7C  A8 2A 23 1F  96 75 ED 53  10 EC E8 F2
  60 14 24 D0  C8 BC 55 3D  C0 70 F7 5E  86 38 1A 0B
  CB 55 9C B2  87 81 27 FF  3C EC E2 F0  90 A0 00 00

The prefixed Binary Data Sequence is thus
  61 8E 14 D9  19 4E D6 02  12 C3 30 A7  BB 5F C7 17
  6D AE 9A 56  7C A8 2A 23  1F 96 75 ED  53 10 EC E8
  F2 60 14 24  D0 C8 BC 55  3D C0 70 F7  5E 86 38 1A
  0B CB 55 9C  B2 87 81 27  FF 3C EC E2  F0 90 A0 00

The 125 bit fingerprint value is MGHB-JWIZ-J3LA-EEWD-GCT3-WX6H-C5W2¶

5.1.9. Using SHA-3-512 Digest with Compression

The content data "UDF Compressed Document 774665" produces a UDF Content Digest SHA-3-512 binary value with 20 trailing zeros and is therefore presented using compressed presentation:¶

Data =
  55 44 46 20  43 6F 6D 70  72 65 73 73  65 64 20 44
  6F 63 75 6D  65 6E 74 20  37 37 34 36  36 35

The UTF8 SHA-3-512 Content Digest is KEJI-Y225-BDUG-XX22-MXKE-5ITF-YVYM¶

5.2.1. Authentication Content Digest Value

The Content Digest Value (CDV) is determined in the exact same fashion as for a Content Digest UDF by applying the digest algorithm to the content data:¶

CDV = H(<Data>))

Where¶

H(x) is the cryptographic digest function¶

<Data> is the binary data.¶

5.2.2. Authentication Value

The Authentication Value (AV) is determined by applying the digest algorithm to the content type identifier and the CDV:¶

AV = MAC (<OKM>, (<Content-ID> + ?:? + CDV))

Where¶

<OKM> is the authentication key as specified below¶

MAC( <Key>, <data>) is the result of applying the Message Authentication Code algorithm to with Key <Key> and data <data>¶

The value <OKM> is calculated as follows:¶

IKM = UTF8 (Key)
PRK = MAC (UTF8 ("KeyedUDFMaster"), IKM)
OKM = HKDF-Expand(PRK, UTF8 ("KeyedUDFExpand"), HashLen)

Where the function UTF8(string) converts a string to the binary UTF8 representation, HKDF-Expand is as defined in [RFC5869] and the function MAC(k,m) is the HMAC function formed from the specified hash H(m) as specified in [RFC2014].¶

Keyed UDFs are typically used in circumstances where user interaction requires a cryptographic commitment type functionality¶

In the following example, <Content-ID> is the UTF8 encoding of the string "text/plain" and <Data> is the UTF8 encoding of the string "Konrad is the traitor". The randomly chosen key is NDD7-6CMX-H2FW-ISAL-K4VB-DQ3E-PEDM.¶

Data =
  4B 6F 6E 72  61 64 20 69  73 20 74 68  65 20 74 72
  61 69 74 6F  72

ContentType =
  74 65 78 74  2F 70 6C 61  69 6E

Key =
  4E 44 44 37  2D 36 43 4D  58 2D 48 32  46 57 2D 49
  53 41 4C 2D  4B 34 56 42  2D 44 51 33  45 2D 50 45
  44 4D

Processing is performed in the same manner as an unkeyed fingerprint except that compression is never used:¶

H(<Data>) =
  93 FC DA F9  FA FD 1E 26  50 26 C3 C1  28 43 40 73
  D8 BC 3D 62  87 73 2B 73  B8 EC 93 B6  DE 80 FF DA
  70 0A D1 CE  E8 F4 36 68  EF 4E 71 63  41 53 91 5C
  CE 8C 5C CE  C7 9A 46 94  6A 35 79 F9  33 70 85 01

<Content-ID> + ':' + H(<Data>) =
  74 65 78 74  2F 70 6C 61  69 6E 3A 93  FC DA F9 FA
  FD 1E 26 50  26 C3 C1 28  43 40 73 D8  BC 3D 62 87
  73 2B 73 B8  EC 93 B6 DE  80 FF DA 70  0A D1 CE E8
  F4 36 68 EF  4E 71 63 41  53 91 5C CE  8C 5C CE C7
  9A 46 94 6A  35 79 F9 33  70 85 01

PRK(Key) =
  77 D3 0A 08  39 BD 9D C0  97 44 DA 33  15 0A 42 5E
  CD 17 80 03  B3 CF CC 89  7A C7 84 12  B4 51 5B 25
  DC 26 F5 E1  1B 20 F3 89  2E 9A 1A 7B  0E 73 23 39
  0E C3 4C EF  2D 40 DA 05  B4 70 C6 1C  82 C1 49 33

HKDF(Key) =
  BF A9 B4 58  9C 1D 68 D7  9A B7 11 F6  C8 98 59 14
  20 D7 82 67  C5 84 22 E5  A0 F9 93 52  B1 C3 87 EB
  05 06 CB C4  E4 D6 E6 EE  1F F0 D4 7A  97 68 5E CE
  28 1C CA AF  D8 B5 D1 24  4A 71 EC E3  AC B5 D2 04

MAC(<key>, <Content-ID> + ':' + H(<Data>)) =
  4C C3 7F D3  F9 9E 52 CF  07 90 74 53  84 65 95 BC
  1A 2B A5 D1  68 9D 05 6D  06 C5 CA BF  17 CB E0 49
  95 39 57 08  79 C4 E5 49  D3 3A 59 A3  32 05 45 A6
  30 26 25 AE  8A F4 47 C6  1F B5 33 7F  AD 69 A6 30

The prefixed Binary Data Sequence is thus
  00 4C C3 7F  D3 F9 9E 52  CF 07 90 74  53 84 65 95
  BC 1A 2B A5  D1 68 9D 05  6D 06 C5 CA  BF 17 CB E0
  49 95 39 57  08 79 C4 E5  49 D3 3A 59  A3 32 05 45
  A6 30 26 25  AE 8A F4 47  C6 1F B5 33  7F AD 69 A6

The 125 bit fingerprint value is ABGM-G76T-7GPF-FTYH-SB2F-HBDF-SW6B¶

5.3.1. PKIX Certificates and Keys

UDF fingerprints MAY be used to identify PKIX certificates, CRLs and public keys in the ASN.1 encoding used in PKIX certificates.¶

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.¶

PKIX certificates, keys and related content data are identified by the following content types:¶

application/pkix-cert

A PKIX Certificate¶

application/pkix-crl

A PKIX CRL¶

application/pkix-keyinfo

The SubjectPublicKeyInfo structure defined in the PKIX certificate specification encoded using DER encoding rules.¶

The SubjectPublicKeyInfo structure is defined in [RFC5280] as follows:¶

   SubjectPublicKeyInfo  ::=  SEQUENCE  {
        algorithm            AlgorithmIdentifier,
        subjectPublicKey     BIT STRING  }

This schema results in an identical DER encoding to the OIDInfo sequence specified in section XXX. The distinction between these productions is that the OIDInfo schema is intended to be used to encode arbitrary data while the application/pkix-keyinfo content type is only intended to be used to describe public keys.¶

5.3.2. OpenPGP Key

OpenPGPv5 keys and key set content data are identified by the following content type:¶

application/pgp-keys

An OpenPGP key set.¶

5.3.3. DNSSEC

DNSSEC record data consists of DNS records which are identified by the following content type:¶

application/dns

A DNS resource record in binary format¶

6.2.1. DNS Web service discovery

DNS Web Discovery is performed as specified in [draft-hallambaker-web-service-discovery] for the service mmm-udf and domain name specified in the URI. For a full description of the discovery mechanism, consult the referenced specification.¶

The use of DNS Web Discovery permits service providers to make full use of the load balancing and service description capabilities afforded by use of DNS SRV and TXT records in accordance with the approach described in [RFC6763].¶

If no SRV or TXT records are specified, DNS Web Discovery specifies that the Web Service Endpoint be the Well Known Service [RFC5785] with the prefix /.well-known/srv/mmm-udf.¶

6.2.2. Content Identifier

For all UDF types other than Secret Share, the Content Identifier value is the UDF SHA-2-512 Content Digest of the canonical form of the UDF specified in the source URI presented at twice the precision to a maximum of 440 bits.¶

If the UDF is of type Secret Share, the shared secret MUST be recovered before the content identifier can be resolved. The shared secret is then expressed as a UDF of type Encryption/Authentication and the Content Identifier determined as for an Encryption/Authentication type UDF.¶

6.2.3. Target URI

The target URI is formed by appending a slash separator '/' and the Content Identifier value to the Web Service Endpoint.¶

Since the path portion of a URI is case sensitive, the UDF value MUST be specified in upper case and MUST include separator marks.¶

6.2.4. Postprocessing

After retrieving the content data, the resolver MUST perform post processing as indicated by the content type:¶

Nonce

No additional post processing is required.¶

Content Digest

The resolver MUST verify that the content returned matches the UDF fingerprint value.¶

Authenticator

The resolver MUST verify that the content returned matches the UDF fingerprint value.¶

Encryption/Authentication

The content data returned is decrypted and authenticated using the key specified in the UDF value as the initial keying material (see below).¶

Secret Share (set)

The content data returned is decrypted and authenticated using the shared secret as the initial keying material (see below).¶

6.2.5. Decryption and Authentication

The steps performed to decode cryptographically enhanced content data depends on the content type specified in the returned content. Two formats are currently supported:¶

• DARE Envelope format as specified in [draft-hallambaker-mesh-dare]¶
• Cryptographic Message Syntax (CMS) Symmetric Key Package as specified in [RFC6031]¶

6.2.6. QR Presentation

Encoding of a UDF URI as a QR code requires only the characters in alphanumeric encoding, thus achieving compactness with minimal overhead.¶

9.4.1. Media Type: application/pkix-keyinfo

Type name:

application¶

Subtype name:

pkix-keyinfo¶

Required parameters:

None¶

Optional parameters:

None¶

Encoding considerations:

Binary¶

Security considerations:

Described in [This]¶

Interoperability considerations:

None¶

Published specification:

[This]¶

Applications that use this media type:

Uniform Data Fingerprint¶

Fragment identifier considerations:

None¶

Additional information:

Deprecated alias names for this type: None¶

Magic number(s): None¶

File extension(s): None¶

Macintosh file type code(s): None¶

Person & email address to contact for further information:

Phillip Hallam-Baker @hallambaker.com>¶

Intended usage:

Content type identifier to be used in constructing UDF Content Digests and Authenticators and related cryptographic purposes.¶

Restrictions on usage:

None¶

Author:

Phillip Hallam-Baker¶

Change controller:

Phillip Hallam-Baker¶

Provisional registration? (standards tree only):

Yes¶

9.4.2. Media Type: application/udf

Type name:

application¶

Subtype name:

udf¶

Required parameters:

None¶

Optional parameters:

None¶

Encoding considerations:

None¶

Security considerations:

Described in [This]¶

Interoperability considerations:

None¶

Published specification:

[This]¶

Applications that use this media type:

Uniform Data Fingerprint¶

Fragment identifier considerations:

None¶

Additional information:

Deprecated alias names for this type: None¶

Magic number(s): None¶

File extension(s): None¶

Macintosh file type code(s): None¶

Person & email address to contact for further information:

Phillip Hallam-Baker @hallambaker.com>¶

Intended usage:

Content type identifier to be used in constructing UDF Content Digests and Authenticators and related cryptographic purposes.¶

Restrictions on usage:

None¶

Author:

Phillip Hallam-Baker¶

Change controller:

Phillip Hallam-Baker¶

Provisional registration? (standards tree only):

Yes¶

9.5.1. The name of the registry

Uniform Data Fingerprint Type Identifier Registry¶

9.5.2. Required information for registrations

Registrants must specify the Type identifier code(s) requested, description and RFC number for the corresponding standards action document.¶

The standards document must specify the means of generating and interpreting the UDF Data Sequence Value and the purpose(s) for which it is proposed.¶

Since the initial letter of the Base32 presentation provides a mnemonic function in UDFs, the standards document must explain why the proposed Type Identifier and associated initial letter are appropriate. In cases where a new initial letter is to be created, there must be an explanation of why this is appropriate. If an existing initial letter is to be created, there must be an explanation of why this is appropriate and/or acceptable.¶

9.5.3. Applicable registration policy

Due to the intended field of use (human data entry), the code space is severely constrained. Accordingly, it is intended that code point registrations be as infrequent as possible.¶

Registration of new digest algorithms is strongly discouraged and should not occur unless, (1) there is a known security vulnerability in one of the two schemes specified in the original assignment and (2) the proposed algorithm has been subjected to rigorous peer review, preferably in the form of an open, international competition and (3) the proposed algorithm has been adopted as a preferred algorithm for use in IETF protocols.¶

Accordingly, the applicable registration policy is Standards Action.¶

9.5.4. Size, format, and syntax of registry entries

Each registry entry consists of a single byte code,¶

9.5.5. Initial assignments and reservations

The following entries should be added to the registry as initial assignments:¶

Code  Description                               Reference
----  ----------------------------------------  ---------
   0  HMAC_SHA_2_512                            [This document]
   1  HMAC_SHA_3_512                            [This document]
  32  HKDF_AES_512                              [This document]
  33  HKDF_AES_512                              [This document]
  80  SHA_3_512                                 [This document]
  81  SHA_3_512 (20 compressed)                 [This document]
  82  SHA_3_512 (30 compressed)                 [This document]
  83  SHA_3_512 (40 compressed)                 [This document]
  84  SHA_3_512 (50 compressed)                 [This document]
  96  SHA_2_512                                 [This document]
  97  SHA_2_512 (20 compressed)                 [This document]
  98  SHA_2_512 (30 compressed)                 [This document]
  99  SHA_2_512 (40 compressed)                 [This document]
 100  SHA_2_512 (50 compressed)                 [This document]
 104  Nonce Data                                [This document]
 112  OID distinguished sequence (DER encoded)  [This document]
 144  Shamir Secret Share                       [This document]
 200  Secret seed                               [This document]