Re: [jose] comments on draft-jones-json-web-signature and draft-jones-json-web-encryption

[Mike Jones <[e-mail]>]

Thanks for writing this up, Jim.

Considering this at a meta-level, I believe that one of the most important things for the working group to be doing at present is collecting potential scenario descriptions and use cases and systematically determining what features are needed to support those use cases.  Done well, that will give us a fairly comprehensive view of the space of choices available to us.  Then the working group can make informed decisions about which scenarios it decides to enable, which not to, and how to factor the solutions(s) enabling those scenarios we choose to support.  One product of this work should be a document clearly describing the rationale for which scenarios the WG decided to support and which it decided were out of scope, so others can understand the reasons for the choices we made.

If the working group can reach consensus at the requirements level, I believe we'll have a decent chance of reaching consensus on actual specifications and meeting our self-declared delivery timelines.  In the absence of that, I suspect that the working group will experience multiple painful rounds with near-final specs, only to have new groups come to us saying "You can do X, Y, and Z that I need, but I also need you to do P, Q, and R", resulting in contentious debates about whether to leave the specs as-is or to open up the box again, potentially making breaking changes, and adding ever more features.

I'll take your note below as one such scenario description for the working group to consider.  (I know that there are others that we should also capture from XMPP, Alto, etc.)

In that light, I'll also take a stab at writing up the web authentication/authorization security token scenario and the resulting requirements behind the current specs.  In that use case, making life simple for developers is paramount.  Complexity is the enemy of adoption. ;-)

				Cheers,
				-- Mike

-----Original Message-----
From: Jim Schaad [mailto:[e-mail]] 
Sent: Wednesday, November 16, 2011 4:55 PM
To: 'David McGrew'; Mike Jones
Cc: [e-mail]
Subject: RE: [jose] comments on draft-jones-json-web-signature and draft-jones-json-web-encryption

Mike,

I think that while the structures for JWS might need to undergo some changes that will mean that while the MAC and Digital Signature structures.  As I mentioned at the F2F meeting, I know of someone is doing some small device work where they are sending messages from the devices to more central locations.  In this case there is not a pre-existing shared secret generally between the two entities and they are not using TLS so they could not derive one from the session key.  Mapping what they do into the current JWS work would require some changes. Specifically

Header Object
   - contains a MAC algorithm to be used - generally AES-GMAC
   - contains a key wrapping algorithm - generally AES key wrap
   - contains a key agreement algorithm - generally EC-DH Key Exchange Value - the CEK wrapped by the KEK where the KEK came from the static-static EC-DH algorithm Body MAC value

In this case we have four not three items that need to be placed in the sequence of items to be sent between the originator and the verifier.  I would still compute the MAC value in much the same way, only I would compute the MAC over the first three elements instead of the two elements.

This is the sort of thing that is used in a more store and forward environment or one where the answer is going to be pre-computed or where it needs to last longer than just the current session (i.e. later validation).

The same type of thing can be used for a long term shared KEK value on both the sender and recipient, where a unique CEK is generated for each message and wrapped.  David would be a better person than I am to address the question of security.  -"Do you have more security by doing an indirection and have a fresh key for doing the MAC on each operation rather than using the long term key for doing the MAC."  

If we did the above change, then I would say that the "Key Exchange Value" would become and empty string if you have a key derivied from the TLS session that you are using - but this would still lead to having four not three elements in the MAC case.

Jim