[Drip] DIME Apex Allocation

[Adam Wiethuechter <[e-mail]>]

All,

I am currently working through Daniels comments, thanks Dan!

I have run across this specific set of comments (spanning Section 4 and Section 4.1) and wish to engage in a discussion of the WG to see what other people think.

<mglt>
I think it would be good to clarify the meaning of the acronyms.
We should also explain what RAA/HDA differs from the generic RAAs/HDAs.
DET defines RAA and HDA as some bits, and it seems that some sort of delegation exists between RAA and HDAs. However, there are no bits for Apex and as such Figure 1 does not seem to represent that delegation induced by the DET fields but instead as a specific "administrative entity" that uses special bits values for RAA and HDA. Maybe that is clarified after, but the current description is missing to specify that it represents business entities or administrations. All of them will be encoded on the RAA and HDA bits.
</mglt>

4.1.  Apex

   The Apex is a special DIME role that holds the values of RAA=0-3 and
   HDA=0.
 It serves as the branch point from the larger DNS system in
   which DETs are defined.  The Apex is the owner of the IPv6 prefix
   portion of the DET associated with it (2001:30/28) which is assigned
   by IANA from the special IPv6 address space for ORCHIDs.

<mglt>
I think I am missing the text that explains briefly why we need to have an Apex. If that is the administrative contact of the prefix why do we need to assign a specific RAA/HDA code point.
</mglt>

The primary discussion is I wish to raise is around if the Apex needs allocations in RAA/HDA space.

The Apex is to be run by some entity. At the moment it is agreed to be IANA until ICAO can fill its place. There will obviously be X.509 certificates that we will need to shadow as mentioned in -dki.

Technically if the Apex is not given a DET out of this space there cannot be a Broadcast Endorsement for the Apex. Currently it is defined that the Broadcast Endorsement for the Apex is self-signed. If this is removed a few things happen:


  1.
drip-auth has one whole Broadcast Endorsement removed from its chain. This is good as then less is needed to be sent over the air. This is bad as the Apex is written into the document in Section 6.
  2.
RAA level Broadcast Endorsement's become self-signed, and clients must jump into the shadow X.509 PKI to confirm if the RAA is legitimate and continue up the chain to the Apex.

I think we have two options to move forward with this comment:


  1.
Remove the allocation of a DET for the Apex (i.e. RAA=0-3, HDA=0) and have it solely be in the X.509 (as the Root CA?) chain. Text would need to be added explaining that X.509s would be required between the Apex and RAAs to confirm legitimate registration.
  2.
Add text justifying the DET for the Apex.

On a technical level I believe it should stay the same, however on a conceptual level legitimacy ends, at least to most end users, at their CAA (which would be the RAA).

Thoughts?

--------
73,
Adam T. Wiethuechter
Software Engineer; AX Enterprize, LLC