Inline: On Wed, Oct 5, 2022 at 4:35 AM Ilari Liusvaara <[email protected]> wrote:
> 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. > I had the same thought, when I finally understood the proposal. > > 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. > > > I'm not sure I fully follow, but if it's possible to achieve the desired outcome, without creating new registry entries, and without creating ambiguity with respect to what a "counter signature" is, That is a desirable feature. > > -Ilari > > _______________________________________________ > 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
