clarification section 4.2

[mglt]

4.2. HIT as A Trustworthy DRIP Entity Identifier

""" 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

"""

It is unclear to me why the registration process provides the uniqueness. If the document provides such claims, it needs to explain at high level why. What is unclear is how registration prevents two users to have different keys HI1 and HI2 that have the same hash.

[ShuaiZhao]

@Bob, this is where we need your expertise...

[cardsw]

If a newly proposed HHIT collides with a previously registered HHIT, the registry rejects it: refuses to sign an attestation or cert. The registry can easily tell it is a collision (rather than a redundant registration of the same HHIT) by looking at the public key (HI) provided as part of the registration request, and checking the signature made with the corresponding private key. I agree we could state that more explicitly here, although I think we do elsewhere?

[ShuaiZhao]

> Editor-note 11: Explain how HIT itself and HHIT registry address naming collision.

[ShuaiZhao]

the improved text below:

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.