<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-hallambaker-mesh-udf-10" indexInclude="false" ipr="trust200902" prepTime="2020-07-27T10:02:39Z" scripts="Common,Latin" sortRefs="true" submissionType="independent" symRefs="true" tocDepth="3" tocInclude="true" version="3" xml:lang="en"><front>
<title abbrev="Mesh UDF">Mathematical Mesh 3.0 Part II: Uniform Data Fingerprint.</title>
<seriesInfo name="Internet-Draft" value="draft-hallambaker-mesh-udf" stream="independent"/>
<author fullname="Phillip Hallam-Baker" initials="P. M." surname="Hallam-Baker"><organization>ThresholdSecrets.com</organization>
<address>
<email>phill@hallambaker.com</email>
</address>
</author>
<date day="27" month="July" year="2020"/>
<area/>
<workgroup/>
<keyword>Cryptography</keyword>
<keyword>Digest Function</keyword>
<keyword>Shamir Secret Sharing</keyword>
<abstract>
<t>This document describes the naming and addressing schemes used in the Mathematical Mesh. The means of generating Uniform Data Fingerprint (UDF) values and their presentation as text sequences and as URIs are described.</t>
<t>A UDF consists of a binary sequence, the initial eight bits of which specify a type identifier code. Type identifier codes have been selected so as to provide a useful mnemonic indicating their purpose when presented in Base32 encoding.</t>
<t>Two categories of UDF are described. Data UDFs provide a compact presentation of a fixed length binary data value in a format that is convenient for data entry. A Data UDF may represent a cryptographic key, a nonce value or a share of a secret. Fingerprint UDFs provide a compact presentation of a Message Digest or Message Authentication Code value.</t>
<t>A Strong Internet Name (SIN) consists of a DNS name which contains at least one label that is a UDF fingerprint of a policy document controlling interpretation of the name. SINs allow a direct trust model to be applied to achieve end-to-end security in existing Internet applications without the need for trusted third parties.</t>
<t>UDFs may be presented as URIs to form either names or locators for use with the UDF location service. An Encrypted Authenticated Resource Locator (EARL) is a UDF locator URI presenting a service from which an encrypted resource may be obtained and a symmetric key that may be used to decrypt the content. EARLs may be presented on paper correspondence as a QR code to securely provide a machine-readable version of the same content. This may be applied to automate processes such as invoicing or to provide accessibility services for the partially sighted.</t>
<t>[Note to Readers]</t>
<t>Discussion of this draft takes place on the MATHMESH mailing list (mathmesh@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=mathmesh.</t>
<t>This document is also available online at <eref target="http://mathmesh.com/Documents/draft-hallambaker-mesh-udf.html"></eref>.</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="n-introduction"><t>A Uniform Data Fingerprint (UDF) is a generalized format for presenting and interpreting short binary sequences representing cryptographic keys or fingerprints of data of any specified type. The UDF format provides a superset of the OpenPGP <xref target="RFC4880"></xref> fingerprint encoding capability with greater encoding density and readability.</t>
<t>This document describes the syntax and encoding of UDFs, the means of constructing and comparing them and their use in other Internet addressing schemes.</t>
<section title="UDF Types" anchor="n-udf-types"><t>Two categories of UDF are described. Data UDFs provide a compact presentation of a fixed length binary data value in a format that is convenient for data entry. A Data UDF may represent a cryptographic key or nonce value or a part share of a key generated using a secret sharing mechanism. Fingerprint UDFs provide a compact presentation of a Message Digest or Message Authentication Code value.</t>
<t>Both categories of UDF are encoded as a UDF binary sequence, the first octet of which is a Type Identifier and the remaining octets specify the binary value according to the type identifier and data referenced.</t>
<t>UDFs are typically presented to the user as a Base32 encoded sequence in groups of four characters separated by dashes. This format provides a useful balance between compactness and readability. The type identifier codes have been selected so as to provide a useful mnemonic when presented in Base32 encoding.</t>
<t>The following are examples of UDF values:</t>
<sourcecode>NC6X-EVQA-M7FV-F7LJ-FFHY-SMDY-UACA
EAML-INHA-2635-5SKT-46SH-XKSL-HAZA
SAQH-SBPX-XEXR-RYGS-RCVV-DTPA-JUPD-G
MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4
KCM5-7VB6-IJXJ-WKHX-NZQF-OKGZ-EWVN
ADRU-4UV2-EGB2-7QW5-DKZZ-GDGJ-42YC
OAYC-4MAH-AYBS-WZLQ-AUAA-GIYA-AQQD-FCCZ-TFA5-FVHH-TTHZ-4JQH-HD43-SHRB
    -Y5WA-A4O5-IIE5-TEFW-JTPY-EDI</sourcecode>
<t>Like email addresses, UDFs are not a Uniform Resource Identifier (URI) but may be expressed in URI form by adding the scheme identifier (UDF) for use in contexts where an identifier in URI syntax is required. A UDF URI <bcp14>MAY</bcp14> contain a domain name component allowing it to be used as a locator</t>
<section title="Cryptographic Keys and Nonces" anchor="n-cryptographic-keys-and-nonces"><t>A Nonce (N) UDF represents a short, fixed length randomly chosen binary value. </t>
<t>Nonce UDFs are used within many Mesh protocols and data formats where it is necessary to represent a nonce value in text form.</t>
<sourcecode>Nonce UDF:
  NC6X-EVQA-M7FV-F7LJ-FFHY-SMDY-UACA</sourcecode>
<t>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.</t>
<sourcecode>KeyValue:
  18 B4 34 E0  D7 B7 DE C9  53 E7 A4 7B  AA 4B 38 32

Encryption/Authenticator UDF:
  EAML-INHA-2635-5SKT-46SH-XKSL-HAZA</sourcecode>
<t>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. </t>
<t>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).</t>
<sourcecode>Key:     EAML-INHA-2635-5SKT-46SH-XKSL-HAZA
Share 0: SAQH-SBPX-XEXR-RYGS-RCVV-DTPA-JUPD-G
Share 1: SAQ5-SV52-SGDH-TYW3-XVXP-6IAW-J4CD-I
Share 2: SARD-TKL5-NHO5-VZHE-6IZK-Y4SM-KDVA-E</sourcecode>
</section>
<section title="Fingerprint type UDFS" anchor="n-fingerprint-type-udfs"><t>Fingerprint type UDFs contains a fingerprint value calculated over a content data item and an IANA media type.</t>
<t>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).</t>
<t>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.</t>
<sourcecode>SHA-2-512: MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4
SHA-3-512: KCM5-7VB6-IJXJ-WKHX-NZQF-OKGZ-EWVN</sourcecode>
<t>An Authentication UDF (A) is formed in the same manner as a fingerprint but using a Message Authentication Code algorithm and a symmetric key.</t>
<t>Authentication UDFs are used to express commitments and to provide a means of blinding fingerprint values within a protocol by means of a nonce.</t>
<sourcecode>SHA-2-512: ADRU-4UV2-EGB2-7QW5-DKZZ-GDGJ-42YC</sourcecode>
</section>
</section>
<section title="Using UDFs in  URIs" anchor="n-using-udfs-in--uris"><t>The UDF URI scheme allows use of a UDF in contexts where a URF is expected. The UDF URI scheme has two forms, name and locator.</t>
<section title="Name Form" anchor="n-name-form"><t>Name form UDF URIs identify a data resource but do not provide a means of discovery. The URI is simply the scheme (<tt>udf</tt>) followed by the UDF value:</t>
<sourcecode>udf:MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4</sourcecode>
</section>
<section title="Locator Form" anchor="n-locator-form"><t>Locator form UDF URIs identify a data resource and provide a hint that <bcp14>MAY</bcp14> 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 <bcp14>MAY</bcp14> be used instead.</t>
<sourcecode>udf://example.com/MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4</sourcecode>
<t>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.</t>
<t>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).</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>To generate the paper invoice, Example.com first creates a new encryption key: </t>
<t>EBXI-SDDC-QJME-B3DV-DSSR-PP7V-QBVF-EG </t>
<t>One or more electronic forms of the invoice are encrypted under the key  EBXI-SDDC-QJME-B3DV-DSSR-PP7V-QBVF-EG and placed on the Example.com Web site so that  the appropriate version is returned if Alice scans the QR code. </t>
<t>The key is then converted to form an EARL for the example.com UDF resolution service: </t>
<t>udf://example.com/EBXI-SDDC-QJME-B3DV-DSSR-PP7V-QBVF-EG </t>
<t>The EARL is then rendered as a QR code:</t>
<figure>
<!-- Include SVG File ../Generated/UDFDigestEARLRAW.svg --><artwork type="svg">
<svg width="820" height="820" xmlns="http://www.w3.org/2000/svg" >
<rect x="0" y="0" width="820" height="820" fill="#FFFFFF" />
<rect x="80" y="80" width="20" height="20" fill="#000000" />
<rect x="80" y="100" width="20" height="20" fill="#000000" />
<rect x="80" y="120" width="20" height="20" fill="#000000" />
<rect x="80" y="140" width="20" height="20" fill="#000000" />
<rect x="80" y="160" width="20" height="20" fill="#000000" />
<rect x="80" y="180" width="20" height="20" fill="#000000" />
<rect x="80" y="200" width="20" height="20" fill="#000000" />
<rect x="80" y="240" width="20" height="20" fill="#000000" />
<rect x="80" y="260" width="20" height="20" fill="#000000" />
<rect x="80" y="300" width="20" height="20" fill="#000000" />
<rect x="80" y="320" width="20" height="20" fill="#000000" />
<rect x="80" y="340" width="20" height="20" fill="#000000" />
<rect x="80" y="360" width="20" height="20" fill="#000000" />
<rect x="80" y="440" width="20" height="20" fill="#000000" />
<rect x="80" y="460" width="20" height="20" fill="#000000" />
<rect x="80" y="480" width="20" height="20" fill="#000000" />
<rect x="80" y="520" width="20" height="20" fill="#000000" />
<rect x="80" y="560" width="20" height="20" fill="#000000" />
<rect x="80" y="600" width="20" height="20" fill="#000000" />
<rect x="80" y="620" width="20" height="20" fill="#000000" />
<rect x="80" y="640" width="20" height="20" fill="#000000" />
<rect x="80" y="660" width="20" height="20" fill="#000000" />
<rect x="80" y="680" width="20" height="20" fill="#000000" />
<rect x="80" y="700" width="20" height="20" fill="#000000" />
<rect x="80" y="720" width="20" height="20" fill="#000000" />
<rect x="100" y="80" width="20" height="20" fill="#000000" />
<rect x="100" y="200" width="20" height="20" fill="#000000" />
<rect x="100" y="240" width="20" height="20" fill="#000000" />
<rect x="100" y="260" width="20" height="20" fill="#000000" />
<rect x="100" y="320" width="20" height="20" fill="#000000" />
<rect x="100" y="340" width="20" height="20" fill="#000000" />
<rect x="100" y="360" width="20" height="20" fill="#000000" />
<rect x="100" y="400" width="20" height="20" fill="#000000" />
<rect x="100" y="460" width="20" height="20" fill="#000000" />
<rect x="100" y="500" width="20" height="20" fill="#000000" />
<rect x="100" y="520" width="20" height="20" fill="#000000" />
<rect x="100" y="560" width="20" height="20" fill="#000000" />
<rect x="100" y="600" width="20" height="20" fill="#000000" />
<rect x="100" y="720" width="20" height="20" fill="#000000" />
<rect x="120" y="80" width="20" height="20" fill="#000000" />
<rect x="120" y="120" width="20" height="20" fill="#000000" />
<rect x="120" y="140" width="20" height="20" fill="#000000" />
<rect x="120" y="160" width="20" height="20" fill="#000000" />
<rect x="120" y="200" width="20" height="20" fill="#000000" />
<rect x="120" y="240" width="20" height="20" fill="#000000" />
<rect x="120" y="260" width="20" height="20" fill="#000000" />
<rect x="120" y="280" width="20" height="20" fill="#000000" />
<rect x="120" y="300" width="20" height="20" fill="#000000" />
<rect x="120" y="320" width="20" height="20" fill="#000000" />
<rect x="120" y="360" width="20" height="20" fill="#000000" />
<rect x="120" y="380" width="20" height="20" fill="#000000" />
<rect x="120" y="420" width="20" height="20" fill="#000000" />
<rect x="120" y="500" width="20" height="20" fill="#000000" />
<rect x="120" y="520" width="20" height="20" fill="#000000" />
<rect x="120" y="560" width="20" height="20" fill="#000000" />
<rect x="120" y="600" width="20" height="20" fill="#000000" />
<rect x="120" y="640" width="20" height="20" fill="#000000" />
<rect x="120" y="660" width="20" height="20" fill="#000000" />
<rect x="120" y="680" width="20" height="20" fill="#000000" />
<rect x="120" y="720" width="20" height="20" fill="#000000" />
<rect x="140" y="80" width="20" height="20" fill="#000000" />
<rect x="140" y="120" width="20" height="20" fill="#000000" />
<rect x="140" y="140" width="20" height="20" fill="#000000" />
<rect x="140" y="160" width="20" height="20" fill="#000000" />
<rect x="140" y="200" width="20" height="20" fill="#000000" />
<rect x="140" y="280" width="20" height="20" fill="#000000" />
<rect x="140" y="340" width="20" height="20" fill="#000000" />
<rect x="140" y="380" width="20" height="20" fill="#000000" />
<rect x="140" y="400" width="20" height="20" fill="#000000" />
<rect x="140" y="420" width="20" height="20" fill="#000000" />
<rect x="140" y="520" width="20" height="20" fill="#000000" />
<rect x="140" y="560" width="20" height="20" fill="#000000" />
<rect x="140" y="600" width="20" height="20" fill="#000000" />
<rect x="140" y="640" width="20" height="20" fill="#000000" />
<rect x="140" y="660" width="20" height="20" fill="#000000" />
<rect x="140" y="680" width="20" height="20" fill="#000000" />
<rect x="140" y="720" width="20" height="20" fill="#000000" />
<rect x="160" y="80" width="20" height="20" fill="#000000" />
<rect x="160" y="120" width="20" height="20" fill="#000000" />
<rect x="160" y="140" width="20" height="20" fill="#000000" />
<rect x="160" y="160" width="20" height="20" fill="#000000" />
<rect x="160" y="200" width="20" height="20" fill="#000000" />
<rect x="160" y="280" width="20" height="20" fill="#000000" />
<rect x="160" y="300" width="20" height="20" fill="#000000" />
<rect x="160" y="340" width="20" height="20" fill="#000000" />
<rect x="160" y="400" width="20" height="20" fill="#000000" />
<rect x="160" y="460" width="20" height="20" fill="#000000" />
<rect x="160" y="500" width="20" height="20" fill="#000000" />
<rect x="160" y="540" width="20" height="20" fill="#000000" />
<rect x="160" y="560" width="20" height="20" fill="#000000" />
<rect x="160" y="600" width="20" height="20" fill="#000000" />
<rect x="160" y="640" width="20" height="20" fill="#000000" />
<rect x="160" y="660" width="20" height="20" fill="#000000" />
<rect x="160" y="680" width="20" height="20" fill="#000000" />
<rect x="160" y="720" width="20" height="20" fill="#000000" />
<rect x="180" y="80" width="20" height="20" fill="#000000" />
<rect x="180" y="200" width="20" height="20" fill="#000000" />
<rect x="180" y="240" width="20" height="20" fill="#000000" />
<rect x="180" y="280" width="20" height="20" fill="#000000" />
<rect x="180" y="300" width="20" height="20" fill="#000000" />
<rect x="180" y="340" width="20" height="20" fill="#000000" />
<rect x="180" y="440" width="20" height="20" fill="#000000" />
<rect x="180" y="460" width="20" height="20" fill="#000000" />
<rect x="180" y="500" width="20" height="20" fill="#000000" />
<rect x="180" y="560" width="20" height="20" fill="#000000" />
<rect x="180" y="600" width="20" height="20" fill="#000000" />
<rect x="180" y="720" width="20" height="20" fill="#000000" />
<rect x="200" y="80" width="20" height="20" fill="#000000" />
<rect x="200" y="100" width="20" height="20" fill="#000000" />
<rect x="200" y="120" width="20" height="20" fill="#000000" />
<rect x="200" y="140" width="20" height="20" fill="#000000" />
<rect x="200" y="160" width="20" height="20" fill="#000000" />
<rect x="200" y="180" width="20" height="20" fill="#000000" />
<rect x="200" y="200" width="20" height="20" fill="#000000" />
<rect x="200" y="240" width="20" height="20" fill="#000000" />
<rect x="200" y="280" width="20" height="20" fill="#000000" />
<rect x="200" y="320" width="20" height="20" fill="#000000" />
<rect x="200" y="360" width="20" height="20" fill="#000000" />
<rect x="200" y="400" width="20" height="20" fill="#000000" />
<rect x="200" y="440" width="20" height="20" fill="#000000" />
<rect x="200" y="480" width="20" height="20" fill="#000000" />
<rect x="200" y="520" width="20" height="20" fill="#000000" />
<rect x="200" y="560" width="20" height="20" fill="#000000" />
<rect x="200" y="600" width="20" height="20" fill="#000000" />
<rect x="200" y="620" width="20" height="20" fill="#000000" />
<rect x="200" y="640" width="20" height="20" fill="#000000" />
<rect x="200" y="660" width="20" height="20" fill="#000000" />
<rect x="200" y="680" width="20" height="20" fill="#000000" />
<rect x="200" y="700" width="20" height="20" fill="#000000" />
<rect x="200" y="720" width="20" height="20" fill="#000000" />
<rect x="220" y="260" width="20" height="20" fill="#000000" />
<rect x="220" y="280" width="20" height="20" fill="#000000" />
<rect x="220" y="300" width="20" height="20" fill="#000000" />
<rect x="220" y="320" width="20" height="20" fill="#000000" />
<rect x="220" y="380" width="20" height="20" fill="#000000" />
<rect x="220" y="440" width="20" height="20" fill="#000000" />
<rect x="220" y="480" width="20" height="20" fill="#000000" />
<rect x="220" y="540" width="20" height="20" fill="#000000" />
<rect x="240" y="80" width="20" height="20" fill="#000000" />
<rect x="240" y="100" width="20" height="20" fill="#000000" />
<rect x="240" y="160" width="20" height="20" fill="#000000" />
<rect x="240" y="180" width="20" height="20" fill="#000000" />
<rect x="240" y="200" width="20" height="20" fill="#000000" />
<rect x="240" y="220" width="20" height="20" fill="#000000" />
<rect x="240" y="240" width="20" height="20" fill="#000000" />
<rect x="240" y="280" width="20" height="20" fill="#000000" />
<rect x="240" y="300" width="20" height="20" fill="#000000" />
<rect x="240" y="320" width="20" height="20" fill="#000000" />
<rect x="240" y="340" width="20" height="20" fill="#000000" />
<rect x="240" y="360" width="20" height="20" fill="#000000" />
<rect x="240" y="380" width="20" height="20" fill="#000000" />
<rect x="240" y="440" width="20" height="20" fill="#000000" />
<rect x="240" y="520" width="20" height="20" fill="#000000" />
<rect x="240" y="560" width="20" height="20" fill="#000000" />
<rect x="240" y="580" width="20" height="20" fill="#000000" />
<rect x="240" y="620" width="20" height="20" fill="#000000" />
<rect x="240" y="680" width="20" height="20" fill="#000000" />
<rect x="240" y="700" width="20" height="20" fill="#000000" />
<rect x="240" y="720" width="20" height="20" fill="#000000" />
<rect x="260" y="100" width="20" height="20" fill="#000000" />
<rect x="260" y="160" width="20" height="20" fill="#000000" />
<rect x="260" y="240" width="20" height="20" fill="#000000" />
<rect x="260" y="260" width="20" height="20" fill="#000000" />
<rect x="260" y="300" width="20" height="20" fill="#000000" />
<rect x="260" y="320" width="20" height="20" fill="#000000" />
<rect x="260" y="360" width="20" height="20" fill="#000000" />
<rect x="260" y="380" width="20" height="20" fill="#000000" />
<rect x="260" y="400" width="20" height="20" fill="#000000" />
<rect x="260" y="420" width="20" height="20" fill="#000000" />
<rect x="260" y="500" width="20" height="20" fill="#000000" />
<rect x="260" y="520" width="20" height="20" fill="#000000" />
<rect x="260" y="540" width="20" height="20" fill="#000000" />
<rect x="260" y="600" width="20" height="20" fill="#000000" />
<rect x="260" y="640" width="20" height="20" fill="#000000" />
<rect x="260" y="660" width="20" height="20" fill="#000000" />
<rect x="280" y="100" width="20" height="20" fill="#000000" />
<rect x="280" y="120" width="20" height="20" fill="#000000" />
<rect x="280" y="140" width="20" height="20" fill="#000000" />
<rect x="280" y="160" width="20" height="20" fill="#000000" />
<rect x="280" y="200" width="20" height="20" fill="#000000" />
<rect x="280" y="220" width="20" height="20" fill="#000000" />
<rect x="280" y="240" width="20" height="20" fill="#000000" />
<rect x="280" y="260" width="20" height="20" fill="#000000" />
<rect x="280" y="380" width="20" height="20" fill="#000000" />
<rect x="280" y="440" width="20" height="20" fill="#000000" />
<rect x="280" y="600" width="20" height="20" fill="#000000" />
<rect x="280" y="620" width="20" height="20" fill="#000000" />
<rect x="280" y="640" width="20" height="20" fill="#000000" />
<rect x="280" y="660" width="20" height="20" fill="#000000" />
<rect x="280" y="700" width="20" height="20" fill="#000000" />
<rect x="300" y="80" width="20" height="20" fill="#000000" />
<rect x="300" y="120" width="20" height="20" fill="#000000" />
<rect x="300" y="160" width="20" height="20" fill="#000000" />
<rect x="300" y="180" width="20" height="20" fill="#000000" />
<rect x="300" y="220" width="20" height="20" fill="#000000" />
<rect x="300" y="280" width="20" height="20" fill="#000000" />
<rect x="300" y="320" width="20" height="20" fill="#000000" />
<rect x="300" y="380" width="20" height="20" fill="#000000" />
<rect x="300" y="440" width="20" height="20" fill="#000000" />
<rect x="300" y="480" width="20" height="20" fill="#000000" />
<rect x="300" y="540" width="20" height="20" fill="#000000" />
<rect x="300" y="600" width="20" height="20" fill="#000000" />
<rect x="300" y="640" width="20" height="20" fill="#000000" />
<rect x="300" y="700" width="20" height="20" fill="#000000" />
<rect x="320" y="80" width="20" height="20" fill="#000000" />
<rect x="320" y="100" width="20" height="20" fill="#000000" />
<rect x="320" y="120" width="20" height="20" fill="#000000" />
<rect x="320" y="200" width="20" height="20" fill="#000000" />
<rect x="320" y="220" width="20" height="20" fill="#000000" />
<rect x="320" y="320" width="20" height="20" fill="#000000" />
<rect x="320" y="340" width="20" height="20" fill="#000000" />
<rect x="320" y="360" width="20" height="20" fill="#000000" />
<rect x="320" y="380" width="20" height="20" fill="#000000" />
<rect x="320" y="480" width="20" height="20" fill="#000000" />
<rect x="320" y="500" width="20" height="20" fill="#000000" />
<rect x="320" y="520" width="20" height="20" fill="#000000" />
<rect x="320" y="540" width="20" height="20" fill="#000000" />
<rect x="320" y="640" width="20" height="20" fill="#000000" />
<rect x="320" y="660" width="20" height="20" fill="#000000" />
<rect x="320" y="680" width="20" height="20" fill="#000000" />
<rect x="320" y="700" width="20" height="20" fill="#000000" />
<rect x="340" y="100" width="20" height="20" fill="#000000" />
<rect x="340" y="160" width="20" height="20" fill="#000000" />
<rect x="340" y="240" width="20" height="20" fill="#000000" />
<rect x="340" y="260" width="20" height="20" fill="#000000" />
<rect x="340" y="300" width="20" height="20" fill="#000000" />
<rect x="340" y="320" width="20" height="20" fill="#000000" />
<rect x="340" y="360" width="20" height="20" fill="#000000" />
<rect x="340" y="400" width="20" height="20" fill="#000000" />
<rect x="340" y="420" width="20" height="20" fill="#000000" />
<rect x="340" y="460" width="20" height="20" fill="#000000" />
<rect x="340" y="480" width="20" height="20" fill="#000000" />
<rect x="340" y="520" width="20" height="20" fill="#000000" />
<rect x="340" y="560" width="20" height="20" fill="#000000" />
<rect x="340" y="580" width="20" height="20" fill="#000000" />
<rect x="340" y="620" width="20" height="20" fill="#000000" />
<rect x="340" y="640" width="20" height="20" fill="#000000" />
<rect x="340" y="680" width="20" height="20" fill="#000000" />
<rect x="340" y="720" width="20" height="20" fill="#000000" />
<rect x="360" y="100" width="20" height="20" fill="#000000" />
<rect x="360" y="120" width="20" height="20" fill="#000000" />
<rect x="360" y="140" width="20" height="20" fill="#000000" />
<rect x="360" y="160" width="20" height="20" fill="#000000" />
<rect x="360" y="200" width="20" height="20" fill="#000000" />
<rect x="360" y="220" width="20" height="20" fill="#000000" />
<rect x="360" y="240" width="20" height="20" fill="#000000" />
<rect x="360" y="260" width="20" height="20" fill="#000000" />
<rect x="360" y="360" width="20" height="20" fill="#000000" />
<rect x="360" y="380" width="20" height="20" fill="#000000" />
<rect x="360" y="400" width="20" height="20" fill="#000000" />
<rect x="360" y="420" width="20" height="20" fill="#000000" />
<rect x="360" y="520" width="20" height="20" fill="#000000" />
<rect x="360" y="540" width="20" height="20" fill="#000000" />
<rect x="360" y="560" width="20" height="20" fill="#000000" />
<rect x="360" y="580" width="20" height="20" fill="#000000" />
<rect x="360" y="680" width="20" height="20" fill="#000000" />
<rect x="360" y="700" width="20" height="20" fill="#000000" />
<rect x="360" y="720" width="20" height="20" fill="#000000" />
<rect x="380" y="80" width="20" height="20" fill="#000000" />
<rect x="380" y="120" width="20" height="20" fill="#000000" />
<rect x="380" y="160" width="20" height="20" fill="#000000" />
<rect x="380" y="180" width="20" height="20" fill="#000000" />
<rect x="380" y="220" width="20" height="20" fill="#000000" />
<rect x="380" y="280" width="20" height="20" fill="#000000" />
<rect x="380" y="320" width="20" height="20" fill="#000000" />
<rect x="380" y="380" width="20" height="20" fill="#000000" />
<rect x="380" y="440" width="20" height="20" fill="#000000" />
<rect x="380" y="460" width="20" height="20" fill="#000000" />
<rect x="380" y="480" width="20" height="20" fill="#000000" />
<rect x="380" y="520" width="20" height="20" fill="#000000" />
<rect x="380" y="560" width="20" height="20" fill="#000000" />
<rect x="380" y="600" width="20" height="20" fill="#000000" />
<rect x="380" y="660" width="20" height="20" fill="#000000" />
<rect x="380" y="680" width="20" height="20" fill="#000000" />
<rect x="380" y="700" width="20" height="20" fill="#000000" />
<rect x="380" y="720" width="20" height="20" fill="#000000" />
<rect x="400" y="80" width="20" height="20" fill="#000000" />
<rect x="400" y="100" width="20" height="20" fill="#000000" />
<rect x="400" y="120" width="20" height="20" fill="#000000" />
<rect x="400" y="200" width="20" height="20" fill="#000000" />
<rect x="400" y="220" width="20" height="20" fill="#000000" />
<rect x="400" y="320" width="20" height="20" fill="#000000" />
<rect x="400" y="340" width="20" height="20" fill="#000000" />
<rect x="400" y="360" width="20" height="20" fill="#000000" />
<rect x="400" y="380" width="20" height="20" fill="#000000" />
<rect x="400" y="400" width="20" height="20" fill="#000000" />
<rect x="400" y="460" width="20" height="20" fill="#000000" />
<rect x="400" y="480" width="20" height="20" fill="#000000" />
<rect x="400" y="500" width="20" height="20" fill="#000000" />
<rect x="400" y="540" width="20" height="20" fill="#000000" />
<rect x="400" y="560" width="20" height="20" fill="#000000" />
<rect x="400" y="580" width="20" height="20" fill="#000000" />
<rect x="400" y="620" width="20" height="20" fill="#000000" />
<rect x="400" y="640" width="20" height="20" fill="#000000" />
<rect x="400" y="680" width="20" height="20" fill="#000000" />
<rect x="400" y="700" width="20" height="20" fill="#000000" />
<rect x="400" y="720" width="20" height="20" fill="#000000" />
<rect x="420" y="80" width="20" height="20" fill="#000000" />
<rect x="420" y="120" width="20" height="20" fill="#000000" />
<rect x="420" y="160" width="20" height="20" fill="#000000" />
<rect x="420" y="320" width="20" height="20" fill="#000000" />
<rect x="420" y="420" width="20" height="20" fill="#000000" />
<rect x="420" y="440" width="20" height="20" fill="#000000" />
<rect x="420" y="480" width="20" height="20" fill="#000000" />
<rect x="420" y="520" width="20" height="20" fill="#000000" />
<rect x="420" y="560" width="20" height="20" fill="#000000" />
<rect x="420" y="640" width="20" height="20" fill="#000000" />
<rect x="420" y="720" width="20" height="20" fill="#000000" />
<rect x="440" y="120" width="20" height="20" fill="#000000" />
<rect x="440" y="140" width="20" height="20" fill="#000000" />
<rect x="440" y="200" width="20" height="20" fill="#000000" />
<rect x="440" y="240" width="20" height="20" fill="#000000" />
<rect x="440" y="260" width="20" height="20" fill="#000000" />
<rect x="440" y="300" width="20" height="20" fill="#000000" />
<rect x="440" y="340" width="20" height="20" fill="#000000" />
<rect x="440" y="400" width="20" height="20" fill="#000000" />
<rect x="440" y="460" width="20" height="20" fill="#000000" />
<rect x="440" y="500" width="20" height="20" fill="#000000" />
<rect x="440" y="520" width="20" height="20" fill="#000000" />
<rect x="440" y="540" width="20" height="20" fill="#000000" />
<rect x="440" y="600" width="20" height="20" fill="#000000" />
<rect x="440" y="660" width="20" height="20" fill="#000000" />
<rect x="460" y="80" width="20" height="20" fill="#000000" />
<rect x="460" y="120" width="20" height="20" fill="#000000" />
<rect x="460" y="140" width="20" height="20" fill="#000000" />
<rect x="460" y="220" width="20" height="20" fill="#000000" />
<rect x="460" y="240" width="20" height="20" fill="#000000" />
<rect x="460" y="280" width="20" height="20" fill="#000000" />
<rect x="460" y="300" width="20" height="20" fill="#000000" />
<rect x="460" y="320" width="20" height="20" fill="#000000" />
<rect x="460" y="360" width="20" height="20" fill="#000000" />
<rect x="460" y="380" width="20" height="20" fill="#000000" />
<rect x="460" y="400" width="20" height="20" fill="#000000" />
<rect x="460" y="440" width="20" height="20" fill="#000000" />
<rect x="460" y="480" width="20" height="20" fill="#000000" />
<rect x="460" y="520" width="20" height="20" fill="#000000" />
<rect x="460" y="580" width="20" height="20" fill="#000000" />
<rect x="460" y="600" width="20" height="20" fill="#000000" />
<rect x="460" y="620" width="20" height="20" fill="#000000" />
<rect x="460" y="640" width="20" height="20" fill="#000000" />
<rect x="460" y="680" width="20" height="20" fill="#000000" />
<rect x="460" y="720" width="20" height="20" fill="#000000" />
<rect x="480" y="100" width="20" height="20" fill="#000000" />
<rect x="480" y="160" width="20" height="20" fill="#000000" />
<rect x="480" y="200" width="20" height="20" fill="#000000" />
<rect x="480" y="260" width="20" height="20" fill="#000000" />
<rect x="480" y="340" width="20" height="20" fill="#000000" />
<rect x="480" y="420" width="20" height="20" fill="#000000" />
<rect x="480" y="440" width="20" height="20" fill="#000000" />
<rect x="480" y="460" width="20" height="20" fill="#000000" />
<rect x="480" y="480" width="20" height="20" fill="#000000" />
<rect x="480" y="500" width="20" height="20" fill="#000000" />
<rect x="480" y="540" width="20" height="20" fill="#000000" />
<rect x="480" y="560" width="20" height="20" fill="#000000" />
<rect x="480" y="600" width="20" height="20" fill="#000000" />
<rect x="480" y="620" width="20" height="20" fill="#000000" />
<rect x="480" y="660" width="20" height="20" fill="#000000" />
<rect x="480" y="680" width="20" height="20" fill="#000000" />
<rect x="480" y="700" width="20" height="20" fill="#000000" />
<rect x="480" y="720" width="20" height="20" fill="#000000" />
<rect x="500" y="120" width="20" height="20" fill="#000000" />
<rect x="500" y="160" width="20" height="20" fill="#000000" />
<rect x="500" y="240" width="20" height="20" fill="#000000" />
<rect x="500" y="260" width="20" height="20" fill="#000000" />
<rect x="500" y="320" width="20" height="20" fill="#000000" />
<rect x="500" y="340" width="20" height="20" fill="#000000" />
<rect x="500" y="360" width="20" height="20" fill="#000000" />
<rect x="500" y="400" width="20" height="20" fill="#000000" />
<rect x="500" y="440" width="20" height="20" fill="#000000" />
<rect x="500" y="500" width="20" height="20" fill="#000000" />
<rect x="500" y="520" width="20" height="20" fill="#000000" />
<rect x="500" y="560" width="20" height="20" fill="#000000" />
<rect x="500" y="720" width="20" height="20" fill="#000000" />
<rect x="520" y="80" width="20" height="20" fill="#000000" />
<rect x="520" y="100" width="20" height="20" fill="#000000" />
<rect x="520" y="140" width="20" height="20" fill="#000000" />
<rect x="520" y="200" width="20" height="20" fill="#000000" />
<rect x="520" y="220" width="20" height="20" fill="#000000" />
<rect x="520" y="280" width="20" height="20" fill="#000000" />
<rect x="520" y="380" width="20" height="20" fill="#000000" />
<rect x="520" y="460" width="20" height="20" fill="#000000" />
<rect x="520" y="480" width="20" height="20" fill="#000000" />
<rect x="520" y="540" width="20" height="20" fill="#000000" />
<rect x="520" y="600" width="20" height="20" fill="#000000" />
<rect x="520" y="640" width="20" height="20" fill="#000000" />
<rect x="520" y="660" width="20" height="20" fill="#000000" />
<rect x="520" y="680" width="20" height="20" fill="#000000" />
<rect x="520" y="700" width="20" height="20" fill="#000000" />
<rect x="540" y="160" width="20" height="20" fill="#000000" />
<rect x="540" y="240" width="20" height="20" fill="#000000" />
<rect x="540" y="280" width="20" height="20" fill="#000000" />
<rect x="540" y="320" width="20" height="20" fill="#000000" />
<rect x="540" y="360" width="20" height="20" fill="#000000" />
<rect x="540" y="380" width="20" height="20" fill="#000000" />
<rect x="540" y="400" width="20" height="20" fill="#000000" />
<rect x="540" y="440" width="20" height="20" fill="#000000" />
<rect x="540" y="500" width="20" height="20" fill="#000000" />
<rect x="540" y="520" width="20" height="20" fill="#000000" />
<rect x="540" y="600" width="20" height="20" fill="#000000" />
<rect x="540" y="620" width="20" height="20" fill="#000000" />
<rect x="540" y="640" width="20" height="20" fill="#000000" />
<rect x="540" y="680" width="20" height="20" fill="#000000" />
<rect x="540" y="700" width="20" height="20" fill="#000000" />
<rect x="560" y="80" width="20" height="20" fill="#000000" />
<rect x="560" y="100" width="20" height="20" fill="#000000" />
<rect x="560" y="120" width="20" height="20" fill="#000000" />
<rect x="560" y="200" width="20" height="20" fill="#000000" />
<rect x="560" y="220" width="20" height="20" fill="#000000" />
<rect x="560" y="240" width="20" height="20" fill="#000000" />
<rect x="560" y="260" width="20" height="20" fill="#000000" />
<rect x="560" y="280" width="20" height="20" fill="#000000" />
<rect x="560" y="300" width="20" height="20" fill="#000000" />
<rect x="560" y="320" width="20" height="20" fill="#000000" />
<rect x="560" y="340" width="20" height="20" fill="#000000" />
<rect x="560" y="420" width="20" height="20" fill="#000000" />
<rect x="560" y="460" width="20" height="20" fill="#000000" />
<rect x="560" y="480" width="20" height="20" fill="#000000" />
<rect x="560" y="560" width="20" height="20" fill="#000000" />
<rect x="560" y="580" width="20" height="20" fill="#000000" />
<rect x="560" y="600" width="20" height="20" fill="#000000" />
<rect x="560" y="620" width="20" height="20" fill="#000000" />
<rect x="560" y="640" width="20" height="20" fill="#000000" />
<rect x="560" y="720" width="20" height="20" fill="#000000" />
<rect x="580" y="240" width="20" height="20" fill="#000000" />
<rect x="580" y="300" width="20" height="20" fill="#000000" />
<rect x="580" y="380" width="20" height="20" fill="#000000" />
<rect x="580" y="400" width="20" height="20" fill="#000000" />
<rect x="580" y="460" width="20" height="20" fill="#000000" />
<rect x="580" y="540" width="20" height="20" fill="#000000" />
<rect x="580" y="560" width="20" height="20" fill="#000000" />
<rect x="580" y="640" width="20" height="20" fill="#000000" />
<rect x="580" y="660" width="20" height="20" fill="#000000" />
<rect x="580" y="680" width="20" height="20" fill="#000000" />
<rect x="580" y="720" width="20" height="20" fill="#000000" />
<rect x="600" y="80" width="20" height="20" fill="#000000" />
<rect x="600" y="100" width="20" height="20" fill="#000000" />
<rect x="600" y="120" width="20" height="20" fill="#000000" />
<rect x="600" y="140" width="20" height="20" fill="#000000" />
<rect x="600" y="160" width="20" height="20" fill="#000000" />
<rect x="600" y="180" width="20" height="20" fill="#000000" />
<rect x="600" y="200" width="20" height="20" fill="#000000" />
<rect x="600" y="240" width="20" height="20" fill="#000000" />
<rect x="600" y="260" width="20" height="20" fill="#000000" />
<rect x="600" y="300" width="20" height="20" fill="#000000" />
<rect x="600" y="320" width="20" height="20" fill="#000000" />
<rect x="600" y="340" width="20" height="20" fill="#000000" />
<rect x="600" y="400" width="20" height="20" fill="#000000" />
<rect x="600" y="420" width="20" height="20" fill="#000000" />
<rect x="600" y="460" width="20" height="20" fill="#000000" />
<rect x="600" y="480" width="20" height="20" fill="#000000" />
<rect x="600" y="520" width="20" height="20" fill="#000000" />
<rect x="600" y="560" width="20" height="20" fill="#000000" />
<rect x="600" y="600" width="20" height="20" fill="#000000" />
<rect x="600" y="640" width="20" height="20" fill="#000000" />
<rect x="600" y="680" width="20" height="20" fill="#000000" />
<rect x="620" y="80" width="20" height="20" fill="#000000" />
<rect x="620" y="200" width="20" height="20" fill="#000000" />
<rect x="620" y="240" width="20" height="20" fill="#000000" />
<rect x="620" y="260" width="20" height="20" fill="#000000" />
<rect x="620" y="320" width="20" height="20" fill="#000000" />
<rect x="620" y="340" width="20" height="20" fill="#000000" />
<rect x="620" y="360" width="20" height="20" fill="#000000" />
<rect x="620" y="380" width="20" height="20" fill="#000000" />
<rect x="620" y="400" width="20" height="20" fill="#000000" />
<rect x="620" y="460" width="20" height="20" fill="#000000" />
<rect x="620" y="480" width="20" height="20" fill="#000000" />
<rect x="620" y="500" width="20" height="20" fill="#000000" />
<rect x="620" y="520" width="20" height="20" fill="#000000" />
<rect x="620" y="540" width="20" height="20" fill="#000000" />
<rect x="620" y="560" width="20" height="20" fill="#000000" />
<rect x="620" y="640" width="20" height="20" fill="#000000" />
<rect x="620" y="720" width="20" height="20" fill="#000000" />
<rect x="640" y="80" width="20" height="20" fill="#000000" />
<rect x="640" y="120" width="20" height="20" fill="#000000" />
<rect x="640" y="140" width="20" height="20" fill="#000000" />
<rect x="640" y="160" width="20" height="20" fill="#000000" />
<rect x="640" y="200" width="20" height="20" fill="#000000" />
<rect x="640" y="240" width="20" height="20" fill="#000000" />
<rect x="640" y="380" width="20" height="20" fill="#000000" />
<rect x="640" y="440" width="20" height="20" fill="#000000" />
<rect x="640" y="520" width="20" height="20" fill="#000000" />
<rect x="640" y="540" width="20" height="20" fill="#000000" />
<rect x="640" y="560" width="20" height="20" fill="#000000" />
<rect x="640" y="580" width="20" height="20" fill="#000000" />
<rect x="640" y="600" width="20" height="20" fill="#000000" />
<rect x="640" y="620" width="20" height="20" fill="#000000" />
<rect x="640" y="640" width="20" height="20" fill="#000000" />
<rect x="640" y="660" width="20" height="20" fill="#000000" />
<rect x="640" y="680" width="20" height="20" fill="#000000" />
<rect x="640" y="720" width="20" height="20" fill="#000000" />
<rect x="660" y="80" width="20" height="20" fill="#000000" />
<rect x="660" y="120" width="20" height="20" fill="#000000" />
<rect x="660" y="140" width="20" height="20" fill="#000000" />
<rect x="660" y="160" width="20" height="20" fill="#000000" />
<rect x="660" y="200" width="20" height="20" fill="#000000" />
<rect x="660" y="260" width="20" height="20" fill="#000000" />
<rect x="660" y="320" width="20" height="20" fill="#000000" />
<rect x="660" y="340" width="20" height="20" fill="#000000" />
<rect x="660" y="380" width="20" height="20" fill="#000000" />
<rect x="660" y="400" width="20" height="20" fill="#000000" />
<rect x="660" y="420" width="20" height="20" fill="#000000" />
<rect x="660" y="460" width="20" height="20" fill="#000000" />
<rect x="660" y="520" width="20" height="20" fill="#000000" />
<rect x="660" y="540" width="20" height="20" fill="#000000" />
<rect x="660" y="560" width="20" height="20" fill="#000000" />
<rect x="660" y="620" width="20" height="20" fill="#000000" />
<rect x="660" y="640" width="20" height="20" fill="#000000" />
<rect x="660" y="660" width="20" height="20" fill="#000000" />
<rect x="660" y="700" width="20" height="20" fill="#000000" />
<rect x="680" y="80" width="20" height="20" fill="#000000" />
<rect x="680" y="120" width="20" height="20" fill="#000000" />
<rect x="680" y="140" width="20" height="20" fill="#000000" />
<rect x="680" y="160" width="20" height="20" fill="#000000" />
<rect x="680" y="200" width="20" height="20" fill="#000000" />
<rect x="680" y="260" width="20" height="20" fill="#000000" />
<rect x="680" y="340" width="20" height="20" fill="#000000" />
<rect x="680" y="440" width="20" height="20" fill="#000000" />
<rect x="680" y="500" width="20" height="20" fill="#000000" />
<rect x="680" y="520" width="20" height="20" fill="#000000" />
<rect x="680" y="600" width="20" height="20" fill="#000000" />
<rect x="680" y="660" width="20" height="20" fill="#000000" />
<rect x="680" y="680" width="20" height="20" fill="#000000" />
<rect x="700" y="80" width="20" height="20" fill="#000000" />
<rect x="700" y="200" width="20" height="20" fill="#000000" />
<rect x="700" y="240" width="20" height="20" fill="#000000" />
<rect x="700" y="280" width="20" height="20" fill="#000000" />
<rect x="700" y="320" width="20" height="20" fill="#000000" />
<rect x="700" y="340" width="20" height="20" fill="#000000" />
<rect x="700" y="360" width="20" height="20" fill="#000000" />
<rect x="700" y="540" width="20" height="20" fill="#000000" />
<rect x="700" y="580" width="20" height="20" fill="#000000" />
<rect x="700" y="620" width="20" height="20" fill="#000000" />
<rect x="700" y="660" width="20" height="20" fill="#000000" />
<rect x="700" y="680" width="20" height="20" fill="#000000" />
<rect x="720" y="80" width="20" height="20" fill="#000000" />
<rect x="720" y="100" width="20" height="20" fill="#000000" />
<rect x="720" y="120" width="20" height="20" fill="#000000" />
<rect x="720" y="140" width="20" height="20" fill="#000000" />
<rect x="720" y="160" width="20" height="20" fill="#000000" />
<rect x="720" y="180" width="20" height="20" fill="#000000" />
<rect x="720" y="200" width="20" height="20" fill="#000000" />
<rect x="720" y="240" width="20" height="20" fill="#000000" />
<rect x="720" y="260" width="20" height="20" fill="#000000" />
<rect x="720" y="280" width="20" height="20" fill="#000000" />
<rect x="720" y="300" width="20" height="20" fill="#000000" />
<rect x="720" y="340" width="20" height="20" fill="#000000" />
<rect x="720" y="360" width="20" height="20" fill="#000000" />
<rect x="720" y="380" width="20" height="20" fill="#000000" />
<rect x="720" y="400" width="20" height="20" fill="#000000" />
<rect x="720" y="420" width="20" height="20" fill="#000000" />
<rect x="720" y="440" width="20" height="20" fill="#000000" />
<rect x="720" y="480" width="20" height="20" fill="#000000" />
<rect x="720" y="500" width="20" height="20" fill="#000000" />
<rect x="720" y="520" width="20" height="20" fill="#000000" />
<rect x="720" y="560" width="20" height="20" fill="#000000" />
<rect x="720" y="580" width="20" height="20" fill="#000000" />
<rect x="720" y="600" width="20" height="20" fill="#000000" />
<rect x="720" y="620" width="20" height="20" fill="#000000" />
<rect x="720" y="640" width="20" height="20" fill="#000000" />
<rect x="720" y="660" width="20" height="20" fill="#000000" />
<rect x="720" y="680" width="20" height="20" fill="#000000" />
<rect x="720" y="720" width="20" height="20" fill="#000000" /></svg>
</artwork>
</figure>
<t>A printable invoice containing the QR code is now generated and sent to Alice.</t>
<t>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.</t>
<t>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. </t>
<sourcecode>Discover ("example.com", "mmm-udf") =
https://example.com/.well-known/mmm-udf/</sourcecode>
<t>Next the fingerprint of the source UDF is obtained. </t>
<sourcecode>UDF (EBXI-SDDC-QJME-B3DV-DSSR-PP7V-QBVF-EG) =
MA7I-5WGZ-NT4U-2UXI-KEP7-LYNV-JJUP-YJJB-D5UM-PYA6-PQW5-WTHS-2WD4-BZFN</sourcecode>
<t>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: </t>
<t>https://example.com/.well-known/mmm-udf/MA7I-5WGZ-NT4U-2UXI-KEP7-LYNV-JJUP-YJJB-D5UM-PYA6-PQW5-WTHS-2WD4-BZFN </t>
<t>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. </t>
</section>
</section>
<section title="Secure Internet Names" anchor="n-secure-internet-names"><t>A SIN is an Internet Identifier that contains a UDF fingerprint of a security policy document that may be used to verify the interpretation of the identifier. This permits traditional forms of Internet address such as URIs and RFC822 email addresses to be used to express a trusted address that is independent of any trusted third party.</t>
<t>This document only describes the syntax and interpretation of the identifiers themselves. The means by which the security policy documents bound to an address govern interpretation of the name is discussed separately in <xref target="draft-hallambaker-mesh-trust"></xref>.</t>
<t>For example, Example Inc holds the domain name example.com and has deployed a  private CA whose root of trust is a PKIX certificate with the UDF fingerprint  MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ. </t>
<t>Alice is an employee of Example Inc., she uses three email addresses: </t>
<dl>
<dt>alice@example.com </dt>
<dd>
<t>A regular email address (not a SIN). </t>
</dd>
<dt>alice@mm--mb2gk-6duf5-ygyyl-jny5e-rwshz.example.com </dt>
<dd>
<t>A strong email address that is backwards compatible. </t>
</dd>
<dt>alice@example.com.mm--mb2gk-6duf5-ygyyl-jny5e-rwshz </dt>
<dd>
<t>A strong email address that is backwards incompatible.  </t>
</dd>
</dl>
<t>All three forms of the address are valid RFC822 addresses and may be used in a legacy email client, stored in an address book application, etc. But the ability of a legacy client to make use of the address differs. Addresses of the first type may always be used. Addresses of the second type may only be used if an appropriate MX record is provisioned. Addresses of the third type will always fail unless the resolver understands that it is a SIN requiring special processing.</t>
<t>These rules allow Bob to send email to Alice with either 'best effort' security or mandatory security as the circumstances demand.</t>
</section>
</section>
<section title="Definitions" anchor="n-definitions"><t>This section presents the related specifications and standard, the terms that are used as terms of art within the documents and the terms used as requirements language.</t>
<section title="Requirements Language" anchor="n-requirements-language"><t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in <xref target="RFC2119"></xref>.</t>
</section>
<section title="Defined Terms" anchor="n-defined-terms"><dl>
<dt>Cryptographic Digest Function</dt>
<dd>
<t>A hash function that has the properties required for use as a cryptographic hash function. These include collision resistance, first pre-image resistance and second pre-image resistance. </t>
</dd>
<dt>Content Type</dt>
<dd>
<t>An identifier indicating how a Data Value is to be interpreted as specified in the IANA registry Media Types.</t>
</dd>
<dt>Commitment</dt>
<dd>
<t>A cryptographic primitive that allows one to commit to a chosen value while keeping it hidden to others, with the ability to reveal the committed value later.</t>
</dd>
<dt>Data Value</dt>
<dd>
<t>The binary octet stream that is the input to the digest function used to calculate a digest value.</t>
</dd>
<dt>Data Object</dt>
<dd>
<t>A Data Value and its associated Content Type</t>
</dd>
<dt>Digest Algorithm</dt>
<dd>
<t>A synonym for Cryptographic Digest Function</t>
</dd>
<dt>Digest Value</dt>
<dd>
<t>The output of a Cryptographic Digest Function</t>
</dd>
<dt>Data Digest Value</dt>
<dd>
<t>The output of a Cryptographic Digest Function for a given Data Value input.</t>
</dd>
<dt>Fingerprint</dt>
<dd>
<t>A presentation of the digest value of a data value or data object.</t>
</dd>
<dt>Fingerprint Presentation</dt>
<dd>
<t>The representation of at least some part of a fingerprint value in human or machine-readable form.</t>
</dd>
<dt>Fingerprint Improvement</dt>
<dd>
<t>The practice of recording a higher precision presentation of a fingerprint on successful validation.</t>
</dd>
<dt>Fingerprint Work Hardening</dt>
<dd>
<t>The practice of generating a sequence of fingerprints until one is found that matches criteria that permit a compressed presentation form to be used. The compressed fingerprint thus being shorter than but presenting the same work factor as an uncompressed one.</t>
</dd>
<dt>Hash</dt>
<dd>
<t>A function which takes an input and returns a fixed-size output. Ideally, the output of a hash function is unbiased and not correlated to the outputs returned to similar inputs in any predictable fashion. </t>
</dd>
<dt>Precision</dt>
<dd>
<t>The number of significant bits provided by a Fingerprint Presentation.</t>
</dd>
<dt>Work Factor</dt>
<dd>
<t>A measure of the computational effort required to perform an attack against some security property.</t>
</dd>
</dl>
</section>
<section title="Related Specifications" anchor="n-related-specifications"><t>This specification makes use of Base32 <xref target="RFC4648"></xref> encoding, SHA-2 <xref target="SHA-2"></xref> and SHA-3 <xref target="SHA-3"></xref> digest functions in the derivation of basic fingerprints. The derivation of keyed fingerprints additionally requires the use of the HMAC <xref target="RFC2014"></xref> and HKDF <xref target="RFC5869"></xref> functions.</t>
<t>Resolution of UDF URI Locators makes use of DNS Web Service Discovery <xref target="draft-hallambaker-web-service-discovery"></xref>.</t>
</section>
<section title="Implementation Status" anchor="n-implementation-status"><t>The implementation status of the reference code base is described in the companion document <xref target="draft-hallambaker-mesh-developer"></xref>.</t>
</section>
</section>
<section title="Architecture" anchor="n-architecture"><t>A Uniform Data Fingerprint (UDF) is a presentation of a UDF Binary Data Sequence.</t>
<t>This document specifies seven UDF Binary Data Sequence types and one presentation.</t>
<t>The first octet of a UDF Binary Data Sequence identifies the UDF type and is referred to as the Type identifier. </t>
<t>UDF Binary Data Sequence types are either fixed length or variable length. A variable length Binary Data Sequence <bcp14>MUST</bcp14> be truncated for presentation. Fixed length Binary Data Sequences <bcp14>MUST</bcp14> not be truncated.</t>
<section title="Base32 Presentation" anchor="n-base32-presentation"><t>The default UDF presentation is Base32 Presentation. </t>
<t>Variable length Binary Data Sequences are truncated to an integer multiple of 20 bits that provides the desired precision before conversion to Base32 form. </t>
<t>Fixed length Binary Data Sequences are converted to Base32 form without truncation.</t>
<t>After conversion to Base32 form, dash '-' characters are inserted between groups of 4 characters to aid reading. This representation improves the accuracy of both data entry and verification.</t>
<section title="Precision Improvement" anchor="n-precision-improvement"><t>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).</t>
<t>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.</t>
<t>Applications <bcp14>SHOULD</bcp14> make use of precision improvement wherever possible.</t>
</section>
</section>
<section title="Type Identifier" anchor="n-type-identifier"><t>A Version Identifier consists of a single byte. </t>
<t>The byte codes have been chosen so that the first character of the Base32 presentation of the UDF provides a mnemonic for its type. A SHA-2 fingerprint UDF will always have M (for Merkle Damgard) as the initial letter, a SHA-3 fingerprint UDF will always have K (for Keccak) as the initial letter, and so on.</t>
<t>The following version identifiers are specified in this document:</t>
<table><thead>
<tr>
<th>
Type ID</th>
<th>
Initial</th>
<th>
Algorithm</th>
</tr>
</thead>
<tbody>
<tr>
<td>
0</td>
<td>
A</td>
<td>
HMAC-SHA-2-512</td>
</tr>
<tr>
<td>
32</td>
<td>
E</td>
<td>
HKDF-AES-512</td>
</tr>
<tr>
<td>
80</td>
<td>
K</td>
<td>
SHA-3-512</td>
</tr>
<tr>
<td>
81</td>
<td>
K</td>
<td>
SHA-3-512 (20 bits compressed)</td>
</tr>
<tr>
<td>
82</td>
<td>
K</td>
<td>
SHA-3-512 (30 bits compressed)</td>
</tr>
<tr>
<td>
83</td>
<td>
K</td>
<td>
SHA-3-512 (40 bits compressed)</td>
</tr>
<tr>
<td>
84</td>
<td>
K</td>
<td>
SHA-3-512 (50 bits compressed)</td>
</tr>
<tr>
<td>
96</td>
<td>
M</td>
<td>
SHA-2-512</td>
</tr>
<tr>
<td>
97</td>
<td>
M</td>
<td>
SHA-2-512 (20 bits compressed)</td>
</tr>
<tr>
<td>
98</td>
<td>
M</td>
<td>
SHA-2-512 (30 bits compressed)</td>
</tr>
<tr>
<td>
99</td>
<td>
M</td>
<td>
SHA-2-512 (40 bits compressed)</td>
</tr>
<tr>
<td>
100</td>
<td>
M</td>
<td>
SHA-2-512 (50 bits compressed)</td>
</tr>
<tr>
<td>
104</td>
<td>
N</td>
<td>
Nonce data</td>
</tr>
<tr>
<td>
112</td>
<td>
O</td>
<td>
OID distinguished sequence (DER encoded)</td>
</tr>
<tr>
<td>
136</td>
<td>
R</td>
<td>
Random generation seed</td>
</tr>
<tr>
<td>
144</td>
<td>
S</td>
<td>
Shamir Secret Sharing</td>
</tr>
<tr>
<td>
200</td>
<td>
Z</td>
<td>
Key pair derivation</td>
</tr>
</tbody>
</table></section>
<section title="Content Type Identifier" anchor="n-content-type-identifier"><t>A secure cryptographic digest algorithm provides a unique digest value that is probabilistically unique for a particular byte sequence but does not fix the context in which a byte sequence is interpreted. While such ambiguity may be tolerated in a fingerprint format designed for a single specific field of use, it is not acceptable in a general-purpose format.</t>
<t>For example, the SSH and OpenPGP applications both make use of fingerprints as identifiers for the public keys used but using different digest algorithms and data formats for representing the public key data. While no such vulnerability has been demonstrated to date, it is certainly conceivable that a crafty attacker might construct an SSH key in such a fashion that OpenPGP interprets the data in an insecure fashion. If the number of applications making use of fingerprint format that permits such substitutions is sufficiently large, the probability of a semantic substitution vulnerability being possible becomes unacceptably large.</t>
<t>A simple control that defeats such attacks is to incorporate a content type identifier within the scope of the data input to the hash function.</t>
</section>
<section title="Truncation" anchor="n-truncation"><t>Different applications of fingerprints demand different tradeoffs between compactness of the representation and the number of significant bits. A larger the number of significant bits reduces the risk of collision but at a cost to convenience.</t>
<t>Modern cryptographic digest functions such as SHA-2 produce output values of at least 256 bits in length. This is considerably larger than most uses of fingerprints require and certainly greater than can be represented in human readable form on a business card.</t>
<t>Since a strong cryptographic digest function produces an output value in which every bit in the input value affects every bit in the output value with equal probability, it follows that truncating the digest value to produce a finger print is at least as strong as any other mechanism if digest algorithm used is strong.</t>
<t>Using truncation to reduce the precision of the digest function has the advantage that a lower precision fingerprint of some data content is always a prefix of a higher prefix of the same content. This allows higher precision fingerprints to be converted to a lower precision without the need for special tools.</t>
<section title="Compressed presentation" anchor="n-compressed-presentation"><t>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. </t>
<t>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^120 with a 2^80 bits, it is necessary for the content generator to perform a brute force search at a cost of the order of 2^40 operations.</t>
<t>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<sup>6</sup> attempts. Reducing this to 12 characters would require 10<sup>12</sup> attempts and to 10 characters, 10<sup>15</sup> attempts.</t>
<t>Omission of support for higher levels of compression than 2<sup>50</sup> is intentional.</t>
<t>In addition to allowing use of shorter presentations, work factor compression <bcp14>MAY</bcp14> be used as evidence of proof of work.</t>
</section>
</section>
<section title="Presentation" anchor="n-presentation"><t>The presentation of a fingerprint is the format in which it is presented to either an application or the user.</t>
<t>Base32 encoding is used to produce the preferred text representation of a UDF fingerprint. This encoding uses only the letters of the Latin alphabet with numbers chosen to minimize the risk of ambiguity between numbers and letters (2, 3, 4, 5, 6 and 7).</t>
<t>To enhance readability and improve data entry, characters are grouped into groups of four. This means that each block of four characters represents an increase in work factor of approximately one million times.</t>
</section>
<section title="Alternative Presentations" anchor="n-alternative-presentations"><t>Applications that support UDF <bcp14>MUST</bcp14> support use of the Base32 presentation. Applications <bcp14>MAY</bcp14> support alternative presentations.</t>
<section title="Word Lists" anchor="n-word-lists"><t>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.</t>
<t>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. </t>
<t>For example, a word list with 16384 entries permits 14 bits of the fingerprint to be encoded at once, 65536 entries permits encoding of 16 bits. These encodings allow a 120 bit fingerprint to be encoded in 9 and 8 words respectively.</t>
</section>
<section title="Image List" anchor="n-image-list"><t>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.</t>
</section>
</section>
</section>
<section title="Fixed Length UDFs" anchor="n-fixed-length-udfs"><t>Fixed length UDFs are used to represent cryptographic keys, nonces and secret shares and have a fixed length determined by their function that cannot be truncated without loss of information.</t>
<t>All fixed length Binary Data Sequence values are an integer multiple of eight bits.</t>
<section title="Nonce Type" anchor="n-nonce-type"><t>A Nonce Type UDF consists of the type identifier octet 104 followed by the Binary Data Sequence value. </t>
<t>The Binary Data Sequence value is an integer number of octets that <bcp14>SHOULD</bcp14> have been generated in accordance with processes and procedures that ensure that it is sufficiently unpredictable for the purposes of the protocol in which the value is to be used. Requirements for such processes and procedures are described in <xref target="RFC4086"></xref>.</t>
<t>Nonce Type UDFs are intended for use in contexts where it is necessary for a randomly chosen value to be unpredictable but not secret. For example, the challenge in a challenge/response mechanism. </t>
</section>
<section title="OID Identified Sequence" anchor="n-oid-identified-sequence"><t>An OID Identified Sequence Type UDF consists of the type identifier octet 108 followed by the Binary Data Sequence value. </t>
<t>The Binary Data Sequence value is an octet sequence that contains the DER encoding of the following ASN.1 data:</t>
<sourcecode>   OIDInfo ::=  SEQUENCE  {
        algorithm            AlgorithmIdentifier,
        data                 BIT STRING  }

   AlgorithmIdentifier  ::=  SEQUENCE  {
        algorithm               OBJECT IDENTIFIER,
        parameters              ANY DEFINED BY algorithm OPTIONAL  }</sourcecode>
