Subject: [jose] JWK-specific key fingerprints?

From: Daniel Holth <[email-masked]>
Date: Tue, 12 Feb 2013 13:56:25 -0500

Is there an interest here in defining a standard way to canonicalize and
fingerprint (sha-256 hash) JWKs? You would take out the kid, encode the JWK
with bencode or canonical json, and hash.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 12 Feb 2013 19:09:34 +0000

> with bencode or canonical json, and hash.

If you do that, please do it compatibly with e.g. DANE.

Or (self promotion:-) if it worked for you, you could
use [1] :-) which is in the RFC editor's queue.

S.

[1] http://tools.ietf.org/html/draft-farrell-decade-ni

> 
> 
> 
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose
>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 12 Feb 2013 11:53:00 -0800

On 12 February 2013 10:56, Daniel Holth <[email-masked]> wrote:
> ... canonical json ....

Isn't mention of canonical JSON a swear-jar offense?  Something needs
canonicalization, but JSON seems a poor candidate.

---

From: Daniel Holth <[email-masked]>
Date: Tue, 12 Feb 2013 15:01:17 -0500

> canonicalization, but JSON seems a poor candidate.

There is something called Canonical JSON. They take out all the whitespace,
sort keys lexicographically, and only quote the " inside strings. It is
used in the wild by the OLPC project I think.

bencode is an easier to implement protocol that is used in bittorrent and
yields a tiny write-only implementation if all you want to do is get unique
hashes for the subset of JSON used by JWK.

---

From: Richard Barnes <[email-masked]>
Date: Mon, 18 Feb 2013 12:51:43 -0500

Citation for Canonical JSON:
<http://wiki.laptop.org/go/Canonical_JSON>

I have implemented this in python.  It is surprisingly easy [1].
 Canonicalization has been anathema to this group, but I suspect largely
because people have been bitten by XML canonicalization, rather than
because JSON canonicalization has been tried and found difficult.

If we're going to go down this path, I would prefer Canonical JSON to
bencode, if only because bencode is an entirely different format to
implement.

Personally, given how easy canonicalization is to implement (it actually
requires fewer lines in my experience than base64!), it seems like a
sensible choice in general.  In particular, for the JSON serialization, it
would save some unnecessary base64 encoding that is currently required.  I
would be glad to contr

--Richard

[1] My own canonicalization, not sure if it matches the one linked above <
http://pastebin.com/ptUfn0c3>

On Tue, Feb 12, 2013 at 3:01 PM, Daniel Holth <[email-masked]> wrote:

> There is something called Canonical JSON. They take out all the
> whitespace, sort keys lexicographically, and only quote the " inside
> strings. It is used in the wild by the OLPC project I think.
>

---

From: Daniel Holth <[email-masked]>
Date: Mon, 18 Feb 2013 13:55:43 -0500

On Mon, Feb 18, 2013 at 12:51 PM, Richard Barnes <[email-masked]> wrote:

>> On Tue, Feb 12, 2013 at 2:53 PM, Martin Thomson <[email-masked]
>> > wrote:
>>
Especially if you are not worried about the CJSON corner cases (which go
away when your data is all printable ASCII) it is stupidly simple. The rest
of the spec would be to exclude the members of the JWK that are not used by
the crypto math (need a better way to say this) and to give it a name like
"hash kid" -> "hkid".

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 19 Feb 2013 17:57:56 +1100

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.

--
James Manger

From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Tuesday, 19 February 2013 4:52 AM
To: Daniel Holth
Cc: Martin Thomson; jose
Subject: Re: [jose] JWK-specific key fingerprints?

I have implemented this in python.  It is surprisingly easy [1].  Canonicalization has been anathema to this group, but I suspect largely because people have been bitten by XML canonicalization, rather than because JSON canonicalization has been tried and found difficult.

If we're going to go down this path, I would prefer Canonical JSON to bencode, if only because bencode is an entirely different format to implement.

Personally, given how easy canonicalization is to implement (it actually requires fewer lines in my experience than base64!), it seems like a sensible choice in general.  In particular, for the JSON serialization, it would save some unnecessary base64 encoding that is currently required.  I would be glad to contr

