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 protected]] On Behalf Of Mike Jones
Sent: Thursday, March 12, 2015 12:37 AM
To: Jim Schaad; [email protected]
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 protected]]
Sent: Wednesday, March 11, 2015 8:57 PM
To: Mike Jones; [email protected]<mailto:[email protected]>
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 protected]] On Behalf Of Mike Jones
Sent: Tuesday, March 03, 2015 2:42 AM
To: [email protected]<mailto:[email protected]>
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
[email protected]
https://www.ietf.org/mailman/listinfo/jose
