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

From: "Jim Schaad" <[email-masked]>
Date: Thu, 22 Jan 2015 17:56:17 -0800

This starts a two week last call on draft-ietf-jose-jwk-thumbprint.  Last
call will end on February 2, 2015.

Due to the general lack of activity on the list.  General silence will be
considered as a vote to park the document and either have it done via the
ISE or with an AD shepherd rather than having group consensus.

---

From: John Bradley <[email-masked]>
Date: Thu, 22 Jan 2015 23:23:27 -0300

Jim,

I would like to see the WG publish the thumbprint spec.

We are using it in openID Connect.

I think draft 01 with the updates from you is fine.   

The general lack of controversy over it is perhaps a good thing.

> On Jan 22, 2015, at 10:56 PM, Jim Schaad <[email-masked]> wrote:
> 
> This starts a two week last call on draft-ietf-jose-jwk-thumbprint.  Last call will end on February 2, 2015.
>  
> Due to the general lack of activity on the list.  General silence will be considered as a vote to park the document and either have it done via the ISE or with an AD shepherd rather than having group consensus.
>  
>  
> _______________________________________________
> jose mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/jose <https://www.ietf.org/mailman/listinfo/jose>

---

From: hideki nara <[email-masked]>
Date: Fri, 23 Jan 2015 12:23:36 +0900

+1

--
hideki nara

2015-01-23 11:23 GMT+09:00 John Bradley <[email-masked]>:

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

---

From: nov matake <[email-masked]>
Date: Fri, 23 Jan 2015 13:50:34 +0900

+1

Sent from my iPhone

> On 2015/01/23, at 11:23, John Bradley <[email-masked]> wrote:
> 
> Jim,
>

---

From: <[email-masked]>
Date: Fri, 23 Jan 2015 10:08:13 +0100

+1

From: jose [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Friday, January 23, 2015 3:23 AM
To: Jim Schaad
Cc: [email-masked]
Subject: Re: [jose] Working Group last call on draft-ietf-jose-jwk-thumbprint

Jim,

On Jan 22, 2015, at 10:56 PM, Jim Schaad <[email-masked]<mailto:[email-masked]>> wrote:

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

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 23 Jan 2015 12:38:32 +0000

I just had a quick look and it seems fine for
asymmetric keys assuming there's a need for it
and a justification for including things like
'{"e":' in the hash input, which I don't see.

The reason I looked at this is that there's some
overlap here with RFC6920, (I'm an author of
that) and DANE and maybe other specs that say
how to hash a public key.

It does seem a shame to have so many ways to
hash public keys, but 6920 is compatible with
DANE and others that hash a SPKI (even if
that's artificially created just as a hash
input), so I wonder if the benefit of the
running code here is really worth being
different from other specs that hash a SPKI.

So, other than that someone has some code,
what is the benefit of being incompatible with
other specs here?

The downside is that I could not determine
that one of these does/doesn't map to the
same public key as some DANE RRs for example.
Seems a bit odd to me to want to accept that
downside unless there's an upside.

Only other thing is for symmetric keys I think
you should add an optional salt, in case you
need the thumbprint of a low-entropy secret,
which is quite likely to happen, and quite
likely to get exposed somehow. And I'd argue
to recommend that a long salt always be used
for potentially low-entropy secret keys.

Apologies if the WG discussed these before
but I missed it;-)

S.

PS: These are just random-punter comments with
no hats.

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Fri, 23 Jan 2015 15:46:24 +0200

What would be a good way to pass the salt? Within the "jkt" parameter
using some kind of a delimiter, or using a separate parameter?

We've got a use case where we need to identify shared JWKs (oct). These
start at 128 bits. What length is generally considered low-entropy to
require a salt to be added?

Vladimir

-- 
Vladimir Dzhuvinov :: [email-masked]

---

From: <[email-masked]>
Date: Fri, 23 Jan 2015 15:30:27 +0100

Stephen,

How does rfc6920 help when the key is a jwk? Like sub_jwk below.

-Axel

{
   "iss": "https://self-issued.me",
   "sub": "NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs",
   "aud": "https://client.example.org/cb",
   "nonce": "n-0S6_WzA2Mj",
   "exp": 1311281970,
   "iat": 1311280970,
   "sub_jwk": {
     "kty":"RSA",
     "n": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx
     4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMs
     tn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2
     QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n91CbOpbI
     SD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_xBniIqb
     w0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw",
     "e":"AQAB"
    }
  }

-----Original Message-----
From: jose [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Friday, January 23, 2015 1:39 PM
To: Jim Schaad; [email-masked]
Subject: Re: [jose] Working Group last call on draft-ietf-jose-jwk-thumbprint

I just had a quick look and it seems fine for asymmetric keys assuming there's a need for it and a justification for including things like '{"e":' in the hash input, which I don't see.

The reason I looked at this is that there's some overlap here with RFC6920, (I'm an author of
that) and DANE and maybe other specs that say how to hash a public key.

It does seem a shame to have so many ways to hash public keys, but 6920 is compatible with DANE and others that hash a SPKI (even if that's artificially created just as a hash input), so I wonder if the benefit of the running code here is really worth being different from other specs that hash a SPKI.

So, other than that someone has some code, what is the benefit of being incompatible with other specs here?

The downside is that I could not determine that one of these does/doesn't map to the same public key as some DANE RRs for example.
Seems a bit odd to me to want to accept that downside unless there's an upside.

Only other thing is for symmetric keys I think you should add an optional salt, in case you need the thumbprint of a low-entropy secret, which is quite likely to happen, and quite likely to get exposed somehow. And I'd argue to recommend that a long salt always be used for potentially low-entropy secret keys.

Apologies if the WG discussed these before but I missed it;-)

S.

PS: These are just random-punter comments with no hats.

On 23/01/15 01:56, Jim Schaad wrote:
> Due to the general lack of activity on the list.  General silence will 
> be considered as a vote to park the document and either have it done 
> via the ISE or with an AD shepherd rather than having group consensus.
> 
>  
> 
>  
> 
> 
> 
>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 23 Jan 2015 14:36:54 +0000

> How does rfc6920 help when the key is a jwk? Like sub_jwk below.

You can easily construct the hash input (an SPKI) from that
and hence could easily produce an ni URI.

And its reasonably likely your implementation supports SPKI
natively as well as its format for exporting a public key.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 23 Jan 2015 14:39:02 +0000

> using some kind of a delimiter, or using a separate parameter?

Either can work fine and tossing a coin is probably
as good a way to decide as any:-)

> require a salt to be added?

If you have a really good randomly generated 128 bits then
you don't need a salt for sure. But I don't think the key
length is really what determines whether or not a salt will
be needed in practice given that many secret keys are
actually created by doing hash(password) anyway;-) So I'd
say if my code allowed for reading a secret key from a file
or other kinds of human input, then I'd want a salt I think,
just in case. If the secret in question was always generated
as a result of a D-H exchange or something then it'd be ok
to not have a salt.

S.

---

From: Richard Barnes <[email-masked]>
Date: Fri, 23 Jan 2015 09:54:07 -0500

I would summarize my reaction to this document as "I can live with it, but
it makes me really sad that we didn't do the stupid simple obvious thing."

The computation of the hash input is technically workable, but
unnecessarily complex.  Rather than building a simple string based on the
components (say, ), it basically requires the implementor to make a custom
JSON serializer to ensure that the fields are serialized in the right order.

Using Javascript as an example, instead of just doing a simple string
construction:

  tp_input = [jwk.e, jwk.kty, jwk.n].join("|")

... instead, I construct and fill in a template:

  tp_input = '{"e":"JWK_E","kty":"JWK_KTY","n":"JWK_N"}'
    .replace("JWK_E", jwk.e)
    .replace("JWK_KTY", jwk.kty)
    .replace("JWK_N", jwk.n)

Requiring a lot of manual coding like this seems to invite interop issues.

The remainder of the text looks fine to me, though.

--Richard

---

From: John Bradley <[email-masked]>
Date: Fri, 23 Jan 2015 12:00:20 -0300

My concern with salting is that in the near future that may turn out not to be effective.  

One observation about salting low entropy keys/passwords is that if the salt is known to the attacker, it may provide a deterrent to rainbow tables, but not one to crackers like oclhashcat.
http://codahale.com/how-to-safely-store-a-password/

The above applies to simple concatenated salt || key cracking but the trend is relatively clear.

Using PBKDF2 or bcrypt are probably more effective than a simple salt.  Though I don't think changing to a different alg for symmetric keys is going to be all that useful.

Low entropy symmetric keys are the problem.   That could be dealt with as a security consideration,  or by precluding thumbprints of symmetric keys.

John B.

> On Jan 23, 2015, at 10:46 AM, Vladimir Dzhuvinov <[email-masked]> wrote:
>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 23 Jan 2015 15:20:15 +0000

On 23/01/15 15:00, John Bradley wrote:
> One observation about salting low entropy keys/passwords is that if
> the salt is known to the attacker, it may provide a deterrent to
> rainbow tables, but not one to crackers like oclhashcat. 

