Subject: Re: [jose] Working Group last call on draft-ietf-jose-jwk-thumbprint

From: Mike Jones <[email-masked]>
Date: Mon, 2 Feb 2015 21:21:39 +0000

Internal Microsoft IoT people (in different groups from mine) are sending me requests like this...

				-- Mike

The JWT’s signature rules are particular about JSON in UTF-8 and base64 encoding is required and as the IoT customers we run into are extremely concerned about data transfer volume, every byte we can save there counts and signature values do add up quickly. Encodings like the ones I listed above encode arrays of octets as such. 
 
For illustration of the bandwidth greed: there are network operators like Sigfox that sell data plans with an allowance of 140 messages per device and per day with 12 bytes (!) per message in payload. I’m not suggesting that we do anything with JWTs in that particular case, but this marks the lower end of a spectrum of which LTE marks the ultra-expensive top when you look at commercial M2M data contracts. Payloads of 100+ bytes are big for many solutions. 

The majority of the work in the current JOSE drafts appears to be reusable for the other encoding types of the “JSON structural family” like the ones I enumerated above, except for the actual signature construction and the text-biased token encoding using base64. 
 
The context in which I’m looking at JWT/JWS is for message-level payload signatures for the purposes of origin attestation and authorization, whereby the signing keys are derived keys scoped to the particular operation/message. A signed payload message might look suspiciously like a JWT.

-----Original Message-----
From: jose [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Friday, January 23, 2015 10:04 AM
To: Richard Barnes
Cc: Jim Schaad; [email-masked]; ⌘ Matt Miller
Subject: Re: [jose] Working Group last call on draft-ietf-jose-jwk-thumbprint

On 23/01/15 17:57, Richard Barnes wrote:
>> >
>> > I think it's at least arguable that that'd be worth the code to 
>> > produce a hashed SPKI and better than either aiming for the 
>> > simplest possible code, or for the current hash input from the 
>> > draft.
>> >
> Dude, seriously.  The whole point of this WG is to not do ASN.1.

Yeah well, it's just a different fixed template so it's not "doing" ASN.1 at all really, or only about as much as PKCS#1 requires, which is almost nothing. And SPKI formatted export of public keys is supported directly in lots of crypto libraries, incl. WebCrypto so it's probably even less lines of code if the key was already imported/generated. And it is the same as some other protocols use, providing interop, which is also the whole point of this and other WGs I'd guess (...dude:-)

S.

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

---

From: Breno de Medeiros <[email-masked]>
Date: Mon, 2 Feb 2015 13:32:49 -0800

On Mon, Feb 2, 2015 at 1:21 PM, Mike Jones <[email-masked]>
wrote:

> The JWT’s signature rules are particular about JSON in UTF-8 and base64
> encoding is required and as the IoT customers we run into are extremely
> concerned about data transfer volume, every byte we can save there counts
> and signature values do add up quickly. Encodings like the ones I listed
> above encode arrays of octets as such.
>
> For illustration of the bandwidth greed: there are network operators like
> Sigfox that sell data plans with an allowance of 140 messages per device
> and per day with 12 bytes (!) per message in payload. I’m not suggesting
> that we do anything with JWTs in that particular case, but this marks the
> lower end of a spectrum of which LTE marks the ultra-expensive top when you
> look at commercial M2M data contracts. Payloads of 100+ bytes are big for
> many solutions.
>
> The majority of the work in the current JOSE drafts appears to be reusable
> for the other encoding types of the “JSON structural family” like the ones
> I enumerated above, except for the actual signature construction and the
> text-biased token encoding using base64.
>

The problem with JSON-based format using non-text-based serialization is
that the handling of spaces is not mandated by parsers and serializers.
It's the original motivation for the Base64 serialization prior to
signature to start with.

That being said, I am not opposed to JOSE declaring the JWT format a
meta-format with alternative serializations. For instance, at Google I have
received requests to optimize the tokens by using the Proto-Buffer format:
https://developers.google.com/protocol-buffers/. Protobuffers have an
unambigous and efficient octet stream serialization and would be amenable
to signature processing rules that do not require 'shielding for ambiguity'
by encoding first. I am not directly asking that PB format be taken as a
JOSE WG effort, but possibly the spec could be written so us to allow
straightforward interpretations in formats other than JSON with nearly
identical processing semantics.

>
> The context in which I’m looking at JWT/JWS is for message-level payload
> signatures for the purposes of origin attestation and authorization,
> whereby the signing keys are derived keys scoped to the particular
> operation/message. A signed payload message might look suspiciously like a
> JWT.
>
>
> Yeah well, it's just a different fixed template so it's not "doing" ASN.1
> at all really, or only about as much as PKCS#1 requires, which is almost
> nothing. And SPKI formatted export of public keys is supported directly in
> lots of crypto libraries, incl. WebCrypto so it's probably even less lines
> of code if the key was already imported/generated. And it is the same as
> some other protocols use, providing interop, which is also the whole point
> of this and other WGs I'd guess (...dude:-)
>
> S.
>

-- 
--Breno

---

From: Mike Jones <[email-masked]>
Date: Mon, 2 Feb 2015 21:51:33 +0000

Sorry - the note below was sent to the wrong thread. Please disregard.
________________________________
From: Mike Jones<mailto:[email-masked]>
Sent: ‎2/‎2/‎2015 1:22 PM
To: Stephen Farrell<mailto:[email-masked]>; Richard Barnes<mailto:[email-masked]>
Cc: Jim Schaad<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; ⌘ Matt Miller<mailto:[email-masked]>
Subject: Re: [jose] Working Group last call on draft-ietf-jose-jwk-thumbprint

                                -- Mike

-----Original Message-----
From: jose [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Friday, January 23, 2015 10:04 AM
To: Richard Barnes
Cc: Jim Schaad; [email-masked]; ⌘ Matt Miller
Subject: Re: [jose] Working Group last call on draft-ietf-jose-jwk-thumbprint

S.

---

From: Mike Jones <[email-masked]>
Date: Fri, 20 Feb 2015 00:46:43 +0000

Text saying this was added to the -02 draft, per your and Hideki’s input.

                                                                -- Mike

From: jose [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Saturday, January 24, 2015 11:39 AM
To: Jim Schaad; [email-masked]
Subject: Re: [jose] Working Group last call on draft-ietf-jose-jwk-thumbprint

I agree with you that we should probably add text saying that the thumbprint value could be used as a Key ID (Hideki Nara made this point yesterday as well), and that it is an application decision whether to carry the value in a “jkt”, “kid”, or another field.  (In one case, OpenID Connect uses it as the “sub” (subject) claim of a JWT, for instance.)

                                                            -- Mike

From: jose [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Saturday, January 24, 2015 10:39 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] Working Group last call on draft-ietf-jose-jwk-thumbprint

I am wondering why this needs to be tagged as a thumbprint.   Is there a reason why this draft should not be presented as – here is a way to compute a kid value for a key that will produce a unique value.  This would be similar to how the computations are presented in PKIX for the subject key identifier extension.

Jim