Subject: [jose] Key Managed JSON Web Signature (KMJWS) specification

From: Mike Jones <[email-masked]>
Date: Tue, 3 Mar 2015 10:42:23 +0000

I took a little time today and wrote a short draft specifying a JWS-like object that uses key management for the MAC key used to integrity protect the payload.  We had considered doing this in JOSE issue #2<http://trac.tools.ietf.org/wg/jose/trac/ticket/2> but didn't do so at the time because of lack of demand.  However, I wanted to get this down now to demonstrate that it is easy to do and specify a way to do it, should demand develop in the future - possibly after the JOSE working group<http://datatracker.ietf.org/wg/jose/charter/> has been closed.  See http://tools.ietf.org/html/draft-jones-jose-key-managed-json-web-signature-00 or http://self-issued.info/docs/draft-jones-jose-key-managed-json-web-signature-00.html.

This spec reuses key management functionality already present in the JWE spec<http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption> and MAC functionality already present in the JWS spec<http://tools.ietf.org/html/draft-ietf-jose-json-web-signature>.  The result is essentially a JWS with an Encrypted Key value added, and a new "mac" Header Parameter value representing the MAC algorithm used.  (Like JWE, the key management algorithm is carried in the "alg" Header Parameter value.)

I also wrote this now as possible input into our thinking on options for creating a CBOR<http://tools.ietf.org/html/rfc7049> JOSE mapping.  If there are CBOR use cases needing managed MAC keys, this could help us reason about ways to structure the solution.

Yes, the spec name and abbreviation are far from catchy.  Better naming ideas would be great.

Feedback welcomed.

                                                            -- Mike

P.S.  This note was also posted at http://self-issued.info/?p=1344 and as @selfissued.

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 03 Mar 2015 12:03:23 +0100

On 2015-03-03 11:42, Mike Jones wrote:
>
> I took a little time today and wrote a short draft specifying a JWS-like object that uses key management for the MAC key used to integrity protect the payload.  We had considered doing this in JOSE issue #2 <http://trac.tools.ietf.org/wg/jose/trac/ticket/2> but didn’t do so at the time because of lack of demand.  However, I wanted to get this down now to demonstrate that it is easy to do and specify a way to do it, should demand develop in the future – possibly after the JOSE working group <http://datatracker.ietf.org/wg/jose/charter/> has been closed.  See http://tools.ietf.org/html/draft-jones-jose-key-managed-json-web-signature-00 or http://self-issued.info/docs/draft-jones-jose-key-managed-json-web-signature-00.html.
>
> This spec reuses key management functionality already present in the JWE spec <http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption> and MAC functionality already present in the JWS spec <http://tools.ietf.org/html/draft-ietf-jose-json-web-signature>.  The result is essentially a JWS with an Encrypted Key value added, and a new “mac” Header Parameter value representing the MAC algorithm used. (Like JWE, the key management algorithm is carried in the “alg” Header Parameter value.)
>

I guess I'm stupid but I don't understand what this scheme brings to the table over what for example RSA signatures already provide.
A short rationale for us imbeciles would be nice to have :-)

Anders

> I also wrote this now as possible input into our thinking on options for creating a CBOR <http://tools.ietf.org/html/rfc7049> JOSE mapping.  If there are CBOR use cases needing managed MAC keys, this could help us reason about ways to structure the solution.
>
> P.S.  This note was also posted at http://self-issued.info/?p=1344 <http://self-issued.info/?p=1344> and as @selfissued.
>
>
>
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 11 Mar 2015 20:56:47 -0700

I cannot respond for Richard, but personally I feel rather insulted by the
current draft.  My first half a dozen responses were rather vulgar and
pejorative to this draft and thus deleted.

This draft seems to be, more or less, what Richard and I were proposing in
Denver and were told was not possible due to backwards compatibility.  What
has changed that this is no longer true?

Why is there  need to have a compact formation for this draft?  We were told
in no uncertain terms that this was completely unnecessary in Denver and
thus was out of scope for the documents.

This document does not seem to have read the security considerations section
of the JWS draft specifically dealing with the existence of multiple sharers
of the secret key.

This document has messed up the current documentation in JWE about how to
determine what type of document is being presented.  This is completely
unacceptable.

There are now multiple representations of direct keying for mac.  This is a
significant problem as one does not know which of the version one is
supposed to be using.

(The fact that I am half, if not all the way drunk has make this message
much easier to write).

Jim

