Re: Propose New Work Item: Ed25519 Signature 2020

On 2020-09-07 19:13, Leonard Rosenthol wrote:
> Orie (etc.) – how do you see this work vis-a-vis the standardization of JAdES (https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=52897) by ETSI and the EU?   Since JAdES is based on JWS and JOSE – it would seem that a move away from that would preclude the use of this new “Ed255519 Signature 2020” from being usable in the EU.

JAdES would require contents to be Base64Url-encoded except when being a part of an HTTP request or response.

If you combine
- JWS in detached embedded mode
- RFC 8785 (JSON Canonicalization Scheme)
- RFC 8037 (EdDSA for JOSE)
and optionally include a hash for the JSON-LD-expansion, you would get a system that should work in a wide range of JSON-based signature scenarios.  The following data is signed by Ed25519:

{
     "statement": "Hello signed world!",
     "otherProperties": [2e+3, true],
     "json-ld-sha256": "eyJhbGciOiJIUzI1NiJ9..VHVItCBCb8Q5CI-49imarDtJeSxH2uLU0DhqQP5Zjw4",
     "signature": "eyJhbGciOiJFZDI1NTE5IiwiandrIjp7Imt0eSI6Ik9LUCIsImNydiI6IkVkMjU1MTkiLCJ4IjoiX2ttczlia3JicEkxbFBMb00yajJnS3lTUy1rODlUT3V5dmdDNDNkWC1NayJ9fQ..JSwEtm0FEFa9T6XX2AxuSOSGFCE8p8sKwWO9BgUptyID8Ac5Y68Ubsew-V2Owu8DgfhKhuyQ2aJLbQlrluJsAg"
}

A true JWS specialist will note that the "alg" parameter is incorrect; I obviously missed that the JOSE folks changed naming strategy for EdDSA compared to ECDSA.  It will be addressed in the next update :)

Thanx,
Anders
https://mobilepki.org/jws-jcs/

