- From: Dean Kevin Poulsen <dean@authenticity.ac>
- Date: Sun, 28 Oct 2018 11:37:05 -0700
- To: Anders Rundgren <anders.rundgren.net@gmail.com>
- Cc: pelle.braendgaard@consensys.net, public-credentials@w3.org
- Message-Id: <6B959761-2B78-4D58-BEF5-B072A2A3A98B@authenticity.ac>
Anders, Maybe canonicalization can be eliminated, because the need for canonicalization stems from the core issue, which is: — The requirement that signed content be modified after being signed. Then, the receiver is required to recreate the signed content through prescribed manipulations. “Seasoned XML developers recalling difficulties getting signatures to validate (usually due to different interpretations of the quite intricate XML canonicalization rules as well as of the equally extensive Web Services security standards)…” — From the introduction to: https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-01 ------ My opinion: SIGNED CONTENT SHOULD NOT BE MODIFIED AFTER IT IS SIGNED. To simplify the proposal, here's a signed JSON-LD in the existing standard and the same signed JSON-LD revised per my proposal: My proposal does two things: 1. It splits the “proof” array into two arrays: “proofMetadata” and “proofValue”. 2. It puts the signed content into a “signedContent” array. The “proofValue” immediately follows the “signedContent” This pulls the “proofValue” out of the signed content, eliminating the need to modify the signed content after it has been signed (except in the case of signature sets, where minimal modification is suggested for convenience). — You mentioned that one form of canonicalization doesn’t require the signature to be included. I can’t find that option in the links that you sent. Can you point me in the right direction? Thanks, Kevin [“Dean” is a title, not my name. :) ] > On Oct 27, 2018, at 11:27 PM, Anders Rundgren <anders.rundgren.net@gmail.com> wrote: > > Hi Dean, > > I don't completely follow your proposal. Does it actually remove the need for RDF/LD canonicalization? > > Anyway, there are subtle differences between formats and one is if the signature parameters should be included or not. Including them requires that the data is modified by the signature and verify process. > > FWIW, this is how my Java verifier code deals with this particular topic for JSON Clear text Signatures: > > // 1. Make a shallow copy of the signature object > LinkedHashMap<String, JSONValue> savedProperties = > new LinkedHashMap<String, JSONValue>(innerSignatureObject.root.properties); > // 2. Hide the signature value property for the serializer... > innerSignatureObject.root.properties.remove(JSONCryptoHelper.VALUE_JSON); > // 3. Serialize ("JSON.stringify()") > normalizedData = signedData.serializeToBytes(JSONOutputFormats.CANONICALIZED); > // 4. Restore the signature object > innerSignatureObject.root.properties = savedProperties; > > Regards, > Anders
Attachments
- text/html attachment: stored
- image/png attachment: SignedJSON-LDFormat_Proposal_v5-snippet.png
Received on Sunday, 28 October 2018 18:37:40 UTC