Subject: [jose] Last Call on draft-ietf-jose-jwk-thumbprint - Round 2

From: "Jim Schaad" <[email-masked]>
Date: Sun, 1 Mar 2015 21:49:57 -0800

The chairs are issuing a one week working group last call on the document
draft-ietf-jose-jwk-thumbprint to see where we stand.  The chairs believe
that the document has addressed all of the issues raised during the previous
last call except for the question of changing the serialization format of
the string to be hashed to compute the thumbprint value.

The previous discussion on the serialization did not reach a consensus
either to keep or change serialization string method.  Given this the
decision to keep the previous one is a conservative decision.   If people
want to re-litigate this issue and try to come to a consensus this is the
time to do it.

Starting the shepherd report raised the question of the correct track for
this document.  It is currently standards track.  Given that it is only
defining an algorithm, it might be reasonable to change it to informational.
We would like to get peoples opinion this question.

If there is no big mail storm, then I would expect that we will progress the
document to the IESG after the last call finishes. 

Last call will finish on March 9th.

Jim

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 02 Mar 2015 06:50:04 +0000

> want to re-litigate this issue and try to come to a consensus this is the

Other hashed-public-key things all use SPKI as the input. Doing
something different is IMO a bad plan for zero benefit. The benefit
of doing the same as others is that one can use the same value to
refer to the same key in different contexts. With the current
approach, one cannot.

S.

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 2 Mar 2015 00:40:21 -0800

Going forward, the argument that SPKI is not easily obtainable is not going to be a valid argument in browsers.  The new WebCrypto API supplies that need.   So this is just an argument about current browsers (well current IE) and non- browser platforms

Jim

> -----Original Message-----
> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Sunday, March 01, 2015 10:50 PM
> To: Jim Schaad; [email-masked]
> Subject: Re: [jose] Last Call on draft-ietf-jose-jwk-thumbprint - Round 2
> 
> 
> 
> > want to re-litigate this issue and try to come to a consensus this is
> > the time to do it.
> 
> Other hashed-public-key things all use SPKI as the input. Doing something
> different is IMO a bad plan for zero benefit. The benefit of doing the same as
> others is that one can use the same value to refer to the same key in
> different contexts. With the current approach, one cannot.
> 
> S.

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 4 Mar 2015 08:51:45 +0900

Stephen asks why JWK Thumbprint should do something other than hash a SPKI
key representation.  Here are a few reasons:

1.  The whole premise of JOSE was to create easy to use crypto data formats
and algorithms that are based on JSON.  Saying “SPKI exists – everyone
should use it” is like saying “CMS exists – everyone should use it, or
perhaps XMLDSIG exists – everyone should use it”.  It does not seem
consistent or helpful to developers for JOSE to effectively say “You can
use JSON-based structures for everything except key hashes and for those,
you have to use a binary structure (based on ASN.1).”

2.  The point of the draft is to create thumbprints of keys that are
already represented in JWK format.  Requiring a format conversion to ASN.1,
which most developers consider to be unapproachable, will result both in
more code and less adoption.  (If the keys are already in X.509 certs, by
all means, hash the SPKI value because it’s easy.  JWK Thumbprint is
similarly easy for JWK keys.)

Stephen also states “The benefit of doing the same as others is that one
can use the same value to refer to the same key in different contexts”.
That sounds great on the face of it, but it is not clear that there’s
much/any benefit to this in practice.  A key is typically deployed for a
particular application context or among applications running over a TLS
connection.  Key reuse across different applications contexts is arguably a
security concern and not something likely to occur much in practice.

Each application defines what key format it uses (X.509/SPKI, XML, JWK,
etc.) and how to create key identifiers for those keys.  Letting the
application choose a JSON-based way to create key identifiers is both
logical and good for adoption of usable crypto.

I also took a look at some adoption data as background information.

   -

   Browser support for WebCrypto is still iffy. See
   http://caniuse.com/#feat=cryptography.

   -

   Notably, all the Android Browsers before Android L (5.0) do not support
   WebCrypto, and there are tons of them out there.  They will be there for
   years.
   -

   There are many enterprise deployments of IE below 10, which are not
   going to be upgraded anytime soon.

   -

   PHP started supporting SPKI in ver. 5.6, which was released Aug. 28,
   2014. Its deployment is very small as you can expect - 0.7%.  Server
   platforms do not do major version upgrades frequently.  See
   http://w3techs.com/technologies/details/pl-php/5/all.
   -

   Python seems to have been supporting SPKI for sometime as a NetscapeSPKI
   object.
   -

   So does Ruby.

   -

   I am not sure if the same is true for Perl. A cursory search didn’t turn
   up any useful data.

In closing, the point of JOSE (and the point of the JWK Thumbprint spec) is
to enable widespread adoption of usable crypto with the development tools
people actually have NOW.  That seems to be reason enough to have this
draft progress now towards RFC status.

Best,

Nat

2015-03-02 15:50 GMT+09:00 Stephen Farrell <[email-masked]>:

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

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: [email-masked]
Date: Wed, 4 Mar 2015 08:08:07 -0000

Hi Nat,

Nat Sakimura wrote:
> and algorithms that are based on JSON.

Sorry, but that's bogus. SPKI is easy to use and simple on pretty
much all web development platforms. Claiming that this is ASN.1 and
therefore bad is just not a valid argument since there is no
requirement for any decoding and there is no complex encoding at
all.

> Saying “SPKI exists – everyone
> which most developers consider to be unapproachable,

Same bogus argument, sorry. Using ASN.1 as a scare tactic is
just not credible here, once one looks at the facts.

> will result both in

Nonsense. SPKI is trivial to generate from any form of public key.

> security concern and not something likely to occur much in practice.

Please demonstrate such a concern. Vague arm-waving isn't useful.

Using the same input bits for the same key would help e.g. to
ensure weak keys like the old debian ones would be more easily
spotted in signature applications, so there are security benefits
to consistency here. (That's a modest, benefit for sure though.)

>    http://caniuse.com/#feat=cryptography.

WebCrypto makes SPKI access the obvious thing to do. Other
platforms require a line of code or so to create the
SPKI bits as a hash input, and that's true in JS or any
other dev environment I've used.

>    I am not sure if the same is true for Perl. A cursory search didn’t

And precisely zero of all of the above support the current
draft's approach.

> draft progress now towards RFC status.

You have IMO only used bogus ASN.1-is-bad arguments to back
up your usability claim. I don't really feel that strongly about
the WG doing the wrong thing here (i.e. wrong-thing==current I-D)
but we should decide based on valid arguments.

S.

PS: In case it's not clear - this is all me arguing as an individual
and nothing to do with IESG evaluation of the draft when it gets
there.

>> the