Subject: [Drip] Manifest Psuedo-Blockchain Hashes

From: "Wiethuechter, Adam" <[email-masked]>
Date: Fri, 31 Jul 2020 07:56:47 -0400

All,

Yesterday at our meeting I had a sub-point on slide 20 mentioning a
question on order of operations. I am at the stage of prototyping this
portion of the draft and I would like feedback on this.

Some context (not presented at the meeting)...can be found here [1].
The manifest formats have two special hashes that create a
"pseudo-blockchain" between manifest messages. These hashes are of the
previous manifest and the current manifest.

So a question is how does one exactly create the current manifest hash and
how does it interact with the signing of the entire wrapper frame. I see
two possible options at this time;

1) Set the current manifest hash field to 0. Hash previous manifest hash +
current manifest hash [0] + message hashes and set it to the current
manifest hash. After this perform the signing of the wrapper frame.

2) Set the current manifest hash field to 0's. Sign the wrapper frame using
this value. Once signed perform a hash across the entire wrapper frame and
overwrite the 0's in the current manifest hash.

To me option 1 is the most obvious selection. We are hashing over what we
have scope over for the manifest (not bleeding out to "higher layers"). It
is also how I have currently prototyped this format and only noticed after
the fact I had deviated from what is in the Authentication Formats draft.
This also makes sense to me as then the signature is actually over what is
being sent - there is no modification of the data being signed after the
signature is computed.

Is there any justification for supporting option 2?

A follow up question to this is how the previous manifest hash is set. Does
the previous current manifest hash just get set to it or do we completely
recompute? A complete recompute would mean that at least on the first
manifest sent that the previous and current would be equal (and probably be
0's I think depends on above). Currently in my prototype the initial value
(of the previous manifest hash) is set to 0 and then the current manifest
hash on the first manifest is set to the second manifest's previous
manifest hash.

Any questions, comments or concerns on this set of problems?

[1]
https://www.ietf.org/id/draft-wiethuechter-drip-auth-03.html#name-pseudo-blockchain-hashes
-- 
73's,
Adam T. Wiethuechter
AX Enterprize, LLC