search

mattrglobal / jwm

JSON Web Message (JWM) RFC
16 stars 6 forks source link

Multilevel Nested JWM #37

Open troyronda opened 4 years ago

troyronda commented 4 years ago

Does the scope of the JWM spec include optimizing the payload encryption for a multi-level nested JWM?

This topic was raised in the Aries community. The idea of a detached JWE mode can potentially help - discussed in Aries RFC 334.

tplooker commented 4 years ago

Im open to considering this, however with that are we not modifying the JWE serialisation formats?

troyronda commented 4 years ago

@tplooker The "on the wire" serialization is changed (appended with detached payloads) but the serialization provided to the JWE library is unchanged. The mechanism was designed with JWS detached mode in mind. JWS defines detached mode where the payload can be removed. As stated in IETF RFC7515, this strategy has the following benefit:

Note that this method needs no support from JWS libraries, as applications can use this method by modifying the inputs and outputs of standard JWS libraries.

In the case of the proposed mechanism, no support is needed from the JWE libraries as the logic outside the library modifies the inputs and outputs (to detach payloads from multi-level nested JWEs).

tplooker commented 4 years ago

@troyronda, ok so we would still need to define this? Much like say Linked Data proofs defines the use of a detached JWS?

A point of language I would consider a nested JWM the protection strategies (e.g JWS JWE) applied over a single attribute set. But in the case of forwarding messaging in DIDComm, there is an attribute set at each layer, so even though that looks like nesting, the final multi layer message I would not say is a single "Nested JWM", rather something else does that make sense?

troyronda commented 4 years ago

@troyronda, ok so we would still need to define this? Much like say Linked Data proofs defines the use of a detached JWS?

I would think so, yes.

I would not say is a single "Nested JWM", rather something else does that make sense?

Sure. I understand the reasoning.

TelegramSam commented 4 years ago

The general idea here is the ability to pass through previously encrypted data. This avoids computation of re-encryption, but more significantly avoids the 33 percent bloat of repeated Base64 encodings. This has application in DIDComm forward messages, but is generally useful anytime you wish to encrypt a message that contains an already encrypted payload.

I'm not sure a detached JWE contains all the mechanisms necessary for our purposes: Part of the message needs to be passed through (be 'detached') and part of it still needs regular encryption. @troyronda any thoughts on this?