clarification section 4.3

[mglt]

4.3. HHIT for DRIP Identifier Registration and Lookup

"""
An
HHIT DRIP identifier contains cryptographically embedded registration
information. This HHIT registration hierarchy, along with the IPv6
prefix, is trustable and sufficient information that can be used to
perform such a lookup. Additionally, the IPv6 prefix can enhance the
HHITs use beyond the basic Remote ID function (e.g use in HIP,
[RFC7401]).

Therefore, a DRIP identifier can be represented as a HHIT. It can be
self-generated by a UAS (either UA or GCS) and registered with the
Private Information Registry (More details in Section 5.2) identified
in its hierarchy fields. Each DRIP identifier represented as an HHIT
can not be used more than once.

A DRIP identifier can be assigned to a UAS as a static HHIT by its
manufacturer, such as a single HI and derived HHIT encoded as a
hardware serial number per [CTA2063A]. Such a static HHIT can only
be used to bind one-time use DRIP identifiers to the unique UA.
Depending upon implementation, this may leave a HI private key in the
possession of the manufacturer (more details in Section 8).

In another case, a UAS equipped for Broadcast RID can be provisioned
not only with its HHIT but also with the HI public key from which the
HHIT was derived and the corresponding private key, to enable message
signature. A UAS equipped for Network RID can be provisioned
likewise; the private key resides only in the ultimate source of
Network RID messages (i.e. on the UA itself if the GCS is merely
relaying rather than sourcing Network RID messages). Each Observer
device can be provisioned either with public keys of the DRIP
identifier root registries or certificates for subordinate
registries.

HHITs can be used throughout the UAS/UTM system. The Operators,
Private Information Registries, as well as other UTM entities, can
use HHITs for their IDs. Such HHITs can facilitate DRIP security
functions such as used with HIP to strongly mutually authenticate and
encrypt communications.

"""

It is unclear to me how this text is related to the lookup or the registration. It seesm to me the text ismore appropriated to section 4.2. HIT as A Trustworthy DRIP Entity Identifier.

[ShuaiZhao]

@mglt, I can integrate this into section 4.2.
updated text for 4.3 will be following:

4.3.  HHIT for DRIP Identifier Registration and Lookup
Remote ID needs a deterministic lookup mechanism that rapidly
   provides actionable information about the identified UA.  Given the
   size constraints imposed by the Bluetooth 4 broadcast media, the
   Remote ID itself needs to be the inquiry input into the lookup.  An
   HHIT DRIP identifier contains cryptographically embedded registration
   information.  This HHIT registration hierarchy, along with the IPv6
   prefix, is trustable and sufficient information that can be used to
   perform such a lookup.  Additionally, the IPv6 prefix can enhance the
   HHITs use beyond the basic Remote ID function (e.g use in HIP,
   [RFC7401]).

 Therefore, a DRIP identifier can be represented as a HHIT.  It can be
   self-generated by a UAS (either UA or GCS) and registered with the
   Private Information Registry (More details in Section 5.2) identified
   in its hierarchy fields.  Each DRIP identifier represented as an HHIT
   can not be used more than once.

the new Section 4.2, after integrating with text from original section 4.3

4.2.  HIT as A Trustworthy DRIP Entity Identifier

   A Remote ID that can be trustworthily used in the RID Broadcast mode
   can be built from an asymmetric keypair.  Rather than using a key
   signing operation to claim ownership of an ID that does not guarantee
   name uniqueness, in this method the ID is cryptographically derived
   directly from the public key.  The proof of ID ownership (verifiable
   attestation, versus mere claim) comes from signing this cryptographic
   ID with the associated private key.  It is statistically hard for
   another entity to create a public key that would generate (spoof) the
   ID.

   The HITs is designed statistically unique through the cryptographic
   hash feature of second-preimage resistance.  The cryptographically-
   bound addition of the Hierarchy and an HHIT registration process
   (e.g. based on Extensible Provisioning Protocol, [RFC5730]) provide
   complete, global HHIT uniqueness.  This registration forces the
   attacker to generate the same public key rather than a public key
   that generates the same HHIT.  This is in contrast to general IDs
   (e.g. a UUID or device serial number) as the subject in an X.509
   certificate.

   A DRIP identifier can be assigned to a UAS as a static HHIT by its
   manufacturer, such as a single HI and derived HHIT encoded as a
   hardware serial number per [CTA2063A].  Such a static HHIT can only
   be used to bind one-time use DRIP identifiers to the unique UA.
   Depending upon implementation, this may leave a HI private key in the
   possession of the manufacturer (more details in Section 8).

   In another case, a UAS equipped for Broadcast RID can be provisioned
   not only with its HHIT but also with the HI public key from which the
   HHIT was derived and the corresponding private key, to enable message
   signature.  A UAS equipped for Network RID can be provisioned
   likewise; the private key resides only in the ultimate source of 
  Network RID messages (i.e. on the UA itself if the GCS is merely
   relaying rather than sourcing Network RID messages).  Each Observer
   device can be provisioned either with public keys of the DRIP
   identifier root registries or certificates for subordinate
   registries.

   HHITs can also be used throughout the USS/UTM system.  The Operators,
   Private Information Registries, as well as other UTM entities, can
   use HHITs for their IDs.  Such HHITs can facilitate DRIP security
   functions such as used with HIP to strongly mutually authenticate and
   encrypt communications.

Please let me know if this is acceptable.

[mglt]

It is unclear to me what section 4.3 says more regarding to registration and lookup than the following lines:

Therefore, a DRIP identifier is represented as a HHIT and registered with the
Private Information Registry (More details in Section 5.2) identified
in its hierarchy fields.

In which case, having an section to specify the indirection to section 5.2 is questionable. It seems to me that such indication may be provided in the preamble of section 4 and section 4.3 can be removed.

[ShuaiZhao]

updated text in section 4.3.

4.3.  HHIT for DRIP Identifier Registration and Lookup

   Remote ID needs a deterministic lookup mechanism that rapidly
   provides actionable information about the identified UA.  Given the
   size constraints imposed by the Bluetooth 4 broadcast media, the
   Remote ID itself needs to be a non-spoofable inquiry input into the
   lookup.

   A DRIP registration process based on the explicit hierarchy within a
   HHIT provides manageable uniqueness of the HI for the HHIT (defense
   against a cryptographic hash second pre-image attack on the HHIT;
   e.g. multiple HIs yielding the same HHIT).  A lookup of the HHIT into
   this registration data provides the registered HI for HHIT proof.  A
   first-come-first-serve registration for a HHIT provides deterministic
   access to any other needed actionable information based on inquiry
   access authority (more details in Section 5.2).