<t>OID Identified Sequences are intended to allow arbitrary data sequences to be encoded in the UDF format without exhausting the limited type identifier space.</t>
<t>In particular, OID Identified Sequences <bcp14>MAY</bcp14> be used to specify public and private key values.</t>
<t>Given the following Ed25519 public key: </t>
<sourcecode>
  32 88 59 99  41 D2 D4 E7  9C CF 9E 26  07 38 F9 B9
  1E 21 C7 6C  00 71 DD 42  09 D9 90 B6  4C DF 82 0D</sourcecode>
<t>The equivalent DER encoding is: </t>
<sourcecode>
  30 2E 30 07  06 03 2B 65  70 05 00 03  23 00 04 20
  32 88 59 99  41 D2 D4 E7  9C CF 9E 26  07 38 F9 B9
  1E 21 C7 6C  00 71 DD 42  09 D9 90 B6  4C DF 82 0D</sourcecode>
<t>To encode this key as a UDF OID sequence we prepend the value OID and convert to Base32: </t>
<sourcecode>OAYC-4MAH-AYBS-WZLQ-AUAA-GIYA-AQQD-FCCZ-TFA5-FVHH-TTHZ-4JQH-HD43-SHRB
    -Y5WA-A4O5-IIE5-TEFW-JTPY-EDI</sourcecode>
