gmane.ietf.woes

Re: Proposed text for wrapped keys

Mike Jones — 2013-05-24T21:06:12

I agree with all of this wording except for the mandatory use of "cty".  We didn't discuss that at the interim.  In many (most?) contexts, it's already known that the value is a wrapped key, so there's no need to explicitly call it out, any more than there is for other content types.  I'm fine with including wording that says that the content type *MAY* be used, however.

Thanks for taking  first crack at this wording, Richard.

                                                                -- Mike

From: jose-bounces< at >ietf.org [mailto:jose-bounces< at >ietf.org] On Behalf Of Richard Barnes
Sent: Friday, May 24, 2013 11:40 AM
To: jose< at >ietf.org
Subject: [jose] Proposed text for wrapped keys

Dear JOSE,

At the interim, it seemed like there was agreement on key wrapping at least in the case of wrapping a JWK-structured key (as opposed to a bare symmetric key).  Namely, we agreed to use JWE to wrap the JWK structure.

It seems to me that it would be prudent to add this recommendation as a section in JWK.  Since we'r

Re: Proposed text for wrapped keys

Matt Miller (mamille2 — 2013-05-24T20:53:15

On May 24, 2013, at 12:40 PM, Richard Barnes <rlb< at >ipv.sx> wrote:


That looks reasonable to me, provided it is paired with one or two complete examples.


- m&m

Matt Miller < mamille2< at >cisco.com >
Cisco Systems, Inc.



_______________________________________________
jose mailing list
jose< at >ietf.org
https://www.ietf.org/mailman/listinfo/jose

Proposed text for wrapped keys

Richard Barnes — 2013-05-24T18:40:23

Dear JOSE,

At the interim, it seemed like there was agreement on key wrapping at least
in the case of wrapping a JWK-structured key (as opposed to a bare
symmetric key).  Namely, we agreed to use JWE to wrap the JWK structure.

It seems to me that it would be prudent to add this recommendation as a
section in JWK.  Since we're defining private key attributes, we should
define in the same document how to protect them.

"""
X.  Wrapped Key Format

A wrapped key is a JWE object with a key as its payload, encoded as a
serialized JWK object.  The "cty" attribute of a wrapped key MUST be set to
the JWK MIME type, "application/jwk+json".  The processing of wrapped keys
is identical to normal JWE processing.
"""

Do people find that to be sufficient text to explain how to generate and
process wrapped keys (as JWK within JWE)?

Thanks,
--Richard



P.S. The astute reader will note that this text is adapted
from draft-barnes-jose-key-wrapping-01
<http://tools.ietf.org/html/draft-barnes-jose-key-wrapping-01#section-2>

Re: #22: JSON Serialization media types not consistent with RFC 6839

Richard Barnes — 2013-05-24T14:19:39

On Thu, May 23, 2013 at 7:56 PM, Manger, James H <
James.H.Manger< at >team.telstra.com> wrote:


This point is not entirely germane to this issue, since the question here
is how to define the media type (thus focused on cases where there is a
media type expressed).  But it's a valid point w.r.t. the requirement level
on "typ".




I don't see a huge difference between the indicator being in the header or
out.  As long as the first component is JSON for all JW* variants.


I agree that a "typ" JSON header field should be mandatory. It should be

No, it wouldn't :)  If it's a parameter, then it can be omitted, and the
bare media type would have to have a semantic.  Also, this would be
duplicative of the "typ" in the object (what if they don't match?).

--Richard



_______________________________________________
jose mailing list
jose< at >ietf.org
https://www.ietf.org/mailman/listinfo/jose

Re: Question about JWK EC

Richard Barnes — 2013-05-24T14:13:39

I don't think that's necessarily the case.  It seems like you could have a
bare public key:

{
   "kty": "EC",
   "crv": "P-256",
   "d": "..."
}

You can compute the public key from that information, since the base point
for the cyclic group is specified as part of the definition of P-256 [1].
 Namely, if G is the base point, you just compute d*G.  That's arguably
even more trivial than computing an RSA public key from the private key.
 (EC point multiplication vs. Euclidean algorithm.  At least it uses the
same operation as ECDH.)

[1] <http://csrc.nist.gov/publications/fips/fips186-3/fips_186-3.pdf>


On Fri, May 24, 2013 at 9:07 AM, Richer, Justin P. <jricher< at >mitre.org>wrote:

_______________________________________________
jose mailing list
jose< at >ietf.org
https://www.ietf.org/mailman/listinfo/jose

Re: Question about JWK EC

Richer, Justin P. — 2013-05-24T13:07:00

It was my read of the spec that the private key components are always in addition and the resulting object is a key pair.

 -- Justin

On May 24, 2013, at 7:22 AM, Ludwig Seitz <ludwig< at >sics.se> wrote:

Re: Question about JWK EC

2013-05-24T12:11:26

This is consistent with the RSA private key section
https://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-10#section-5.3.2

" In addition to the members used to represent RSA public keys, the
   following members are used to represent RSA private keys."



-----Original Message-----
From: jose-bounces< at >ietf.org [mailto:jose-bounces< at >ietf.org] On Behalf Of Ludwig Seitz
Sent: Friday, May 24, 2013 1:22 PM
To: jose< at >ietf.org
Subject: [jose] Question about JWK EC

Hello,

while implementing the JWK EC part of the JOSE draft, I've come across the following question:

draft-ietf-jose-json-web-algorithms-10

"5.2.2.  JWK Parameters for Elliptic Curve Private Keys

   In addition to the members used to represent Elliptic Curve public
   keys, the following member MUST be present to represent Elliptic
   Curve private keys:"

However an EC private key is fundamentally different from an EC public key, it is just an integer and doesn't have the x and y parameters that an EC public key ha

Question about JWK EC

Ludwig Seitz — 2013-05-24T11:22:07

Hello,

while implementing the JWK EC part of the JOSE draft, I've come across
the following question:

draft-ietf-jose-json-web-algorithms-10

"5.2.2.  JWK Parameters for Elliptic Curve Private Keys

   In addition to the members used to represent Elliptic Curve public
   keys, the following member MUST be present to represent Elliptic
   Curve private keys:"

However an EC private key is fundamentally different from an EC public
key, it is just an integer and doesn't have the x and y 
parameters that an EC public key has. So when representing a EC private
key, the x and y members of the public key are not
readily available.

Was it the intention of the WG that the encoding of the EC private key
should include the parameters from the public key?


Regards,

Ludwig Seitz

Re: #22: JSON Serialization media types not consistent with RFC 6839

Manger, James H — 2013-05-23T23:56:02

The assumption is that looking at the JSON header of any JOSE message is sufficient to work out what it is (signed, MACed, directly encrypted, unprotected etc). In many situations a JOSE message will NOT be accompanied by a media type (eg a JOSE message as a bearer token in an HTTP message) so the media type cannot be required for disambiguation.

It might well be helpful in some situations to distinguish the variety of JOSE message before peeking into the JSON header (I proposed a 1-character prefix to do just that a year ago). In that case, though, I want to distinguish "unprotected" from "asymmetrically signed" from "MACed" from "encrypted with a shared secret" from "key exchange + encrypted" -- not "JWS" vs "JWE".


I agree that a "typ" JSON header field should be mandatory. It should be the primary way to indicate how to process the message, should obviate the need for "crit", and should have values like "sig", "mac", "plain", "aead", "keyex".

Allowing the "typ" field as a parameter of an appl

Re: #21: JWK and JWKSet do not have media types registered

Matt Miller (mamille2 — 2013-05-23T18:26:28

On May 23, 2013, at 12:12 PM, Richard Barnes <rlb< at >ipv.sx>
 wrote:



Or, you know, < http://tools.ietf.org/html/draft-miller-jose-jwe-protected-jwk.html > (-:


- m&m

Matt Miller < mamille2< at >cisco.com >
Cisco Systems, Inc.

_______________________________________________
jose mailing list
jose< at >ietf.org
https://www.ietf.org/mailman/listinfo/jose

Re: #22: JSON Serialization media types not consistent with RFC 6839

Richard Barnes — 2013-05-23T18:14:12

Sharing a media type only makes sense if there's a way to disambiguate.  So
the "typ" header would have to be mandatory.


On Wed, May 22, 2013 at 11:32 PM, Manger, James H <
James.H.Manger< at >team.telstra.com> wrote:

_______________________________________________
jose mailing list
jose< at >ietf.org
https://www.ietf.org/mailman/listinfo/jose

Re: #21: JWK and JWKSet do not have media types registered

Richard Barnes — 2013-05-23T18:12:46

On Thu, May 23, 2013 at 9:58 AM, Matt Miller (mamille2)
<mamille2< at >cisco.com>wrote:


This is exactly what I was going to say.
<http://tools.ietf.org/html/draft-barnes-jose-key-wrapping-01#section-2>




_______________________________________________
jose mailing list
jose< at >ietf.org
https://www.ietf.org/mailman/listinfo/jose

Re: #21: JWK and JWKSet do not have media types registered

Matt Miller (mamille2 — 2013-05-23T13:58:43

On May 22, 2013, at 9:16 PM, "Manger, James H" <James.H.Manger< at >team.telstra.com> wrote:


Having a media type for a single key would help with wrapped keys:

{
  "alg":"PBES2-A256KW+HS256",
  "enc":"A256-GCM",
  "cty":"application/jwk+json"
}

...


- m&m

Matt Miller < mamille2< at >cisco.com >
Cisco Systems, Inc.

_______________________________________________
jose mailing list
jose< at >ietf.org
https://www.ietf.org/mailman/listinfo/jose

Re: #22: JSON Serialization media types not consistent with RFC 6839

Manger, James H — 2013-05-23T03:32:14

Why have separate media types for JWS and JWE?
Wouldn’t it be better to have one media type for the dot-separated-base64url serialization of a JOSE message — regardless of whether the content was unprotected, signed, MACed, encrypted with any of the supported options, or any future algorithm?

  application/jose

A second media type for the separate serialization is useful.

  application/jose+json

--
James Manger


_______________________________________________
jose mailing list
jose< at >ietf.org
https://www.ietf.org/mailman/listinfo/jose

Re: #21: JWK and JWKSet do not have media types registered

Manger, James H — 2013-05-23T03:16:19

Do we need a media type for a single JWK? I though URIs in JOSE were always expected to result in a set of keys (there might only be 1 key in a set, of course).

I would prefer one media type: applications/keys+json

--
James Manger

Re: #22: JSON Serialization media types not consistent with RFC 6839

Nat Sakimura — 2013-05-22T23:24:04

+1

=nat via iPhone

May 23, 2013 6:05、jose issue tracker <trac+jose< at >trac.tools.ietf.org> のメッセ_______________________________________________
jose mailing list
jose< at >ietf.org
https://www.ietf.org/mailman/listinfo/jose

Re: #21: JWK and JWKSet do not have media types registered

Nat Sakimura — 2013-05-22T23:23:41

+1

=nat via iPhone

May 23, 2013 5:51、jose issue tracker <trac+jose< at >trac.tools.ietf.org> のメッセ_______________________________________________
jose mailing list
jose< at >ietf.org
https://www.ietf.org/mailman/listinfo/jose

Re: #21: JWK and JWKSet do not have media types registered

John Bradley — 2013-05-22T22:56:45

+1

On 2013-05-22, at 6:53 PM, Mike Jones <Michael.Jones< at >microsoft.com> wrote:


_______________________________________________
jose mailing list
jose< at >ietf.org
https://www.ietf.org/mailman/listinfo/jose

Re: #21: JWK and JWKSet do not have media types registered

Mike Jones — 2013-05-22T22:53:39

Fine with me

From: jose-bounces< at >ietf.org [mailto:jose-bounces< at >ietf.org] On Behalf Of Richard Barnes
Sent: Wednesday, May 22, 2013 3:53 PM
To: jose issue tracker
Cc: draft-ietf-jose-json-web-key< at >tools.ietf.org; jose< at >ietf.org; mamille2< at >cisco.com
Subject: Re: [jose] #21: JWK and JWKSet do not have media types registered

+1

On Wednesday, May 22, 2013, jose issue tracker wrote:
#21: JWK and JWKSet do not have media types registered

 Media types are not registered for JWK and JWKSet.  Suggested values are:

 * JWK -- "application/jwk+json"
 * JWKSet -- "application/jwk-set+json"

--
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-jose-json-web-
  mamille2< at >cisco.com<javascript:;>     |  key< at >tools.ietf.org<javascript:;>
     Type:  enhancement  |     Status:  new
 Priority:  minor        |  Milestone:
Component:  json-web-    |    Version:
  key                    |   Keywords:
 Severity:  Active WG    |
  Document               |
---

Re: #22: JSON Serialization media types not consistent with RFC 6839

Mike Jones — 2013-05-22T22:53:12

For what it's worth, I'm fine with this proposal.

                                                                -- Mike

From: jose-bounces< at >ietf.org [mailto:jose-bounces< at >ietf.org] On Behalf Of Richard Barnes
Sent: Wednesday, May 22, 2013 3:52 PM
To: jose issue tracker
Cc: draft-ietf-jose-json-web-encryption< at >tools.ietf.org; jose< at >ietf.org; mamille2< at >cisco.com
Subject: Re: [jose] #22: JSON Serialization media types not consistent with RFC 6839

+1

On Wednesday, May 22, 2013, jose issue tracker wrote:
#22: JSON Serialization media types not consistent with RFC 6839

 The JSON Serialization media types "application/jwe-js" and "application
 /jws-js" are not consistent with RFC 6839.

 * "application/jwe-js" should be "application/jwe+json"
 * "application/jws-js" should be "application/jws+json"

--
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-jose-json-web-
  mamille2< at >cisco.com<javascript:;>     |  encryption< at >tools.ietf.org<java

Re: #21: JWK and JWKSet do not have media types registered

Richard Barnes — 2013-05-22T22:52:30

+1

On Wednesday, May 22, 2013, jose issue tracker wrote:

_______________________________________________
jose mailing list
jose< at >ietf.org
https://www.ietf.org/mailman/listinfo/jose