Re: [jose] canonical JSON

A SHA-256 hash of the base64url encoding of the UTF-8 representation of JWK seems like a fine fingerprint that requires no canonicalization.

				-- Mike

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

I suspect that a way to fingerprint a subset of a JWK is what is desired.  e.g. probably font want to include "kid" as you may want to use the fingerprint for that.

I suspect that is possible without trying to come up with a general method to canonicallise JSON.

One might be to ASN1 encode it:)  No that is crazy speak.

I do empathize for the desire to have fingerprints without resorting to DER encoding.

If we scope the problem down to having a canonical representation for a limited set of jwk elements that may be worth pursuing.

John  B.
On 2013-02-19, at 5:35 PM, "Matt Miller (mamille2)" <mamille2@cisco.com> wrote:

> 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