<t>The corresponding UDF content digest value is more compact and allows us to identify the  key unambiguously but does not provide the value: </t>
<sourcecode>MABG-IFIZ-EOYV-7EF6-FC54-JOAW-M3GT</sourcecode>
</section>
<section title="Encryption/Authentication Type" anchor="n-encryptionauthentication-type"><t>An Encryption/Authentication Type UDF consists of the type identifier octet 0 followed by the Binary Data Sequence value. </t>
<t>The Binary Data Sequence value is an integer number of octets that <bcp14>SHOULD</bcp14> have been generated in accordance with processes and procedures that ensure that it is sufficiently unpredictable and unguessable for the purposes of the protocol in which the value is to be used. Requirements for such processes and procedures are described in <xref target="RFC4086"></xref>.</t>
<t>Encryption/Authentication Type UDFs are intended to be used as a means of specifying secret cryptographic keying material. For example, the input to a Key Derivation Function used to encrypt a document. Accordingly, the identifier UDF corresponding to an Encryption/Authentication type UDF is a UDF fingerprint of the Encryption/Authentication Type UDF in Base32 presentation with content type 'application/udf-encryption'. </t>
</section>
<section title="Key Pair Derivation" anchor="n-key-pair-derivation"><t>The key pair derivation type is used to specify a public key pair value by means of a sufficiently random input to a deterministic key generation function. </t>
<t>A key pair derivation Type UDF consists of the type identifier octet 200 followed by the Binary Data Sequence value. </t>
<t>The first two octets of the Binary Data Sequence value comprise the Key Specifier which specifies the algorithm and key uses for which the private key is to be derived.</t>
<ul>
<li>Bits 6-7 of the first octet specify the key use.</li>
<li>Bits 0-5 of the first byte and bits 0-7 of the second specify the key algorithm in network byte order.</li>
</ul>
<t>In the unlikely event that this code space is ever exhausted, allocation of a new UDF type code will be required.</t>
<t>The following key uses are specified:</t>
<table><thead>
<tr>
<th>
Code</th>
<th>
Key Use</th>
</tr>
</thead>
<tbody>
<tr>
<td>
0</td>
<td>
Any</td>
</tr>
<tr>
<td>
1</td>
<td>
Encryption</td>
</tr>
<tr>
<td>
2</td>
<td>
Signature</td>
</tr>
<tr>
<td>
3</td>
<td>
Authentication</td>
</tr>
</tbody>
</table><t></t>
<t>Derivation of key pairs for the following algorithms is specified in this document:</t>
<table><thead>
<tr>
<th>
Code</th>
<th>
Algorithm</th>
<th>
Description</th>
</tr>
</thead>
<tbody>
<tr>
<td>
0</td>
<td>
Any</td>
<td>
Seed MAY be used to generate keypairs for any algorithm</td>
</tr>
<tr>
<td>
1</td>
<td>
X25519</td>
<td>
X25519 keypair as described in RFC7748</td>
</tr>
<tr>
<td>
2</td>
<td>
X448</td>
<td>
X448 keypair as described in RFC7748</td>
</tr>
<tr>
<td>
3</td>
<td>
Ed25519</td>
<td>
Ed25519 keypair as described in RFC8032</td>
</tr>
<tr>
<td>
4</td>
<td>
Ed448</td>
<td>
Ed448 keypair as described in RFC8032</td>
</tr>
<tr>
<td>
5</td>
<td>
P-256</td>
<td>
NIST curve P-256</td>
</tr>
<tr>
<td>
6</td>
<td>
P-384</td>
<td>
NIST curve P-384</td>
</tr>
<tr>
<td>
7</td>
<td>
P-521</td>
<td>
NIST curve P-521</td>
</tr>
<tr>
<td>
8</td>
<td>
RSA-2048</td>
<td>
2048 bit RSA keypair</td>
</tr>
<tr>
<td>
9</td>
<td>
RSA-3072</td>
<td>
3072 bit RSA keypair</td>
</tr>
<tr>
<td>
10</td>
<td>
RSA-4096</td>
<td>
4096 bit RSA keypair</td>
</tr>
</tbody>
</table><t>It is intended that the key derivation mechanism completely specify all parameters of the keypair generated for all key algorithms other than type 0 which is intended for applications where multiple keys are to be generated.</t>
<t>The HKDF function <xref target="RFC5869"></xref> is used to derive key pairs for all the algorithms specified in this document. Derivation functions for additional key algorithms <bcp14>MAY</bcp14> use a different function for this purpose provided that it meets the applicable security requirements.</t>
<t>The HKDF function is specified as a two-step extract-expand process with an optional non-secret value input at both steps. </t>
<section title="Extraction step" anchor="n-extraction-step"><t>The HKDF extraction step calculates a PRK value from a <tt>salt</tt> and <tt>IKM</tt>: </t>
<sourcecode>HKDF-Extract(salt, IKM) -&gt; PRK</sourcecode>
<t>The IKM value is the binary presentation of the complete Binary Data Sequence as originally specified.</t>
<t>The salt value is the 16-bit Key Specifier value specifying the algorithm for which the key pair is to be derived in network byte order. Note that this value <bcp14>MAY</bcp14> differ from the one specified in the Binary Data Sequence by the replacement of algorithm type or key use Any with a specific algorithm or key use.</t>
<t>The output from the extraction step forms the input to the expand step:</t>
<sourcecode>HKDF-Expand(PRK, info, L) -&gt; OKM</sourcecode>
<t>For cases where the key pair generation requires a single parameter, the value <tt>info</tt> is the null string and it suffices to specify the number of bits required and how they are to be used to generate the algorithm parameter.</t>
<t>For cases where the key pair generation requires multiple parameters, a different value of the <tt>info</tt> parameter is required for each.</t>
<t>An X25519 key may be derived as follows: </t>
<sourcecode>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</sourcecode>
<t>Derivation of an X448 key: </t>
<sourcecode>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</sourcecode>
<t>Derivation of an Ed25519 key: </t>
<sourcecode>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</sourcecode>
<t>Derivation of an Ed448 key: </t>
<sourcecode>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</sourcecode>
</section>
<section title="Elliptic Curve Diffie Hellman Key Pairs type 1-4" anchor="n-elliptic-curve-diffie-hellman-key-pairs-type-14-"><t>The generation of key pairs for X25519, X448, Ed25519 and Ed448 is specified in <xref target="RFC7748"></xref> and <xref target="RFC8032"></xref>. 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.</t>
<t>Thus, info is the null string and the value L is specified as follows: </t>
<table><thead>
<tr>
<th>
Algorithm</th>
<th>
L</th>
</tr>
</thead>
<tbody>
<tr>
<td>
X25519</td>
<td>
256</td>
</tr>
<tr>
<td>
X448</td>
<td>
448</td>
</tr>
<tr>
<td>
Ed25519</td>
<td>
256</td>
</tr>
<tr>
<td>
Ed448</td>
<td>
448</td>
</tr>
</tbody>
</table><t></t>
</section>
<section title="Elliptic Curve Diffie Hellman Key Pairs type 5-7" anchor="n-elliptic-curve-diffie-hellman-key-pairs-type-57"><t>The generation of key pairs for the curves P-256, P-384 and P-521 described in <xref target="RFC5903"></xref> 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:</t>
<t>The number of random bits L is given by the following table:</t>
<table><thead>
<tr>
<th>
Algorithm</th>
<th>
L</th>
</tr>
</thead>
<tbody>
<tr>
<td>
P-256</td>
<td>
320</td>
</tr>
<tr>
<td>
P-384</td>
<td>
448</td>
</tr>
<tr>
<td>
p-521</td>
<td>
592</td>
</tr>
</tbody>
</table><t></t>
<t>Note that this rounds up the number of random bits required to the nearest integer multiple of 8.</t>
<t>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 <tt>c</tt>.</t>
<t>The parameter <tt>c</tt> is reduced modulo the value of the prime field <tt>n</tt> to yield the secret scalar value d:</t>
<t>d = (c mod (n?1)) + 1.</t>
<t>A P-256 key may be derived as follows: </t>
<sourcecode>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 =
    82352103978746514619167815909572981157103618409885983602799410986
        678676075099</sourcecode>
