Re: [jose] canonical JSON

[Repeating this on the correct thread...]

I'm strongly against canonicalization.  The XML canonicalization experience was horrible and resulted in more interop bugs than any other aspect of XML DSIG, XML ENC, etc.  Let's not repeat the mistakes of our elders. ;-)

I also haven't seen a clear use case that canonicalization solves that can't be more easily solved another way.

				-- Mike

-----Original Message-----
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Matt Miller (mamille2)
Sent: Tuesday, February 19, 2013 12:35 PM
To: Richard Barnes
Cc: Daniel Holth; Manger, James H; jose
Subject: Re: [jose] canonical JSON

I know I'm still reeling from canonicalization (c14n) issues in XML, but I can put that aside.  It would be nice to have JWK fingerprinting.

I can see value in each JWK type defining what is canonical; I'm less thrilled limiting metadata to a specific place, but could live with that.  I can see where excluding metadata can get us in trouble later, but I think that would mean having a much more robust c14n approach.

By the way, there is going to be a JSON BoF in Orlando, and c14n seems like a good thing to bring up there.

- m&m

Matt Miller < mamille2@cisco.com >
Cisco Systems, Inc.

PS: 42 vs 4.2e0 vs 4.2e1

On Feb 19, 2013, at 7:59 AM, Richard Barnes <rlb@ipv.sx> wrote:

> So your fingerprint algorithm would be something like the following?
> 
> INPUT: JWK
> 1. Remove "metadata" fields.  So, for RSA, you would be left with 
> {"kty", "n", "e"} 2. Convert stripped JWK to canonical form 3. Compute 
> digest over canonical form
> 
> That seems generally agreeable to me.
> 
> For (1) to be possible, you would need to define which fields are 
> covered in the fingerprint for each key type ("kty" value).  Or, 
> alternatively, you could restructure JWK so that metadata fields are grouped into a "meta"
> sub-dict.  Which might be nice anyway.
> 
> For (2), I agree that there is probably a better canonicalization than 
> CJSON.  The code I pasted earlier implements the following changes 
> from RFC
> 4627:
> -- Object fields must be in lexicographic order, sorted by field name
> -- No white space allowed
> -- Numbers: Exponent part must use 'e'
> -- Numbers: Exponent part must not use '+'
> -- Numbers: Fraction part must not have trailing zeros
> -- Strings: All characters must be escaped ISTM that those changes are 
> fairly minimal, and avoid some of the CJSON problems that have been 
> discussed above. Reasonably people can disagree over the string 
> aspect; if you want less expansion, you could do things like exempt 
> printable ASCII.
> 
> 
> 
> 
> On Tue, Feb 19, 2013 at 8:56 AM, Daniel Holth <dholth@gmail.com> wrote:
> 
>> On Tue, Feb 19, 2013 at 1:57 AM, Manger, James H < 
>> James.H.Manger@team.telstra.com> wrote:
>> 
>>> A canonical form of JSON might be fairly easy, but the one you quote 
>>> (
>>> http://wiki.laptop.org/go/Canonical_JSON) can't handle floating 
>>> point numbers (or very large integers), and produces invalid JSON if 
>>> a string includes a tab! Fix those (escaping control chars 
>>> [\u0000-\u001f]; use normalized scientific notation for numbers) and 
>>> it might be worth
>>> considering.****
>>> 
>>> ** **
>>> 
>>> Defining JOSE calculations in terms of 1 or more byte arrays, the 
>>> first of which is a UTF-8-encoded JSON header, would be useful. It 
>>> can then be packaged as dot-separated base64url-encoded segments to 
>>> be HTTP-header-friendly, or packaged as a single JSON object to be 
>>> programmer-friendly, or packaged as raw bytes to be efficient.
>>> 
>> 
>> I am only proposing a key fingerprinting specification that does not 
>> employ DER encoding. JWKs do not contain tabs or floating point numbers.
>> 
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose

_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose