ECDH-ES question about apu and apv (from waci-pex)
bumblefudge opened this issue · 5 comments
note: https://blog.identity.foundation/ecdh-1pu-implementation/
discussed on today's WACI-PEx call (in the context of a diff signature suite, ECDH-ES ) -- @OR13 was asking what libraries and how interact with them to get apu and apv into every message? @rolsonquadras said he'd check with baha but figured maybe this group might want to chime in with any other links or ideas or anecdotes
(follows up on this merged PR ) #205
kid is optional can be safely ignored... but note that apu / apv are not present for "ECDH-ES+A256KW":
DIDComm spec says apu / apv are required for ECDH-1PU.... but I am here to confirm that the are NOT required for "ECDH-ES+A256KW"... this snippet was produced by vanilla https://www.npmjs.com/package/jose
{
"ciphertext": "ozt71h4tEJJQN9obCx8pm6I1SNgWfzxlUqs5r2VRmeoB97B0O-lQnjsarI0nNnTConsv5jo2XErifc7xHS-lEZ7Yw_p1Vg",
"iv": "Z4x3pmg07q7fQP7s",
"recipients": [
{
"encrypted_key": "YEQjibgREmfkhoYcD0XJUsI4wuaCmKxj2GgaOtPMqYk0CkcIkhdLwA",
"header": {
"alg": "ECDH-ES+A256KW",
"kid": "did:example:123#key-0",
"epk": {
"x": "Ua4qf2B-v5gq2ENXTHjXGJIoiTOjA5_KMzNYnFfu_Qo",
"crv": "X25519",
"kty": "OKP"
}
}
},
{
"encrypted_key": "V9b2WfHaK-1zfSRQPi73eIsvQkHyv7b4WWoM2noVjLYAuf1_dlerOA",
"header": {
"alg": "ECDH-ES+A256KW",
"kid": "did:example:123#key-1",
"epk": {
"x": "YLaGAnv4sMc7g5NXbzEmLXSIYs7B0knkcoJDYl0i5h4",
"crv": "X25519",
"kty": "OKP"
}
}
}
],
"tag": "c8i0EmPILd_aqX59AwzaNw",
"protected": "eyJlbmMiOiJBMjU2R0NNIn0"
}const { publicKeyJwk, privateKeyJwk } = {
publicKeyJwk: {
kty: 'OKP',
crv: 'X25519',
x: 'sJ4qz3Dvax-H2TVRDYXkK1onaafdO3mRL-qLj-KKKEI',
},
privateKeyJwk: {
kty: 'OKP',
crv: 'X25519',
x: 'sJ4qz3Dvax-H2TVRDYXkK1onaafdO3mRL-qLj-KKKEI',
d: 'mK2jV5pAes3Zw6wZZ89_6lJtDtyB_RltGVZzRXoO2ns',
},
};
const message = {
message: 'It's a dangerous business, Frodo, going out your door.',
};
That's right, ECDH-ES (used in Anoncrypt) does not require apu/apv (they're useful to add integrity to the message as they're used in the key derivation process).
As for ECDH-1PU (Authcrypt), these are required since the sender kid (skid) can be replaced by APU (which is b64(skid)) if skid is missing in the headers. As for APV, the DIDcomm V2 spec explains it's the list of recipients kid alphabetically sorted and joined with ., the SHA256(result) digest is then b64 encoded and set as APV. See the spec definition here: https://identity.foundation/didcomm-messaging/spec/#ecdh-1pu-key-wrapping-and-common-protected-headers. Our Aries Framework Go has this implemented here. I believe other languages support for 1PU do exist or are in the process of being developed.
However, since DIDComm V2 requires the agents to be authenticated (via means of already known public DIDs), the 1PU is the only viable option in the protocol. Therefore APU/APV recipient headers are mandatory. I'll submit a pr to the DIDComm V2 spec to clarify this point since having both Authcrypt and Anoncrypt support in the spec does not tell why Authcrypt is required.
One can still use ECDH-ES for Anoncrypt requests, but it's not warranted to trigger subsequent DIDComm V2 calls.
@Baha-sk : you mentioned that you'd submit a PR to clarify this point. Can you possibly do this immediately? We want to close out the final issues on the spec by this coming Monday... If not, can you simply suggest an approximation of what you'd say, and where, and I'll turn it into a PR?