<t>Derivation of a P-384 key: </t>
<sourcecode>Fingerprint =
    ZAAA-NPLI-G7Z3-WFD2-GBJ6-OONN-ELTO-MHA

Key =
    36904921143188906308790025170320747449095307663051394962072923012
        683284321458397574918591433311657724460124046828583</sourcecode>
<t>Derivation of a P-521 key: </t>
<sourcecode>Fingerprint =
    ZAAA-PQCC-YFVT-LRWP-7MUZ-GJV3-HLX2-JPQ

Key =
    63465426400294013455234274700017867331515038924288212787589996717
        9893357080737359910264830086847526999862042693445504370476919
        922072068801363203357706689700</sourcecode>
</section>
<section title="RSA Key Pairs" anchor="n-rsa-key-pairs"><t>Generation of RSA key pairs requires two parameters, p, q which are prime. </t>
<table><thead>
<tr>
<th>
Parameter</th>
<th>
Info </th>
<th>
UTF8 equivalent string</th>
</tr>
</thead>
<tbody>
<tr>
<td>
p</td>
<td>
[112] </td>
<td>
"p"</td>
</tr>
<tr>
<td>
q</td>
<td>
[113]</td>
<td>
"q"</td>
</tr>
</tbody>
</table><t></t>
<t>The value of L is the same for generating the OKM values from which q are derived and is determined by the algorithm identifier:</t>
<table><thead>
<tr>
<th>
Algorithm</th>
<th>
L</th>
</tr>
</thead>
<tbody>
<tr>
<td>
RSA-2048</td>
<td>
1024</td>
</tr>
<tr>
<td>
RSA-3072</td>
<td>
1536</td>
</tr>
<tr>
<td>
RSA-4096</td>
<td>
2048</td>
</tr>
</tbody>
</table><t></t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>An RSA-2048 may be derived as follows: </t>
<sourcecode>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 =
    66413758812235725334838013235321881586339612574162219539634589986
        848279686793

