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

[John Bradley <[e-mail]>]

Jim,

I may be missing something.

The scenario below is using RFC6278 and pre shared EC keys to crate a master symmetric key to wrap a per message symmetric key used for generating a HMAC, or to use the master symmetric key to wrap a MAC of the message?

For EC we only included ECDSA.  

The main difference is that with EC-DH-SS only the intended recipient can verify the message.  Slightly different from the ECDSA case.  

Is the reason for this performance in a embedded environment?

I think there is a general question about key wrapping vs using the pre-shared or key agreement value directly.   
The current specs lean towards using the values directly rather than for key wrapping.

I tend to prefer key wrapping for security,  but that depends on people actually rotating keys, and it makes the minimum message size larger.

Is key agreement for integrity (signing) common?

John B.
On 2011-11-16, at 9:54 PM, Jim Schaad wrote:

> 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
> 
> 
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose