Subject: [Drip] short ASTM update

From: "Card, Stu" <[email-masked]>
Date: Tue, 13 Oct 2020 18:27:38 -0400

I had a brief conversation today with Gabriel Cox (cc'ed), leader of the
ASTM F38.02 workgroup that produced F3411-19 and will at some point revise
it:

(1) ASTM will continue to hold off substantive revisions until the FAA
publishes a final rule. ASTM may make some minor editorial changes
(corrections to the document that reflect the original intent of its
developers, not changes to intent).

(2) Others are also requesting changes based on thinking similar to ours in
DRIP. E.g., Adam has defined a "DRIP type", to demultiplex different DRIP
structures inside ASTM F3411 Authentication Messages; others have suggested
an authentication mechanism byte, indexing into a list similar to IANA's
registered protocol ports. This bodes well, assuming we can harmonize some
of the heretofore independent efforts. Gabriel has already put Bob M. in
contact with one individual investigating use of IEEE 1609 certificates in
UAS RID.

ASTM's next big meeting is 2 weeks before IETF 109. We shall see. :-)

---

From: "shuaiizhao(Shuai Zhao)" <[email-masked]>
Date: Wed, 14 Oct 2020 22:09:16 +0000

Thanks Stu for the update,

let’s assume ASTM will take DRIP RID type onboard. At the end of day, who has the final authority to assign and distribute RID? From current regulation reading, I would assume only USS/UTM has the capability to do that. What is your vision?

Best,
Shuai Zhao

From: Tm-rid <[email-masked]> on behalf of "Card, Stu" <[email-masked]>
Date: Tuesday, October 13, 2020 at 15:28
To: "[email-masked]" <[email-masked]>
Cc: "Cox, Gabriel C" <[email-masked]>
Subject: [Drip] short ASTM update(Internet mail)

I had a brief conversation today with Gabriel Cox (cc'ed), leader of the ASTM F38.02 workgroup that produced F3411-19 and will at some point revise it:

(1) ASTM will continue to hold off substantive revisions until the FAA publishes a final rule. ASTM may make some minor editorial changes (corrections to the document that reflect the original intent of its developers, not changes to intent).

(2) Others are also requesting changes based on thinking similar to ours in DRIP. E.g., Adam has defined a "DRIP type", to demultiplex different DRIP structures inside ASTM F3411 Authentication Messages; others have suggested an authentication mechanism byte, indexing into a list similar to IANA's registered protocol ports. This bodes well, assuming we can harmonize some of the heretofore independent efforts. Gabriel has already put Bob M. in contact with one individual investigating use of IEEE 1609 certificates in UAS RID.

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 14 Oct 2020 18:23:14 -0400

Let me give this a try, based on my reading of the FAA UAS ConOps.

All RID MUST be registered to a USS. The USS maintains all direct 
communications with UAS and forwards appropriate information to UTM.  
UTM may have other sources of information on UAS and MAY query USS for 
more information on a UAS.

RID Type = 2 is CAA Assigned Registration Number.  Obviously, the UAS 
got this from its CAA and uses it in its registration with its USS.

RID Type = 1 is ANSI/CTA-2063-A.  This is Manufacturer assigned to the 
UAS.  It is used in the UAS registration with the USS.

RID Type = 3 is UUID.  This can go either way: created by the UAS and 
registered to the USS or created by the USS during registration.

We envision RID Type = DRIP (4?) to be UAS created and registered to USS.

We have learned that there may well be additional RID types.  How those 
will work will be revealed in time.  The FAA UAS ConOps (and other CAAs) 
will still apply.

On 10/14/20 6:09 PM, shuaiizhao(Shuai Zhao) wrote:
> let’s assume ASTM will take DRIP RID type onboard. At the end of day, 
> who has the final authority to assign and distribute RID? From current 
> regulation reading, I would assume only USS/UTM has the capability to 
> do that. What is your vision?
>
> Best,
>
> Shuai Zhao
>
> *From: *Tm-rid <[email-masked]> on behalf of "Card, Stu" 
> <[email-masked]>
> *Date: *Tuesday, October 13, 2020 at 15:28
> *To: *"[email-masked]" <[email-masked]>
> *Cc: *"Cox, Gabriel C" <[email-masked]>
> *Subject: *[Drip] short ASTM update(Internet mail)
>
> I had a brief conversation today with Gabriel Cox (cc'ed), leader of 
> the ASTM F38.02 workgroup that produced F3411-19 and will at some 
> point revise it:
>
> (2) Others are also requesting changes based on thinking similar to 
> ours in DRIP. E.g., Adam has defined a "DRIP type", to demultiplex 
> different DRIP structures inside ASTM F3411 Authentication Messages; 
> others have suggested an authentication mechanism byte, indexing into 
> a list similar to IANA's registered protocol ports. This bodes well, 
> assuming we can harmonize some of the heretofore independent efforts. 
> Gabriel has already put Bob M. in contact with one individual 
> investigating use of IEEE 1609 certificates in UAS RID.
>

---

From: "shuaiizhao(Shuai Zhao)" <[email-masked]>
Date: Wed, 14 Oct 2020 22:36:48 +0000

Thanks Stu, very informative.

Best,
Shuai Zhao

From: Robert Moskowitz <[email-masked]>
Date: Wednesday, October 14, 2020 at 15:23
To: "shuaiizhao(Shuai Zhao)" <[email-masked]>, "Card, Stu" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "Cox, Gabriel C" <[email-masked]>
Subject: Re: [Drip] short ASTM update(Internet mail)

All RID MUST be registered to a USS. The USS maintains all direct communications with UAS and forwards appropriate information to UTM.  UTM may have other sources of information on UAS and MAY query USS for more information on a UAS.

RID Type = 2 is CAA Assigned Registration Number.  Obviously, the UAS got this from its CAA and uses it in its registration with its USS.

RID Type = 1 is ANSI/CTA-2063-A.  This is Manufacturer assigned to the UAS.  It is used in the UAS registration with the USS.

RID Type = 3 is UUID.  This can go either way: created by the UAS and registered to the USS or created by the USS during registration.

We have learned that there may well be additional RID types.  How those will work will be revealed in time.  The FAA UAS ConOps (and other CAAs) will still apply.
On 10/14/20 6:09 PM, shuaiizhao(Shuai Zhao) wrote:
Thanks Stu for the update,

Best,
Shuai Zhao

From: Tm-rid <[email-masked]><mailto:[email-masked]> on behalf of "Card, Stu" <[email-masked]><mailto:[email-masked]>
Date: Tuesday, October 13, 2020 at 15:28
To: "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Cc: "Cox, Gabriel C" <[email-masked]><mailto:[email-masked]>
Subject: [Drip] short ASTM update(Internet mail)

-->

---

From: "Stuart W. Card" <[email-masked]>
Date: Wed, 14 Oct 2020 20:54:56 -0400

interspersed

> Thanks Stu, very informative.

Actually that was Bob. :-)

I've continued to cc: Gabriel in case he wishes to add anything.

> *From: *Robert Moskowitz <[email-masked]>
> ...

Good description, but there are some permutations --

- UAS participating in UTM & RID: ID will be registered w/USS

- UAS participating in neither: some government & many hobby aircraft,
the latter only in special designated flying areas (in the US, the FAA
NPRM calls these "FAA-Recognized Identification Areas", a strange name
for an area where the UAS do _not_ identify themselves, applications for
designation as such must be in within 1 year from a final rule & such
areas will be phased out over time): ID unregistered or does not exist

- UAS participating in UTM but not RID: not contemplated AFAIK (except
maybe some government aircraft only partially participating in UTM)

- UAS participating in RID but not UTM: likely, especially hobbyists, in
the US: could only do Broadcast, not Network, RID, therefore not
proposed in the FAA NPRM (but little birdies suggest final rule may be
very different): ID would have to be an ASTM UAS ID type other than 3,
probably 1 as that would be "burned in" by the manufacturer: in the EU,
very likely, even for commercial UAS, at least until U-space comes

> got this from its CAA and uses it in its registration with its USS.

Well, the UAS _operator_ got it from the CAA, and provisioned the UAS
with it. UAS that do things like this autonomously are a ways out. ;-)

> UAS.  It is used in the UAS registration with the USS.

We have a way that a manufacturer can generate, from a keypair, both an
ANSI/CTI-2063-A compliant serial number and a HHIT, so that either can
be regarded as an encoding of the other. Thus, out of the box, we get
something already recognized in ASTM F3411 and the [proposed] rules,
enabling all the benefits of our proposed Type 4 except unlinkability of
single use session IDs, that can be used to sign subsequent single use
session IDs (or the "genesis block" of a chain of such). :-)