> 
> Leonard
> 
> *From: *Orie Steele <orie@transmute.industries>
> *Date: *Monday, September 7, 2020 at 12:14 PM
> *To: *"W3C Credentials CG (Public List)" <public-credentials@w3.org>
> *Subject: *Propose New Work Item: Ed25519 Signature 2020
> *Resent-From: *<public-credentials@w3.org>
> *Resent-Date: *Monday, September 7, 2020 at 12:12 PM
> 
> Friends,
> 
> A few of us (Manu, Dave and Tobias) have been working on a new linked data signature suite "Ed25519 Signature 2020"
> 
> Here are some links to our work in progress:
> 
> https://transmute-industries.github.io/vc.js/ed25519-signature-2020/ <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftransmute-industries.github.io%2Fvc.js%2Fed25519-signature-2020%2F&data=02%7C01%7Clrosenth%40adobe.com%7Cb256ff68fe534f81902008d8534910a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637350920568806905&sdata=PdAk3zCIZqgvIvqG7lOPbaymRme7f89uHesLzHDU1pY%3D&reserved=0>
> https://github.com/transmute-industries/vc.js/tree/master/packages/ed25519-signature-2020 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftransmute-industries%2Fvc.js%2Ftree%2Fmaster%2Fpackages%2Fed25519-signature-2020&data=02%7C01%7Clrosenth%40adobe.com%7Cb256ff68fe534f81902008d8534910a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637350920568811903&sdata=Yju40RtHGfFI8jEJscDHLU2tnSNNP0l9V0O8qe0Bw2w%3D&reserved=0>
> 
> We would like to move the spec to the CCG, and continue to iterate on it as an official W3C CCG work item.
> 
> I will now summarize what's new about this suite / spec, and why we think incubation in the CCG would be helpful:
> 
> 1. A model for anti cryptographic agility.
> 
> Ed25519Signature2018 used detached JWS, and while it is limited to supporting Ed25519 EdDSA, its structure is actually closer to Json Web Signature 2020... It invited extension, because it relied on JOSE.
> 
> We want to provide an example of a suite which does not rely on JOSE, which reflects some of the design aesthetics (many of which I personally don't agree with) that have been developed in the CCG over the past few years.
> 
> With Json Web Signature 2020 now a shining example of the opposite approach, we think a counter example is needed to better illuminate the arguments against cryptographic agility.
> 
> 2. Support for Multibase
> 
> We're not 100% aligned on its use, but we are hopeful that we might be able to better represent raw bytes using mutlibase, and mitigate some of the contention we have seen over base64, base64url and base58, base58btc, etc...
> 
> https://tools.ietf.org/html/draft-multiformats-multibase-00#appendix-D.1 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-multiformats-multibase-00%23appendix-D.1&data=02%7C01%7Clrosenth%40adobe.com%7Cb256ff68fe534f81902008d8534910a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637350920568821882&sdata=UUheH7CeFXOyDNeaTr6TP3dVLjgt6mvwTr7aLlyYQkE%3D&reserved=0>
> 
> Another major reason to consider multibase is that bi-directional transformations between JSON-LD and CBOR-LD can take advantage of the multibase and automatically compress string encodings like base64, base64pad, base64url, base64urlpad, etc... in absence of multibase... the codec logic for CBOR-LD could become expensive.... multibase is also much more friendly for non web browser environments like IoT development using Rust and Go Lang.
> 
> Multibase / multiformats are also the bridge towards better integrations with IPFS / IPLD....
> 
> https://github.com/multiformats/cid#what-is-it
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmultiformats%2Fcid%23what-is-it&data=02%7C01%7Clrosenth%40adobe.com%7Cb256ff68fe534f81902008d8534910a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637350920568826868&sdata=NN29PZuHmuG9s5Wfxmtlc245xJrAEd0EiqYe7G1nDUM%3D&reserved=0>
> With better support for multibase in JSON-LD, it should be easier to start to better integrate IPLD and CBOR-LD.
> 
> 3. Better standards for linked data suites
> 
> We are also eager to provide better examples for other spec authors to draw from.
> 
> Some of the major areas for improvement are:
> 
> 3.1  better language around verification method requirements, and the relationship between verification methods and keypairs.
> 3.2 conventions around test vectors
> 3.3 better examples of how to extend JSON-LD contexts for LD Proofs and VCs
> 
> We hope that after getting stronger consenus on what a good "linked data proof suite spec" looks like, we can make some revisions to:
> 
> https://w3c-ccg.github.io/ld-proofs/ <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw3c-ccg.github.io%2Fld-proofs%2F&data=02%7C01%7Clrosenth%40adobe.com%7Cb256ff68fe534f81902008d8534910a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637350920568826868&sdata=ipsEMsL12Ugo1KDJVF7xudfgS14f0XegGsmKrD9Not4%3D&reserved=0>
> 
> We're think that the best way to do that is to start with an exemplar suite ( Ed25519Signature2020 ) that has the features / language we want, and reverse engineer the language which we can use to better support the ld-proofs spec.
> 
> Some of the early areas we have identified are:
> 
> 1. better language regarding naming conventions
> 2. examples of JSON-LD context extensions
> 3. conventions regarding test vectors
> 
> Once ld-proofs has been upgraded, we think it will be easier to create linked data suites, and the suites can be more focused on unique differences and less focused on filling the gaps missing the ld-proofs spec.
> 
> Regards,
> 
> OS
> 
> 
> -- 
> 
> *ORIE STEELE*
> 
> Chief Technical Officer
> 
> www.transmute.industries
> 
> Image removed by sender. <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.transmute.industries%2F&data=02%7C01%7Clrosenth%40adobe.com%7Cb256ff68fe534f81902008d8534910a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637350920568831858&sdata=PsIv7bGbIKT7fFrVoBDCuxNCWtuuOoDyHiPgicf%2B7x4%3D&reserved=0>
>

Received on Tuesday, 8 September 2020 13:53:49 UTC