--Richard

[1] My own canonicalization, not sure if it matches the one linked above <http://pastebin.com/ptUfn0c3>

On Tue, Feb 12, 2013 at 3:01 PM, Daniel Holth <[email-masked]<mailto:[email-masked]>> wrote:
On Tue, Feb 12, 2013 at 2:53 PM, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:

There is something called Canonical JSON. They take out all the whitespace, sort keys lexicographically, and only quote the " inside strings. It is used in the wild by the OLPC project I think.
bencode is an easier to implement protocol that is used in bittorrent and yields a tiny write-only implementation if all you want to do is get unique hashes for the subset of JSON used by JWK.

_______________________________________________
jose mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/jose

---

From: Daniel Holth <[email-masked]>
Date: Tue, 19 Feb 2013 08:56:16 -0500

On Tue, Feb 19, 2013 at 1:57 AM, Manger, James H <
[email-masked]> 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.

---

From: Richard Barnes <[email-masked]>
Date: Tue, 19 Feb 2013 09:59:35 -0500

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 <[email-masked]> wrote:

>> 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
> I am only proposing a key fingerprinting specification that does not
> employ DER encoding. JWKs do not contain tabs or floating point numbers.
>

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Tue, 19 Feb 2013 20:35:21 +0000

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 < [email-masked] >
Cisco Systems, Inc.

PS: 42 vs 4.2e0 vs 4.2e1

---

From: Mike Jones <[email-masked]>
Date: Tue, 19 Feb 2013 20:48:01 +0000

[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: [email-masked] [mailto:[email-masked]] 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

- m&m

PS: 42 vs 4.2e0 vs 4.2e1

On Feb 19, 2013, at 7:59 AM, Richard Barnes <[email-masked]> wrote:

> 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
> 
> 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"
> -- 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.
> 
> 
> 
> 
>>> 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

---

From: Tim Bray <[email-masked]>
Date: Tue, 19 Feb 2013 12:50:13 -0800

My instinct, as the author of a reasonably popular library that generates
canonical XML, is that JSON ought to be quite a bit easier.  But that’s
only interesting if Mike is wrong and there aren’t better alternatives. -T

On Tue, Feb 19, 2013 at 12:48 PM, Mike Jones <[email-masked]>wrote:

> 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 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.
>

---

From: David Waite <[email-masked]>
Date: Tue, 19 Feb 2013 14:02:20 -0700

I think JSON canonicalization and potential transforms could be a limiting factor in adoption. In terms of technical challenges (outside deciding on string normalization), I suspect some JSON implementations might break due to the use of integer types to represent non-floating-point numbers in their parsed data.  

As an example, the integer 9007199254740993 can't be represented in a Javascript Number type, as numbers are actually doubles. A 64-bit integer would have no problem representing it, however.

-David Waite

On Feb 19, 2013, at 1:50 PM, Tim Bray <[email-masked]> wrote:

> My instinct, as the author of a reasonably popular library that generates canonical XML, is that JSON ought to be quite a bit easier.  But that’s only interesting if Mike is wrong and there aren’t better alternatives. -T
> 
> 
> On Tue, Feb 19, 2013 at 12:48 PM, Mike Jones <[email-masked]> wrote:

---

From: John Bradley <[email-masked]>
Date: Tue, 19 Feb 2013 19:15:56 -0300

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.

---

From: Mike Jones <[email-masked]>
Date: Tue, 19 Feb 2013 22:19:24 +0000

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: [email-masked] [mailto:[email-masked]] 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

John  B.
On 2013-02-19, at 5:35 PM, "Matt Miller (mamille2)" <[email-masked]> wrote:

>> {"kty", "n", "e"} 2. Convert stripped JWK to canonical form 3. 
>> Compute digest over canonical form
>> 
>> 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:
>> -- 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 
>>>> 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.****
>>>> 
>>>> ** **
>>>>

---

From: Justin Richer <[email-masked]>
Date: Tue, 19 Feb 2013 17:40:50 -0500

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

  -- Justin

---

From: Mike Jones <[email-masked]>
Date: Wed, 20 Feb 2013 00:15:53 +0000

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: [email-masked] [mailto:[email-masked]] 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:
>>>>> 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.
>>>>

---

From: <[email-masked]>
Date: Wed, 20 Feb 2013 07:07:19 +0100

Mike is right. Canonicalization is "evil".
Axel

From: [email-masked] [mailto:[email-masked]] On Behalf Of Tim Bray
Sent: Tuesday, February 19, 2013 9:50 PM
To: Mike Jones
Cc: Richard Barnes; Daniel Holth; Manger, James H; jose; Matt Miller (mamille2)
Subject: Re: [jose] canonical JSON

My instinct, as the author of a reasonably popular library that generates canonical XML, is that JSON ought to be quite a bit easier.  But that's only interesting if Mike is wrong and there aren't better alternatives. -T

On Tue, Feb 19, 2013 at 12:48 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
[Repeating this on the correct thread...]

                                -- Mike

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] 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