Key Q =
    59371323150670971897831168338735525379591827337915650990989572561
        8914057069</sourcecode>
</section>
<section title="Any Key Algorithm" anchor="n-any-key-algorithm"><t>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.</t>
<sourcecode>Fingerprint =
    ZAAA-A6WP-XMGW-FUOF-2T5L-AHNL-FBPY-RSY

To generate an RSA-2048 key

salt =

  00 08

Key P =
    18437770556273302343384069787329923965493769166213940128456164676
        903354830137

Key Q =
    74101698940301025126555268512889815535724251370021060722478350575
        007811846521

To generate an X25519 key

salt =

  00 08

Key =
    System.Byte[]</sourcecode>
</section>
</section>
<section title="Shamir Shared Secret" anchor="n-shamir-shared-secret"><t>The UDF format <bcp14>MAY</bcp14> be used to encode shares generated by a secret sharing mechanism. The only secret sharing mechanism currently supported is the Shamir Secret Sharing mechanism <xref target="Shamir79"></xref>. Each secret share represents a point represents a point <em>on (x, f(x))</em>, a polynomial in a modular field <em>p</em>. The secret being shared is an integer multiple of 32 bits represented by the polynomial value <em>f(0)</em>.</t>
<t>A Shamir Shared Secret Type UDF consists of the type identifier octet 144 followed by the Binary Data Sequence value describing the share value. </t>
<t>The first octet of the Binary Data Sequence value specifies the threshold value and the x value of the particular share:</t>
<ul>
<li>Bits 4-7 of the first byte specify the threshold value.</li>
<li>Bits 0-3 of the first byte specify the x value minus 1.</li>
</ul>
<t>The remaining octets specify the value <em>f(x)</em> in network byte (big-endian) order with leading padding if necessary so that the share has the same number of bytes as the secret.</t>
<t>The algorithm requires that the value <em>p</em> be a prime larger than the integer representing the largest secret being shared. For compactness of representation we chose <em>p</em> to be the smallest prime that is greater than 2<em><sup>n</sup></em> where <em>n</em> is an integer multiple of 32.  This approach leaves a small probability that a set of chosen polynomial parameters cause one or more share values be larger than 2<em><sup>n</sup></em>. Since it is the value of the secret rather than the polynomial parameters that is of important, such parameters <bcp14>MUST NOT</bcp14> be used.</t>
<section title="Secret Generation" anchor="n-secret-generation"><t>To share a secret of <em>L</em> bits with a threshold of <em>n</em> we use a <em>f(x)</em> a polynomial of degree <em>n</em> in the modular field <em>p</em>:</t>
<t>f(x) = a<sub>0</sub> + a<sub>1</sub>.x + a<sub>2</sub>.x<sup>2</sup> + ... a<sub>n</sub>.x<sup>n</sup></t>
<t>where:</t>
<dl>
<dt>L</dt>
<dd>
<t>Is the length of the secret in bits, an integer multiple of 32.</t>
</dd>
<dt>n</dt>
<dd>
<t>Is the threshold, the number of shares required to reconstitute the secret.</t>
</dd>
<dt>a<sub>0</sub></dt>
<dd>
<t>Is the integer representation of the secret to be shared.</t>
</dd>
<dt>a<sub>1</sub> ... a<sub>n</sub></dt>
<dd>
<t>Are randomly chosen integers less than p</t>
</dd>
<dt>p</dt>
<dd>
<t>Is the smallest prime that is greater than 2<sup>L</sup>.</t>
</dd>
</dl>
<t>For L=128, p = 2<sup>128</sup>+51.</t>
<t>The values of the key shares are the values <em>f</em>(1), <em>f</em>(2),...<em> f</em>(n).</t>
<t>The most straightforward approach to generation of Shamir secrets is to generate the set of polynomial coefficients, a<sub>0</sub>, a<sub>1</sub>, ... a<sub>n</sub> and use these to generate the share values <em>f</em>(1), <em>f</em>(2),...<em> f</em>(n). </t>
<t>Note that if this approach is adopted, there is a small probability that one or more of the values <em>f</em>(1), <em>f</em>(2),...<em> f</em>(n) exceeds the range of values supported by the encoding. Should this occur, at least one of the polynomial coefficients <bcp14>MUST</bcp14> be replaced.</t>
<t>An alternative means of generating the set of secrets is to select up to <em>n-1</em> secret share values and use secret recovery to determine at least one additional share. If <em>n</em> shares are selected, the shared secret becomes an output of rather than an input to the process.</t>
</section>
<section title="Recovery" anchor="n-recovery"><t>To recover the value of the shared secret, it is necessary to obtain sufficient shares to meet the threshold and recover the value <em>f(0)</em> = a<sub>0</sub>.</t>
<t>Applications <bcp14>MAY</bcp14> employ any approach that returns the correct result. The use of Lagrange basis polynomials is described in Appendix C.</t>
<t>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. </t>
<sourcecode>Alice's master secret is
  CA 65 A1 30  57 25 91 56  B9 6F 32 D0  17 F0 A2 5A</sourcecode>
<t>This has the UDF representation: </t>
<t>EDFG-LIJQ-K4SZ-CVVZ-N4ZN-AF7Q-UJNA </t>
<t>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. </t>
<t>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: </t>
<sourcecode>a0 = 269031746429133624973381789488312787546
a1 = 322115533094025657321906342357735266839
a2 = 32658764136027301650768999736923473956</sourcecode>
<t>The master secret is the value f(0) = a0. The key shares are the values f(1), f(2)...f(5): </t>
<sourcecode>f(1) = 283523676738248120482682524151203316834
f(2) = 23050768398478755830146650856172582527
f(3) = 168177755251702457942523384466757007639
f(4) = 38339903456042299893063510119420169156
f(5) = 314101946853375208608516242677698490092</sourcecode>
<t>The first byte of each share specifies the recovery information (quorum, x value), the remaining bytes specify the share value in network byte order: </t>
<sourcecode>f(1) =
  30 D5 4C AC  84 88 7E AF  0F 3C E4 8B  92 BC 61 44
  62
f(2) =
  31 11 57 6A  A0 65 D7 A1  45 95 07 AE  BC D2 44 76
  7F
f(3) =
  32 7E 85 DB  83 EF 30 67  F9 C1 D8 9C  4E 59 9A 39
  17
f(4) =
  33 1C D7 FF  2F 24 89 03  2B C3 57 54  47 52 62 8B
  C4
f(5) =
  34 EC 4D D5  A2 05 E1 72  DB 99 83 D6  A7 BC 9D 6E
  EC</sourcecode>
<t>The UDF presentation of the key shares is thus: </t>
<sourcecode>f(1) = SAYN-KTFM-QSEH-5LYP-HTSI-XEV4-MFCG-E
f(2) = SAYR-CV3K-UBS5-PIKF-SUD2-5PGS-IR3H-6
f(3) = SAZH-5BO3-QPXT-AZ7Z-YHMJ-YTSZ-TI4R-O
f(4) = SAZR-ZV77-F4SI-SAZL-YNLV-IR2S-MKF4-I
f(5) = SA2O-YTOV-UIC6-C4W3-TGB5-NJ54-TVXO-Y</sourcecode>
<t>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. </t>
</section>
</section>
</section>
<section title="Variable Length UDFs" anchor="n-variable-length-udfs-"><t>Variable length UDFs are used to represent fingerprint values calculated over a content type identifier and the cryptographic digest of a content data item. The fingerprint value <bcp14>MAY</bcp14> be specified at any integer multiple of 20 bits that provides a work factor sufficient for the intended purpose.</t>
<t>Two types of fingerprint are specified:</t>
<dl>
<dt>Digest fingerprints </dt>
<dd>
<t>Are computed with the same cryptographic digest algorithm used to calculate the digest of the content data.</t>
</dd>
<dt>Message Authentication Code fingerprints</dt>
<dd>
<t>Are computed using a Message Authentication Code.</t>
</dd>
</dl>
<t>For a given algorithm (and key, if requires), if two UDF fingerprints are of the same content data and content type, either the fingerprint values will be the same or the initial characters of one will be exactly equal to the other.</t>
<section title="Content Digest" anchor="n-content-digest"><t>A Content Digest Type UDF consists of the type identifier octet followed by the Binary Data Sequence value.</t>
<t>The type identifier specifies the digest algorithm used and the compression level. Two digest algorithms are currently specified with four compression levels for each making a total of eight possible type identifiers.</t>
<t>The Content Digest UDF for given content data is generated by the steps of:</t>
<ol start="0">
<li>Applying the digest algorithm to determine the Content Digest Value</li>
<li>Applying the digest algorithm to determine the Typed Content Digest Value</li>
<li>Determining the compression level from bytes 0-3 of the Typed Content Digest Value.</li>
<li>Determining the Type Identifier octet from the Digest algorithm identifier and compression level.</li>
<li>Truncating bytes 4-63 of the Typed Content Digest Value to determine the Binary Data Sequence value.</li>
</ol>
<section title="Content Digest Value" anchor="n-content-digest-value"><t>The Content Digest Value (CDV) is determined by applying the digest algorithm to the content data:</t>
<sourcecode>CDV = H(&lt;Data&gt;)</sourcecode>
<t>Where</t>
<dl>
<dt></dt>
<dd>
<t>H(x) is the cryptographic digest function</t>
<t>&lt;Data&gt; is the binary data.</t>
</dd>
</dl>
</section>
<section title="Typed Content Digest Value" anchor="n-typed-content-digest-value"><t>The Typed Content Digest Value (TCDV) is determined by applying the digest algorithm to the content type identifier and the CDV:</t>
<sourcecode>TCDV = H (&lt;Content-ID&gt; + ?:? + CDV)</sourcecode>
<t>Where</t>
<dl>
<dt></dt>
<dd>
<t>A + B represents concatenation of the binary sequences A and B.</t>
<t>&lt;Content-ID&gt; is the IANA Content Type of the data in UTF8 encoding</t>
</dd>
</dl>
<t>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.</t>
</section>
<section title="Content Digest Compression" anchor="n-content-digest-compression"><t>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:</t>
<dl>
<dt>19 or fewer leading zero bits</dt>
<dd>
<t>Compression factor = 0</t>
</dd>
<dt>29 or fewer leading zero bits</dt>
<dd>
<t>Compression factor = 20</t>
</dd>
<dt>39 or fewer leading zero bits</dt>
<dd>
<t>Compression factor = 30</t>
</dd>
<dt>49 or fewer leading zero bits</dt>
<dd>
<t>Compression factor = 40</t>
</dd>
<dt>50 or more leading zero bits</dt>
<dd>
<t>Compression factor = 50</t>
</dd>
</dl>
<t>The least significant bits of each octet are regarded to be 'trailing'.</t>
<t>Applications <bcp14>MUST</bcp14> use compression when creating and comparing UDFs. Applications <bcp14>MAY</bcp14> support content generation techniques that search for UDF values that use a compressed representation. Presentation of a content digest value indicating use of compression <bcp14>MAY</bcp14> be used as an indicator of 'proof of work'.</t>
</section>
<section title="Content Digest Presentation" anchor="n-content-digest-presentation"><t>The type identifier is determined by the algorithm and compression factor as follows:</t>
<table><thead>
<tr>
<th>
Type ID</th>
<th>
Initial</th>
<th>
Algorithm</th>
<th>
Compression</th>
</tr>
</thead>
<tbody>
<tr>
<td>
80</td>
<td>
K</td>
<td>
SHA-3-512</td>
<td>
0</td>
</tr>
<tr>
<td>
81</td>
<td>
K</td>
<td>
SHA-3-512</td>
<td>
20</td>
</tr>
<tr>
<td>
82</td>
<td>
K</td>
<td>
SHA-3-512</td>
<td>
30</td>
</tr>
<tr>
<td>
83</td>
<td>
K</td>
<td>
SHA-3-512</td>
<td>
40</td>
</tr>
<tr>
<td>
84</td>
<td>
K</td>
<td>
SHA-3-512</td>
<td>
50</td>
</tr>
<tr>
<td>
96</td>
<td>
M</td>
<td>
SHA-2-512</td>
<td>
0</td>
</tr>
<tr>
<td>
97</td>
<td>
M</td>
<td>
SHA-2-512</td>
<td>
20</td>
</tr>
<tr>
<td>
98</td>
<td>
M</td>
<td>
SHA-2-512</td>
<td>
30</td>
</tr>
<tr>
<td>
99</td>
<td>
M</td>
<td>
SHA-2-512</td>
<td>
40</td>
</tr>
<tr>
<td>
100</td>
<td>
M</td>
<td>
SHA-2-512</td>
<td>
50</td>
</tr>
</tbody>
</table><t>The Binary Data Sequence value is taken from the Typed Content Digest Value starting at the 9<sup>th</sup> octet and as many additional bytes as are required to meet the presentation precision.</t>
</section>
<section title="Example Encoding" anchor="n-example-encoding"><t>In the following examples, &lt;Content-ID&gt; is the UTF8 encoding of the string  "text/plain" and &lt;Data&gt; is the UTF8 encoding of the string "UDF Data Value" </t>
<sourcecode>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</sourcecode>
</section>
<section title="Using SHA-2-512 Digest" anchor="n-using-sha2512-digest-"><sourcecode>H(&lt;Data&gt;) =
  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

