On Tue, Oct 04, 2022 at 12:00:27PM +0000, Maik Riechert 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 > } > ] > ]
As note, the "node_certificate" seems to be defined as X.509 certificate. X.509 is enormously complex. And furthemore, the draft looks to be using X.509 keys for signing with COSE, which is very questionable thing to do. And then looking at the structures, it looks like this only allows for two-length certificate chain? If so, this thing looks like it could be simplified a lot. And from presence of inclusion_proof field, I presuem this is intended to be some sort of synchronous batch signature. However, the inclusion proof looks odd: This seems to be modelled after Certificate Transparency. However, in addition to node hashes, CT needs leaf index and tree size to construct its inclusiong proof. [+ ProofElement] would look to be just node hashes. > 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: I do not see how this makes sense. The protected header is leaf attributes, which belong together with the leaft itself. While top- level structure would seem to be about the the root. > The new `contents` would then look like this: > <...> > > If you then squint a bit more, you can re-imagine this as a COSE V2 > countersignature: I do not see this being any kind of countersignature. To me it looks like a normal signature on constructed piece of data. It might be useful to use detached signatures: Have enough information in unsigned receipt to construct the to-be-signed for the tree root signature, and then sepearatedly store the protected headers for the root signature and the signature value for the root signature. Yes, this allows malleability with root used, but I do not see that is a problem. I don't think that could even be eliminated without signing each leaf separatedly (Certificate Transparency does not eliminate it even with leaf signatures). > 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. Is this application-specific versions of algorithms? I do not see how this could lead to anything else than enormous amounts of excess complexity. Application-specific signature algorithm is already plenty bad, this seems much worse than that. And I can say that, if I was a DE, I definitely would not approve this. > 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. I do not see that as a precedent: Only the cryptographic primitive sees the substrucutre. Anything above, be it COSE or anything else does not see there being any substructure. > 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. What I think would be a third option, a message containing roughly the following. But I would not be surprised if I was missing something why nothing like this could work: - protected headers from root COSE_Signature0 - attached COSE_Signature0 over node COSE_Key (using headers if needed) - Root timestamp - Tree size - Leaf pseudo-index (left/right choices on path from root, these might not be unique: E.g. p-i 3 in RFC 9162 s. 2.1.5.) - Inclusion proof hashes - leaf protected headers (including timestamp and possible hash salt) - leaf data - signature from root COSE_Signature0 To recover the data for root signature: - Any extra attributes are already in protected headers. - Root timestamp from dedicated field. - Tree size from dedicated field. - The root hash can be computed from leaf hash and proof hashes, with leaf pseudo-index telling if to combine left or right in each step. - Leaf hash can be calculated from leaf protected headers and leaf data. - Key can be obtained by verifying the signature on node key and unwrapping the signature. This does not use countersignatures or multi-signatures, only the most basic COSE signature mode. It is essentially a simplified form of Certificate Transparency (e.g., dropping leaf signatures by assuming synchronous root signing). Consistency proofs work like in CT. -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
