Re: [Drip] DIME Apex Allocation

[Daniel Migault <[e-mail]>]

Thanks for submitting a new version. I will go through the new version just
published. I think what would help me and probably convince everyone we
need a DET for the Apex is to expose what wrong could happen if we do not
have a DET for the Apex. If that can help to figure out the issue I have
(at least from the previous version of the draft), is that I do see
the function of the Apex as purely administrative.

Yours,
Daniel

On Wed, Mar 27, 2024 at 3:48 PM Stu Card <[e-mail]> wrote:

> I am strongly in favor of the Apex having a DET as there must be an Apex
> for each IPv6 prefix and in applications beyond UAS RID of DRIP (e.g. the
> ICAO Trust Framework for the entire civil aviation ecosystem) there will be
> more than one prefix, leading to proliferation of RAA level X.509
> cross-certificates between agencies in related sectors and X.509 - DRIP
> cross-endorsements such that verifying a full path from a leaf (e.g. UA) to
> a root of trust would get complicated. That said, the ICAO Trust Framework
> Panel has already gotten push-back from some of its member states, who
> understandably do not want to surrender any of their sovereign authority to
> ICAO by making the latter the sole global root of trust for civil aviation
> computer networking, so cross-certs between RAAs, least one of which has
> neither an X.509 cert nor a DET based DRIP endorsement, are very likely to
> exist, and we will need to support them.
>
> Sent from my Verizon, Samsung Galaxy smartphone
> Get Outlook for Android <https://aka.ms/AAb9ysg>
> ------------------------------
> *From:* Tm-rid <[e-mail]> on behalf of Adam Wiethuechter <
> [e-mail]>
> *Sent:* Wednesday, March 27, 2024 1:17:16 PM
> *To:* [e-mail] <[e-mail]>
> *Subject:* [Drip] DIME Apex Allocation
>
> 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
> --
> Tm-rid mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tm-rid
>


-- 
Daniel Migault
Ericsson