On Tue, Mar 14, 2023 at 08:36:43AM -0500, Orie Steele wrote:
> Here is the I-D, I promised:
>
> https://datatracker.ietf.org/doc/html/draft-steele-cose-merkle-tree-proofs-00
>
> There are a few rough edges still, I look forward to discussing with
> the group.
Some quick comments/ideas:
- Extra data should either be supported by every tree algorithm, or
eliminated. Otherwise it seems like a nasty footgun.
- Add optional nonce in SignedMerkleTreeProof (to make some attacks
harder). The nonce must go into the leaf hash first.
- UndirectionalInclusionPath should either be used or eliminated.
- The payload could be detached like in signatures.
- The structure could be flattened. Something like:
SignedMerkleTreeProof = [
root_protected: bstr .cbor header_map,
root_unprotected: header_map,
index: uint,
peer_hashes: [+ bstr],
nonce: bstr / nil,
extra_data: bstr / nil,
payload: bstr / nil,
root_signature: bstr,
]
Where root_* are the corresponding fields from COSE_Sign1 forming the
root signature.
If root_protected does not contain tree size property, then index
contains path vector (lsb is toward leafs, 1 is right, 0 is left).
- To prevent possible cross-protocol attacks, either this needs to
flag the tree algorithm as critical or use a new context for
signature.
- The hash data could be CBOR-encoded:
InternalNode = [
left: bstr,
right: bstr,
]
LeafNode = [
nonce: bstr / nil,
extra_data: bstr / nil,
payload: bstr,
]
And then the hash is either:
HASH(CanonicalEncode(InternalNode))
HASH(CanonicalEncode(LeafNode))
Where CanonicalEncode is the canonical encoding as in RFC 9052.
These can not collide, because one is 2 elements (always starts with
0x82) and the other is 3 (always starts with 0x83).
-Ilari
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
