Below is some pseudo-inline review of this document for gen-art. Without authentication, an Observer has no basis for trust. As the messages are sent via wireless broadcast, they may be transmitted anywhere within wireless range and making any claims desired by the sender. Observer has not yet been defined here, is it expected that the reader knows what this refers to? DRIP Specific Authentication Methods, carried in ASTM Authentication Messages (Message Type 0x2) are defined herein. These methods, when properly used, enable a high level of trust in that the content of other ASTM Messages was generated by their claimed registered source. The last sentence here is a bit confusing, consider rewording "enable a high level of trust in that the". Extended Transports: use of extended advertisements (Bluetooth 5.x), service info (Wi- Fi NaN) or vendor specific element information (Wi-Fi BEACON) in broadcast frames as specified in [F3411]. Must use ASTM Message Pack (Message Type 0xF). Is Wi-Fi NaN supposed to be Wi-Fi NAN? HHIT Domain Authority (HDA): A class of DIME usually associated with a USS in UTM. Is it expected that the reader know what DIME, USS, and UTM are? [F3411] defines Authentication Message framing only. It does not define authentication formats or methods. It explicitly anticipates several signature options, but does not fully define even those. [F3411] Annex A1 defines a Broadcast Authentication Verifier Service, which has a heavy reliance on Observer real-time connectivity to the Internet (specifically into UTM) that is not always guaranteed. Fortunately, [F3411] also allows third party standard Authentication Types, several of which DRIP defines herein. "but does not fully define even those." -> "but does not fully define those." "which has a heavy reliance on Observer real-time connectivity to the Internet (specifically into UTM) that is not always guaranteed." -> "which has a heaby reliance on an Observer's real-time connectivity to the Internet" 3.1.4. UAS RID Trust Section 3.1.1, Section 3.1.2 and Section 3.1.3 above complete the trust chain but the chain cannot yet be trusted as having any relevance to the observed UA because reply attacks are trivial. At this point the key nominally possessed by the UA is trusted but the UA has not yet been proven to possess that private key. Should "reply" be "replay"? Also, I'm not sure what "cannot yet be trusted as having any relevance to the observed UA" means. 4.3.1. Message Count When decoding a DRIP Wrapper on a receiver, the number of messages wrapped can be determined by checking the length between the UA DET and the VNB Timestamp by UA is a multiple of 25-bytes. Consider rewording. "checking" here sort of implies that an invariant is being checked, rather than the number of messages being calculated (i.e. integral division by 25). The functionality of Wrapper in this form is identical to Message Set Signature (Authentication Type 0x3) when running over Extended Transports. What Wrapper provides is the same format but over both Extended and Legacy Transports allowing the transports to be similar. Message Set Signature also implies using the ASTM validator system architecture which relies on Internet connectivity for verification which the receiver may not have at the time of receipt of an Authentication Message. This is something Wrapper, and all DRIP Authentication Formats, avoid when the UA key is obtained via a DRIP Link Authentication Message. "Wrapper" without an article (the) reads a bit strangely, and in the subsequent paragraph "the Wrapper format" is used instead. The primary limitation of the Wrapper format is the bounding of up to 4 ASTM Messages that can be sent within it. Another limitation is that the format can not be used as a surrogate for messages it is wrapping. This is due to high potential a receiver on the ground does not support DRIP. Thus, when Wrapper is being used the wrapper data must effectively be sent twice, once as a single framed message (as specified in [F3411]) and then again wrapped within the Wrapper format. As above, some inconsistency with "Wrapper" and "wrapper" and "the Wrapper format". By hashing previously sent messages and signing them we gain trust in a UA's previous reports without retransmitting them. An Observer who has been listening for any length of time SHOULD hash received messages and cross-check them against the manifest hashes. This is a way to evade the limitation of a maximum of 4 messages in the Wrapper Format (Section 4.3.3) and greatly reduce overhead. As above, "the Wrapper Format" is now used, inconsistent with above. Judicious use of Manifest enables an entire Broadcast RID message stream to be strongly authenticated with less than 100% overhead relative to a completely unauthenticated message stream (see Appendix E). Similar to comment on "Wrapper", "Judicious use of Manifest" without a leading article (i.e. "the Manifest") reads awkwardly. The evidence section of the DES (Section 4.1.2) is populated with 8-byte hashes of [F3411] Broadcast RID messages and two special hashes (Section 4.4.2). All these hashes can be concatenated together into a single byte object or be set in the evidence section individually. The Previous Manifest Hash and Current Manifest Hash MUST always come before the ASTM Message Hashes as seen in Figure 8. "concatenated together into a single byte object" is a bit confusing -- does this imply mixing the hashes into a single byte or literally concatenating the bytes to form a byte sequence? A receiver SHOULD use the manifest to verify each ASTM Message hashed therein that it has previously received. It can do this without having received them all. A manifest SHOULD typically encompass a single transmission cycle of messages being sent, see Section 6.4 and Appendix E. Is manifest not "Manifest" here? If so, the distinction is not completely clear. The number of hashes in the Manifest can be variable (2-11). An easy way to determine the number of hashes is to take the length of the data between the end of the UA DET and VNB Timestamp by UA and divide it by the hash length (8). If this value is not an integer, the message is invalid. As above with "Manifest". Also, "If this value is not an integer," seems imprecise. Integer division by most definitions only results in integers. I assume what was intended is that length of the data must be integer-divisible by the hash length. 9.1. Replay Attacks The astute reader may note that the DRIP Link messages, which are recommended to be sent, are static in nature and contain various timestamps. These DRIP Link messages can easily be replayed by an attacker who has copied them from previous broadcasts. If an attacker (who is smart and spoofs more than just the UAS ID/ data payloads) willing replays an DRIP Link message they have in principle actually helped by ensuring the message is sent more frequently and be received by potential Observers. "astute" and "smart" are not required here, I would recommend sticking to being factual. Additionally, "willing replays an DRIP Link message they have in principle actually helped by ensuring the message is sent more frequently and be received by potential Observers." is a confusing sentence, and I do not know what it means exactly.