Hi all,
In the SCITT community call yesterday we had a discussion on receipts
(https://datatracker.ietf.org/doc/html/draft-birkholz-scitt-receipts-01) and
whether they should be represented as standard COSE V2 countersignatures
(https://datatracker.ietf.org/doc/html/draft-ietf-cose-countersign).
The current receipt format's CDDL is as follows:
[
service_id: tstr
contents: any
]
where `contents` depends on the "tree" algorithm (with the requirement that it
has to contain a protected header somewhere in it) identified via parameters
associated to the service_id. Currently there is only a single tree algorithm
(based on a CCF ledger implementation) where the CDDL is as follows:
[
signature: bstr
node_certificate: bstr
inclusion_proof: [+ ProofElement]
leaf_info: [
internal_hash: bstr
internal_data: bstr
protected: bstr .cbor {
issuedAt: uint
}
]
]
In order to support more schemes around key discovery (e.g., DID), it makes
sense to move the protected header to the front and make it part of the common
top-level structure:
[
protected: bstr .cbor {
service_id: tstr
issuedAt: uint
},
contents: any
]
The new `contents` would then look like this:
[
signature: bstr
node_certificate: bstr
inclusion_proof: [+ ProofElement]
leaf_info: [
internal_hash: bstr
internal_data: bstr
]
]
If you then squint a bit more, you can re-imagine this as a COSE V2
countersignature:
[
protected: bstr .cbor {
alg: tstr
service_id: tstr
issuedAt: uint
},
unprotected: { * label => values }
signature: bstr
]
For the CCF tree algorithm, this would equate to `alg` being a new identifier
(e.g., "SCITT-CCF-ES256") and the signature being the `contents` structure
wrapped as bstr.
Russ raised concerns that carrying all of the additional bits in the signature
bytes may be hard to justify when it comes to registration of the new signature
algorithm in COSE's IANA registry. There seems to be precedent though, for
example https://datatracker.ietf.org/doc/html/rfc8778 where for Leighton-Micali
the signature value (see 2.2) is a structure containing a leaf number, an
LM-OTS signature, a type code indicating a subalgorithm, and a tree path from
leaf to root.
We discussed two alternatives: 1. Keeping it a separate format specific to
SCITT. 2. Establishing receipts as new COSE message type, though this may be
more challenging.
Any discussions and opinions on this topic are highly appreciated.
Maik
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
