[Mathmesh] UDF Design notes

[Phillip Hallam-Baker <[e-mail]>]

Discussing:

http://mathmesh.com/Documents/draft-hallambaker-mesh-udf.html

I try to avoid giving explanations in documents that contain normative text
as this can be a source of ambiguity. So I will try to summarize the design
concerns here.

The original starting point was the need for a 'better PGP fingerprint'. In
particular, I wanted a digest representation that was:

* Reasonably compact in both printed and voiced form.
* Supported use of SHA2
* Could be expressed at varying precision as the application needs demanded
* Could be upgraded to make use of new algorithms if absolutely necessary
* Could be input via a keyboard
* Could be compared for equality
* Could be used to create a fingerprint of any type of data (not just keys)
* Support use in QR codes, DNS labels, etc.

After a while I quickly realized I would also need to ensure that

* UDFs could not be confused with OpenPGP fingerprints
* A UDF of a key could not be confused with a UDF of a document or
executable

This led to the construct described in the document, i.e.

* A binary UDF is an octet stream in which the first octet describes the
digest algorithm used to create it.
* The binary UDF is canonically presented in BASE32

The choice of Base32 comes from the observation that fingerprints are
frequently read out aloud and having to distinguish case makes the process
tedious and error prone. So it cant be Base64 but Base32 gives us five bits
per char instead of four.

The Type Identifiers for SHA-2 and SHA-3 are chosen so as to cause the
first letter of a SHA-2 digest to always be an M (for Merkle-Damgard and to
remind us of the Rivest/MD5 legacy) and tthe first letter of a SHA-3 digest
will always be a K for Keccak.

I have tried various groupings of digits and ended up choosing 4 because it
makes the code least complex.


A UDF content digest is a digest of a typed content sequence. First
the Content Digest Value (CDV) is determined by applying the digest
algorithm to the content data:

CDV = H(<Data>))

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

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

The reason for this two step process is that while there are tens of
thousands of content types in use, 99% of documents out there are of less
than 50 content types. So if we have a fingerprint of a file and we are not
sure what content type was intended, we can check the 50 most likely
content types as quickly on a 1GB file as on a 1KB file.

Finally, I started seeing that people have Bitcoin addresses of the form
faceb-ookds-lkjh or whatever. Pretty kewl huh, the first letters of my key
tells you who owns it?

Erm no, what people have done there is provide a new attack vector because
most people will only remember the first ten digits of an address at most
and this mnemonic is encouraging people to assume from memory. Anyone who
wants to impersonate the above, just needs to search for a public key whose
first eight digits match and they will probably trick enough people to be
interesting.

So I decided to encourage people not to do this and then thought, what if
they could have a shorter fingerprint that was just as strong.

There is IETF precedent for this as Christian Huitema (ccd) can explain.
There is unfortunately a patent to Microsoft. It is not clear that the MSFT
patent covers my approach however and since they allowed a royalty free
etc. license in the past, they might well in this instance.



Having developed a spec for content digests, I quickly realized that my
code was also generating a number of ASCII outputs that look like UDF
fingerprints but were not content digests. So I decided to assign code
points for the following:

* Nonces (N)
* Encryption keys (E)
* MAC results (A)
* Shamir Secret Share (S)

These are the features I use in the Mesh and so I have a fairly good
understanding of at least a partial set of requirements. But it is not
necessarily a complete list.

The two use cases that I am most tempted to add are representations for
public and private key literals.

PRO: One spec fits all.
CON: Even 25519 keys are long do we read them out over the phone? Perhaps
we should consider Base64?

I have not decided on this yet and I don't have a use case. But I might
when I get to thinking about TLS SNI encryption type things. I currently
have two possible ways forward.

The first is to add a Type indicator PKIX (112 = P)  which would be
followed by a PKIX KeyInfo block. This would be encoded in Base32. This
would look something like this for an Ed25519 key:

PB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4-SAQQ-RY7F-Q7UU-URHU-VCDB-HALY-LNCG

The second would be to do the above in Base64 but use a type indicator that
gives an initial letter in Base64:

x-Z4lAx9fFvhzLO3a9RHGDPgtcwapxVCo_XdlAj1s1CPI

I have no strong vies on this either way.