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

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:jose-bounces@ietf.org] *On Behalf Of *Mike Jones
> *Sent:* Thursday, March 12, 2015 12:37 AM
> *To:* Jim Schaad; jose@ietf.org
> *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:ietf@augustcellars.com]
> *Sent:* Wednesday, March 11, 2015 8:57 PM
> *To:* Mike Jones; jose@ietf.org <mailto:jose@ietf.org>
> *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. J
>
>> Jim
>
>                                                              Thanks again,
>
>                                                              -- Mike
>
> *From:*jose [mailto:jose-bounces@ietf.org] *On Behalf Of *Mike Jones
> *Sent:* Tuesday, March 03, 2015 2:42 AM
> *To:* jose@ietf.org <mailto:jose@ietf.org>
> *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.)
>
> 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.
>
>
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>