Re: [jose] canonical JSON

[Mike Jones <[e-mail]>]

Nothing's preventing people from using the JWK as the payload of a JWS if you want to sign/MAC it - just like Matt's draft uses it as the payload of a JWE.  Problem solved. ;-)

				-- Mike

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Justin Richer
Sent: Tuesday, February 19, 2013 2:41 PM
To: Mike Jones
Cc: Daniel Holth; Richard Barnes; jose; Matt Miller (mamille2); John Bradley; Manger, James H
Subject: Re: [jose] canonical JSON

Since JWKs are passed around as JSON documents, and order/spacing/formatting of JSON documents isn't guaranteed, this approach won't work.

  -- Justin

On 02/19/2013 05:19 PM, Mike Jones wrote:
> 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: [e-mail] [mailto:[e-mail]] 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)" <[e-mail]> 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 < [e-mail] >
>> Cisco Systems, Inc.
>>
>> PS: 42 vs 4.2e0 vs 4.2e1
>>
>> On Feb 19, 2013, at 7:59 AM, Richard Barnes <[e-mail]> 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 <[e-mail]> wrote:
>>>
>>>> On Tue, Feb 19, 2013 at 1:57 AM, Manger, James H < 
>>>> [e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/jose
>> _______________________________________________
>> jose mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/jose
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose

_______________________________________________
jose mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/jose