Subject: [apps-discuss] draft-farrell-decade-ni-04: more glitches in examples

From: "Manger, James H" <[email-masked]>
Date: Mon, 30 Apr 2012 12:23:15 +1000

Ari and Stephen,

There are new glitches in the examples in "Naming Things with Hashes" <draft-farrell-decade-ni-04>.

The 1st examples are wrong:
  "Hello World!" (without the quotes, being 12 characters)
  ni:///sha-256;A7ogTlDRJuRnTABeBNguhMITZngK8fQ71Uo3gWtqs0A

A7og... is the (base64url-encoded) SHA-256 hash of *13* characters that includes a newline char at the end.
Base64url(SHA-256("Hello World!\n")) = A7ogTlDRJuRnTABeBNguhMITZngK8fQ71Uo3gWtqs0A
Base64url(SHA-256("Hello World!")) = f4OxZX_x_FO5LcGBSKHWXfwtSx-j1ncoSt3SABJtkGk

The URI should be
ni:///sha-256;f4OxZX_x_FO5LcGBSKHWXfwtSx-j1ncoSt3SABJtkGk

The 2nd examples are wrong:
  Given the SubjectPublicKeyInfo in Figure 5...
  0000000 82 01 0a 02 82 01 01 00 a2 5f 83 da 9b d9 f1 7a
  0000020 3a 36 67 ba fd 5a 94 0e cf 16 d5 5a 55 3a 5e d4

This is not a SubjectPublicKeyInfo value. It is not even "the value of the BIT STRING subjectPublicKey (excluding the tag, length, and number of unused bits)" -- which is commonly the input to a key-id calculation.
Add an initial 0x30 to make the data a subjectPublicKey value (ie a DER-encoded RSAPublicKey); then add the DER-encoding for the rsaEncryption algorithm id and wrappers.

The full data should be:

  000000 : 30 82 01 22 30 0D 06 09  2A 86 48 86 F7 0D 01 01
  000010 : 01 05 00 03 82 01 0F 00  30 82 01 0A 02 82 01 01
  000020 : 00 A2 5F 83 DA 9B D9 F1  7A 3A 36 67 BA FD 5A 94
  000030 : 0E CF 16 D5 5A 55 3A 5E  D4 03 B1 65 8E 6D CF A3
  000040 : B7 DB A4 E7 CC 0F 52 C6  7D 35 1D C4 68 C2 BD 7B
  000050 : 9D DB E4 0A D7 10 CD F9  53 20 EE 0D D7 56 6E 5B
  000060 : 7A AE 2C 5F 83 0A 19 3C  72 58 96 D6 86 E8 0E E6
  000070 : 94 EB 5C F2 90 3E F3 A8  8A 88 56 B6 CD 36 38 76
  000080 : 22 97 B1 6B 3C 9C 07 F3  4F 97 08 A1 BC 29 38 9B
  000090 : 81 06 2B 74 60 38 7A 93  2F 39 BE 12 34 09 6E 0B
  0000A0 : 57 10 B7 A3 7B F2 C6 EE  D6 C1 E5 EC AE C5 9C 83
  0000B0 : 14 F4 6B 58 E2 DE F2 FF  C9 77 07 E3 F3 4C 97 CF
  0000C0 : 1A 28 9E 38 A1 B3 93 41  75 A1 A4 76 3F 4D 78 D7
  0000D0 : 44 D6 1A E3 CE E2 5D C5  78 4C B5 31 22 2E C7 4B
  0000E0 : 8C 6F 56 78 5C A1 C4 C0  1D CA E5 B9 44 D7 E9 90
  0000F0 : 9C BC EE B0 A2 B1 DC DA  6D A0 0F F6 AD 1E 2C 12
  000100 : A2 A7 66 60 3E 36 D4 91  41 C2 F2 E7 69 39 2C 9D
  000110 : D2 DF B5 A3 44 95 48 7C  87 64 89 DD BF 05 01 EE
  000120 : DD 02 03 01 00 01

The SHA-256 hash and all the subsequent URIs need to be changed to reflect the corrected input data.

--
James Manger

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 30 Apr 2012 13:06:45 +0100

Thanks James,

Shooting out a -05 shortly to fix that and other comments
from Barry/Alexey.

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 30 Apr 2012 17:06:14 +0100

Hi James,

I pushed out a version [1] that I hope fixes this. We'll see I
guess;-)

Thanks for catching those though!

Cheers,
S.

[1] http://tools.ietf.org/html/draft-farrell-decade-ni-05

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 1 May 2012 12:17:37 +1000

A check digit would be more appropriate than an CRC for the human-readable format in "Naming Things with Hashes" <draft-farrell-decade-ni>. The draft currently has an optional 16-bit CRC, represented with 4 hex digits. CRCs are really designed for detecting bit errors (or bursts of bit errors). Check digits, on the other hand, are designed to detect human errors (changing digits, transposing digits etc). 1 or 2 check digits are sufficient, instead of 4 chars for a 16-bit CRC.

Most check digit algorithms work on decimal digits. This draft needs one for a string or at least for hex digits. Perhaps the Luhn mod N algorithm would be suitable <http://en.wikipedia.org/wiki/Luhn_mod_N_algorithm>? Using N=16 and calculating the checksum over just the hex digits of the hash should work well. Such a checksum doesn't "protect" the algorithm name, but it doesn't need to as there are only a handful of valid values anyway. Such a checksum would also ignore the case of hex digits. It doesn't change if you switch from an alg name to id (eg "sha-256-120" to "3").

P.S. The examples in draft 05 all look correct now.

--
James Manger