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

:(

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.


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.



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.

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]>


_______________________________________________
COSE mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to