Add support for ECDH-1PU+ XC20PKW

[awoie]

Currently, the spec only supports AES-based key wrapping algorithms. IMO, we should have support for XC20PKW especially for people who use XC20P for content encryption to minimize crypto-libs.

XC20PKW is defined here: https://tools.ietf.org/html/draft-amringer-jose-chacha-02

[awoie]

We have our ECDH-1PU+XC20PKW implementation (see impl in DIF did-jwt) based on Amringer's latest XC20PKW draft that only talks about Key Wrapping and Content Encryption with XChacha/Chacha (in contrast to a previous version of the draft).

Please note, in the latest Amringer draft, there are iv and tag in the recipient header which is not the case in the most recent proposed Aries ECDH-1PU+XC20PKW test vectors which can be found here. IMO, that is an independent problem that Aries 0334 needs to address. Note, since Amringer does not register ECDH-1PU+XC20PKW, Aries is not necessarily wrong but imo, it would make sense to use XC20PKW as per Amringer to avoid confusion. It might be more of an issue with anoncrypt that uses ECDH-ES+XC20PKW that is also defined by the Amringer draft but Aries does not use iv and tag for recipients.

A few things that I'd like to discuss:

1. Do we need to register ECDH-1PU+XC20PKW in IANA and if this is the case, would this need to happen through Madden's ECDH-1PU draft?
2. If adopted by Madden, should ECDH-1PU-XC20PKW be based on Amringer's latest spec which is different from the test vector's in Aries? Note, there is no JWE spec that matches the XC20PKW in Aries yet. I'd say, we should try to keep inventing new specs minimal and yes, in that case Aries should likely use Amringer's latest spec.
3. Someone probably needs to reach out to Amringer and ask about the status of the draft since it has not been adopted by CFRG yet and the draft has expired in July 2020.

For better visibility in Aries, I created an issue there too: https://github.com/hyperledger/aries-rfcs/issues/648

Any thoughts? @andrewwhitehead @oed @kdenhartog @TelegramSam @Baha-sk

[kdenhartog]

Do we need to register ECDH-1PU+XC20PKW in IANA and if this is the case, would this need to happen through Madden's ECDH-1PU draft?

Yes, I suspect it will be faster to get XC20P through first before 1PU, so registering it in the 1PU draft makes more sense.

If adopted by Madden, should ECDH-1PU-XC20PKW be based on Amringer's latest spec which is different from the test vector's in Aries?

It likely will have to be. I think the standards we can get moving will play the largest impact on this. I'm still waiting to hear back from CFRG chairs/Neil/Scott (xchacha20 rfc author) to see if this is something we can move forward.

Someone probably needs to reach out to Amringer and ask about the status of the draft since it has not been adopted by CFRG yet and the draft has expired in July 2020

Agreed, we've got 3 possibly 4 things that have expired at this point that would be good to get moved into a WG somewhere at IETF. At this point I'm not aware enough with how IETF works to know the best way to get these things moving forward.

@troyronda or @Baha-sk I've seen that @jricher will help consult for you guys and also knows the IETF process well. Maybe he can help so we can get a plan to figure out how to get these RFCs we're depending on moving?

[baha-ai]

@kdenhartog @awoie, I believe we should follow the same format as ECDH-1PU+A256KW (similar to the standard ECDH-ES+A256KW), ie no iv and no tag in the recipient headers.

The easiest way to do this is by setting the recipient encrypted_header with the concatenation result: nonce+ciphertext+tag

I personally like how Tink returns cipher text from their primitives: they concatenate nonce+ciphertext+tag and return the result as a ciphertext to the user who doesn't need to know/parse ciphertext, the library takes care of it for them.

In Golang, the XChacha20Poly1305 primitive's Seal() call returns a ciphertext that is comprised of ciphertext+tag (Tink goes one step further by also prepending nonce to simplify the user's interaction with the library).

In AFGO, we've followed suit with what Tink does. In our ECDH-1PU+XC20PKW implementation, we made the encrypted_key header to contain the resulting nonce+ciphertext+tag value of the wrapped key. The recipient can extract them directly since both nonce and tag sizes are predetermined for XChacaha20Poly1305.

Let me know if it makes sense to go this route for ECDH-1PU+XC20PKW. It's not in an IETF draft, but it's the closest to ECDH-1PU and ECDH-ES.

[awoie]

Closing this issue since ECDH-1PU (v4) does not allow XC20PKW anymore. See discussion here.