On Sat, Aug 24, 2024 at 10:28 AM Anders Rundgren < [email protected]> wrote:
> Hi Orie, > > On 2024-08-24 14:47, Orie Steele wrote: > > What are your requirements? > They are approximately the same as > https://www.w3.org/TR/vc-data-model-2.0/#example-usage-of-issuer-expanded-property > using EdDSA. > > That is, they and I want the proof (signature) to be a part of the > credential (data). > > What they must likely will end-up is rather the opposite, here using JWT: > > eyJraWQiOiJFeEhrQk1XOWZtYmt2VjI2Nm1ScHVQMnNVWV9OX0VXSU4xbGFwVXpPOHJvIiwiYWxnIjoiR > > VMyNTYifQ.eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJ > > odHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaWQiOiJodHRwOi8v > > dW5pdmVyc2l0eS5leGFtcGxlL2NyZWRlbnRpYWxzLzM3MzIiLCJ0eXBlIjpbIlZlcmlmaWFibGVDcmVkZ > > W50aWFsIiwiRXhhbXBsZURlZ3JlZUNyZWRlbnRpYWwiXSwiaXNzdWVyIjp7ImlkIjoiZGlkOmV4YW1wbG > > U6NzZlMTJlYzcxMmViYzZmMWMyMjFlYmZlYjFmIiwibmFtZSI6IkV4YW1wbGUgVW5pdmVyc2l0eSJ9LCJ > > 2YWxpZEZyb20iOiIyMDEwLTAxLTAxVDE5OjIzOjI0WiIsImNyZWRlbnRpYWxTdWJqZWN0Ijp7ImlkIjoi > > ZGlkOmV4YW1wbGU6ZWJmZWIxZjcxMmViYzZmMWMyNzZlMTJlYzIxIiwiZGVncmVlIjp7InR5cGUiOiJFe > > GFtcGxlQmFjaGVsb3JEZWdyZWUiLCJuYW1lIjoiQmFjaGVsb3Igb2YgU2NpZW5jZSBhbmQgQXJ0cyJ9fX > > 0.v85SIqmg4AFCB8iJRl3yIg7lOf3xjaNlHVWVDtVf7BORIj-QUY20VBDDoHFJTHp9xT4XqhdfocC5xW3UD3wsiA > > :( > > Thats a JWT as a JWS with an encoded payload, as opposed to a detached unencoded payload JWT, per: https://datatracker.ietf.org/doc/html/rfc7797 > > Are you trying to implement an embedded detached signature? > > The proper term is rather enveloped signature. It was featured in XML > DSig. CSF is code-wise between 1 and 2 magnitudes simpler. > Do you have an IETF citation for this? Seems like a misuse of "enveloped" in the context of https://datatracker.ietf.org/doc/html/rfc9052#name-enveloped-cose-structure > > > Is that why you require the map to be modified and then CDE applied? > > In this scheme, CDE is/must be an integral part of the CBOR toolbox. > Given that a full-blown CBOR CDE encoder can be built using less than 300 > lines of (well-commented) JavaScript code [1], CDE is not a showstopper; > not buying into COSE is the only problem. OTOH, the blockchain commons are > pushing for standards [2] that do not make use of COSE either, and probably > for the same reasons as I; a desire keeping the data and its container > intact. > > If I put an RFC 7797 signature in a RFC 8785 JSON object under the key "detached_sigantures". I can easily create the same concept of "signatures in envelopes for json"... no CDE required. The ingredients of the scheme are: - canonicalization / normalization / CDE (so you get a consistent hash of the resource) - detached signatures (so you can embed signatures of the canonical resource, and remove them in a deterministic way) > > > > Why not just say: > > > > Detach the signatures, apply cde to the original map, sign the hash of > the cde with cose sign1... Attach the signature. > > > > In this approach you also get a content identifier for the CBOR map, > which you can use to build unique URIs. > > I'm not able to fully decipher what you are suggesting here, an example > would be nice. > If you are already required to enforce deterministic ordering of the "container" as you call it, then each container under that canonical form has a unique sha-256 hash. So you can sign that hash, with any signing algorithm... JOSE / COSE / PGP... I'm not recommending any of this... I'm pointing out that its application specific processing, which is at a different layer than COSE protocol stuff. > Anders > > 1] https://github.com/cyberphone/simple-cbor-encoder.js/blob/main/cde.js > > 2] https://datatracker.ietf.org/doc/html/draft-mcnally-envelope-07 > > > > > > > On Sat, Aug 24, 2024, 2:19 AM Anders Rundgren < > [email protected] <mailto:[email protected]>> > wrote: > > > > Assume you have a message like this, where a tag holding a URL acts > as an object type Id: > > > > 1010(["https://example.com/status <https://example.com/status>", { > > / temperature / > > 1: 2.56, > > / weight / > > 2: 505, > > / timestamp / > > 3: "2024-08-22T15:32:20Z" > > }]) > > > > Using the CBOR Signature Format (CSF) you would get this: > > > > 1010(["https://example.com/status <https://example.com/status>", { > > 1: 2.56, > > 2: 505, > > 3: "2024-08-22T15:32:20Z", > > / Signature container / > > -1: { > > / Signature algorithm (COSE Ed25519) / > > 1: -50, > > / Ed25519 public key in COSE format / > > 4: { > > 1: 1, > > -1: 6, > > -2: > h'fe49acf5b92b6e923594f2e83368f680ac924be93cf533aecaf802e37757f8c9' > > }, > > / Signature value / > > 6: > h'1f10bf2efcfddee741a6dea052ef49e6b67dd549d580be36e5a1d50dc3f9afd5fb92a28ce37dfc877111ff35fb2f4c1f21ff0b0b48bdc04276742e6af033330b' > > } > > }]) > > > > Compared to COSE you get the following advantages: > > - The entire message is signed including the object type Id > > - The message is kept in its original form > > - Headers are in clear > > - Extremely simple algorithm > > > > WDYT? > > > > Anders > > https://datatracker.ietf.org/doc/draft-ietf-cbor-cde/ < > https://datatracker.ietf.org/doc/draft-ietf-cbor-cde/> > > > https://cyberphone.github.io/javaapi/org/webpki/cbor/doc-files/signatures.html > < > https://cyberphone.github.io/javaapi/org/webpki/cbor/doc-files/signatures.html > > > > https://www.ietf.org/archive/id/draft-rundgren-cotx-04.html < > https://www.ietf.org/archive/id/draft-rundgren-cotx-04.html> > > > > _______________________________________________ > > COSE mailing list -- [email protected] <mailto:[email protected]> > > To unsubscribe send an email to [email protected] <mailto: > [email protected]> > > > > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
