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 protected]]
Sent: Wednesday, March 11, 2015 10:40 PM
To: Jim Schaad
Cc: Mike Jones; [email protected]
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].
[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 protected]<mailto:[email protected]>> 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.
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 protected]<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]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