> registered to the USS or created by the USS during registration.

Again, we have a way that an UAS can generate and propose to its USS,
from a keypair, both an UTM UUID and a HHIT, such that the latter can be
inferred from the former together with the RAA and HDA corresponding to
the USS (but not vice versa as there is more entropy in the UUID than in
the HHIT). Thus, from Network RID (we don't learn the ID of the USS from
Broadcast), we again can deduce a HHIT, enabling e.g. HIP for Observer
to Pilot comms.

> ...

That's the most fundamental thing we are requesting from ASTM:
recognition of HHIT as a valid UAS ID Type.

We've also suggested that type 15 might be designated for experimental
use and type 14 for organizational use (where an organization has
exclusive control of a large airspace volume), but that goes beyond the
concerns of the DRIP WG.

Adam has worked out procedures for the UAS operator and the UA itself to
generate keypairs, derive HHITs, propose them to the USS, if approved
get back very compact (fitting in Broadcast RID) certificates proving
registration, etc.

> ...
>     let’s assume ASTM will take DRIP RID type onboard. At the end of
>     day, who has the final authority to assign and distribute RID? From
>     current regulation reading, I would assume only USS/UTM has the
>     capability to do that. What is your vision?
> 

-- 
-----------------------------------------
Stuart W. Card, PhD, Principal Engineer
AX Enterprize, LLC  www.axenterprize.com
4947 Commercial Drive, Yorkville NY 13495