True, but I think thumbprint=salt||sha256(f(salt,key)) is still
better than sha256(key) which immediately gives the game away.
But yes, bcrypt or pbkdf2 would of course be better.

> Using PBKDF2 or bcrypt are probably more effective than a simple
> salt.  Though I don't think changing to a different alg for symmetric
> keys is going to be all that useful.
> 
> Low entropy symmetric keys are the problem.   That could be dealt
> with as a security consideration,  or by precluding thumbprints of
> symmetric keys.

Yeah fair points. I'm not clear if thumbprints of symmetric keys
are needed but if they are then h(secret) just isn't good enough
a lot of the time, so I'd say the good choices are 1) don't support
symmetric or 2) figure out an acceptable way to do it that's not
a slam-dunk for the attacker when a low-entropy secret is used.
Either implies a change to the draft.

S

>> What would be a good way to pass the salt? Within the "jkt"
>> parameter using some kind of a delimiter, or using a separate
>> parameter?
>> 
>> We've got a use case where we need to identify shared JWKs (oct).
>> These start at 128 bits. What length is generally considered
>> low-entropy to require a salt to be added?
>> 
>> Vladimir
>> 
>>> I just had a quick look and it seems fine for asymmetric keys
>>> assuming there's a need for it and a justification for including
>>> things like '{"e":' in the hash input, which I don't see.
>>> 
>>> The reason I looked at this is that there's some overlap here
>>> with RFC6920, (I'm an author of that) and DANE and maybe other
>>> specs that say how to hash a public key.
>>> 
>>> It does seem a shame to have so many ways to hash public keys,
>>> but 6920 is compatible with DANE and others that hash a SPKI
>>> (even if that's artificially created just as a hash input), so I
>>> wonder if the benefit of the running code here is really worth
>>> being different from other specs that hash a SPKI.
>>> 
>>> So, other than that someone has some code, what is the benefit of
>>> being incompatible with other specs here?
>>> 
>>> The downside is that I could not determine that one of these
>>> does/doesn't map to the same public key as some DANE RRs for
>>> example. Seems a bit odd to me to want to accept that downside
>>> unless there's an upside.
>>> 
>>> Only other thing is for symmetric keys I think you should add an
>>> optional salt, in case you need the thumbprint of a low-entropy
>>> secret, which is quite likely to happen, and quite likely to get
>>> exposed somehow. And I'd argue to recommend that a long salt
>>> always be used for potentially low-entropy secret keys.
>>> 
>>>> This starts a two week last call on
>>>> draft-ietf-jose-jwk-thumbprint.  Last call will end on February
>>>> 2, 2015.
>>>> 
>>>> 
>>>> 
>>>> Due to the general lack of activity on the list.  General
>>>> silence will be considered as a vote to park the document and
>>>> either have it done via the ISE or with an AD shepherd rather
>>>> than having group consensus.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________ jose mailing
>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/jose
>>>> 
>>> _______________________________________________ jose mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/jose
>> 
>> -- Vladimir Dzhuvinov :: [email-masked]
>> 
>> _______________________________________________ jose mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/jose
> 
> 
> 
> _______________________________________________ jose mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/jose
>

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 23 Jan 2015 09:21:29 -0800

Why do you find using a this draft rather than generating some type of
random value for kid to be preferable.  If you generate a kid value it does
not have to be dependent on the value of the key and therefore a low entropy
key generator would not be a big issue.

Jim

> From: jose [mailto:[email-masked]] On Behalf Of Vladimir Dzhuvinov
> Sent: Friday, January 23, 2015 5:46 AM
> To: [email-masked]
using
> some kind of a delimiter, or using a separate parameter?
> 
start
> at 128 bits. What length is generally considered low-entropy to require a
salt to
> be added?
> > I just had a quick look and it seems fine for asymmetric keys assuming
> > there's a need for it and a justification for including things like
> > It does seem a shame to have so many ways to hash public keys, but
> > 6920 is compatible with DANE and others that hash a SPKI (even if
> > that's artificially created just as a hash input), so I wonder if the
> > benefit of the running code here is really worth being different from
> > other specs that hash a SPKI.
> >
> > does/doesn't map to the same public key as some DANE RRs for example.
> > exposed somehow. And I'd argue to recommend that a long salt always be
> > used for potentially low-entropy secret keys.
> >
> >> Due to the general lack of activity on the list.  General silence
> >> will be considered as a vote to park the document and either have it
> >> done via the ISE or with an AD shepherd rather than having group
> consensus.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 23 Jan 2015 09:26:31 -0800

I have to agree that the fact that you cannot just do a simple stringify is one of the things that I do not care for.  This is one of the reasons that I pressed this issue in my last review to figure out if that was going to just simply work.

From: jose [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Friday, January 23, 2015 6:54 AM
To: Jim Schaad
Cc: [email-masked]
Subject: Re: [jose] Working Group last call on draft-ietf-jose-jwk-thumbprint

I would summarize my reaction to this document as "I can live with it, but it makes me really sad that we didn't do the stupid simple obvious thing."

The computation of the hash input is technically workable, but unnecessarily complex.  Rather than building a simple string based on the components (say, ), it basically requires the implementor to make a custom JSON serializer to ensure that the fields are serialized in the right order.

Using Javascript as an example, instead of just doing a simple string construction:

    .replace("JWK_E", jwk.e)

    .replace("JWK_N", jwk.n)

--Richard

---

From: ⌘ Matt Miller <[email-masked]>
Date: Fri, 23 Jan 2015 10:28:35 -0700

On 1/23/15 7:54 AM, Richard Barnes wrote:
> I would summarize my reaction to this document as "I can live with
> it, but it makes me really sad that we didn't do the stupid simple
> obvious thing."
> 
> unnecessarily complex.  Rather than building a simple string based
> on the components (say, ), it basically requires the implementor to
> make a custom JSON serializer to ensure that the fields are
> serialized in the right order.
> 
> .replace("JWK_E", jwk.e) .replace("JWK_KTY", jwk.kty) 
> .replace("JWK_N", jwk.n)
> 

I agree with Richard that the hash input looks needlessly complex.
Picking a delimiter isn't necessary if it instead takes advantage of
existing JSON implementations by simply serializing an array of the
required values, still ordered lexicographically according to their
associated member names.

In some real code, that's:

* JavaScript: tp_input = JSON.stringify([jwk.e, jwk.kty, jwk.n]);
* Ruby: tp_input = JSON.generate [ jwk["e"], jwk["kty"], jwk["n"] ]
* Python: tp_input = json.dumps([jwk['e'], jwk['kty'], jwk['n'])

This could very well get rid of most of section 5.  It might also get
rid of some of text in Section 7 regarding weird member names if we're
careful.

- -- 
- - m&m

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

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 23 Jan 2015 17:38:23 +0000

> I agree with Richard that the hash input looks needlessly complex.

Well that's one dimension and if the wg consider it's not
important to produce something one can compare with hashed
public keys from other protocols that's fine and I'd agree
with Richard/you.

But, why give up the ability to compare thumbprints with
DANE etc?

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.

S.

PS: Just to be clear, I'm not arguing that the wg should
produce ni URIs, but that the hash input be the same as
that and DANE etc. In the process of writing 6920 I did
take a look around and SPKI was the most commonly used
hash input I found then and I suspect still is.

---

From: Richard Barnes <[email-masked]>
Date: Fri, 23 Jan 2015 12:57:13 -0500

On Fri, Jan 23, 2015 at 12:38 PM, Stephen Farrell <[email-masked]
> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>

Dude, seriously.  The whole point of this WG is to not do ASN.1.

--Richard

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJUwocPAAoJEC88hzaAX42iQWoH/3hDWZiCyGpCQGCp9gGd7H2/
> i4tWtaW5fex9ELKL3gEN7UjUAN6u0uJMyAobvGbD+EkVoRFndi5dmUjrwR7HJgXX
> JpNiBkZf97hVJ865C4sS3yHxlVtUK/c3/Dyusw32u9VgbcEo8w+HT1R0kqreEY3s
> Gy/oeGC1vzFgRngCe5Zv2GRacROCVe/fYp8ogPYUBoN18bBZHROb/Av5wcr/V5WR
> 9QEnY/nrehFdBp9euRkWOqx3l2fMGj628NgTfQRm+ZX4a3pyNfYnCxiJ10oHdqYt
> WyGxrAf8RALyektd7KviFbXLVWr4vl7KWU3WvZhfF92Iovf5VN8b3yp7xuhc6OQ=
> =GbJ+
> -----END PGP SIGNATURE-----
>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 23 Jan 2015 18:04:19 +0000

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

---

From: ⌘ Matt Miller <[email-masked]>
Date: Fri, 23 Jan 2015 11:04:49 -0700

On 1/23/15 10:57 AM, Richard Barnes wrote:
> 
> 
> On Fri, Jan 23, 2015 at 12:38 PM, Stephen Farrell 
> <[email-masked] <mailto:[email-masked]>>
> wrote:
> 
> 
> 
> Well that's one dimension and if the wg consider it's not important
> to produce something one can compare with hashed public keys from
> other protocols that's fine and I'd agree with Richard/you.
> 
> But, why give up the ability to compare thumbprints with DANE etc?
> 
> 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.
> 
> 

One could make an argument that the JWK thumbprint hash input be
defined in a manner that's not in terms of ASN.1 but would be
compatible [1].

But I am not making that argument, because it's way more work than I'm
willing to do, with little payoff for the things I work on.

- -- 
- - m&m

[1] http://cdn.meme.am/instances/500x/58395759.jpg

---

From: Richard Barnes <[email-masked]>
Date: Fri, 23 Jan 2015 13:09:35 -0500

On Fri, Jan 23, 2015 at 1:04 PM, ⌘ Matt Miller <[email-masked]> wrote:

> Hash: SHA512

Anything that would be compatible would require decoding and dealing with
binary octets, which I'm pretty sure is more work than most people on this
list are willing to do just to get a thumbprint.

> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
> Comment: GPGTools - https://gpgtools.org
>
> iQEcBAEBCgAGBQJUwo1BAAoJEDWi+S0W7cO1EFYH/0mI4W3W5YduIxF8BiDwpGB/
> v5N0j/88Ed8uAUVHbcI/hqU0HX/S2ytx2ORnU1yw7hKcjHyfrFbjO0YJxz6QkshI
> E7zvoqWoUL9C0YYko9m51UsUJkK0C5OS//q1AX9ilt51C9NBNkLUCWK03Cv9FtPG
> EcVzE9H0Ye9lvnC8FyQpdKNO9Z7bdtUr9oV1r7INTpQjZX4zvLci6lIrRmniJAKa
> rlgJJoTNn+txwnVIdmLmXn78P5fJPYgIcFAuciV0s0rlCx/UFNeyr9Yd7J206Vgv
> kCsOO5aiD3yBsfzkgqCMYD/v9C+QrfDp9RKeVGJ9EAfmQmHGx5s2p7pNyZ3rYAM=
> =iHwT

---

From: Richard Barnes <[email-masked]>
Date: Fri, 23 Jan 2015 13:12:07 -0500

> whole point of this and other WGs I'd guess (...dude:-)

Yes, you could quasi-templatize it.  You would still have to manually
adjust length fields and munge byte strings together.  Eww.

Given the amount of DANE deployment, it's not a huge priority for me.  DANE
could also meet us half-way here by defining a new binding type should
there be a need.

--Richard

---

From: John Bradley <[email-masked]>
Date: Fri, 23 Jan 2015 15:17:31 -0300

Mat in the first version that we did, we didn't have delimiters.

I think it was James Manger that pointed out that without delimiters there were some potential attacks. 

Depending on the order of the parameters the issues are different. 

I think the specific issue was concatenating e directly to n.

That lead us to create the current doc.

John B.

> On Jan 23, 2015, at 2:28 PM, ⌘ Matt Miller <[email-masked]> wrote:
> 
> iQEcBAEBCgAGBQJUwoTDAAoJEDWi+S0W7cO16gYH+wbQ+RhWRoPOXDEXa0ieyqzD
> GxS+6Jj77QQjknkm9bfw+6mTzP0+CFshy4OJP/qNQScRLSTvDS20sQUPPb4/NAbq
> CV/xV9Td/OrT/73iwR17PHoovLkwHOhbgxX93U4XA6JXVXSlslM0hUKBsDfmqM4j
> jBI0yRvowAweDhmQ5rqdHhH4WBQQamR2XT8y61H9ERHAvlru3v5C9n3Qwa9Y8/ju
> 1SjzQc1t1UIE3vOmhkxZWlkDfnWI6grOoGDt/JIy7JIK/0WJ/g8mjbqUTh61xU3V
> a6SAjw0fjvhfJQ6FJfmmteOYVCOeUO0fCNTCjnkDBMtz9Zho+H7WUfXBvE5QrrY=
> =lZoe

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 23 Jan 2015 18:21:12 +0000

> adjust length fields and munge byte strings together.  Eww.

Not in practice no, public key lengths aren't that variable
and all that's is done by most libraries incl. webcrypto and
openssl - in fact I'd be interested in knowing which crypto
libraries do not directly support this already. I can't think
of any tbh. And I assume our thumbprinting code will use
a library for the hashing and that the public key is very
likely to be used as well as just thumbprinted, so your
argument seems to me broken and h(spki) likely simpler
overall.

> could also meet us half-way here by defining a new binding type should

It's not only DANE - if you go looking around h(spki) is
what's used elsewhere too. And the reason is it's obvious
and correct.

The choice seems to be between something compatible with
other protocols (allowing comparisons) or rolling your
own to save 2 lines of code or so. (Assuming there are
no other advantages to what you're suggesting?)

But we're repeating ourselves nearly I guess.

S.

---

From: Richard Barnes <[email-masked]>
Date: Fri, 23 Jan 2015 13:32:49 -0500

> But we're repeating ourselves nearly I guess.

As a matter of process, this would have been a good objection to bring up
at milestone / doc adoption time, since if we're just doing h(spki),
there's no need for a document.

--Richard

---

From: Mike Jones <[email-masked]>
Date: Fri, 23 Jan 2015 18:39:06 +0000

I was about to write a similar message to John's.  James Manger also pointed out the need to have different hash inputs for different kinds of keys, so as to avoid the possibility of collisions.  The simple suggestion earlier in the thread of using an array of values for the hash input doesn't have this property.  If there were two kinds of keys with the same number of values in the input, for instance three values such as [A, B, C], then without also having the member tags "kty", etc. in the hash input, collisions are possible.

That's why James suggested that the natural and safe hash input for a JWK is a sorted JWK itself.  We went with that.

I agree that encodings using ASN.1 sort of defeat the point.  Others could define how to do that and add them to the appropriate registries if they want, but using JSON solutions is the point of the working group and this draft.

As for symmetric keys, I don't think we actually have a use case for them at present.  I'd be fine with the working group deciding to drop them or to add security considerations on the necessity for there to be sufficient key entropy if a thumbprint is to be exposed to a party not holding the key.  Or the security considerations could say that the thumbprint MUST only be exposed to parties already in possession of the key.  While I understand going the salt route, I'm only comfortable with us doing that now if someone has a real use case for it.  Since I think the chairs want to have this draft complete quickly, I'd rather drop symmetric keys than figure out the salt mechanisms on the fly.  But others are free to propose otherwise, obviously.

At a meta-point responding to Jim's message, I think this morning's discussions exactly demonstrate the value of the draft being in the working group.  There's a lot of good discussion going on about the choices made, tradeoffs, and alternatives that wouldn't necessarily happen if this weren't a working group draft.

				Thanks all,
				-- Mike

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

John B.

>> unnecessarily complex.  Rather than building a simple string based on 
>> the components (say, ), it basically requires the implementor to make 
>> a custom JSON serializer to ensure that the fields are serialized in 
>> the right order.
>>

---

From: Mike Jones <[email-masked]>
Date: Fri, 23 Jan 2015 18:46:27 +0000

> As a matter of process, this would have been a good objection to bring up at milestone / doc adoption time, since if we're just doing h(spki), there's no need for a document.

Actually, the point of the draft would be to define and register the header parameter names used to hold the value for each particular hash function used.

                                                            -- Mike

---

From: Richard Barnes <[email-masked]>
Date: Fri, 23 Jan 2015 13:54:10 -0500

On Fri, Jan 23, 2015 at 1:39 PM, Mike Jones <[email-masked]>
wrote:

> I was about to write a similar message to John's.  James Manger also
> pointed out the need to have different hash inputs for different kinds of
> keys, so as to avoid the possibility of collisions.  The simple suggestion
> earlier in the thread of using an array of values for the hash input
> doesn't have this property.  If there were two kinds of keys with the same
> number of values in the input, for instance three values such as [A, B, C],
> then without also having the member tags "kty", etc. in the hash input,
> collisions are possible.
>
> That's why James suggested that the natural and safe hash input for a JWK
> is a sorted JWK itself.  We went with that.
>

The problem is that there's no good way to create a "sorted JWK".  (BTW,
you also mean "whitespace-free".)  Thankfully, the whitespace problem is
easy to deal with here.  Since the included attributes do not allow any
internal whitespace, you can just delete all whitespace.  But sorting is a
big deal.  Like I said, it basically requires you to hand-serialize the
JSON.  At which point, you might as well use ASN.1 :)

ISTM that (1) including "kty" and (2) using a delimiter that's not in the
allowed character set would together address the collision issues.  So we
could get away with something like "kty-value|n-value|e-value".  Miller's
proposal to use a JSON array would also work for me, although it would
require removing white space in case the serializer added any.  Anything
that doesn't require custom serialization code :)

> I agree that encodings using ASN.1 sort of defeat the point.  Others could
> define how to do that and add them to the appropriate registries if they
> want, but using JSON solutions is the point of the working group and this
> draft.
>
> As for symmetric keys, I don't think we actually have a use case for them
> at present.  I'd be fine with the working group deciding to drop them or to
> add security considerations on the necessity for there to be sufficient key
> entropy if a thumbprint is to be exposed to a party not holding the key.
> Or the security considerations could say that the thumbprint MUST only be
> exposed to parties already in possession of the key.  While I understand
> going the salt route, I'm only comfortable with us doing that now if
> someone has a real use case for it.  Since I think the chairs want to have
> this draft complete quickly, I'd rather drop symmetric keys than figure out
> the salt mechanisms on the fly.  But others are free to propose otherwise,
> obviously.
>
> At a meta-point responding to Jim's message, I think this morning's
> discussions exactly demonstrate the value of the draft being in the working
> group.  There's a lot of good discussion going on about the choices made,
> tradeoffs, and alternatives that wouldn't necessarily happen if this
> weren't a working group draft.
>
>                                 Thanks all,
>                                 -- Mike
>

---

From: John Bradley <[email-masked]>
Date: Fri, 23 Jan 2015 15:55:20 -0300

The only use I had for something like this with symmetric keys was in PKCE/SPOP https://tools.ietf.org/html/draft-ietf-oauth-spop-06

However trying to do it with a JWK added more complexity that it is worth.

We settled on hashing the symmetric key directly and getting people to use 256bit keys to eliminate the need to salt.

I can live with limiting this to public keys.

John B.

> On Jan 23, 2015, at 3:39 PM, Mike Jones <[email-masked]> wrote:
>

---

From: Mike Jones <[email-masked]>
Date: Fri, 23 Jan 2015 19:02:11 +0000

In practice, you wouldn’t ever implement the sort.  You’d have printf statements for the key types you support (and we’ve only defined three of them to date – only two if you only use public keys).  So in pseudo-code, the hash input generator I would write would look something like this:

if kty == “RSA” then
    printf(‘{“e”:”’, e, ‘”,”kty”:”’, kty, ‘”,”n”:”’, n, ‘”}’)
else if kty == “EC” then
    printf(‘{“crv”:”’, crv, ‘”,”kty”:”’, kty, ‘”,”x”:”’, x, ‘”,”y”:”’, y, ‘”}’)
else
    FAIL

No sorting code involved!

From: Richard Barnes [mailto:[email-masked]]
Sent: Friday, January 23, 2015 10:54 AM
To: Mike Jones
Cc: John Bradley; Matt Miller; Jim Schaad; [email-masked]
Subject: Re: [jose] Working Group last call on draft-ietf-jose-jwk-thumbprint

On Fri, Jan 23, 2015 at 1:39 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
I was about to write a similar message to John's.  James Manger also pointed out the need to have different hash inputs for different kinds of keys, so as to avoid the possibility of collisions.  The simple suggestion earlier in the thread of using an array of values for the hash input doesn't have this property.  If there were two kinds of keys with the same number of values in the input, for instance three values such as [A, B, C], then without also having the member tags "kty", etc. in the hash input, collisions are possible.

The problem is that there's no good way to create a "sorted JWK".  (BTW, you also mean "whitespace-free".)  Thankfully, the whitespace problem is easy to deal with here.  Since the included attributes do not allow any internal whitespace, you can just delete all whitespace.  But sorting is a big deal.  Like I said, it basically requires you to hand-serialize the JSON.  At which point, you might as well use ASN.1 :)

ISTM that (1) including "kty" and (2) using a delimiter that's not in the allowed character set would together address the collision issues.  So we could get away with something like "kty-value|n-value|e-value".  Miller's proposal to use a JSON array would also work for me, although it would require removing white space in case the serializer added any.  Anything that doesn't require custom serialization code :)

                                Thanks all,
                                -- Mike

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

John B.

> On Jan 23, 2015, at 2:28 PM, ⌘ Matt Miller <[email-masked]<mailto:[email-masked]>> wrote:
>
> Matt Miller < [email-masked]<mailto:[email-masked]> >
> Cisco Systems, Inc.

---

From: Mike Jones <[email-masked]>
Date: Fri, 23 Jan 2015 19:04:56 +0000

In fact, we should probably add an appendix with an implementation note to that effect, so people don’t needlessly go down the complicated path when the simple one is the one intended.

From: Mike Jones
Sent: Friday, January 23, 2015 11:02 AM
To: 'Richard Barnes'
Cc: John Bradley; Matt Miller; Jim Schaad; [email-masked]
Subject: RE: [jose] Working Group last call on draft-ietf-jose-jwk-thumbprint

if kty == “RSA” then

From: Richard Barnes [mailto:[email-masked]]
Sent: Friday, January 23, 2015 10:54 AM
To: Mike Jones
Cc: John Bradley; Matt Miller; Jim Schaad; [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] Working Group last call on draft-ietf-jose-jwk-thumbprint

                                Thanks all,
                                -- Mike

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

John B.

---

From: "Richer, Justin P." <[email-masked]>
Date: Fri, 23 Jan 2015 19:08:19 +0000

Then this does beg the question, why isn't it a printf statement like this instead:

if kty == "RSA" then
  printf(e, ".", kty, ".", n)
else if kty == "EC" then
  printf(crv, ".", kty, ".", x, ".", y)

Pretending it is a JSON structure doesn't help me if I can't input a JSON object from my source language in a meaningful fashion.

 -- Justin

On Jan 23, 2015, at 2:02 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:

if kty == “RSA” then

                                Thanks all,
                                -- Mike

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

John B.

> Comment: GPGTools - https://gpgtools.org<https://gpgtools.org/>
>

---

From: Mike Jones <[email-masked]>
Date: Fri, 23 Jan 2015 19:12:36 +0000

Periods are used in some JSON values, including strings and floating point numbers, and so wouldn’t be a safe delimiter in all potential future cases.  What if your kty value was “EC.little-endian”, for instance?

From: Richer, Justin P. [mailto:[email-masked]]
Sent: Friday, January 23, 2015 11:08 AM
To: Mike Jones
Cc: Richard Barnes; John Bradley; Jim Schaad; [email-masked]; Matt Miller
Subject: Re: [jose] Working Group last call on draft-ietf-jose-jwk-thumbprint

if kty == "RSA" then

 -- Justin

if kty == “RSA” then

                                Thanks all,
                                -- Mike

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

John B.

---

From: "Richer, Justin P." <[email-masked]>
Date: Fri, 23 Jan 2015 19:25:48 +0000

Complaining about the particular choice of delimiter in my is a red herring, as it could be anything that fits the need. Or you could require quoting of strings (like a json-like string would) and have an unquoted value in the delimiter, I don't care. My point was just that if you're expecting the implementation to be a print-to-template, and that template looks and feels like JSON, you shouldn't be surprised if developers will want to use JSON parsers and objects. If you want them to print to a string template, give them something that's a string template with very, very clear character rules.

I should caveat my opinion here that at this point, I have no driving use case or plan to *use* the thumbprint mechanism, so I'm a little ambivalent about where it lands. That said, I'm in favor of simplicity, which includes not having text pretend to be something it's not.

 -- Justin

On Jan 23, 2015, at 2:12 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:

From: Richer, Justin P. [mailto:[email-masked]]
Sent: Friday, January 23, 2015 11:08 AM
To: Mike Jones
Cc: Richard Barnes; John Bradley; Jim Schaad; [email-masked]<mailto:[email-masked]>; Matt Miller
Subject: Re: [jose] Working Group last call on draft-ietf-jose-jwk-thumbprint

if kty == "RSA" then

 -- Justin

if kty == “RSA” then

                                Thanks all,
                                -- Mike

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

John B.

---

From: ⌘ Matt Miller <[email-masked]>
Date: Fri, 23 Jan 2015 12:27:09 -0700

On 1/23/15 12:12 PM, Mike Jones wrote:
> Periods are used in some JSON values, including strings and
> floating point numbers, and so wouldn’t be a safe delimiter in all
> potential future cases.  What if your kty value was
> “EC.little-endian”, for instance?
> 
> 
> 

I understand your points, but I still think it's more complex than it
needs to be, and can lead to interoperability problems.  Having an
input that looks like you serialize a JSON object is going to lead
some implementers to the false optimization of actually serializing a
JSON object, regardless of what this document says.  It might even
work today for some JSON implementations -- and fail in a future
update to that same implementation.

I'd really rather see some other hash input generation scheme.

- -- 
- - m&m

---

From: Richard Barnes <[email-masked]>
Date: Fri, 23 Jan 2015 15:19:04 -0500

On Fri, Jan 23, 2015 at 2:02 PM, Mike Jones <[email-masked]>
wrote:

>  In practice, you wouldn’t ever implement the sort.  You’d have printf
> statements for the key types you support (and we’ve only defined three of
> them to date – only two if you only use public keys).  So in pseudo-code,
> the hash input generator I would write would look something like this:
>
>
>
> if kty == “RSA” then
>

You may notice that I put something similar in my first message on this
thread :)

My point is that this style of code is brittle and deals poorly with things
like escaping.

I can see your point w.r.t. separators.  That seems to indicate that Matt's
suggestion of a JSON array is the right answer:

tp_input = JSON.stringify([jwk.e, jwk.kty, jwk.n]).replace(/\s/g, "")

That way the order is preserved, but the JSON serializer handles all the
string serialization.

--Richard

>
>
> *From:* Richard Barnes [mailto:[email-masked]]
> *Sent:* Friday, January 23, 2015 10:54 AM
> *To:* Mike Jones
> *Cc:* John Bradley; Matt Miller; Jim Schaad; [email-masked]
>
> *Subject:* Re: [jose] Working Group last call on
> draft-ietf-jose-jwk-thumbprint
>
>
>
>
>
>
>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 23 Jan 2015 15:22:10 -0500

<sarcasm>

Of course, as an alternative, we could follow the example of JWS / JWE
compact and base64url all the things:

base64url(jwk.e) + '.' + base64url(jwk.kty) + '.' + base64url(jwk.n)

</sarcasm>

On Fri, Jan 23, 2015 at 3:19 PM, Richard Barnes <[email-masked]> wrote:

> My point is that this style of code is brittle and deals poorly with
> things like escaping.
>
> I can see your point w.r.t. separators.  That seems to indicate that
> Matt's suggestion of a JSON array is the right answer:
>
>> I agree that encodings using ASN.1 sort of defeat the point.  Others
>> could define how to do that and add them to the appropriate registries if
>> they want, but using JSON solutions is the point of the working group and
>> this draft.
>>

---

From: Mike Jones <[email-masked]>
Date: Fri, 23 Jan 2015 21:14:43 +0000

As I wrote earlier (and as pointed out by James Manger as the format was being designed), the array serialization is subject to collisions between keys of different types unless the field names are also included.  [e, kty, n] in theory could match [kty, x, y] for a different key type, and yet not be the same key.  So the representation needs to include the field names or equivalent metadata – not just the field values.

As for being brittle and dealing with escaping, at least the printf for a particular key type can take advantage of knowledge about the representation of that key type.  For instance, for RSA, EC, and OCT keys, no escaping will ever be needed since the values are all ASCII strings, so the code can be simple.

I agree that any hash input computation with the right properties would do the job.  Those properties are primarily the ability to unambiguously represent a JWK key and necessary key metadata as an octet sequence.  Yes, we could choose anything.  But the good news about the choice in the current draft, which was James Manger’s idea, is that we already have a data structure that is known to be able to unambiguously represent JWK keys, both existing ones and future ones, as an octet sequence.  That data structure is a JWK itself!  That’s why I know that the other inventors and I were drawn to James’ suggestion and why I personally think that it gives us the right balance of simplicity now and flexibility in the future.

                                                                Best wishes,
                                                                -- Mike

From: Richard Barnes [mailto:[email-masked]]
Sent: Friday, January 23, 2015 12:19 PM
To: Mike Jones
Cc: John Bradley; Matt Miller; Jim Schaad; [email-masked]
Subject: Re: [jose] Working Group last call on draft-ietf-jose-jwk-thumbprint

On Fri, Jan 23, 2015 at 2:02 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
In practice, you wouldn’t ever implement the sort.  You’d have printf statements for the key types you support (and we’ve only defined three of them to date – only two if you only use public keys).  So in pseudo-code, the hash input generator I would write would look something like this:

if kty == “RSA” then

You may notice that I put something similar in my first message on this thread :)

My point is that this style of code is brittle and deals poorly with things like escaping.

I can see your point w.r.t. separators.  That seems to indicate that Matt's suggestion of a JSON array is the right answer:

That way the order is preserved, but the JSON serializer handles all the string serialization.

--Richard

From: Richard Barnes [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, January 23, 2015 10:54 AM
To: Mike Jones
Cc: John Bradley; Matt Miller; Jim Schaad; [email-masked]<mailto:[email-masked]>

                                Thanks all,
                                -- Mike

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

John B.

---

From: John Bradley <[email-masked]>
Date: Fri, 23 Jan 2015 18:26:56 -0300

Yes,  it allows for new key types to work with this spec in the future without needing to redo the spec and worry about downgrade attacks.

It seemed obvious at the time to use the JWK format.   It is interesting that some people specifically don’t want that.

Atleast we have the conversation restarted.

> On Jan 23, 2015, at 6:14 PM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
> 
> From: Richard Barnes [mailto:[email-masked] <mailto:[email-masked]>] 
> Cc: John Bradley; Matt Miller; Jim Schaad; [email-masked] <mailto:[email-masked]>
> On Fri, Jan 23, 2015 at 2:02 PM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
> From: Richard Barnes [mailto:[email-masked] <mailto:[email-masked]>] 
> Cc: John Bradley; Matt Miller; Jim Schaad; [email-masked] <mailto:[email-masked]>
> 
> On Fri, Jan 23, 2015 at 1:39 PM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
> From: jose [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of John Bradley
> Cc: Richard Barnes; Jim Schaad; [email-masked] <mailto:[email-masked]>
> > On Jan 23, 2015, at 2:28 PM, ⌘ Matt Miller <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > Matt Miller < [email-masked] <mailto:[email-masked]> >
> > Cisco Systems, Inc.
> > Comment: GPGTools - https://gpgtools.org <https://gpgtools.org/>
> >

---

From: ⌘ Matt Miller <[email-masked]>
Date: Fri, 23 Jan 2015 14:50:27 -0700

On 1/23/15 2:26 PM, John Bradley wrote:
> Yes,  it allows for new key types to work with this spec in the 
> future without needing to redo the spec and worry about downgrade 
> attacks.
> 
> It seemed obvious at the time to use the JWK format.   It is 
> interesting that some people specifically don’t want that.
> 

This document is calling for handcrafting JSON.  It's eschewing
whatever existing support in order to have a canonical format[1].

My original proposal still included the kty, which (I assume)
disambiguates heterogeneous keys today.  I think it exceedingly
unlikely that two different keys of different types will have
parameter names and values that will collide with others, but I accept
that some find it worthy of concern.

What if the serialization were a JSON array consisting of an array of
pairs -- the member name followed by the member value?  For instance:

[["crv","P-256"],["kty","EC"],["x","Ze2loSV3wrroKUN_4zhwGhCqo3Xhu1td4QjeQ5wIVR0"],["y","HlLtdXARY_f55A3fnzQbPcm6hgr34Mp8p-nuzQCE0Zw"]]

Or in a flattened format, which is probably about the same amount of
coding work:

["crv","P-256","kty","EC","x","Ze2loSV3wrroKUN_4zhwGhCqo3Xhu1td4QjeQ5wIVR0","y","HlLtdXARY_f55A3fnzQbPcm6hgr34Mp8p-nuzQCE0Zw"]

Or maybe we seriously consider SPKI.

- -- 
- - m&m

[1] And yes, I fully appreciate how little weight this argument
carries if a certain working group did something about canonicalization.

---

From: John Bradley <[email-masked]>
Date: Fri, 23 Jan 2015 19:07:55 -0300

I don't know that having the element names is required.

They do however need to be sorted into a canonical order with separators, and kty is required.

We should probably give James a chance to respond from his TZ.

I don't personally care all that much what the separator character is as long as it cant appear in the values.

I think Richard mentioned some issues with spaces in using an array. 
Are there any other issues?

John B.

> On Jan 23, 2015, at 6:50 PM, ⌘ Matt Miller <[email-masked]> wrote:
> 
> iQEcBAEBCgAGBQJUwsIjAAoJEDWi+S0W7cO10roH/jvyu4X/nTBW/sYw94l2xa6L
> kDd4ZuQwQOPoSI0IawcZ8PQOk/php3eumS1EqTR/kxMGNbfDrc72Si3Kb6s4dRot
> ZPn9ol8fu9HjaQUlT5J/f1tjLjClISVYZ/fAdu+GbxM/4C2tsgnyzWLPfLVE6l5k
> MSGyV5j0MTmY3rBX5oQEcLRZc48EibL+R+gka0Mi/zSFdOkrVPG5i8E/qV1HwO2O
> pIXHpvj/vuyrbFSjWml1Y9yiC4bMTK5HePgVzZ3+Jj1dBibg+TDH9gQMoInEIIIS
> yKbt74TmZ5DLPobfPcmvBSofdMCPGgNIQWiF1OBJZpzj14d/APgAj+ICv0C4Ycc=
> =+KOE

---

From: Richard Barnes <[email-masked]>
Date: Fri, 23 Jan 2015 17:12:18 -0500

On Fri, Jan 23, 2015 at 4:14 PM, Mike Jones <[email-masked]>
wrote:

>  As I wrote earlier (and as pointed out by James Manger as the format was
> being designed), the array serialization is subject to collisions between
> keys of different types unless the field names are also included.  [e, kty,
> n] in theory could match [kty, x, y] for a different key type, and yet not
> be the same key.  So the representation needs to include the field names or
> equivalent metadata – not just the field values.
>

This seems like a total red herring.  You can solve this entirely by
putting kty in a fixed position (first).

As for being brittle and dealing with escaping, at least the printf for a
> particular key type can take advantage of knowledge about the
> representation of that key type.  For instance, for RSA, EC, and OCT keys,
> no escaping will ever be needed since the values are all ASCII strings, so
> the code can be simple.
>
>
> I agree that any hash input computation with the right properties would do
> the job.  Those properties are primarily the ability to unambiguously
> represent a JWK key and necessary key metadata as an octet sequence.  Yes,
> we could choose anything.  But the good news about the choice in the
> current draft, which was James Manger’s idea, is that we already have a
> data structure that is known to be able to unambiguously represent JWK
> keys, both existing ones and future ones, as an octet sequence.  That data
> structure is a JWK itself!  That’s why I know that the other inventors and
> I were drawn to James’ suggestion and why I personally think that it gives
> us the right balance of simplicity now and flexibility in the future.
>

If we had a canonical form for JSON, or even canonicalizing serializers, I
would agree with you.  But we don't, so I don't.

--Richard

>                                                                 Best
> wishes,
> *Sent:* Friday, January 23, 2015 12:19 PM
>
> *To:* Mike Jones

---

From: Mike Jones <[email-masked]>
Date: Fri, 23 Jan 2015 22:18:12 +0000

An array-based serialization assumes that JWKs will never have structured values - JSON objects or arrays - that, or that when that case arises for future JWKs we'll have to invent an extension to the serialization instructions at that time.  It's not inconceivable that a future key format might include tuples of values, for instance.  The beauty of the current algorithm, being JSON-based, is that it's fairly future-proof.

-----Original Message-----
From: ⌘ Matt Miller [mailto:[email-masked]] 
Sent: Friday, January 23, 2015 1:50 PM
To: John Bradley; Mike Jones
Cc: Richard Barnes; Jim Schaad; [email-masked]
Subject: Re: [jose] Working Group last call on draft-ietf-jose-jwk-thumbprint

On 1/23/15 2:26 PM, John Bradley wrote:
> Yes,  it allows for new key types to work with this spec in the future 
> without needing to redo the spec and worry about downgrade attacks.
> 

This document is calling for handcrafting JSON.  It's eschewing whatever existing support in order to have a canonical format[1].

My original proposal still included the kty, which (I assume) disambiguates heterogeneous keys today.  I think it exceedingly unlikely that two different keys of different types will have parameter names and values that will collide with others, but I accept that some find it worthy of concern.

What if the serialization were a JSON array consisting of an array of pairs -- the member name followed by the member value?  For instance:

Or in a flattened format, which is probably about the same amount of coding work:

- --
- - m&m

[1] And yes, I fully appreciate how little weight this argument carries if a certain working group did something about canonicalization.

---

From: ⌘ Matt Miller <[email-masked]>
Date: Fri, 23 Jan 2015 15:19:13 -0700

On 1/23/15 3:07 PM, John Bradley wrote:
> I don't personally care all that much what the separator character
> is as long as it cant appear in the values.
> 
> I think Richard mentioned some issues with spaces in using an
> array. Are there any other issues?
> 

Some JSON serializers (notably one for Python) insert spaces between
array elements by default, although that can be disabled in the ones
I'm aware of.  The vast majority of other JSON serializers don't by
default.

- -- 
- - m&m

---

From: Mike Jones <[email-masked]>
Date: Fri, 23 Jan 2015 22:24:41 +0000

Replies inline…

From: Richard Barnes [mailto:[email-masked]]
Sent: Friday, January 23, 2015 2:12 PM
To: Mike Jones
Cc: John Bradley; Matt Miller; Jim Schaad; [email-masked]
Subject: Re: [jose] Working Group last call on draft-ietf-jose-jwk-thumbprint

On Fri, Jan 23, 2015 at 4:14 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
As I wrote earlier (and as pointed out by James Manger as the format was being designed), the array serialization is subject to collisions between keys of different types unless the field names are also included.  [e, kty, n] in theory could match [kty, x, y] for a different key type, and yet not be the same key.  So the representation needs to include the field names or equivalent metadata – not just the field values.

This seems like a total red herring.  You can solve this entirely by putting kty in a fixed position (first).

As I just wrote to Matt, an array-based serialization isn’t future-proof, as there isn’t an obvious way of serializing structured values, such as JSON objects or arrays.  I’m more worried about inventing something new than using something that’s already well-defined, because even if new code is needed to emit the fields in sorted order, at least the intended syntax is already clear and accommodates the full range of reasonable JSON JWK representations that might be used.
As for being brittle and dealing with escaping, at least the printf for a particular key type can take advantage of knowledge about the representation of that key type.  For instance, for RSA, EC, and OCT keys, no escaping will ever be needed since the values are all ASCII strings, so the code can be simple.

If we had a canonical form for JSON, or even canonicalizing serializers, I would agree with you.  But we don't, so I don't.

There’s actually a few open source ones out there already that do the right thing for all the cases we’re using.

--Richard

                                                                Best wishes,
                                                                -- Mike

To: Mike Jones

if kty == “RSA” then

--Richard

                                Thanks all,
                                -- Mike

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

John B.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 23 Jan 2015 23:12:57 +0000

> Or maybe we seriously consider SPKI.

Yes. It works. It's used elsewhere so offers better
interop. All libraries support it so coding up the
thumbprint stuff with that is trivial and far less
error prone. It avoids any need for (even more)
pointless debate about hash-input nitpicking. There's
less spec text needed too. All useful asymmetric
algs will have a well defined SPKI for the next
decade because those are used in TLS and for the
WebPKI which is not going away no matter how much
you want it to go away. That is a pile of advantages.

And, most important, there is zero advantage in
pointlessly inventing a new variation. Frankly the
supposed advantages offered so far:

- - a line or two less code, (maybe, maybe not,
  unimportant in any case)
- - "not asn.1" (nonsense, SPKI needs no generic
  asn.1 support, we've known for decades how
  to do without that, and your library constructs
  the octets from the key already)
- - "it should be json" (more nonsense, it's a hash
  input and never sent or stored, nobody cares what
  format it has)

...are utterly unconvincing in any rational view.

S.

PS: As another data point, the W3C sub-resource
integrity spec [1] uses ni URIs today. I've no idea
if that's likely to last into a W3C REC or get
deployed, but seems to me like not-reinventing in
this space is one sensible thing those folks have
(sensibly:-) done, given the utter lack of benefit
from re-inventing.

[1] http://www.w3.org/TR/SRI/

---

From: Mike Jones <[email-masked]>
Date: Sat, 24 Jan 2015 02:12:10 +0000

> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Friday, January 23, 2015 3:13 PM
> To: ⌘ Matt Miller; John Bradley; Mike Jones
> Yes. It works. It's used elsewhere so offers better interop. All libraries
> support it so coding up the thumbprint stuff with that is trivial and far less
> error prone.

I believe you that you have SPKI support if you're writing in C/C++, Java, or C# but not necessarily if you're writing in JavaScript, Ruby, Python, etc.

> It avoids any need for (even more) pointless debate about
> hash-input nitpicking. There's less spec text needed too. All useful
> asymmetric algs will have a well defined SPKI for the next decade because
> those are used in TLS and for the WebPKI which is not going away no matter
> how much you want it to go away. That is a pile of advantages.
> 
> And, most important, there is zero advantage in pointlessly inventing a new
> variation. Frankly the supposed advantages offered so far:
> 

If you follow this line of reasoning to its logical conclusion, we would have insisted on people always using SPKI and/or X.509 key representations, rather than "pointlessly inventing a new variation" called JWK.  And for that matter, we would have insisted on people using CMS rather than developing JWS and JWE. ;-)

I'm not saying that it's not possible to construct SPKI hash inputs from JWKs in JavaScript, etc., but creating the one specified in the draft seems a lot more straightforward to me if what you already have is a JWK.

> PS: As another data point, the W3C sub-resource integrity spec [1] uses ni
> URIs today. I've no idea if that's likely to last into a W3C REC or get deployed,
> but seems to me like not-reinventing in this space is one sensible thing those
> folks have
> (sensibly:-) done, given the utter lack of benefit from re-inventing.
> 

P.S.  There's nothing stopping someone from writing a very short draft also registering header parameter names for hashes of SPKI key values.  I'm all for that.  Then people can vote with their feet (with their code) on which they prefer to build and use.

				-- Mike

---

From: hideki nara <[email-masked]>
Date: Sat, 24 Jan 2015 14:16:53 +0900

I'm thinking of the following 3 times alter reading draft 01.

1. "jkt" seems to be used to identify a Jwk.
     So this can replace "kid", can't?

2. It should be mentioned if a "jkt" is specified
     in a protected header or an unprotected header
    for the "JSON Serialization" in JWS/JWE.

3. (This has been discussed while I'm sleeping)
    JSON canonicalization should be stated more clearly.

   For example, because Python "json.dumps(obj)" fills single whitespace
   just after separators(",", ":") by default,
   the "separators" parameter must be specified to override this.

Regards,
---
hideki

---

From: [email-masked]
Date: Sat, 24 Jan 2015 12:04:36 +0000

> I believe you that you have SPKI support if you're writing in C/C++, Java, or C# but not necessarily if you're writing in JavaScript, Ruby, Python, etc.

Sorry I think you're wrong. Afaik all of em and php have this if they have crypto.  

S

---

From: Brian Campbell <[email-masked]>
Date: Sat, 24 Jan 2015 07:35:59 -0700

+ 1 to the point below about the value of the draft being in the working
group

---

From: "Jim Schaad" <[email-masked]>
Date: Sat, 24 Jan 2015 10:39:13 -0800

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

---

From: Mike Jones <[email-masked]>
Date: Sat, 24 Jan 2015 19:38:40 +0000

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]
Subject: Re: [jose] Working Group last call on draft-ietf-jose-jwk-thumbprint

Jim

---

From: John Bradley <[email-masked]>
Date: Sat, 24 Jan 2015 16:47:06 -0300

You are correct that because we are only calculating the hash over the public key, what we are doing is closer to SKID than a thumbprint.

One important difference is that skid is only required to be unique,  and id not necessarily calculable based on the public key.

RFC 3280 recommends using one of two methods to calculate it,  but the SHOULD allows for wiggle room.

      (1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the
      value of the BIT STRING subjectPublicKey (excluding the tag,
      length, and number of unused bits).

      (2) The keyIdentifier is composed of a four bit type field with
      the value 0100 followed by the least significant 60 bits of the
      SHA-1 hash of the value of the BIT STRING subjectPublicKey
      (excluding the tag, length, and number of unused bit string bits).

If the skid definition of RFC 3280 had a MUST instead of a SHOULD then it would be closer.

The reason we used the term thumbprint is that likely it would be used for a similar purpose as a thumbprint.

I guess what we have is something in between the two. 

If calling it a “Public Key ID” rather then a thumb print then that is probably worth discussion.

I suspect that the naming is going to be easier to sort out than the questions raised around the serialization of the input to the hash function.

John B.

> On Jan 24, 2015, at 3:39 PM, Jim Schaad <[email-masked]> wrote:
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Sat, 24 Jan 2015 15:07:20 -0500

Sent from my iPhone

> On Jan 24, 2015, at 2:47 PM, John Bradley <[email-masked]> wrote:
> 
And would require an update to all of the drafts in the RFC editor queue to replace the name.  That's doable, but we'll need to be careful.

Kathleen

---

From: "Jim Schaad" <[email-masked]>
Date: Sat, 24 Jan 2015 12:08:11 -0800

Implied in my comment is that the parameter jkt would go away.

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

                                                            -- Mike

Jim

---

From: Mike Jones <[email-masked]>
Date: Sat, 24 Jan 2015 20:12:45 +0000

For the uses in the existing specs, the term “Thumbprint” is well established.  For instance, http://msdn.microsoft.com/en-us/library/windows/desktop/aa376544(v=vs.85).aspx, describing the “Certificate.Thumbprint property”, is exactly what our X.509 SHA-1 Certificate Thumbprint (x5t) value is.

I don’t think John was suggesting reopening naming for any of the existing specs, only possibly for the new spec.

                                                                           -- Mike

From: jose [mailto:[email-masked]] On Behalf Of Kathleen Moriarty
Sent: Saturday, January 24, 2015 12:07 PM
To: John Bradley
Cc: Jim Schaad; [email-masked]
Subject: Re: [jose] Working Group last call on draft-ietf-jose-jwk-thumbprint

Sent from my iPhone

On Jan 24, 2015, at 2:47 PM, John Bradley <[email-masked]<mailto:[email-masked]>> wrote:
You are correct that because we are only calculating the hash over the public key, what we are doing is closer to SKID than a thumbprint.

Kathleen

John B.

On Jan 24, 2015, at 3:39 PM, Jim Schaad <[email-masked]<mailto:[email-masked]>> wrote:

Jim

---

From: Mike Jones <[email-masked]>
Date: Sat, 24 Jan 2015 20:50:15 +0000

While this may surprise you, that wouldn’t personally bother me.  The use cases I know of would either use it as a Key ID or Subject claim value.  The “jkt” definition was there just to be parallel with “x5t”.  What the draft is really about is the computation definition.

What do others in the working group think about Jim’s suggestion?

                                                            -- Mike

From: Jim Schaad [mailto:[email-masked]]
Sent: Saturday, January 24, 2015 12:08 PM
To: Mike Jones; [email-masked]
Subject: RE: [jose] Working Group last call on draft-ietf-jose-jwk-thumbprint

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

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

Jim

---

From: "Jim Schaad" <[email-masked]>
Date: Sat, 24 Jan 2015 13:46:16 -0800

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

[JLS]  There is no requirement for EE certificates that the value be unique.  That requirement is only CA certificates.   This is really just a key identifier for the holder of the key.   Uniqueness of the values for each owner over all of its keys is helpful for the key owner, it makes no difference for the person referencing the key on the other end.  They need to be able to deal with conflicts in all cases.

John B.

 
Jim

---

From: John Bradley <[email-masked]>
Date: Sat, 24 Jan 2015 21:17:03 -0300

No I wasn't suggesting opening up the other does in any way.  

John B. 

Sent from my iPhone

> On Jan 24, 2015, at 5:12 PM, Mike Jones <[email-masked]> wrote:
>

---

From: John Bradley <[email-masked]>
Date: Sat, 24 Jan 2015 21:20:15 -0300

I am ok with that.   If we need to differentiate between a arbitrary key identifier and a key identifier that is cryptographically related to the public key,  we could register the additional element later.  

John B. 

Sent from my iPhone

> On Jan 24, 2015, at 5:50 PM, Mike Jones <[email-masked]> wrote:
>

---

From: Brian Campbell <[email-masked]>
Date: Sun, 25 Jan 2015 09:50:13 -0700

I'd be okay with dropping the "jkt" member definitions. It's not clear that
they really add anything in the context of this draft.

A "jkt" claim for JWT might be useful as a common way for an issuer to say
that a subject/presenter can/should/must present some proof-of-possession
of the key identified by the thumbprint claim. Is something like that in
the OAuth POP work already? It's been a while since I've looked at that
stuff. But I digress as that's all for a different WG.

On Sat, Jan 24, 2015 at 5:20 PM, John Bradley <[email-masked]> wrote:

> I am ok with that.   If we need to differentiate between a arbitrary key
> identifier and a key identifier that is cryptographically related to the
> public key,  we could register the additional element later.
>
> John B.
>
> Sent from my iPhone
>
>  While this may surprise you, that wouldn’t personally bother me.  The
> use cases I know of would either use it as a Key ID or Subject claim
> value.  The “jkt” definition was there just to be parallel with “x5t”.
> What the draft is really about is the computation definition.
>
>
>
> *From:* Jim Schaad [mailto:[email-masked] <[email-masked]>]
>
> *Sent:* Saturday, January 24, 2015 12:08 PM
> *To:* Mike Jones; [email-masked]
> *Subject:* RE: [jose] Working Group last call on
> *From:* Mike Jones [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Saturday, January 24, 2015 11:39 AM
> *To:* Jim Schaad; [email-masked]
> *Subject:* RE: [jose] Working Group last call on
> 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] <[email-masked]>] *On
> Behalf Of *Jim Schaad
> *Sent:* Saturday, January 24, 2015 10:39 AM
> *To:* [email-masked]
> 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
>
>
>

---

From: John Bradley <[email-masked]>
Date: Sun, 25 Jan 2015 14:41:16 -0300

Yes in the POP specs sending a Thumbprint of the public key might save space vs including the entire public key in the token, especially for RSA keys.
That would mostly apply to channel binding  & token binding where the public key is delivered outside the token.

Leaving it up to those specs to define the element is OK with me.

Agreeing on the method to calculate the hash is still useful.

John B.

> On Jan 25, 2015, at 1:50 PM, Brian Campbell <[email-masked] <mailto:[email-masked]>> wrote:
> 
> I'd be okay with dropping the "jkt" member definitions. It's not clear that they really add anything in the context of this draft. 
> 
> A "jkt" claim for JWT might be useful as a common way for an issuer to say that a subject/presenter can/should/must present some proof-of-possession of the key identified by the thumbprint claim. Is something like that in the OAuth POP work already? It's been a while since I've looked at that stuff. But I digress as that's all for a different WG.
> 
> 
> 
> On Sat, Jan 24, 2015 at 5:20 PM, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
> On Jan 24, 2015, at 5:50 PM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> From: Jim Schaad [mailto:[email-masked] <mailto:[email-masked]>] 
>> To: Mike Jones; [email-masked] <mailto:[email-masked]>
>> From: Mike Jones [mailto:[email-masked] <mailto:[email-masked]>] 
>> To: Jim Schaad; [email-masked] <mailto:[email-masked]>
>> From: jose [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Jim Schaad
>> To: [email-masked] <mailto:[email-masked]>

---

From: John Bradley <[email-masked]>
Date: Sun, 25 Jan 2015 14:42:03 -0300

John B.

---

From: Brian Campbell <[email-masked]>
Date: Mon, 26 Jan 2015 08:30:47 -0700

Agree that agreeing on a method to calculate the hash is still useful.

As far as the discussion around the serialization of the input to the hash
function goes, I get the sense that folks have been taking past each other
a bit on this thread.

Yes, any hash input computation with the right properties will work. Yes,
the current input computation is more complex than it needs to be for the
existing JWK types (EC & RSA). And the pseudo-JSON used to produce a
canonical hash input is somewhat disconcerting.  But it's also trying to
accommodate future JWK key types without placing too many restrictions on
what they can look like while still being thumbprintable via this mechanism.

Does it get the balance right? Hard to say without knowing the future
(maybe we can organize a BoF for seeing the future in Dallas?). IMHO, the
fears of interoperability problems are a bit overblown. But I'm also
skeptical that future JWK key types will have members whose values are
themselves JSON objects, and a lot of the complexity seems to stem from
supporting that case.

So what's my take on the draft? Meh. It's okay. It's fine.

As an aside, if we do decided to drop the "jkt" Member Definitions, there
probably needs to be some discussion about where/how the hash algorithm is
specified along with some semblance of support for future algorithm agility.

On Sun, Jan 25, 2015 at 10:41 AM, John Bradley <[email-masked]> wrote:

> Yes in the POP specs sending a Thumbprint of the public key might save
> space vs including the entire public key in the token, especially for RSA
> keys.
> That would mostly apply to channel binding  & token binding where the
> public key is delivered outside the token.
>
> On Jan 25, 2015, at 1:50 PM, Brian Campbell <[email-masked]>
> wrote:
>
> I'd be okay with dropping the "jkt" member definitions. It's not clear
> that they really add anything in the context of this draft.
>
>> While this may surprise you, that wouldn’t personally bother me.  The use
>> cases I know of would either use it as a Key ID or Subject claim value.
>> The “jkt” definition was there just to be parallel with “x5t”.  What the
>> draft is really about is the computation definition.
>>
>>
>>

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 26 Jan 2015 15:39:15 +0000

On 26/01/15 15:30, Brian Campbell wrote:
> IMHO, the
> fears of interoperability problems are a bit overblown.

That is not the point I was making. If two sides the
same hash input of any kind that has the public key
and relevant parameters then you will get interop. I
made no argument that there will be interop problems
no matter how baroque an approach is adopted.

But if you choose SPKI as the hash input you get interop
and system-level benefits that you do not get with any
other input. The reason being that other specifications
and systems use that input. The ways in which that can
be beneficial should be obvious, but e.g. some JOSE
application could benefit from TLSA RRs for example and
I can see how that might be useful for developers
who would like to securely associate a DNS name with
a public key (whenever DNSSEC is deployed for the relevant
names:-).

I have yet to see anyone produce a goo argument against
those benefits. ("Meh" doesn't count as good, though I
do get, and could nearly agree with, the sentiment:-)

S.

---

From: Brian Campbell <[email-masked]>
Date: Mon, 26 Jan 2015 11:33:45 -0700

Sorry for any misunderstanding Stephen, others had suggested the potential
for interop problems (mainly Richard and Matt, I think). Not you. Although,
thinking back to some recent examples of JWKs using regular base64 rather
than base64url [1] now has me wondering if interop might be somewhat
problematic - liberal decoders have allowed that to not be an interop
problem for the parsing of JWKs but it would definitely be a problem as
part of a hash input.

I didn't responded to your suggestion of using SubjectPublicKeyInfo because
it seemed like everyone else had dismissed it already.  But, admittedly, it
does have a certain appeal.

The objection I've heard is that it might be difficult to get at or produce
the SPKI in some programming environments. I'm not sure how true that is. I
mostly work in java and it's not-terribly-great documentation suggests that
it's trivial.

Another potential objection is that SubjectPublicKeyInfo doesn't work for
symmetric keys. So a different mechanism is needed there or we say they
aren't supported (which has also been suggested for other reasons - but I
think there's value in supporting it).

In conclusion, I'd like to reiterate my previous point: meh. ;)

[1] http://www.ietf.org/mail-archive/web/jose/current/msg04783.html &
http://www.ietf.org/mail-archive/web/jose/current/msg04807.html

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 26 Jan 2015 11:55:52 -0800

From: jose [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Monday, January 26, 2015 7:31 AM
To: John Bradley
Cc: Michael Jones; Jim Schaad; [email-masked]
Subject: Re: [jose] Working Group last call on draft-ietf-jose-jwk-thumbprint

As far as the discussion around the serialization of the input to the hash function goes, I get the sense that folks have been taking past each other a bit on this thread.

Yes, any hash input computation with the right properties will work. Yes, the current input computation is more complex than it needs to be for the existing JWK types (EC & RSA). And the pseudo-JSON used to produce a canonical hash input is somewhat disconcerting.  But it's also trying to accommodate future JWK key types without placing too many restrictions on what they can look like while still being thumbprintable via this mechanism.

Does it get the balance right? Hard to say without knowing the future (maybe we can organize a BoF for seeing the future in Dallas?). IMHO, the fears of interoperability problems are a bit overblown. But I'm also skeptical that future JWK key types will have members whose values are themselves JSON objects, and a lot of the complexity seems to stem from supporting that case.

[JLS] I have to agree with this as long as the draft is going to say that we want to hash the equivalent of a SPKI value rather than a certificate.  It is not like we are going to suddenly decide that an EC point should be represented as an array of two values. If we want to hash the equivalent of a certificate (personal position) then we have things like key_ops which are JSON objects and need to be dealt with.  Some arrays are ordered and some are not – which is this?

As an aside, if we do decided to drop the "jkt" Member Definitions, there probably needs to be some discussion about where/how the hash algorithm is specified along with some semblance of support for future algorithm agility.

[JLS]  If we are just looking at a method of computing kid values, I don’t think this needs to be done.  The only reason that it would be required to be able to determine the hash function is if one is planning to have both the sender and the recipient compute the values independently.   That is not a requirement for kid.  This is one of the problems that I have with having a jkt member that sits in a jwk object, having a pointer to myself that is computable by the recipient seems odd.  I have normally used thumbprints in the order of – do I already have this key in my database of keys.  This means pointing from a message makes sense but I compute the value when I put it into my database for lookup purposes.  Otherwise it is just a random key identifier and it does not matter how it is computed.

John B.

On Jan 25, 2015, at 1:50 PM, Brian Campbell <[email-masked]> wrote:

 

John B. 

Sent from my iPhone

                                                            -- Mike

                                                            -- Mike

Jim

---

From: Brian Campbell <[email-masked]>
Date: Mon, 26 Jan 2015 18:46:49 -0700

My understanding is that this draft wants to hash the equivalent of a SPKI
value rather than a certificate. Perhaps that needs to be stated more
explicitly?

Also there are some cases, mentioned briefly earlier in this thread about
JWT and jkt style claim, where both the sender and the reviver will compute
the hash values independently. That may well be out of scope for this draft
but it will very likely make use of this draft.

On Mon, Jan 26, 2015 at 12:55 PM, Jim Schaad <[email-masked]> wrote:

>
>
>
>
> *From:* jose [mailto:[email-masked]] *On Behalf Of *Brian Campbell
> *Sent:* Monday, January 26, 2015 7:31 AM
> *To:* John Bradley
> *Cc:* Michael Jones; Jim Schaad; [email-masked]
> [JLS] I have to agree with this as long as the draft is going to say that
> we want to hash the equivalent of a SPKI value rather than a certificate.
> It is not like we are going to suddenly decide that an EC point should be
> represented as an array of two values. If we want to hash the equivalent of
> a certificate (personal position) then we have things like key_ops which
> are JSON objects and need to be dealt with.  Some arrays are ordered and
> some are not – which is this?
>
> [JLS]  If we are just looking at a method of computing kid values, I don’t
> think this needs to be done.  The only reason that it would be required to
> be able to determine the hash function is if one is planning to have both
> the sender and the recipient compute the values independently.   That is
> not a requirement for kid.  This is one of the problems that I have with
> having a jkt member that sits in a jwk object, having a pointer to myself
> that is computable by the recipient seems odd.  I have normally used
> thumbprints in the order of – do I already have this key in my database of
> keys.  This means pointing from a message makes sense but I compute the
> value when I put it into my database for lookup purposes.  Otherwise it is
> just a random key identifier and it does not matter how it is computed.
>
>
>
>
>
>
>