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]> 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]] *On Behalf Of *Mike Jones > *Sent:* Tuesday, March 03, 2015 2:42 AM > *To:* [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 > >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