&lt;Content-ID&gt; + ':' + H(&lt;Data&gt;) =
  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(&lt;Content-ID&gt; + ':' + H(&lt;Data&gt;)) =
  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</sourcecode>
<t>The 125 bit fingerprint value is MDDK-7N6A-727A-JZNO-STRX-XKS7-DJAF </t>
<t>This fingerprint MAY be specified with higher or lower precision as appropriate. </t>
<dl>
<dt>100 bit precision </dt>
<dd>
<t>MDDK-7N6A-727A-JZNO-STRX </t>
</dd>
<dt>120 bit precision </dt>
<dd>
<t>MDDK-7N6A-727A-JZNO-STRX-XKS7 </t>
</dd>
<dt>200 bit precision </dt>
<dd>
<t>MDDK-7N6A-727A-JZNO-STRX-XKS7-DJAF-XI6O-ZSLU-2VOA </t>
</dd>
<dt>260 bit precision </dt>
<dd>
<t>MDDK-7N6A-727A-JZNO-STRX-XKS7-DJAF-XI6O-ZSLU-2VOA-TZQ6-JMHP-TSXP  </t>
</dd>
</dl>
</section>
<section title="Using SHA-3-512 Digest" anchor="n-using-sha3512-digest-"><sourcecode>H(&lt;Data&gt;) =
  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

&lt;Content-ID&gt; + ':' + H(&lt;Data&gt;) =
  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(&lt;Content-ID&gt; + ':' + H(&lt;Data&gt;)) =
  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</sourcecode>
<t>The 125 bit fingerprint value is KCFI-NCQG-DRKG-47R7-OVPT-TCHZ-7UXY </t>
</section>
<section title="Using SHA-2-512 Digest with Compression" anchor="n-using-sha2512-digest-with-compression--"><t>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: </t>
<sourcecode>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"</sourcecode>
<t>The UTF8 Content Digest is given as: </t>
<sourcecode>H(&lt;Data&gt;) =
  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

&lt;Content-ID&gt; + ':' + H(&lt;Data&gt;) =
  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(&lt;Content-ID&gt; + ':' + H(&lt;Data&gt;)) =
  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</sourcecode>
<t>The 125 bit fingerprint value is MGHB-JWIZ-J3LA-EEWD-GCT3-WX6H-C5W2 </t>
</section>
<section title="Using SHA-3-512 Digest with Compression" anchor="n-using-sha3512-digest-with-compression--"><t>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: </t>
<sourcecode>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</sourcecode>
<t>The UTF8 SHA-3-512 Content Digest is KEJI-Y225-BDUG-XX22-MXKE-5ITF-YVYM </t>
</section>
</section>
<section title="Authenticator UDF" anchor="n-authenticator-udf"><t>An authenticator Type UDF consists of the type identifier octet followed by the Binary Data Sequence value.</t>
<t>The type identifier specifies the digest and Message Authentication Code algorithm. Two algorithm suites are currently specified. Use of compression is not supported.</t>
<t>The Authenticator UDF for given content data and key is generated by the steps of:</t>
<ol start="0">
<li>Applying the digest algorithm to determine the Content Digest Value</li>
<li>Applying the MAC algorithm to determine the Authentication value</li>
<li>Determining the Type Identifier octet from the Digest algorithm identifier and compression level.</li>
<li>Truncating the Authentication value to determine the Binary Data Sequence value.</li>
</ol>
<t>The key used to calculate and Authenticator type UDF is always a UNICODE string. If use of a binary value as a key is required, the value <bcp14>MUST</bcp14> be converted to a string format first. For example, by conversion to an Encryption/Authentication type UDF.</t>
<section title="Authentication Content Digest Value" anchor="n-authentication-content-digest-value"><t>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:</t>
<sourcecode>CDV = H(&lt;Data&gt;))</sourcecode>
<t>Where</t>
<dl>
<dt></dt>
<dd>
<t>H(x) is the cryptographic digest function</t>
<t>&lt;Data&gt; is the binary data.</t>
</dd>
</dl>
</section>
<section title="Authentication Value" anchor="n-authentication-value"><t>The Authentication Value (AV) is determined by applying the digest algorithm to the content type identifier and the CDV:</t>
<sourcecode>AV = MAC (&lt;OKM&gt;, (&lt;Content-ID&gt; + ?:? + CDV))</sourcecode>
<t>Where</t>
<dl>
<dt></dt>
<dd>
<t>&lt;OKM&gt; is the authentication key as specified below</t>
<t>MAC( &lt;Key&gt;, &lt;data&gt;) is the result of applying the Message Authentication Code algorithm to with Key &lt;Key&gt; and data &lt;data&gt;</t>
</dd>
</dl>
<t>The value &lt;OKM&gt; is calculated as follows:</t>
<sourcecode>IKM = UTF8 (Key)
PRK = MAC (UTF8 ("KeyedUDFMaster"), IKM)
OKM = HKDF-Expand(PRK, UTF8 ("KeyedUDFExpand"), HashLen)</sourcecode>
<t>Where the function UTF8(string) converts a string to the binary UTF8 representation, HKDF-Expand is as defined in <xref target="RFC5869"></xref> and the function MAC(k,m) is the HMAC function formed from the specified hash H(m) as specified in <xref target="RFC2014"></xref>. </t>
<t>Keyed UDFs are typically used in circumstances where user interaction requires a cryptographic commitment type functionality </t>
<t>In the following example, &lt;Content-ID&gt; is the UTF8 encoding of the string  "text/plain" and &lt;Data&gt; is the UTF8 encoding of the string "Konrad is the traitor". The randomly chosen key is NDD7-6CMX-H2FW-ISAL-K4VB-DQ3E-PEDM. </t>
<sourcecode>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</sourcecode>
<t>Processing is performed in the same manner as an unkeyed fingerprint except that compression is never used: </t>
<sourcecode>H(&lt;Data&gt;) =
  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

&lt;Content-ID&gt; + ':' + H(&lt;Data&gt;) =
  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(&lt;key&gt;, &lt;Content-ID&gt; + ':' + H(&lt;Data&gt;)) =
  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</sourcecode>
<t>The 125 bit fingerprint value is ABGM-G76T-7GPF-FTYH-SB2F-HBDF-SW6B </t>
</section>
</section>
<section title="Content Type Values" anchor="n-content-type-values"><t>While a UDF fingerprint <bcp14>MAY</bcp14> be used to identify any form of static data, the use of a UDF fingerprint to identify a public key signature key provides a level of indirection and thus the ability to identify dynamic data. The content types used to identify public keys are thus of particular interest.</t>
<t>As described in the security considerations section, the use of fingerprints to identify a bare public key and the use of fingerprints to identify a public key and associated security policy information are very different.</t>
<section title="PKIX Certificates and Keys" anchor="n-pkix-certificates-and-keys"><t>UDF fingerprints <bcp14>MAY</bcp14> be used to identify PKIX certificates, CRLs and public keys in the ASN.1 encoding used in PKIX certificates.</t>
<t>Since PKIX certificates and CLRs contain security policy information, UDF fingerprints used to identify certificates or CRLs <bcp14>SHOULD</bcp14> be presented with a minimum of 200 bits of precision. PKIX applications <bcp14>MUST</bcp14> not accept UDF fingerprints specified with less than 200 bits of precision for purposes of identifying trust anchors.</t>
<t>PKIX certificates, keys and related content data are identified by the following content types:</t>
<dl>
<dt>application/pkix-cert</dt>
<dd>
<t>A PKIX Certificate</t>
</dd>
<dt>application/pkix-crl</dt>
<dd>
<t>A PKIX CRL</t>
</dd>
<dt>application/pkix-keyinfo</dt>
<dd>
<t>The SubjectPublicKeyInfo  structure defined in the PKIX certificate specification encoded using DER encoding rules.</t>
</dd>
</dl>
<t>The SubjectPublicKeyInfo  structure is defined in <xref target="RFC5280"></xref> as follows:</t>
<sourcecode>   SubjectPublicKeyInfo  ::=  SEQUENCE  {
        algorithm            AlgorithmIdentifier,
        subjectPublicKey     BIT STRING  }</sourcecode>
<t>This schema results in an identical DER encoding to the <tt>OIDInfo</tt> sequence specified in section XXX. The distinction between these productions is that the <tt>OIDInfo</tt> 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.</t>
</section>
<section title="OpenPGP Key" anchor="n-openpgp-key"><t>OpenPGPv5 keys and key set content data are identified by the following content type:</t>
<dl>
<dt>application/pgp-keys</dt>
<dd>
<t>An OpenPGP key set.</t>
</dd>
</dl>
</section>
<section title="DNSSEC" anchor="n-dnssec"><t>DNSSEC record data consists of DNS records which are identified by the following content type:</t>
<dl>
<dt>application/dns</dt>
<dd>
<t>A DNS resource record in binary format</t>
</dd>
</dl>
</section>
</section>
</section>
<section title="UDF URIs" anchor="n-udf-uris"><t>The UDF URI scheme describes a means of constructing URIs from a UDF value. </t>
<t>Two forms or UDF URI are specified, Name and Locator. In both cases the URI <bcp14>MUST</bcp14> specify the scheme type "<tt>UDF</tt>", and a UDF fingerprint and <bcp14>MAY</bcp14> specify a query identifier and/or a fragment identifier.</t>
<t>By definition a Locator form URI contains an <tt>authority</tt> field which <bcp14>MUST</bcp14> be a DNS domain name. The use of IP address forms for this purpose is not permitted.</t>
<t>Name Form URIs allow static content data to be identified without specifying the means by which the content data may be retrieved. Locator form URIs allow static content data or dynamic network resources to be identified and the means of retrieval.</t>
<t>The syntax of a UDF URI is a subset of the generic URI syntax specified in <xref target="RFC3986"></xref>. The use of userinfo and port numbers is not supported and the path part of the uri is a UDF in base32 presentation.</t>
<sourcecode>URI           = "UDF:" udf [ "?" query ] [ "" fragment ]

udf           = name-form / locator-form

name-form     = udf-value
locator-form  = "//" authority "/" udf-value

