If I understand this proposal correctly, a value for SCITT-CCF-ES256 would be added to the IANA-maintained COSE Algorithms registry. Right now, all of the entries are for cryptographic algorithms. I'd like to hear what the Designated Experts think about using the registry to identify an application-specific structure in addition to the cryptographic algorithm.
Russ > On Oct 4, 2022, at 8:00 AM, Maik Riechert > <[email protected]> wrote: > > 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 > <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 > <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 > <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] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/cose > <https://www.ietf.org/mailman/listinfo/cose>
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
