[Drip] Comments on draft-wiethuechter-drip-identity-claims-02

[Robert Moskowitz <[e-mail]>]

Adam had sent me a pre-submit copy, I sent him my comments in two 
emails.  He incorporated some of my comments and submit what is now ver 
-02.  Here is an edit version of his two responses of those items not 
addressed:



On 10/26/20 9:33 PM, Wiethuechter, Adam wrote:
> Bob,
>
> See inline from me.
>
> On Mon, Oct 26, 2020 at 3:39 PM Robert Moskowitz 
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>
>
>     On 10/23/20 4:32 PM, Wiethuechter, Adam wrote:
>     > All,
>     >
>     > Attached is my latest Identity Claims draft. This draft is now
>     written
>     > solely in Markdown.
>     > All the text has been rewritten to switch back to using the term
>     > "certificate" but kept a section to mention that "claim" could
>     also be
>     > used.
>     >
>     > Cleaned up text for provisioning under DRIP for all relevant
>     parties.
>     > Added a small version of Cxx (from Bob's draft). Lots of small
>     stuff.
>
>     This small form is really important.
>     Plus you need at least 1 less BT4 frame?  That should improve
>     reliability.
>
>
> <atw>
> True. However just this certificate form is never sent. It is always 
> wrapping something. HHIT + Trust Timestamp + Payload + Signature.
> Really no one should ever send this certificate because it's useless 
> unless the Observer has connectivity.
> </atw>
>
>
>     Need to remove [hhit-registries] from the draft.  I suppose it can
>     stay
>     for this version.  We really need that EPP draft already.
>
>
> <atw>
> Where is EPP draft??
> </atw>
>
>     "   These certificates when chained together can create a chain of
>     trust
>         back to the manufacturer itself during the initial
>         production of a given Aircraft.  The chain can also be used by
>         authorized entities to trace an Aircraft through all owners and
>         flights in the Aircraft's lifetime (ICAO practice on manned
>     aircraft)."
>
>
>
>     I hope that the manufacturer is not the root of trust?  Well I
>     will see
>     as I proceed.  Plus you use chain in the next sentence.
>
>
> <atw>
> AFAIK yes. For ICAO they seem to want the manufacturers to maintain or 
> be part of a CA.
> </atw>
>
>
>     Note that Cxx has its uses, but in Broadcast Auth messages is open to
>     replay attacks.  There are various ways you can mitigate this in your
>     drip-auth draft, not limited to my drip-rid self-claim example.
>
>
> <atw>
> Cxx should never be sent as itself. Instead it should be part of a 
> larger certificate; such as Cxy when creating Cra.
> </atw>
>
>
>
>     > 2) Section 3.2: There are some words on how the Expiration
>     Timestamp.
>     > I feel like these important words get buried in the text and how
>     care
>     > should be taken for how far into the future they should be set.
>     > Suggestions welcome.
>
>     First I think that the sense of X and Y should be changed.
>
>
>     "where Entity y asserts trust in the binding claimed by Entity x
>     (in Cxx)".
>
>     This is more in line with X.509 field order, and thus the way many
>     think
>     of this.
>
>     3.2.1
>
>     Again, I think you should switch x and y.  Also Cxx is first,
>     followed
>     by HHIT(y).
>
>     Note the replay attack here and how you may mitigate it.
>
>
> <atw>
> Have Cxx first before HHIT(y) is counter intuitive as the owner of 
> HHIT(y) would sign OVER Cxx.
>
> The first field makes more sense to be the key to who is actually 
> signing the whole payload (HHIT | Cyy | Expiration Timestamp).
>
> X/Y is arbitrary as this is a generic form. Perhaps if it explicitly 
> states that the signature is from the same entity that owns Cxx or the 
> HHIT would fix this ambiguity?
> </atw>

And:



On 10/26/20 9:43 PM, Wiethuechter, Adam wrote:
> See inline.
>
> On Mon, Oct 26, 2020 at 3:59 PM Robert Moskowitz 
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>
>
>     On 10/23/20 4:32 PM, Wiethuechter, Adam wrote:
>     > All,
>     >
>
>
>     4.5.2
>
>         To start the Operator generates on behalf of the Aircraft a new
>         keypair and Certificate: Aircraft N on Aircraft N.  This
>     keypair and
>         certificate are injected into the Aircraft for it to generate
>         Certificate: Aircraft 0 on Aircraft N. [perhaps keypairs are
>         extracted to allow for this to happen externally as well??
>     Security
>         risk?]
>
>     on Aircraft N.  After injecting the keypair and certificate, the
>     Operator MUST destroy all copies of the keypair.
>
>     5. Security Considerations
>
>     This is why the cache is HDA's HHIT *and* HI.  Now the attack is
>     limited
>     to replicating the HDA's keypair.
>
>
> <atw>
> Is this a generic comment here or actual text you think should be in 
> that section?
> </atw>

I really need to do a new review and there is this difference between 
the theory of the attestations and what will be done in reality within 
the ASTM Authentication Message and the UAS <-> USS interactions.