Subject: [Drip] Review of UAS RID v06

From: Adam Wiethuechter <[email-masked]>
Date: Mon, 4 Jan 2021 21:59:52 +0000

Bob,

I finally am reviewing your latest UAS RID draft (version 06).

Section 2.2
I believe your notation is fine and understandable here. Let's stick with it.

Section 3.4
"This can be either a standalone Authentication Message, or an enhanced self attestation Authentication Message." I am not sure what you mean by this. The Manifest Authentication Message is by design an "enhanced self-attestation" as it is a payload type of the Wrapper Frame.

When you say "Alternatively the ASTM Message Pack (Msg Type 0xF) can provide this feature, but only over Bluetooth 5 or WiFi NAN broadcasts" you are explicitly calling out the "5 Wrapped ASTM Messages" format - cite it (Section 4.2.3.1.3 of Auth Formats).

Section 9.3
Fix the names in the text to be updated to your new ones (or the ones I propose below).

Appendix E and E.1
I do not understand why Appendix E and E.1 are still present. They are covered by F.2.1 and F.4 respectively. The text of the E sections can be moved into the F sections to avoid duplication.

Appendix F
I like these functional style naming conventions. I propose the following change: the parameters be a list of the owners (X, Y, etc.) and the expected type (HHIT, HI, Attestation, Certification, Assertion, etc.).

For F.2 (Self-Attestation) would be the functional notation of Attestation(X: HHIT, X: HI).
For F.2.1 (Concise Self-Attestation) would be the functional notation of Attestation(X: HHIT)
For F.3 (???) would the functional notation of Certificate(X: Assertion, Y: Assertion)
For F.3.1 (Concise Certificate) would the functional notation of Certificate(X: HHIT, Y: Assertion)
For F.4 (Offline Broadcast Attestation) would the functional notation of Attestation(X: HHIT, Y: HHIT, Y: HI)

F.1 is excluded from above as it is a special case I think and makes things awkward. It would be HHIT = Claim/Assertion(...) or something similar.

This allows us to keep our short hands of different structures. Aoo still is Attestation(Operator, Operator) - but its implicit that the first is the HHIT in the function and the second is the HI.

Anyone have any comments on this change??

Appendix F.3
I see you couldn't come up with a good short name either. I also see you caught an error in my work. Two bytes would give me a max value of 65535 (why was I thinking it was 255???). I added those two Length fields and intended to have a discussion on them before the merge happened. Let's see if people have any comments on these.

I am unsure if allowing the mixing of full and concise forms is a good idea, but I'd rather allow for the flexibility than explicitly reject it unless it presents a serious issue.

I am a bit concerned about the wording for Assertion(X) and Assertion(Y) in the figure. Is it really an entity anymore? Also is Assertion even the right term here? I used it kind of as a place holder and it doesn't exactly work with what is defined in Section 2.2 as is. Attestation/Certificate is better but becomes self-referential which is problematic, I think.

Appendix F.3.1
This used to be the Certificate used in Broadcast - hence the limitation of 200 bytes. Considering we have a newer better certificate (F.4) the requirement of 200 bytes can be removed on this one. The text "Ayy MUST NOT be the in Concise Form." can be removed.

This should then be called "Concise Certificate(X, Y)". Ayy should be expanded to Assertion Y in the figure and the accompanying text updated to use that instead of Ayy.

We do not need a length field here as the start of the format (HHIT of 16 bytes) and end (ETS + Sig of 68 bytes) never changes. Just blindly extract the middle between these points (Assertion Start Byte = 17, Assertion End Byte = Length of Concise Certificate - 68).

That's all I see for now.

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

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 4 Jan 2021 17:08:46 -0500

Adam,

Thanks for the review.  -06 was mostly a merge and I knew it needed 
cleanup and such, but the best way to get that is to put it out for review!

On 1/4/21 4:59 PM, Adam Wiethuechter wrote:
> *Section 2.2*
> *Section 3.4*
> "This can be either a standalone Authentication Message, or an 
> enhanced self attestation Authentication Message." I am not sure what 
> you mean by this. The Manifest Authentication Message is by design an 
> "enhanced self-attestation" as it is a payload type of the Wrapper Frame.
>
> When you say "Alternatively the ASTM Message Pack (Msg Type 0xF) can 
> provide this feature, but only over Bluetooth 5 or WiFi NAN 
> broadcasts" you are explicitly calling out the "5 Wrapped ASTM 
> Messages" format - cite it (Section 4.2.3.1.3 of Auth Formats).

Probably hanging chad that missed pruning from prior versions.  I will 
check it out.

> *
> *
> *Section 9.3*
> *Appendix E and E.1*
> I do not understand why Appendix E and E.1 are still present. They are 
> covered by F.2.1 and F.4 respectively. The text of the E sections can 
> be moved into the F sections to avoid duplication.

It is not a clear mapping.  So I left it in for now to give me and 
others time to think how best to merge E into F.

>
> *Appendix F*
> I like these functional style naming conventions. I propose the 
> following change: the parameters be a list of the owners (X, Y, etc.) 
> and the expected type (HHIT, HI, Attestation, Certification, 
> Assertion, etc.).

I will go through these and work out how to update the text.

> F.1 is excluded from above as it is a special case I think and makes 
> things awkward. It would be HHIT = Claim/Assertion(...) or something 
> similar.
>
> This allows us to keep our short hands of different structures. Aoo 
> still is Attestation(Operator, Operator) - but its implicit that the 
> first is the HHIT in the function and the second is the HI.
>
> *Appendix F.3*
> I see you couldn't come up with a good short name either. I also see 
> you caught an error in my work. Two bytes would give me a max value of 
> 65535 (why was I thinking it was 255???). I added those two Length 
> fields and intended to have a discussion on them before the merge 
> happened. Let's see if people have any comments on these.
>
> I am unsure if allowing the mixing of full and concise forms is a good 
> idea, but I'd rather allow for the flexibility than explicitly reject 
> it unless it presents a serious issue.
>
> I am a bit concerned about the wording for Assertion(X) and 
> Assertion(Y) in the figure.

I was concerned as well, but copied the text for later review.

> Is it really an entity anymore? Also is Assertion even the right term 
> here? I used it kind of as a place holder and it doesn't exactly work 
> with what is defined in Section 2.2 as is. Attestation/Certificate is 
> better but becomes self-referential which is problematic, I think.
> *
> *
> *Appendix F.3.1 *
> This used to be the Certificate used in Broadcast - hence the 
> limitation of 200 bytes. Considering we have a newer better 
> certificate (F.4) the requirement of 200 bytes can be removed on this 
> one. The text "Ayy MUST NOT be the in Concise Form." can be removed.
>
> This should then be called "Concise Certificate(X, Y)". Ayy should be 
> expanded to Assertion Y in the figure and the accompanying text 
> updated to use that instead of Ayy.
>
> We do not need a length field here as the start of the format (HHIT of 
> 16 bytes) and end (ETS + Sig of 68 bytes) never changes. Just blindly 
> extract the middle between these points (Assertion Start Byte = 17, 
> Assertion End Byte = Length of Concise Certificate - 68).
>

Thanks.  I have some work to do,...,