Subject: [Drip] Encoding HHITs in CTA-2063-A space

From: Robert Moskowitz <[email-masked]>
Date: Thu, 31 Dec 2020 11:31:06 -0500

this is a serious consideration as part of draft-drip-rid for 
manufacturers that assign HHITs at manufacture time and want both HHITs 
and 2063 serial numbers:

1st consider a 34 valued character mapped to bits.

If only use 32 values (drop Z and S as too similar to 2 and 5), each 
character can map 5 bits.  The 64 bit hash portion of the HHIT can be 
encoded in 13 characters (65 bits).  But use a full 15 character length 
with the first two being "ZZ".

The 4 character Manufacturer code is a big challenge.  Assume all 34 
values possible.  It would take 23 bits for a dense binary encoding 
(2^23 > 34^4).  This would take 1/512th of the RAA space to map this 
into RAA|HDA.  Ouch.

So rather a registry of MC to Prefix|RAA|HDA (as longgg time for all MC 
assigned), leaving what to do with the OGA.  That could replace the 2nd 
Z above.

Messy, but maybe worth including?

I will shortly push out an update for drip-rid without this little 
twist.  It needs time to ferment.

---

From: "Card, Stu" <[email-masked]>
Date: Thu, 31 Dec 2020 12:52:53 -0500

I worked this out many months ago, not just for ANSI/CTA-2063-A (ASTM UAS
ID Type 1), but also for FAA single use SessionID (ASTM UAS ID Type 3,
USS/UTM assigned UUID).

See again attached illustration.

However, it was based on the previous HHIT structure, so may need revision.

Also, "maybeHash" vs "maybeDerive" should be decided:

- hashing directly from HIbits to Hash64bits is in the spirit of cSHAKE;

- hashing first to Hash122bits, then deriving Hash64bits, allows the same
HI to be used as the basis of a Type 3 (UUID128bits) and a Type 1
(CtaSN20char) with a computable mapping from the Type 3 to the Type 1,
which _might_ be useful, e.g. to initialize a chain of registrations of
SessionIDs that should be traceable (by authorized parties only) back to
the SN.

ANSI/CTI-2063-A designates 0 (zero) vs O (oh) and 1 (one) vs I (eye) as the
visually similar cases to be avoided: they drop oh and eye, I also dropped
zero and one to get 32 characters; perhaps Bob's idea of dropping Z and S
might be more useful (avoiding 2 more cases of ambiguity rather than more
strongly avoiding the first 2 cases).

I assume each manufacturer code will correspond to a single HDA (either run
by the manufacturer or run by some competent registry operator contracted
by the manufacturer), and that this mapping can be resolved by DNS; other
schemes for mapping MfrCode4char to MfrReg32bits (RAA, HDA) are possible,
but only 21 bits are needed at most, and MFR code allocation is likely
sparse.

Rather than fixing the first 2 characters to ZZ, they can encode the OGA ID
(HIT Suite) and the last 4 bits of the IANA assigned prefix (in case
additional "address" space is needed later); that is assumed in the
attached diagram.

Summary (simplified, some caveats apply if OGA ID or IANA prefix vary):

- from HI and MFR code, one can derive HHIT, Type 1 (SN) and/or Type 3
(UUID);

- from Type 3 (UUID), one can derive HHIT, and if maybeDerive path is
followed also Type 3 (SN);

- from Type 1 (SN), one can derive HHIT;

- from HHIT, one can derive Type 1 (SN) but _not_ Type 3 (UUID).

This has been my fall-back plan if ASTM declines to allocate a UAS ID Type
for DRIP HHITs (although such an allocation is highly preferable).

The FAA Final Rule discussion about assignment of single use Session IDs in
the absence of NetRID-SP USS invites our contribution!

On Thu, Dec 31, 2020 at 11:31 AM Robert Moskowitz <[email-masked]>
wrote:

> --
> Tm-rid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tm-rid
>

---

From: "Card, Stu" <[email-masked]>
Date: Thu, 31 Dec 2020 12:55:50 -0500

Oops. One typo:

 from Type 3 (UUID), one can derive HHIT, and if maybeDerive path is
followed also Type 3 (SN);

should be

  from Type 3 (UUID), one can derive HHIT, and if maybeDerive path is
followed also Type 1 (SN);

Sorry. :-(

On Thu, Dec 31, 2020 at 12:52 PM Card, Stu <[email-masked]>
wrote:

> ANSI/CTI-2063-A designates 0 (zero) vs O (oh) and 1 (one) vs I (eye) as
> the visually similar cases to be avoided: they drop oh and eye, I also
> dropped zero and one to get 32 characters; perhaps Bob's idea of dropping Z
> and S might be more useful (avoiding 2 more cases of ambiguity rather than
> more strongly avoiding the first 2 cases).
>
> I assume each manufacturer code will correspond to a single HDA (either
> run by the manufacturer or run by some competent registry operator
> contracted by the manufacturer), and that this mapping can be resolved by
> DNS; other schemes for mapping MfrCode4char to MfrReg32bits (RAA, HDA) are
> possible, but only 21 bits are needed at most, and MFR code allocation is
> likely sparse.
>
> Rather than fixing the first 2 characters to ZZ, they can encode the OGA
> ID (HIT Suite) and the last 4 bits of the IANA assigned prefix (in case
> The FAA Final Rule discussion about assignment of single use Session IDs
> in the absence of NetRID-SP USS invites our contribution!
>
> On Thu, Dec 31, 2020 at 11:31 AM Robert Moskowitz <
> [email-masked]> wrote:
>