authority     = host
host          = reg-name</sourcecode>
<section title="Name form URI" anchor="n-name-form-uri"><t>Name form UDF URIs provide a means of presenting a UDF value in a context in which a URI form of a name is required without providing a means of resolution. </t>
<t>Adding the UDF scheme prefix to a UDF fingerprint does not change the semantics of the fingerprint itself. The semantics of the name result from the context in which it is used.</t>
<t>For example, a UDF value of any type <bcp14>MAY</bcp14> be used to give a unique targetNamespace value in an XML Schema <xref target="XMLSchema"></xref></t>
</section>
<section title="Locator form URI" anchor="n-locator-form-uri"><t>The locator form of an unkeyed UDF URI is resolved by the following steps:</t>
<ul>
<li>Use DNS Web service discovery to determine the Web Service Endpoint.</li>
<li>Determine the content identifier from the source URI.</li>
<li>Append the content identifier to the Web Service Endpoint as a suffix to form the target URI.</li>
<li>Retrieve content from the Web Service Endpoint by means of a GET method.</li>
<li>Perform post processing as specified by the UDF type.</li>
</ul>
<section title="DNS Web service discovery" anchor="n-dns-web-service-discovery"><t>DNS Web Discovery is performed as specified in <xref target="draft-hallambaker-web-service-discovery"></xref> for the service <tt>mmm-udf</tt> and domain name specified in the URI. For a full description of the discovery mechanism, consult the referenced specification.</t>
<t>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 <xref target="RFC6763"></xref>.</t>
<t>If no SRV or TXT records are specified, DNS Web Discovery specifies that the Web Service Endpoint be the Well Known Service <xref target="RFC5785"></xref> with the prefix <tt>/.well-known/srv/mmm-udf.</tt></t>
</section>
<section title="Content Identifier" anchor="n-content-identifier"><t>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.</t>
<t>If the UDF is of type Secret Share, the shared secret <bcp14>MUST</bcp14> 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.</t>
</section>
<section title="Target URI" anchor="n-target-uri"><t>The target URI is formed by appending a slash separator '/' and the Content Identifier value to the Web Service Endpoint.</t>
<t>Since the path portion of a URI is case sensitive, the UDF value <bcp14>MUST</bcp14> be specified in upper case and <bcp14>MUST</bcp14> include separator marks.</t>
</section>
<section title="Postprocessing" anchor="n-postprocessing"><t>After retrieving the content data, the resolver <bcp14>MUST</bcp14> perform post processing as indicated by the content type:</t>
<dl>
<dt>Nonce</dt>
<dd>
<t>No additional post processing is required.</t>
</dd>
<dt>Content Digest</dt>
<dd>
<t>The resolver <bcp14>MUST</bcp14> verify that the content returned matches the UDF fingerprint value.</t>
</dd>
<dt>Authenticator</dt>
<dd>
<t>The resolver <bcp14>MUST</bcp14> verify that the content returned matches the UDF fingerprint value.</t>
</dd>
<dt>Encryption/Authentication </dt>
<dd>
<t>The content data returned is decrypted and authenticated using the key specified in the UDF value as the initial keying material (see below).</t>
</dd>
<dt>Secret Share (set)</dt>
<dd>
<t>The content data returned is decrypted and authenticated using the shared secret as the initial keying material (see below).</t>
</dd>
</dl>
</section>
<section title="Decryption and Authentication" anchor="n-decryption-and-authentication"><t>The steps performed to decode cryptographically enhanced content data depends on the content type specified in the returned content. Two formats are currently supported:</t>
<ul>
<li>DARE Envelope format as specified in <xref target="draft-hallambaker-mesh-dare"></xref></li>
<li>Cryptographic Message Syntax (CMS) Symmetric Key Package as specified in <xref target="RFC6031"></xref></li>
</ul>
</section>
<section title="QR Presentation" anchor="n-qr-presentation"><t>Encoding of a UDF URI as a QR code requires only the characters in alphanumeric encoding, thus achieving compactness with minimal overhead.</t>
</section>
</section>
</section>
<section title="Strong Internet Names" anchor="n-strong-internet-names"><t>A Strong Internet Name is an Internet address that is bound to a policy governing interpretation of that address by means of a Content Digest type UDF of the policy expressed as a UDF prefixed DNS label within the address itself.</t>
<t>The Reserved LDH labels as defined in <xref target="RFC5890"></xref> that begin with the prefix <tt>mm--</tt> are reserved for use as Strong Internet Names. The characters following the prefix are a Content Digest type UDF in Base32 presentation.</t>
<t>Since DNS labels are limited to 63 characters, the presentation of the SIN itself is limited to 59 characters and thus 240 bits of precision. </t>
</section>
<section title="Security Considerations" anchor="n-security-considerations"><t>This section describes security considerations arising from the use of UDF in general applications.</t>
<t>Additional security considerations for use of UDFs in Mesh services and applications are described in the Mesh Security Considerations guide <xref target="draft-hallambaker-mesh-security"></xref>.</t>
<section title="Confidentiality" anchor="n-confidentiality"><t>Encrypted locator is a bearer token</t>
</section>
<section title="Availability" anchor="n-availability"><t>Corruption of a part of a shared secret may prevent recovery</t>
</section>
<section title="Integrity" anchor="n-integrity"><t>Shared secret parts do not contain context information to specify which secret they relate to.</t>
</section>
<section title="Work Factor and Precision" anchor="n-work-factor-and-precision"><t>A given UDF data object has a single fingerprint value that may be presented at different precisions. The shortest legitimate precision with which a UDF fingerprint may be presented has 96 significant bits</t>
<t>A UDF fingerprint presents the same work factor as any other cryptographic digest function. The difficulty of finding a second data item that matches a given fingerprint is 2^n and the difficulty or finding two data items that have the same fingerprint is 2^(n/2). Where n is the precision of the fingerprint.</t>
<t>For the algorithms specified in this document, n = 512 and thus the work factor for finding collisions is 2^256, a value that is generally considered to be computationally infeasible.</t>
<t>Since the use of 512 bit fingerprints is impractical in the type of applications where fingerprints are generally used, truncation is a practical necessity. The longer a fingerprint is, the less likely it is that a user will check every character. It is therefore important to consider carefully whether the security of an application depends on second pre-image resistance or collision resistance.</t>
<t>In most fingerprint applications, such as the use of fingerprints to identify public keys, the fact that a malicious party might generate two keys that have the same fingerprint value is a minor concern. Combined with a flawed protocol architecture, such a vulnerability may permit an attacker to construct a document such that the signature will be accepted as valid by some parties but not by others.</t>
<t>For example, Alice generates keypairs until two are generated that have the same 100 bit UDF presentation (typically 2^48 attempts). She registers one keypair with a merchant and the other with her bank. This allows Alice to create a payment instrument that will be accepted as valid by one and rejected by the other.</t>
<t>The ability to generate of two PKIX certificates with the same fingerprint and different certificate attributes raises very different and more serious security concerns. For example, an attacker might generate two certificates with the same key and different use constraints. This might allow an attacker to present a highly constrained certificate that does not present a security risk to an application for purposes of gaining approval and an unconstrained certificate to request a malicious action.</t>
<t>In general, any use of fingerprints to identify data that has security policy semantics requires the risk of collision attacks to be considered. For this reason, the use of short, 'user friendly' fingerprint presentations (Less than 200 bits) <bcp14>SHOULD</bcp14> only be used for public key values.</t>
</section>
<section title="Semantic Substitution" anchor="n-semantic-substitution"><t>Many applications record the fact that a data item is trusted, rather fewer record the circumstances in which the data item is trusted. This results in a semantic substitution vulnerability which an attacker may exploit by presenting the trusted data item in the wrong context.</t>
<t>The UDF format provides protection against high level semantic substitution attacks by incorporating the content type into the input to the outermost fingerprint digest function. The work factor for generating a UDF fingerprint that is valid in both contexts is thus the same as the work factor for finding a second preimage in the digest function (2^512 for the specified digest algorithms). </t>
<t>It is thus infeasible to generate a data item such that some applications will interpret it as a PKIX key and others will accept as an OpenPGP key. While attempting to parse a PKIX key as an OpenPGP key is virtually certain to fail to return the correct key parameters it cannot be assumed that the attempt is guaranteed to fail with an error message.</t>
<t>The UDF format does not provide protection against semantic substitution attacks that do not affect the content type.  </t>
</section>
<section title="QR Code Scanning" anchor="n-qr-code-scanning"><t>The act of scanning a QR code <bcp14>SHOULD</bcp14> be considered equivalent to clicking on an unlabeled hypertext link. Since QR codes are scanned in many different contexts, the mere act of scanning a QR code <bcp14>MUST NOT</bcp14> be interpreted as constituting an affirmative acceptance of terms or conditions or as creating an electronic signature.</t>
<t>If such semantics are required in the context of an application, these <bcp14>MUST</bcp14> be established by secondary user actions made subsequent to the scanning of the QR code. </t>
<t>There is a risk that use of QR codes to automate processes such as payment will lead to abusive practices such as presentation of fraudulent invoices for goods not ordered or delivered. It is therefore important to ensure that such requests are subject to adequate accountability controls. </t>
</section>
</section>
<section title="IANA Considerations" anchor="n-iana-considerations"><t>Registrations are requested in the following registries:</t>
<ul>
<li>Service Name and Transport Protocol Port Number</li>
<li>well-known URI registry</li>
<li>Uniform Resource Identifier (URI) Schemes</li>
<li>Media Types</li>
</ul>
<t>In addition, the creation of the following registry is requested: Uniform Data Fingerprint Type Identifier Registry.</t>
<section title="Protocol Service Name" anchor="n-protocol-service-name"><t>The following registration is requested in the Service Name and Transport Protocol Port Number Registry in accordance with <xref target="RFC6355"></xref></t>
<dl>
<dt>Service Name (<bcp14>REQUIRED</bcp14>)</dt>
<dd>
<t>mmm-udf</t>
</dd>
<dt>Transport Protocol(s) (<bcp14>REQUIRED</bcp14>)</dt>
<dd>
<t>TCP</t>
</dd>
<dt>Assignee (<bcp14>REQUIRED</bcp14>)</dt>
<dd>
<t>Phillip Hallam-Baker, phill@hallambaker.com</t>
</dd>
<dt>Contact (<bcp14>REQUIRED</bcp14>)</dt>
<dd>
<t>Phillip Hallam-Baker, phill@hallambaker.com</t>
</dd>
<dt>Description (<bcp14>REQUIRED</bcp14>)</dt>
<dd>
<t>mmm-udf is a Web Service protocol that resolves Mathematical Mesh Uniform Data Fingerprints (UDF) to resources. The mmm-udf service name is used in service discovery to identify a Web Service endpoint to perform resolution of a UDF presented in URI locator form.</t>
</dd>
<dt>Reference (<bcp14>REQUIRED</bcp14>)</dt>
<dd>
<t>[This document]</t>
</dd>
<dt>Port Number (<bcp14>OPTIONAL</bcp14>)</dt>
<dd>
<t>None</t>
</dd>
<dt>Service Code (<bcp14>REQUIRED</bcp14> for DCCP only)</dt>
<dd>
<t>None</t>
</dd>
<dt>Known Unauthorized Uses (<bcp14>OPTIONAL</bcp14>)</dt>
<dd>
<t>None</t>
</dd>
<dt>Assignment Notes (<bcp14>OPTIONAL</bcp14>)</dt>
<dd>
<t>None</t>
</dd>
</dl>
</section>
<section title="Well Known" anchor="n-well-known"><t>The following registration is requested in the well-known URI registry in accordance with <xref target="RFC5785"></xref></t>
<dl>
<dt>URI suffix</dt>
<dd>
<t>srv/mmm-udf</t>
</dd>
<dt>Change controller</dt>
<dd>
<t>Phillip Hallam-Baker, phill@hallambaker.com</t>
</dd>
<dt>Specification document(s):</dt>
<dd>
<t>[This document]</t>
</dd>
<dt>Related information</dt>
<dd>
</dd>
</dl>
<t><xref target="draft-hallambaker-web-service-discovery"></xref></t>
</section>
<section title="URI Registration" anchor="n-uri-registration"><t>The following registration is requested in the Uniform Resource Identifier (URI) Schemes registry in accordance with <xref target="RFC7595"></xref></t>
<dl>
<dt>Scheme name:</dt>
<dd>
<t>UDF</t>
</dd>
<dt>Status:</dt>
<dd>
<t>Provisional</t>
</dd>
<dt>Applications/protocols that use this scheme name:</dt>
<dd>
<t>Mathematical Mesh Service protocols (mmm)</t>
</dd>
<dt>Contact:</dt>
<dd>
<t>Phillip Hallam-Baker mailto:phill@hallambaker.com</t>
</dd>
<dt>Change controller:</dt>
<dd>
<t>Phillip Hallam-Baker</t>
</dd>
<dt>References:</dt>
<dd>
<t>[This document]</t>
</dd>
</dl>
</section>
<section title="Media Types Registrations" anchor="n-media-types-registrations"><section title="Media Type: application/pkix-keyinfo" anchor="n-media-type-applicationpkixkeyinfo"><dl>
<dt>Type name:</dt>
<dd>
<t>application</t>
</dd>
<dt>Subtype name:</dt>
<dd>
<t>pkix-keyinfo</t>
</dd>
<dt>Required parameters:</dt>
<dd>
<t>None</t>
</dd>
<dt>Optional parameters:</dt>
<dd>
<t>None</t>
</dd>
<dt>Encoding considerations:</dt>
<dd>
<t>Binary</t>
</dd>
<dt>Security considerations:</dt>
<dd>
<t>Described in [This]</t>
</dd>
<dt>Interoperability considerations:</dt>
<dd>
<t>None</t>
</dd>
<dt>Published specification:</dt>
<dd>
<t>[This]</t>
</dd>
<dt>Applications that use this media type:</dt>
<dd>
<t>Uniform Data Fingerprint</t>
</dd>
<dt>Fragment identifier considerations:</dt>
<dd>
<t>None</t>
</dd>
<dt>Additional information:</dt>
<dd>
<t>Deprecated alias names for this type: None</t>
<t>Magic number(s): None</t>
<t>File extension(s): None</t>
<t>Macintosh file type code(s): None</t>
</dd>
<dt>Person &amp; email address to contact for further information:</dt>
<dd>
<t>Phillip Hallam-Baker @hallambaker.com&gt;</t>
</dd>
<dt>Intended usage:</dt>
<dd>
<t>Content type identifier to be used in constructing UDF Content Digests and Authenticators and related cryptographic purposes.</t>
</dd>
<dt>Restrictions on usage:</dt>
<dd>
<t>None</t>
</dd>
<dt>Author:</dt>
<dd>
<t>Phillip Hallam-Baker</t>
</dd>
<dt>Change controller:</dt>
<dd>
<t>Phillip Hallam-Baker</t>
</dd>
<dt>Provisional registration? (standards tree only):</dt>
<dd>
<t>Yes</t>
</dd>
</dl>
</section>
<section title="Media Type: application/udf-encryption" anchor="n-media-type-applicationudfencryption"><dl>
<dt>Type name:</dt>
<dd>
<t>application</t>
</dd>
<dt>Subtype name:</dt>
<dd>
<t>udf-encryption</t>
</dd>
<dt>Required parameters:</dt>
<dd>
<t>None</t>
</dd>
<dt>Optional parameters:</dt>
<dd>
<t>None</t>
</dd>
<dt>Encoding considerations:</dt>
<dd>
<t>None</t>
</dd>
<dt>Security considerations:</dt>
<dd>
<t>Described in [This]</t>
</dd>
<dt>Interoperability considerations:</dt>
<dd>
<t>None</t>
</dd>
<dt>Published specification:</dt>
<dd>
<t>[This]</t>
</dd>
<dt>Applications that use this media type:</dt>
<dd>
<t>Uniform Data Fingerprint</t>
</dd>
<dt>Fragment identifier considerations:</dt>
<dd>
<t>None</t>
</dd>
<dt>Additional information:</dt>
<dd>
<t>Deprecated alias names for this type: None</t>
<t>Magic number(s): None</t>
<t>File extension(s): None</t>
<t>Macintosh file type code(s): None</t>
</dd>
<dt>Person &amp; email address to contact for further information:</dt>
<dd>
<t>Phillip Hallam-Baker @hallambaker.com&gt;</t>
</dd>
<dt>Intended usage:</dt>
<dd>
<t>Content type identifier to be used in constructing UDF Content Digests and Authenticators and related cryptographic purposes.</t>
</dd>
<dt>Restrictions on usage:</dt>
<dd>
<t>None</t>
</dd>
<dt>Author:</dt>
<dd>
<t>Phillip Hallam-Baker</t>
</dd>
<dt>Change controller:</dt>
<dd>
<t>Phillip Hallam-Baker</t>
</dd>
<dt>Provisional registration? (standards tree only):</dt>
<dd>
<t>Yes</t>
</dd>
</dl>
</section>
<section title="Media Type: application/udf-secret" anchor="n-media-type-applicationudfsecret"><dl>
<dt>Type name:</dt>
<dd>
<t>application</t>
</dd>
<dt>Subtype name:</dt>
<dd>
<t>udf- secret</t>
</dd>
<dt>Required parameters:</dt>
<dd>
<t>None</t>
</dd>
<dt>Optional parameters:</dt>
<dd>
<t>None</t>
</dd>
<dt>Encoding considerations:</dt>
<dd>
<t>None</t>
</dd>
<dt>Security considerations:</dt>
<dd>
<t>Described in [This]</t>
</dd>
<dt>Interoperability considerations:</dt>
<dd>
<t>None</t>
</dd>
<dt>Published specification:</dt>
<dd>
<t>[This]</t>
</dd>
<dt>Applications that use this media type:</dt>
<dd>
<t>Uniform Data Fingerprint</t>
</dd>
<dt>Fragment identifier considerations:</dt>
<dd>
<t>None</t>
</dd>
<dt>Additional information:</dt>
<dd>
<t>Deprecated alias names for this type: None</t>
<t>Magic number(s): None</t>
<t>File extension(s): None</t>
<t>Macintosh file type code(s): None</t>
</dd>
<dt>Person &amp; email address to contact for further information:</dt>
<dd>
<t>Phillip Hallam-Baker @hallambaker.com&gt;</t>
</dd>
<dt>Intended usage:</dt>
<dd>
<t>Content type identifier to be used in constructing UDF Content Digests and Authenticators and related cryptographic purposes.</t>
</dd>
<dt>Restrictions on usage:</dt>
<dd>
<t>None</t>
</dd>
<dt>Author:</dt>
<dd>
<t>Phillip Hallam-Baker</t>
</dd>
<dt>Change controller:</dt>
<dd>
<t>Phillip Hallam-Baker</t>
</dd>
<dt>Provisional registration? (standards tree only):</dt>
<dd>
<t>Yes</t>
</dd>
</dl>
</section>
</section>
<section title="Uniform Data Fingerprint Type Identifier Registry" anchor="n-uniform-data-fingerprint-type-identifier-registry"><t>This document describes a new extensible data format employing fixed length version identifiers for UDF types.</t>
<section title="The name of the registry" anchor="n-the-name-of-the-registry"><t>Uniform Data Fingerprint Type Identifier Registry</t>
</section>
<section title="Required information for registrations" anchor="n-required-information-for-registrations"><t>Registrants must specify the Type identifier code(s) requested, description and RFC number for the corresponding standards action document.</t>
<t>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. </t>
<t>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.</t>
</section>
<section title="Applicable registration policy" anchor="n-applicable-registration-policy"><t>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. </t>
<t>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.</t>
<t>Accordingly, the applicable registration policy is Standards Action.</t>
</section>
<section title="Size, format, and syntax of registry entries" anchor="n-size-format-and-syntax-of-registry-entries"><t>Each registry entry consists of a single byte code, </t>
</section>
<section title="Initial assignments and reservations" anchor="n-initial-assignments-and-reservations"><t>The following entries should be added to the registry as initial assignments:</t>
<sourcecode>Code  Description                      Reference
---  -------------------               ---------
00   HMAC and SHA-2-512                [This document]
32   HKDF-AES-512                      [This document]
80   SHA-3-512                         [This document]
81   SHA-3-512 with 20 trailing zeros  [This document]
82   SHA-3-512 with 30 trailing zeros  [This document]
82   SHA-3-512 with 40 trailing zeros  [This document]
83   SHA-3-512 with 50 trailing zeros  [This document]
96   SHA-2-512                         [This document]
97   SHA-2-512 with 20 trailing zeros  [This document]
98   SHA-2-512 with 30 trailing zeros  [This document]
99   SHA-2-512 with 40 trailing zeros  [This document]
100  SHA-2-512 with 50 trailing zeros  [This document]
104  Random nonce                      [This document]
144  Shamir Secret Share               [This document]</sourcecode>
</section>
</section>
</section>
<section title="Acknowledgements" anchor="n-acknowledgements"><t>A list of people who have contributed to the design of the Mesh is presented in <xref target="draft-hallambaker-mesh-architecture"></xref>.</t>
<t>Thanks are due to Viktor Dukhovni, Damian Weber and an anonymous member of the cryptography@metzdowd.com list for assisting in the compilation of the table of prime values.</t>
</section>
<section title="Appendix A: Prime Values for Secret Sharing" anchor="n-appendix-a-prime-values-for-secret-sharing"><t>The following are the prime values to be used for sharing secrets of up to 512 bits.</t>
<t>If it is necessary to share larger secrets, the corresponding prime may be found by choosing a value (2<sup>32</sup>)<sup>n</sup> that is larger than the secret to be encoded and determining the next largest number that is prime.</t>
<table><thead>
<tr>
<th>
Number of bits</th>
<th>
Offset = Primen - 2n</th>
</tr>
</thead>
<tbody>
<tr>
<td>
32</td>
<td>
15</td>
</tr>
<tr>
<td>
64</td>
<td>
13</td>
</tr>
<tr>
<td>
 96</td>
<td>
61</td>
</tr>
<tr>
<td>
128</td>
<td>
51</td>
</tr>
<tr>
<td>
160</td>
<td>
7</td>
</tr>
<tr>
<td>
192</td>
<td>
133</td>
</tr>
<tr>
<td>
224</td>
<td>
735</td>
</tr>
<tr>
<td>
256</td>
<td>
297</td>
</tr>
<tr>
<td>
288</td>
<td>
127</td>
</tr>
<tr>
<td>
320</td>
<td>
27</td>
</tr>
<tr>
<td>
352</td>
<td>
55</td>
</tr>
<tr>
<td>
384</td>
<td>
231</td>
</tr>
<tr>
<td>
416</td>
<td>
235</td>
</tr>
<tr>
<td>
448</td>
<td>
211</td>
</tr>
<tr>
<td>
480</td>
<td>
165</td>
</tr>
<tr>
<td>
512</td>
<td>
75</td>
</tr>
</tbody>
</table><t>For example, the prime to be used to share a 128 bit value is 2<sup>128</sup> + 51.</t>
</section>
<section title="Recovering Shamir Shared Secret" anchor="n-recovering-shamir-shared-secret-"><t>The value of a Shamir Shared secret may be recovered using Lagrange basis polynomials.</t>
<t>To share a secret with a threshold of <em>n</em> shares and L bits we constructed <em>f(x)</em> a polynomial of degree <em>n</em> in the modular field <em>p</em> where <em>p</em> is the smallest prime greater than 2<sup>L</sup>:</t>
<t>f(x) = a<sub>0</sub> + a<sub>1</sub>.x + a<sub>2</sub>.x<sup>2</sup> + ... a<sub>n</sub>.x<sup>n</sup></t>
<t>The shared secret is the binary representation of the value a<sub>0</sub></t>
<t>Given <em>n</em> shares (<em>x<sub>0</sub></em>, <em>y<sub>0</sub></em>), (<em>x<sub>1</sub></em>, <em>y<sub>1</sub></em>), ... (<em>x<sub>n-1</sub></em>, <em>y<sub>n-1</sub></em>), The corresponding the Lagrange basis polynomials <em>l<sub>0</sub></em>, <em>l<sub>1</sub></em>, .. <em>l<sub>n-1</sub></em> are given by:</t>
<t>lm = ((x - x(m<sub>0</sub>)) / (x(m) - x(m<sub>0</sub>))) . ((x - x(m<sub>1</sub>)) / (x(m) - x(m<sub>1</sub>))) . ... .  ((x - x(m<sub>n-2</sub>)) / (x(m) - x(m<sub>n-2</sub>)))</t>
<t>Where the values m<sub>0</sub>, m<sub>1</sub>, ... m<sub>n-2</sub>, are the integers 0, 1, .. <em>n</em>-1, excluding the value <em>m</em>.</t>
<t>These can be used to compute <em>f(x)</em> as follows:</t>
<t>f(x) = y<sub>0</sub>l<sub>0</sub> + y<sub>1</sub>l<sub>1</sub> + ... y<sub>n-1</sub>l<sub>n-1</sub></t>
<t>Since it is only the value of <em>f(0)</em> that we are interested in, we compute the Lagrange basis for the value <em>x</em> = 0:</t>
<t>lz<sub>m</sub> = ((x(m<sub>1</sub>)) / (x(m) - x(m<sub>1</sub>))) . ((x(m<sub>2</sub>)) / (x(m) - x(m<sub>2</sub>)))</t>
<t>Hence,</t>
<t>a<sub>0</sub> = f(0) = y<sub>0</sub>lz<sub>0</sub> + y<sub>1</sub>lz<sub>1</sub> + ... y<sub>n-1</sub>l<sub>n-1</sub></t>
<t>The following C# code recovers the values.</t>
<sourcecode>using System;
using System.Collections.Generic;
using System.Numerics;

