Likewise I am with Orie on this one cty or similar would make things a whole lot cleaner for Interop reasons and prevents a lot of potential confusion and complexity
Mike Prorock mesur.io On Tue, Oct 4, 2022, 07:01 Orie Steele <[email protected]> wrote: > 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 >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
