Clarify the need for JWE extensions in Message Format Section

[csmarc]

[from RWOT8-Barcelona Peer DID Method Specification Report]

In sec 3.2 Messages (Messages are serialized and encrypted...), Indy HIPE message protocol is referenced - what extensions are required (multiplexed encryption) and why? The observation here is that pure JWE may be better for adoption, so understanding the need for extensions would be helpful.

[dhh1128]

@kdenhartog, Would you be willing to create a PR explaining the extension we need? I believe it consists of moving something into the protected section so it is tamper-evident. I know that you discussed this with Mike Jones (JWE owner from MS) at the recent IIW, and that you may have new updates...

[kdenhartog]

Yeah, I can add details. I'll add this to my todo list, and hopefully can get to this in the next week or two.

[kdenhartog]

This is the list of things we need to change (including spec updates):

• "alg" Authcrypt needs to be changed to something like ECDH-SS+ES+C256KW

  • The C256 would be XChacha20-Poly1305_ietf based (256 bit key, with 192 bit nonce). Right now IETF only has a 96 bit nonce version (no x used in the naming scheme). We may be able to avoid this step if other agree a 96 bit nonce is sufficient and can stick with what they defined. The current implementation uses 96 bit nonces which is ietf compliant. (It still gives us 256GB of ciphertext coverage, so I think this is plenty good)
  • We would also need to build a KW algorithm (this is the algorithm I was referring to) off of this which would allow us to eliminate the private "iv" header from the recipients section.

• The recipients block needs to be moved back to the same layer as the same level as the "ciphertext" field which is how it's specified in the spec.

• We would need to add an "aad" field

  • our implementation would require the use of verifying this data.
  • We'd need to define the data model that goes in there. (concat the "kid" from each header might work with a period delimiter between each "kid")

• Write the specs for the XChacha20-Poly1305_ietf algorithm as well as the XChacha20-Poly1305_ietf Key wrapping algorithm

• Define how the operation of the ECDH-SS+ES+C256KW algorithm works with a spec and add to IANA registry

• Add ECDH-ES+C256KW to IANA registry with spec. This is very similar to what's already defined with AES, but we're changing the key wrapping algorithm.

For the implementation stuff, we just need to do 1, 2, and 3. For it to be fully compliant we'd need the specs added as well. The most contentious aspect in here is the ECDH-SS+ES+C256KW because typically only one is used (SS or ES, not both). The reason that we would want both is because we would use the static-static aspect to encrypt the "encrypted_key" and then we would use the ES function to encrypt the sender's public key so we get sender anonymity.

This is what we would need to do in order to make it "JWE Compliant". In any case, we'd still have to build independent implementations because the JWE libraries likely won't add these additions even if they get added to the spec.

[dhh1128]

I have now linked the spec to to Kyle's comment above, plus to a revised version of his encryption envelope RFC. There is still no inline explanation of what the specific JWE extensions are, but the improved links do provide a lot more detail.

@csmarc I'd love your feedback about the latest draft, which includes numerous improvements including this one plus an explanation of how peer DID Docs are CRDTs to avoid merge conflicts, and details about the various sections of a peer DID Doc. I also associated a link to KILT with your name in the author list. Let me know if that's okay.

Should we close this, or keep it open?

[kdenhartog]

Sorry I haven't gotten to the point of adding these details in. I had a PR with them half written and then deleted it accidentally without pushing the commits to my repository. I'll have to go add them again.

[csmarc]

@dhh1128 Thanks for updating the author list, perfect! I started going over the revised version, I will put in issues with suggestions as I go along.

I think we can close this for now, but if @kdenhartog can make it better with a PR he is more than welcome to do it.