On 2024-08-26 20:07, Orie Steele wrote:
On Sat, Aug 24, 2024 at 10:28 AM Anders Rundgren <[email protected]
<mailto:[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
<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,
Right, that's the only solution that would pass through the IETF since they
didn't accept RFC 8785.
as opposed to a detached unencoded payload JWT, per:
https://datatracker.ietf.org/doc/html/rfc7797
<https://datatracker.ietf.org/doc/html/rfc7797>
RFC 8785 didn't really make it in JOSE. CBOR/CDE meets all reasonable requirements including a
much improved blob and big integer handling. The "JSON" object in JavaScript is crippled
beyond belief. A corresponding "CBOR" object would not build on 20 year old JavaScript:
https://github.com/cyberphone/CBOR.js#cborjs
> 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?
The "inspiration" rather comes from:
https://www.w3.org/TR/xmldsig-core/#def-SignatureEnveloped
Seems like a misuse of "enveloped" in the context of
https://datatracker.ietf.org/doc/html/rfc9052#name-enveloped-cose-structure
<https://datatracker.ietf.org/doc/html/rfc9052#name-enveloped-cose-structure>
Unlike the CBOR Signature Format (CSF), COSE does not sign CBOR, it signs
anything binary. Specialization versus universality.
> 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.
Although I'm the primary author of RFC 8785, I have given up on that and JSON as well.
CBDR/CDE + CSF/CEF seem like an unbeatable "combo" for payment wallets.
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)
Yes, that is what CSF does, although I tend to call it enveloped.
For the CBOR Encryption Format (CEF), this scheme is also for used for creating
Additional Authentication Data (AAD):
https://cyberphone.github.io/javaapi/org/webpki/cbor/doc-files/encryption.html
>
> 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...
Indeed.
I'm not recommending any of this...
I don't ask anybody to recommend this but it would be cool with a peer review
or two:
https://test.webpki.org/csf-lab/create
I'm pointing out that its application specific processing, which is at a
different layer than COSE protocol stuff.
CSF is indeed quite different to COSE.
Anders
Anders
1] https://github.com/cyberphone/simple-cbor-encoder.js/blob/main/cde.js
<https://github.com/cyberphone/simple-cbor-encoder.js/blob/main/cde.js>
2] https://datatracker.ietf.org/doc/html/draft-mcnally-envelope-07
<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]> <mailto:[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>
<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>
<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://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://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>
<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]>
<mailto:[email protected] <mailto:[email protected]>>
> To unsubscribe send an email to [email protected] <mailto:[email protected]>
<mailto:[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]