namespace Examples {

    class Examples {

        ///
        /// Combine a set of  points (x, f(x))
        /// on a polynomial of degree  in a
        /// discrete field modulo prime  to
        /// recover the value f(0) using Lagrange basis polynomials.
        ///
        /// The values f(x).
        /// The values for x.
        /// The modulus.
        /// The polynomial degree.
        /// The value f(0).
        static BigInteger CombineNK(
                    BigInteger[] fx,
                    int[] x,
                    BigInteger p,
                    int n) {
            if (fx.Length &lt; n) {
                throw new Exception("Insufficient shares");
                }

            BigInteger accumulator = 0;
            for (var formula = 0; formula &lt; n; formula++) {
                var value = fx[formula];

                BigInteger numerator = 1, denominator = 1;
                for (var count = 0; count &lt; n; count++) {
                    if (formula == count) {
                        continue;  // If not the same value
                        }

                    var start = x[formula];
                    var next = x[count];

                    numerator = (numerator * -next) % p;
                    denominator = (denominator * (start - next)) % p;
                    }

                var InvDenominator = ModInverse(denominator, p);

                accumulator = Modulus((accumulator +
                    (fx[formula] * numerator * InvDenominator)), p);
                }

            return accumulator;
            }

        ///
        /// Compute the modular multiplicative inverse of the value
        ///  modulo
        ///
        /// The value to find the inverse of
        /// The modulus.
        ///
        static BigInteger ModInverse(
                    BigInteger k,
                    BigInteger p) {
            var m2 = p - 2;
            if (k &lt; 0) {
                k = k + p;
                }

            return BigInteger.ModPow(k, m2, p);
            }

        ///
        /// Calculate the modulus of a number with correct handling
        /// for negative numbers.
        ///
        /// Value
        /// The modulus.
        /// x mod p
        public static BigInteger Modulus(
                    BigInteger x,
                    BigInteger p) {
            var Result = x % p;
            return Result.Sign &gt;= 0 ? Result : Result + p;
            }
        }
    }</sourcecode>
</section>
</middle>
<back>
<references title="Normative References"><reference anchor="RFC2119"><front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname="S. Bradner" initials="S." surname="Bradner"><organization/>
<address>
</address>
</author>
<date month="March" year="1997"/>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="SHA-2"><front>
<title>Secure Hash Standard</title>
<author><organization>NIST</organization>
<address>
</address>
</author>
<date month="August" year="2015"/>
</front>
<format type="pdf" target="https://dx.doi.org/10.6028/NIST.FIPS.180-4"/>
</reference>
<reference anchor="SHA-3"><front>
<title>SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions</title>
<author fullname="Morris J. Dworkin" initials="M. J." surname="Dworkin"><organization>NIST</organization>
<address>
</address>
</author>
<date month="August" year="2015"/>
</front>
<format type="pdf" target="https://dx.doi.org/10.6028/NIST.FIPS.202"/>
</reference>
<reference anchor="RFC7748"><front>
<title>Elliptic Curves for Security</title>
<author fullname="A. Langley" initials="A." surname="Langley"><organization/>
<address>
</address>
</author>
<author fullname="M. Hamburg" initials="M." surname="Hamburg"><organization/>
<address>
</address>
</author>
<author fullname="S. Turner" initials="S." surname="Turner"><organization/>
<address>
</address>
</author>
<date month="January" year="2016"/>
</front>
<seriesInfo name="RFC" value="7748"/>
<seriesInfo name="DOI" value="10.17487/RFC7748"/>
</reference>
<reference anchor="RFC8032"><front>
<title>Edwards-Curve Digital Signature Algorithm (EdDSA)</title>
<author fullname="S. Josefsson" initials="S." surname="Josefsson"><organization/>
<address>
</address>
</author>
<author fullname="I. Liusvaara" initials="I." surname="Liusvaara"><organization/>
<address>
</address>
</author>
<date month="January" year="2017"/>
</front>
<seriesInfo name="RFC" value="8032"/>
<seriesInfo name="DOI" value="10.17487/RFC8032"/>
</reference>
<reference anchor="RFC3986"><front>
<title>Uniform Resource Identifier (URI): Generic Syntax</title>
<author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee"><organization/>
<address>
</address>
</author>
<author fullname="R. Fielding" initials="R." surname="Fielding"><organization/>
<address>
</address>
</author>
<author fullname="L. Masinter" initials="L." surname="Masinter"><organization/>
<address>
</address>
</author>
<date month="January" year="2005"/>
</front>
<seriesInfo name="STD" value="66"/>
<seriesInfo name="RFC" value="3986"/>
<seriesInfo name="DOI" value="10.17487/RFC3986"/>
</reference>
<reference anchor="RFC4648"><front>
<title>The Base16, Base32, and Base64 Data Encodings</title>
<author fullname="S. Josefsson" initials="S." surname="Josefsson"><organization/>
<address>
</address>
</author>
<date month="October" year="2006"/>
</front>
<seriesInfo name="RFC" value="4648"/>
<seriesInfo name="DOI" value="10.17487/RFC4648"/>
</reference>
<reference anchor="RFC2014"><front>
<title>IRTF Research Group Guidelines and Procedures</title>
<author fullname="A. Weinrib" initials="A." surname="Weinrib"><organization/>
<address>
</address>
</author>
<author fullname="J. Postel" initials="J." surname="Postel"><organization/>
<address>
</address>
</author>
<date month="October" year="1996"/>
</front>
<seriesInfo name="BCP" value="8"/>
<seriesInfo name="RFC" value="2014"/>
<seriesInfo name="DOI" value="10.17487/RFC2014"/>
</reference>
<reference anchor="RFC5869"><front>
<title>HMAC-based Extract-and-Expand Key Derivation Function (HKDF)</title>
<author fullname="H. Krawczyk" initials="H." surname="Krawczyk"><organization/>
<address>
</address>
</author>
<author fullname="P. Eronen" initials="P." surname="Eronen"><organization/>
<address>
</address>
</author>
<date month="May" year="2010"/>
</front>
<seriesInfo name="RFC" value="5869"/>
<seriesInfo name="DOI" value="10.17487/RFC5869"/>
</reference>
<reference anchor="RFC5903"><front>
<title>Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and IKEv2</title>
<author fullname="D. Fu" initials="D." surname="Fu"><organization/>
<address>
</address>
</author>
<author fullname="J. Solinas" initials="J." surname="Solinas"><organization/>
<address>
</address>
</author>
<date month="June" year="2010"/>
</front>
<seriesInfo name="RFC" value="5903"/>
<seriesInfo name="DOI" value="10.17487/RFC5903"/>
</reference>
<reference anchor="RFC5280"><front>
<title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
<author fullname="D. Cooper" initials="D." surname="Cooper"><organization/>
<address>
</address>
</author>
<author fullname="S. Santesson" initials="S." surname="Santesson"><organization/>
<address>
</address>
</author>
<author fullname="S. Farrell" initials="S." surname="Farrell"><organization/>
<address>
</address>
</author>
<author fullname="S. Boeyen" initials="S." surname="Boeyen"><organization/>
<address>
</address>
</author>
<author fullname="R. Housley" initials="R." surname="Housley"><organization/>
<address>
</address>
</author>
<author fullname="W. Polk" initials="W." surname="Polk"><organization/>
<address>
</address>
</author>
<date month="May" year="2008"/>
</front>
<seriesInfo name="RFC" value="5280"/>
<seriesInfo name="DOI" value="10.17487/RFC5280"/>
</reference>
<reference anchor="RFC6031"><front>
<title>Cryptographic Message Syntax (CMS) Symmetric Key Package Content Type</title>
<author fullname="S. Turner" initials="S." surname="Turner"><organization/>
<address>
</address>
</author>
<author fullname="R. Housley" initials="R." surname="Housley"><organization/>
<address>
</address>
</author>
<date month="December" year="2010"/>
</front>
<seriesInfo name="RFC" value="6031"/>
<seriesInfo name="DOI" value="10.17487/RFC6031"/>
</reference>
<reference anchor="draft-hallambaker-web-service-discovery"><front>
<title>DNS Web Service Discovery</title>
<author fullname="Phillip Hallam-Baker" initials="P" surname="Hallam-Baker"><organization/>
<address>
</address>
</author>
<date day="23" month="October" year="2019"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-hallambaker-web-service-discovery-03"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-hallambaker-web-service-discovery-03.txt"/>
</reference>
<reference anchor="draft-hallambaker-mesh-dare"><front>
<title>Mathematical Mesh 3.0 Part III : Data At Rest Encryption (DARE)</title>
<author fullname="Phillip Hallam-Baker" initials="P" surname="Hallam-Baker"><organization/>
<address>
</address>
</author>
<date day="9" month="March" year="2020"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-hallambaker-mesh-dare-07"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-hallambaker-mesh-dare-07.txt"/>
</reference>
<reference anchor="draft-hallambaker-mesh-security"><front>
<title>Mathematical Mesh 3.0 Part VII: Security Considerations</title>
<author fullname="Phillip Hallam-Baker" initials="P" surname="Hallam-Baker"><organization/>
<address>
</address>
</author>
<date day="9" month="March" year="2020"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-hallambaker-mesh-security-04"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-hallambaker-mesh-security-04.txt"/>
</reference>
<reference anchor="draft-hallambaker-mesh-architecture"><front>
<title>Mathematical Mesh 3.0 Part I: Architecture Guide</title>
<author fullname="Phillip Hallam-Baker" initials="P" surname="Hallam-Baker"><organization/>
<address>
</address>
</author>
<date day="9" month="March" year="2020"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-hallambaker-mesh-architecture-13"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-hallambaker-mesh-architecture-13.txt"/>
</reference>
</references>
<references title="Informative References"><reference anchor="RFC4086"><front>
<title>Randomness Requirements for Security</title>
<author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"><organization/>
<address>
</address>
</author>
<author fullname="J. Schiller" initials="J." surname="Schiller"><organization/>
<address>
</address>
</author>
<author fullname="S. Crocker" initials="S." surname="Crocker"><organization/>
<address>
</address>
</author>
<date month="June" year="2005"/>
</front>
<seriesInfo name="BCP" value="106"/>
<seriesInfo name="RFC" value="4086"/>
<seriesInfo name="DOI" value="10.17487/RFC4086"/>
</reference>
<reference anchor="Shamir79"><front>
<title>How to share a secret.</title>
<author fullname="Adi Shamirt" initials="A." surname="Shamir"><address>
</address>
</author>
<date year="1979"/>
</front>
</reference>
<reference anchor="XMLSchema"><front>
<title>W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures</title>
<author fullname="Shudi  Gao" initials="S." surname="Gao"><organization/>
<address>
</address>
</author>
<author fullname="C. M. Sperberg-McQueen" initials="C. M." surname="Sperberg-McQueen"><organization/>
<address>
</address>
</author>
<author fullname="Henry S. Thompson" initials="H. S." surname="Thompson"><organization/>
<address>
</address>
</author>
<author fullname="Noah Mendelsohn" initials="N." surname="Mendelsohn"><organization/>
<address>
</address>
</author>
<author fullname="David Beech" initials="D." surname="Beech"><organization/>
<address>
</address>
</author>
<author fullname="Murray Maloney" initials="M." surname="Maloney"><organization/>
<address>
</address>
</author>
<date day="5" month="April" year="2012"/>
</front>
</reference>
<reference anchor="RFC6763"><front>
<title>DNS-Based Service Discovery</title>
<author fullname="S. Cheshire" initials="S." surname="Cheshire"><organization/>
<address>
</address>
</author>
<author fullname="M. Krochmal" initials="M." surname="Krochmal"><organization/>
<address>
</address>
</author>
<date month="February" year="2013"/>
</front>
<seriesInfo name="RFC" value="6763"/>
<seriesInfo name="DOI" value="10.17487/RFC6763"/>
</reference>
<reference anchor="RFC5785"><front>
<title>Defining Well-Known Uniform Resource Identifiers (URIs)</title>
<author fullname="M. Nottingham" initials="M." surname="Nottingham"><organization/>
<address>
</address>
</author>
<author fullname="E. Hammer-Lahav" initials="E." surname="Hammer-Lahav"><organization/>
<address>
</address>
</author>
<date month="April" year="2010"/>
</front>
<seriesInfo name="RFC" value="5785"/>
<seriesInfo name="DOI" value="10.17487/RFC5785"/>
</reference>
<reference anchor="RFC4880"><front>
<title>OpenPGP Message Format</title>
<author fullname="J. Callas" initials="J." surname="Callas"><organization/>
<address>
</address>
</author>
<author fullname="L. Donnerhacke" initials="L." surname="Donnerhacke"><organization/>
<address>
</address>
</author>
<author fullname="H. Finney" initials="H." surname="Finney"><organization/>
<address>
</address>
</author>
<author fullname="D. Shaw" initials="D." surname="Shaw"><organization/>
<address>
</address>
</author>
<author fullname="R. Thayer" initials="R." surname="Thayer"><organization/>
<address>
</address>
</author>
<date month="November" year="2007"/>
</front>
<seriesInfo name="RFC" value="4880"/>
<seriesInfo name="DOI" value="10.17487/RFC4880"/>
</reference>
<reference anchor="RFC5890"><front>
<title>Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework</title>
<author fullname="J. Klensin" initials="J." surname="Klensin"><organization/>
<address>
</address>
</author>
<date month="August" year="2010"/>
</front>
<seriesInfo name="RFC" value="5890"/>
<seriesInfo name="DOI" value="10.17487/RFC5890"/>
</reference>
<reference anchor="RFC6355"><front>
<title>Definition of the UUID-Based DHCPv6 Unique Identifier (DUID-UUID)</title>
<author fullname="T. Narten" initials="T." surname="Narten"><organization/>
<address>
</address>
</author>
<author fullname="J. Johnson" initials="J." surname="Johnson"><organization/>
<address>
</address>
</author>
<date month="August" year="2011"/>
</front>
<seriesInfo name="RFC" value="6355"/>
<seriesInfo name="DOI" value="10.17487/RFC6355"/>
</reference>
<reference anchor="RFC7595"><front>
<title>Guidelines and Registration Procedures for URI Schemes</title>
<author fullname="D. Thaler" initials="D." surname="Thaler"><organization/>
<address>
</address>
</author>
<author fullname="T. Hansen" initials="T." surname="Hansen"><organization/>
<address>
</address>
</author>
<author fullname="T. Hardie" initials="T." surname="Hardie"><organization/>
<address>
</address>
</author>
<date month="June" year="2015"/>
</front>
<seriesInfo name="BCP" value="35"/>
<seriesInfo name="RFC" value="7595"/>
<seriesInfo name="DOI" value="10.17487/RFC7595"/>
</reference>
<reference anchor="draft-hallambaker-mesh-trust"><front>
<title>Mathematical Mesh 3.0 Part VI: The Trust Mesh</title>
<author fullname="Phillip Hallam-Baker" initials="P" surname="Hallam-Baker"><organization/>
<address>
</address>
</author>
<date day="9" month="March" year="2020"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-hallambaker-mesh-trust-05"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-hallambaker-mesh-trust-05.txt"/>
</reference>
<reference anchor="draft-hallambaker-mesh-developer"><front>
<title>Mathematical Mesh: Reference Implementation</title>
<author fullname="Phillip Hallam-Baker" initials="P" surname="Hallam-Baker"><organization/>
<address>
</address>
</author>
<date day="23" month="October" year="2019"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-hallambaker-mesh-developer-09"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-hallambaker-mesh-developer-09.txt"/>
</reference>
</references>
</back>
</rfc>
