We're in the process of revising the cbor diagnostic for
https://datatracker.ietf.org/doc/html/draft-ietf-cose-merkle-tree-proofs

I still feel uncomfortable with how the commitment to the verifiable data
structure is done in the protected header,
and how the mutable / redactable proof types are referenced in the
unprotected header.

Different verifiable data structures have different proof types, for
example binary merkle trees support inclusion proofs.

I'm wondering if it would be better to make a top level unprotected header
parameter that was a map, and then
nest all the proof details under it, if we don't do this, we might see
collisions on proof types, seems like we need to add
another layer of nesting in the unprotected header.

This would somewhat mirror how
https://datatracker.ietf.org/doc/draft-ietf-cose-cwt-claims-in-headers/
creates a new
map in the protected header.

Instead of our current example output, we would have something like:

protected header:
{
    1: -35,
    TBD_1: 1 // TBD_1 indicates a type of verifiable data structure, 1
indicates RFC9162 binary merkle tree.
}

unprotected header:
{
    TBD_2: { // TBD_2 indicates verifiable data structure proofs
       100: [ ... ], // 100 indicates inclusion proofs
       200: [ ... ]  // 200 indicates consistency proofs
    },
   // ... other unprotected header params here...
}

This is what the current tooling we have outputs:

Signed Inclusion Proof

~~~~ cbor-diag
18(                                 / COSE Single Signer Data Object        /
    [
      h'a2013822...5f636838',       / Protected header                      /
      {                             / Unprotected header                    /
        100: [                      / Inclusion proofs (1)                  /
          h'83020181...c6bf0202',   / Inclusion proof 1                     /
        ],

        200: [                      / Consistency proofs (1)                /
          h'e5f5a481...c8ffd5e6',   / Consistency proof 1                   /
        ],

}, h'', / Detached payload / h'6140da0f...419c8ec0' / Signature / ] ) ~~~~

Decoded Protected Header

~~~~ cbor-diag
{                                   / Protected header                      /
  1: -35,                           / Cryptographic algorithm to use        /
  4: h'75726e3a...5f636838',        / Key identifier                        /
  TBD_1: 1                          / Type of verifiable data structure     /
}
~~~~

Regards,

OS
-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose

Reply via email to