- m&m

Matt Miller < [email-masked]<mailto:[email-masked]> >
Cisco Systems, Inc.

PS: 42 vs 4.2e0 vs 4.2e1

On Feb 19, 2013, at 7:59 AM, Richard Barnes <[email-masked]<mailto:[email-masked]>> wrote:

> On Tue, Feb 19, 2013 at 8:56 AM, Daniel Holth <[email-masked]<mailto:[email-masked]>> wrote:
>
>> [email-masked]<mailto:[email-masked]>> wrote:
>>

---

From: Richard Barnes <[email-masked]>
Date: Thu, 21 Feb 2013 12:47:18 -0500

Axel,
This comment is not very helpful without a technical argument.
--Richard

On Wed, Feb 20, 2013 at 1:07 AM, <[email-masked]> wrote:

> Mike is right. Canonicalization is “evil”.****
>
> Axel****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Tim Bray
> *Sent:* Tuesday, February 19, 2013 9:50 PM
> *To:* Mike Jones
> *Cc:* Richard Barnes; Daniel Holth; Manger, James H; jose; Matt Miller
> (mamille2)
>
> *Subject:* Re: [jose] canonical JSON****
>
> ** **
>
> ****
> On Tue, Feb 19, 2013 at 12:48 PM, Mike Jones <[email-masked]>
> wrote:****
>
>                                 -- Mike****
> https://www.ietf.org/mailman/listinfo/jose****
>
> ** **
>

---

From: Richard Barnes <[email-masked]>
Date: Thu, 21 Feb 2013 12:50:29 -0500

That doesn't solve the problem.  The point of a fingerprint is to have an
identifier for the key that is shorter than the key itself. So a JWS with a
JWK payload is irrelevant.  Likewise, any solution that requires
base64-encoding is also irrelevant, since you would need to carry the
encoded version along in order to interpret the fingerprint.

--Richard

On Tue, Feb 19, 2013 at 7:15 PM, Mike Jones <[email-masked]>wrote:

> 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
>
> order/spacing/formatting of JSON documents isn't guaranteed, this approach
> won't work.
>
>   -- Justin
>
> > 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
> >
> > 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.
> >
> > 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.
> >> 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.
> >>

---

From: Daniel Holth <[email-masked]>
Date: Thu, 21 Feb 2013 13:06:11 -0500

> encoded version along in order to interpret the fingerprint.

Impressed by the c14n can of worms. The one advantage of a bencode c14n
scheme is that it would obviously be crazy to rearchitect an entire JSON
crypto scheme around it. Subset-of-CJSON-only-defined-for-JWK is enough.

There is a system called The Update Framework that pre-dates JOSE and is
used to secure software updates. The root document is a very long list of
RSA key fingerprints trusted to sign some sub-document. Each sub-document
includes the entire RSA key. If the sub-document's signature is valid and
the key fingerprint matches then the sub-document can be trusted. The root
document would be too big if it had to include the whole keys instead of
fingerprints.