Re: [Json] Canonicalization

[Tim Bray <[e-mail]>]

OK, this discussion has convinced me that there’s no real need for this
group to proactively take up JSON c14n.  If at some future point there’s a
strong demonstrated real (not hypothetical) use case, it’s a fairly
tractable problem.  But for now, it’s unnecessary work.

-T


On Tue, Feb 19, 2013 at 7:11 PM, Nico Williams <[e-mail]>wrote:

> On Tue, Feb 19, 2013 at 9:00 PM, Francis Galiegue <[e-mail]>
> wrote:
> > On Wed, Feb 20, 2013 at 3:36 AM, Nico Williams <[e-mail]>
> wrote:
> > [...]
> >>
> >> Yes and no.  If the verifier and the signer both have the same
> >> document then no c14n is needed.  If the verifier must reconstruct the
> >> signed document -as opposed to receiving it from the signer- then the
> >> verifier must reconstruct exactly the signed document or the signature
> >> will not verify.
> >>
> >
> > There is one thing I don't get: in any case, what is transmitted over
> > the network is just a stream of bytes. One end writes that stream, the
> > other reads it.
>
> No, in this one case the two ends construct some data.  A good example
> would be channel bindings (RFCs 5056, 5929), except that mostly that
> has no structure, so it's not really a good example after all, but it
> illustrates the point.
>
> > In order for the receiving end to interpret that data, should signing
> > be used, it needs to verify that the _byte stream_, not its
> > interpretation, is correct. That byte stream MAY be JSON. It may not
> > be.
>
> That's just it: in this case the data isn't transmitted, only the
> signature.  There's many protocols that transmit signatures (or
> hashes) but not necessarily contents.  E.g., rsync.  What if you had a
> JSON-based synchronization protocol and you're sending file metadata,
> only there's a lot of it (e.g., large ACLs), and you're trying to
> avoid sending it, so you send file names and metadata hashes, and if
> the receiver's don't match then you send the actual metadata?
>
> Nico
> --
> _______________________________________________
> json mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/json
>