On Fri, Jun 16, 2023 at 06:19:01PM -0500, Orie Steele wrote:
> We would like some time to discuss this draft at IETF 117:
>
> https://github.com/ietf-scitt/draft-steele-cose-merkle-tree-proofs
> https://ietf-scitt.github.io/draft-steele-cose-merkle-tree-proofs/draft-steele-cose-merkle-tree-proofs.html
>
> We've made several changes that were requested at 116.
>
> We provide a sample implementation demonstrating how to use RFC9162 tree
> algorithm with COSE Sign1 to create signed "inclusion" and "consistency"
> proofs.
>
> We updated the draft to support registration of other tree algorithms which
> can be specified in separate documents.
>
> If there are other changes folks would like to see, we are happy to try to
> get them in before the cut off date.
I have hard time understanding what is actually going on, but based on
what I managed to (mis)understand:
- The "consistency" proofs in RFC9162 are not signed. I can't quickly
evaulate what would be impact of signing those.
The reason why "consistency" proofs are not signed is that those are
just post-hoc auditing methods for showing that no entries have been
dropped from the tree and that history is linear.
- There seems to be no context separation between signed "inclusion" and
"consistency" proofs, which is cryptographically suspect.
- If "consistency" proofs are not supposed to be signed, then those
should use their one (tree-algorithm-dependent) structure.
- This seems to rather dramatically reconfigure how signing works and the
inputs, so it should use a new structure.
- For "inclusion" proofs, maybe something like:
- root_parameters (bstr-encoded-map). The parameters for root. MUST
contain things like alg and tree_alg (and tree_size)?.
- leaf_parameters (bstr-encoded-map). The parameters for leaf.
- leaf (bstr). The actual leaf data.
- proof (bstr). The inclusion proof. Format depends on tree_alg.
- signature (bstr). Result of signature operation.
- The above requires reconfiguring how signing works. Maybe something
like:
The leaf context is core canonical serialization of:
- context: Fixed tstr "merkle-leaf".
- protected (bstr). The leaf_parameters.
- data (bstr). The leaf.
This is fed as a leaf to the merkle tree algorithm. The resulting
inclusion proof is placed to proof.
The root context is core canonical serialization of:
- context: Fixed tstr "merkle-root".
- protected (bstr). The root_parameters.
- root (bstr). The root hash from merkle tree algorithm.
This is fed to the signature primitive, and the resulting signature is
placed to signature.
- One usecase of leaf_parameters is dealing with the info leak described
in the document. One can add salt to leaf_parameters to fix it. This
also makes the hash function much stronger.
I also suspect that various real-world usecases want both per-leaf
and per-tree parameters.
- I suspect it is necressary to handle redaction of leafs for the
cases where leafs contain material that is just too hot to pushlish
(this can be used as an attack).
At minimum, this means that not having some leaf available (publishing
hash of redacted leaf is okay) must not break auditing of non-removal
and linearity-of-history.
- And another thing to talk about is how to deal with log failures. Even
if I don't recall any incident where Certificate Transparency log
failed due to overt malice, I recall several cases where the log
failed due to bugs, and at least two cases where "cosmic ray" caused
the log to fail.
This can impact proofs. For example, if there can be multiple
inclusion proofs from various logs, that affects format of "inclusion"
proofs, as one probably does not want to want to repeat leaf in all
the proofs (but leaf_parameters are log-dependent).
-Ilari
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
