Subject: [jose] Proposed text for wrapped keys

From: Richard Barnes <[email-masked]>
Date: Fri, 24 May 2013 14:40:23 -0400

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>
This is not an accident.  I'm proposing to first address the question of
key wrapping in general; then we can talk about whether we want to
special-case symmetric keys with no attributes.

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Fri, 24 May 2013 20:53:15 +0000

> process wrapped keys (as JWK within JWE)?

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

- m&m

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

---

From: Mike Jones <[email-masked]>
Date: Fri, 24 May 2013 21:06:12 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Friday, May 24, 2013 11:40 AM
To: [email-masked]
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'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>
This is not an accident.  I'm proposing to first address the question of key wrapping in general; then we can talk about whether we want to special-case symmetric keys with no attributes.

---

From: Richard Barnes <[email-masked]>
Date: Sat, 25 May 2013 16:37:50 -0400

There was some discussion of "cty" at the interim, in the context of
distinguishing wrapped JWK from wrapped bare key.  Since this is only
addressing wrapped JWK, that need goes away.

However, there's still the security consideration that we don't want
applications mixing up keys and data. Marking wrapped keys with "cty"
supports that goal.

So the most softening I would be willing to do would be something
like "MUST ... unless application context specifies the content of the
wrapped key package."  Thy way, it's always clear that the package is
wrapped key and not general JWE, either by marking or by application rules.

That sounds to me pretty much like what you're saying. Would that text work
for you?

--Richard

On Friday, May 24, 2013, Mike Jones wrote:

>  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:* [email-masked] <javascript:_e({}, 'cvml',
> [email-masked]');> [mailto:[email-masked]<javascript:_e({}, 'cvml', [email-masked]');>]
> *On Behalf Of *Richard Barnes
> *Sent:* Friday, May 24, 2013 11:40 AM
> *To:* [email-masked] <javascript:_e({}, 'cvml', [email-masked]');>
> *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.**
> **
>
> ** **
>
> define in the same document how to protect them.****
>
> ** **
>
> """****
>
> X.  Wrapped Key Format****
>
> ** **
>
> is identical to normal JWE processing.****
>
> """****
>
> ** **
>
> process wrapped keys (as JWK within JWE)?****
>
> ** **
>
> Thanks,****
>
> --Richard****
>
> ** **
>
> ** **
>
> ** **
>
> from draft-barnes-jose-key-wrapping-01   ****
>
> <http://tools.ietf.org/html/draft-barnes-jose-key-wrapping-01#section-2>**
> **
>
> special-case symmetric keys with no attributes.****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>