I'm a -1 to needing to register a new alg for every existing registered alg when used with counter signatures... specifically:
- SCITT-CCF-ES256 - SCITT-CCF-EdDSA - SCITT-CCF-ES384 - SCITT-CCF-FANCY_NEW_PQC_1 - SCITT-CCF-FANCY_NEW_PQC_2 - SCITT-CCF-FANCY_NEW_PQC_3 Can we move the "application specific" component of the "alg" value to a separate field? Example: alg: ES256 // support existing alg values with no changes cty: 'application/scitt-ccf' // signal the content type ? Regards, OS On Tue, Oct 4, 2022 at 7:44 AM Russ Housley <[email protected]> wrote: > 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) > 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 > > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose > -- *ORIE STEELE* Chief Technical Officer www.transmute.industries <https://www.transmute.industries>
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