From: jose [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Tuesday, March 03, 2015 2:42 AM
To: [email-masked]
Subject: [jose] Key Managed JSON Web Signature (KMJWS) specification

I took a little time today and wrote a short draft specifying a JWS-like
object that uses key management for the MAC key used to integrity protect
the payload.  We had considered doing this in JOSE issue #2
<http://trac.tools.ietf.org/wg/jose/trac/ticket/2>  but didn't do so at the
time because of lack of demand.  However, I wanted to get this down now to
demonstrate that it is easy to do and specify a way to do it, should demand
develop in the future - possibly after the JOSE working group
<http://datatracker.ietf.org/wg/jose/charter/>  has been closed.  See
http://tools.ietf.org/html/draft-jones-jose-key-managed-json-web-signature-0
0 or
http://self-issued.info/docs/draft-jones-jose-key-managed-json-web-signature
-00.html.

This spec reuses key management functionality already present in the JWE
spec <http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption>  and
MAC functionality already present in the JWS spec
<http://tools.ietf.org/html/draft-ietf-jose-json-web-signature> .  The
result is essentially a JWS with an Encrypted Key value added, and a new
"mac" Header Parameter value representing the MAC algorithm used.  (Like
JWE, the key management algorithm is carried in the "alg" Header Parameter
value.)

I also wrote this now as possible input into our thinking on options for
creating a CBOR <http://tools.ietf.org/html/rfc7049>  JOSE mapping.  If
there are CBOR use cases needing managed MAC keys, this could help us reason
about ways to structure the solution.

Yes, the spec name and abbreviation are far from catchy.  Better naming
ideas would be great.

Feedback welcomed.

                                                            -- Mike

P.S.  This note was also posted at http://self-issued.info/?p=1344 and as
@selfissued.

---

From: Richard Barnes <[email-masked]>
Date: Wed, 11 Mar 2015 22:39:43 -0700

I was simply going to note with bemusement that exactly this eventuality
was foreseen by those of us that favored a more general approach to key
wrapping [0][1].  Those that dismissed that idea have made their bed full
of complexity, and now they are lying in it.

At this point, the least harmful approach would be to simply define an "ek"
header field that contains an encrypted key, in the form of a JWE
containing a JWK [0].

[0] http://tools.ietf.org/agenda/85/slides/slides-85-jose-7.pdf
[1] http://tools.ietf.org/agenda/86/slides/slides-86-jose-0.pdf

On Wed, Mar 11, 2015 at 8:56 PM, Jim Schaad <[email-masked]> wrote:

> Why is there  need to have a compact formation for this draft?  We were
> told in no uncertain terms that this was completely unnecessary in Denver
> and thus was out of scope for the documents.
>
>
>
> This document does not seem to have read the security considerations
> section of the JWS draft specifically dealing with the existence of
> multiple sharers of the secret key.
>
>
>
> There are now multiple representations of direct keying for mac.  This is
> a significant problem as one does not know which of the version one is
> supposed to be using.
>
>
>
> *From:* jose [mailto:[email-masked]] *On Behalf Of *Mike Jones
> *Sent:* Tuesday, March 03, 2015 2:42 AM
> *To:* [email-masked]
> *Subject:* [jose] Key Managed JSON Web Signature (KMJWS) specification
>
>
>
> <http://trac.tools.ietf.org/wg/jose/trac/ticket/2> but didn’t do so at
> the time because of lack of demand.  However, I wanted to get this down now
> to demonstrate that it is easy to do and specify a way to do it, should
> demand develop in the future – possibly after the JOSE working group
> http://tools.ietf.org/html/draft-jones-jose-key-managed-json-web-signature-00
> or
> http://self-issued.info/docs/draft-jones-jose-key-managed-json-web-signature-00.html
> .
>
>
>
> <http://tools.ietf.org/html/draft-ietf-jose-json-web-signature>.  The
> result is essentially a JWS with an Encrypted Key value added, and a new “
> mac” Header Parameter value representing the MAC algorithm used.  (Like
> JWE, the key management algorithm is carried in the “alg” Header
> Parameter value.)
>
>
>
> there are CBOR use cases needing managed MAC keys, this could help us
> reason about ways to structure the solution.
>
>
>

---

From: Mike Jones <[email-masked]>
Date: Thu, 12 Mar 2015 07:37:24 +0000

Hi Jim.  Thanks for responding and for your honest feedback.  While you may feel insulted (I'm genuinely sorry about that!), I'm to try to take the negatives you've expressed as positives, in the sense that they can constructively inform future work by the working group.

One reason I wrote this draft was to get down a straightforward way of using key managed HMACs, should people want to do that in the future, especially since there's talk of closing the working group soon.  The other reason I wrote it was to further illuminate the upsides and downsides of some of the choices we made in JWS and JWE, given we have a chance to reuse and/or revisit those choices should the COSE work go forward.

Replies to your specific points follow inline...

From: Jim Schaad [mailto:[email-masked]]
Sent: Wednesday, March 11, 2015 8:57 PM
To: Mike Jones; [email-masked]
Subject: RE: [jose] Key Managed JSON Web Signature (KMJWS) specification

> I cannot respond for Richard, but personally I feel rather insulted by the current draft.  My first half a dozen responses were rather vulgar and pejorative to this draft and thus deleted.
>
> This draft seems to be, more or less, what Richard and I were proposing in Denver and were told was not possible due to backwards compatibility.  What has changed that this is no longer true?

For what it's worth, I've occasionally been thinking about key management for MACs ever since you and Richard raised the possibility in Denver.  Somewhere along the way I realized that there was a simple way to combine the JWE key management methods and the JWS MAC methods.  So I decided to write it down, while there was still a working group to consider it, should the working group decide to do so.

If the reason you're insulted is that you feel that you should receive more credit for some of the ideas, I'd be glad to point out in the Acknowledgements that you and Richard suggested the possibility of key-managed MACs and/or make you co-editors if you agree with the approach and would like to work more actively on it.  If the reason that you're insulted is that you feel that we should have done this earlier, I think the verdict is still out on whether we need to do this at all.  Looking at http://trac.tools.ietf.org/wg/jose/trac/ticket/2, Karen made a consensus call that "we should not add the ability to have a randomly generated MAC key protected by a different key" based on working group input.

I think the key question for the working group relative to this draft is whether people now want to see a standard way to do this or not.

As for the backwards compatibility issues discussed in Denver, I know that several participants were opposed to seeing the JWS format for non-key-managed MACs change.  I suspect that's what you're referring to.  The good news about the current draft is that it adds the ability to have key-managed MACs without such a change.

Should we have thought of this approach then?  Probably.  Did we?  At least I didn't.  I thought of it recently, so I decided to write it down.

> Why is there need to have a compact formation for this draft?  We were told in no uncertain terms that this was completely unnecessary in Denver and thus was out of scope for the documents.

I can't remember the part of the discussion that you're referring to in Denver and I can't find it in the published notes.  The only uses of "compact" in the notes aren't about this.

That said, there's a compact serialization for key managed MACs for the same reason that there's a compact serialization for the other JOSE objects - to provide a compact, URL-safe representation for use cases that need it.  It also makes this draft more parallel to both JWS and JWE than it would otherwise be.

> This document does not seem to have read the security considerations section of the JWS draft specifically dealing with the existence of multiple sharers of the secret key.

I'm not sure I'm following you here, because different recipients use different ephemeral keys in this representation.  What's the security consideration that you think wasn't taken into account?

> This document has messed up the current documentation in JWE about how to determine what type of document is being presented.  This is completely unacceptable.

It's backwards-compatible in the sense that if an implementation supports JWSs and JWEs but not KMJWSs (I'm still looking for a better name than KMJWS, BTW), the current rules all continue to do the right thing.  If an implementation supports all three, yes, a little bit of additional logic would be needed, just like a little bit of additional code would be needed, but no breaking changes result.  A KMJWS is neither a legal JWS nor a legal JWE, so even if the existing discrimination rules were applied to a KMJWS and it was mis-categorized as one or the other, upon parsing, it would still be rejected, since it would be missing required properties.

> There are now multiple representations of direct keying for mac.  This is a significant problem as one does not know which of the version one is supposed to be using.

Thanks for pointing this out.  We should probably just prohibit the use of "alg":"dir" in KMJWS so that there's exactly one way of representing non-key-managed MACS - the existing way.

> (The fact that I am half, if not all the way drunk has make this message much easier to write).

I'm glad you enjoyed your evening. :)

> Jim

                                                            Thanks again,
                                                            -- Mike

From: jose [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Tuesday, March 03, 2015 2:42 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [jose] Key Managed JSON Web Signature (KMJWS) specification

Feedback welcomed.

                                                            -- Mike

---

From: Mike Jones <[email-masked]>
Date: Thu, 12 Mar 2015 07:56:15 +0000

Per my note to Jim just now, I give you and Jim full credit for bringing up the possibility of key-managed MACs for JOSE in Denver and subsequently.  The possibility has intrigued me ever since, for what it’s worth.

I understand but disagree with your “ek” suggestion.  I disagree because it’s inventing a new mechanism not currently used in JOSE, whereas the present draft provides an existence proof that JWE key management and JWS MACs can be combined in a straightforward way to accomplish the goal without inventing any new mechanisms.  (Yes, the new header parameter field name “mac” is invented to hold the MAC algorithm, instead of “alg”, but that’s pretty much the extent of the invention.)

Like we talked about in Denver and afterwards, while I understand the conceptual elegance of having all wrapped keys be represented as encrypted JWKs, in practice, that generality isn’t needed for wrapped keys (since no key attributes are needed) and it takes up extra space.  All you actually need are the symmetric key bits, so that’s where we landed, and put them in the encrypted_key field.  KMJWS does the same.

As an aside, I do realize now that if we’d used header parameter names differently, and in particular, not overloaded “alg” in the way we did, this could be even more elegant.  Hindsight is 20-20.  We have the opportunity to have it be more elegant in COSE, while keeping the basic model the same, should we choose to take on that new work.  (In fact, making that clear for COSE is part of why I wrote KMJWS in the first place.)

I’m looking forward to seeing you in Dallas.

                                                            -- Mike

From: Richard Barnes [mailto:[email-masked]]
Sent: Wednesday, March 11, 2015 10:40 PM
To: Jim Schaad
Cc: Mike Jones; [email-masked]
Subject: Re: [jose] Key Managed JSON Web Signature (KMJWS) specification

I was simply going to note with bemusement that exactly this eventuality was foreseen by those of us that favored a more general approach to key wrapping [0][1].  Those that dismissed that idea have made their bed full of complexity, and now they are lying in it.
At this point, the least harmful approach would be to simply define an "ek" header field that contains an encrypted key, in the form of a JWE containing a JWK [0].

On Wed, Mar 11, 2015 at 8:56 PM, Jim Schaad <[email-masked]<mailto:[email-masked]>> wrote:
I cannot respond for Richard, but personally I feel rather insulted by the current draft.  My first half a dozen responses were rather vulgar and pejorative to this draft and thus deleted.

Jim

From: jose [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Mike Jones
Sent: Tuesday, March 03, 2015 2:42 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [jose] Key Managed JSON Web Signature (KMJWS) specification

I took a little time today and wrote a short draft specifying a JWS-like object that uses key management for the MAC key used to integrity protect the payload.  We had considered doing this in JOSE issue #2<http://trac.tools.ietf.org/wg/jose/trac/ticket/2> but didn’t do so at the time because of lack of demand.  However, I wanted to get this down now to demonstrate that it is easy to do and specify a way to do it, should demand develop in the future – possibly after the JOSE working group<http://datatracker.ietf.org/wg/jose/charter/> has been closed.  See http://tools.ietf.org/html/draft-jones-jose-key-managed-json-web-signature-00 or http://self-issued.info/docs/draft-jones-jose-key-managed-json-web-signature-00.html.

This spec reuses key management functionality already present in the JWE spec<http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption> and MAC functionality already present in the JWS spec<http://tools.ietf.org/html/draft-ietf-jose-json-web-signature>.  The result is essentially a JWS with an Encrypted Key value added, and a new “mac” Header Parameter value representing the MAC algorithm used.  (Like JWE, the key management algorithm is carried in the “alg” Header Parameter value.)

Feedback welcomed.

                                                            -- Mike

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

---

From: Mike Jones <[email-masked]>
Date: Thu, 12 Mar 2015 15:55:45 +0000

I'll add one other thing, Jim.  I'm sorry that you left the Denver meeting feeling like your idea for key management was dismissed.  We should have pushed harder then to try to come up with an approach for that that would work for all.  I'll try to personally take this an object lesson for future standards work.

See you in Dallas!

                                                            -- Mike

From: jose [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Thursday, March 12, 2015 12:37 AM
To: Jim Schaad; [email-masked]
Subject: Re: [jose] Key Managed JSON Web Signature (KMJWS) specification

From: Jim Schaad [mailto:[email-masked]]
Sent: Wednesday, March 11, 2015 8:57 PM
To: Mike Jones; [email-masked]<mailto:[email-masked]>
Subject: RE: [jose] Key Managed JSON Web Signature (KMJWS) specification

                                                            Thanks again,
                                                            -- Mike

Feedback welcomed.

                                                            -- Mike

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 13 Mar 2015 06:52:20 +0100

Hi Guys,

Mainly for satisfying my curiosity:
Would it be possible to get a minimal rationale/use-case for using encrypted MAC keys compared to traditional asymmetric signature schemes?
Is this scheme already featured in another standard or widely deployed system?

Cheers,
Anders

On 2015-03-12 16:55, Mike Jones wrote:
> I’ll add one other thing, Jim.  I’m sorry that you left the Denver meeting feeling like your idea for key management was dismissed. We should have pushed harder then to try to come up with an approach for that that would work for all.  I’ll try to personally take this an object lesson for future standards work.
>
> See you in Dallas!
>
>                                                              -- Mike
>
> *From:*jose [mailto:[email-masked]] *On Behalf Of *Mike Jones
> *Sent:* Thursday, March 12, 2015 12:37 AM
> *To:* Jim Schaad; [email-masked]
> *Subject:* Re: [jose] Key Managed JSON Web Signature (KMJWS) specification
>
> Hi Jim.  Thanks for responding and for your honest feedback.  While you may feel insulted (I’m genuinely sorry about that!), I’m to try to take the negatives you’ve expressed as positives, in the sense that they can constructively inform future work by the working group.
>
> One reason I wrote this draft was to get down a straightforward way of using key managed HMACs, should people want to do that in the future, especially since there’s talk of closing the working group soon.  The other reason I wrote it was to further illuminate the upsides and downsides of some of the choices we made in JWS and JWE, given we have a chance to reuse and/or revisit those choices should the COSE work go forward.
>
> Replies to your specific points follow inline…
>
> *From:*Jim Schaad [mailto:[email-masked]]
> *Sent:* Wednesday, March 11, 2015 8:57 PM
> *To:* Mike Jones; [email-masked] <mailto:[email-masked]>
> *Subject:* RE: [jose] Key Managed JSON Web Signature (KMJWS) specification
>
> For what it’s worth, I’ve occasionally been thinking about key management for MACs ever since you and Richard raised the possibility in Denver.  Somewhere along the way I realized that there was a simple way to combine the JWE key management methods and the JWS MAC methods.  So I decided to write it down, while there was still a working group to consider it, should the working group decide to do so.
>
> If the reason you’re insulted is that you feel that you should receive more credit for some of the ideas, I’d be glad to point out in the Acknowledgements that you and Richard suggested the possibility of key-managed MACs and/or make you co-editors if you agree with the approach and would like to work more actively on it.  If the reason that you’re insulted is that you feel that we should have done this earlier, I think the verdict is still out on whether we need to do this at all.  Looking at http://trac.tools.ietf.org/wg/jose/trac/ticket/2, Karen made a consensus call that “we should not add the ability to have a randomly generated MAC key protected by a different key” based on working group input.
>
> As for the backwards compatibility issues discussed in Denver, I know that several participants were opposed to seeing the JWS format for non-key-managed MACs change.  I suspect that’s what you’re referring to. The good news about the current draft is that it adds the ability to have key-managed MACs without such a change.
>
> Should we have thought of this approach then?  Probably.  Did we?  At least I didn’t.  I thought of it recently, so I decided to write it down.
>
> I can’t remember the part of the discussion that you’re referring to in Denver and I can’t find it in the published notes.  The only uses of “compact” in the notes aren’t about this.
>
> That said, there’s a compact serialization for key managed MACs for the same reason that there’s a compact serialization for the other JOSE objects – to provide a compact, URL-safe representation for use cases that need it.  It also makes this draft more parallel to both JWS and JWE than it would otherwise be.
>
> I’m not sure I’m following you here, because different recipients use different ephemeral keys in this representation.  What’s the security consideration that you think wasn’t taken into account?
>
> It’s backwards-compatible in the sense that if an implementation supports JWSs and JWEs but not KMJWSs (I’m still looking for a better name than KMJWS, BTW), the current rules all continue to do the right thing. If an implementation supports all three, yes, a little bit of additional logic would be needed, just like a little bit of additional code would be needed, but no breaking changes result.  A KMJWS is neither a legal JWS nor a legal JWE, so even if the existing discrimination rules were applied to a KMJWS and it was mis-categorized as one or the other, upon parsing, it would still be rejected, since it would be missing required properties.
>
> Thanks for pointing this out.  We should probably just prohibit the use of “alg”:”dir” in KMJWS so that there’s exactly one way of representing non-key-managed MACS – the existing way.
>
> I’m glad you enjoyed your evening. J
>
>> Jim
>
>                                                              Thanks again,
>
>                                                              -- Mike
>
> *From:*jose [mailto:[email-masked]] *On Behalf Of *Mike Jones
> *To:* [email-masked] <mailto:[email-masked]>