Let me address your points in a question/answer style (hopefully covering your points well enough).
Q: Is this all application-specific? In the current spec (https://www.ietf.org/archive/id/draft-birkholz-scitt-receipts-01.html) we tried to have a minimal generic top-level structure (3.) and then depending on the "tree algorithm" an inner application-specific / tree-specific structure, currently with a single one defined to support CCF-compatible implementations. Q: Is a COSE algorithm always a cryptographic primitive? Likely. I'm assuming this is where some of the pushback comes from, as we would regard SCITT-CCF-ES256 as a cryptographic primitive in that sense, even though it is not. Q: Why not use COSE_Sign1 to sign the Merkle tree root? In an ideal world, this would be my preference as well. This issue is that existing ledger/log implementations, as far as I know, don't allow to change how the root is signed, and typically they sign the root hash directly, not as COSE_Sign1 or other envelope. Q: Why put common/root-type attributes in the leaf protected header? You're right, this is unexpected and can be regarded as a little wasteful. I consider it a compromise resulting from the constraint that the root is not signed with its own protected header, or that at least we can't generally expect that. Moving the root-type metadata into the leaf (like service_id) duplicates it across leaves. Q: Why use X.509 with COSE? Yes, COSE is more common in constrained environments which may or may not use X.509, but in general I don't see this as an issue given https://datatracker.ietf.org/doc/html/draft-ietf-cose-x509-08. Q: What exactly is in inclusion_proof? In CCF, an inclusion proof is the sequence of (hash, direction)-tuples which is just another style that doesn't rely on knowing the tree size and leaf number. Q: Do leaves get signed individually? No, at least not in CCF, and to the best of my knowledge also not in certificate transparency. In CCF, a node signs the root, and that node's certificate is endorsed by the service. There's no double signing or unwrapping needed during verification. Q: Why is this a countersignature? Good question. We were looking at SCITT as a "notary public" that applies some checks on the signed document (signature verification and other acceptance policies), files it (store in a transparency log), and applies its own signature as confirmation that this happened. I would conceptually regard this as a countersignature. Whether this should be a COSE V2 countersignature (with new signature algorithm) is another question. It may not be a good idea, and a new structure that we call receipt can conceptually still be a countersignature but technically be something new that supports the semantics of SCITT better. In either case, we would still allow the outcome to be embedded in the unprotected header of the original signed document. In general, the goal is to allow various implementations of SCITT, not all of which will be based on CCF. Trying to find a balance between application-specific parts and common structures is the challenge here. -----Original Message----- From: SCITT <[email protected]> On Behalf Of Ilari Liusvaara Sent: Mittwoch, 5. Oktober 2022 10:35 To: [email protected]; [email protected] Subject: [EXTERNAL] Re: [SCITT] [COSE] SCITT receipts as COSE V2 countersignatures [You don't often get email from [email protected]. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdat > atracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-birkholz-scitt-receipts-01& > data=05%7C01%7CMaik.Riechert%40microsoft.com%7Cdce4f9f3fd5142f84d4408d > aa6b4e609%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638005594257681 > 553%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi > I6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=F9oh12NDgaTxCTh0Mn% > 2FieWkGQ6PxSre5%2FDk%2FSm9k%2BiY%3D&reserved=0) > and whether they should be represented as standard COSE V2 > countersignatures > (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-cose-countersign&data=05%7C01%7CMaik.Riechert%40microsoft.com%7Cdce4f9f3fd5142f84d4408daa6b4e609%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638005594257681553%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=mdN%2Bu%2FaH5vOyUDC%2BevklTmg1TwznSSiTXMmYzG8j%2BkA%3D&reserved=0). > > 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata > tracker.ietf.org%2Fdoc%2Fhtml%2Frfc8778&data=05%7C01%7CMaik.Rieche > rt%40microsoft.com%7Cdce4f9f3fd5142f84d4408daa6b4e609%7C72f988bf86f141 > af91ab2d7cd011db47%7C1%7C0%7C638005594257681553%7CUnknown%7CTWFpbGZsb3 > d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7 > C2000%7C%7C%7C&sdata=U142Mic9YK9TH24bmWsJNz29t3TIgNh%2FSFixO58hYlA > %3D&reserved=0 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 -- SCITT mailing list [email protected] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fscitt&data=05%7C01%7CMaik.Riechert%40microsoft.com%7Cdce4f9f3fd5142f84d4408daa6b4e609%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638005594257681553%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=3Rp2aB7Ma99RjW3ZHuJpIpQ1uXt8cLwwdXz8cFbKaaw%3D&reserved=0 _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
