Decryption race condition

[woutslakhorst]

Decrypting the PAL header (or other future decryption actions) is done by getting the latest DID Document. If a key rotation has occurred, an older key might be able to decode but this is currently not done.

This is a broader issue with encryption/decryption and legacy keys. We might have to say that encryption/decryption with asymmetric keys from the DID Document can only be used in runtime (timewise) use-cases?

[reinkrul]

We currently don't remove rotated keys (#1660) but if we do, you can't decrypt the PAL header after key rotation has occurred (because now the private key is gone).

We can currently only solve this by saying PAL is a runtime-property, which can only be checked in the present (with some delay to account for network latency and key rotation). But that means it can't be used to exchange historic private TX payload.

It's really just a transport-level ACL: to determine whether the other party is allowed to receive it. Would DIDComm be able to solve this?

[woutslakhorst]

Even a 1 second delay could become a problem when a key rotation occurs within that window. No feedback will be available when this happens.

[woutslakhorst]

Backport to V5

[woutslakhorst]

It's really just a transport-level ACL: to determine whether the other party is allowed to receive it. Would DIDComm be able to solve this?

no

[woutslakhorst]

If you rotate an asymmetric encryption key, you usually decrypt all symmetric keys and then re-encrypt them. In our case this would not be possible since encrypted data is on-chain. The encryptor could detect new keys and re-issue any VC. This really feels like a bandaid solution. A cleaner solution would be to reverse the responsibility of who must guarantee the delivery. This is currently the case for the wallet owner.

[woutslakhorst]

We could migrate everything to OIDC4VCI with the pre-authorized code flow.

This would eliminate the need for authenticated grpc connections, ECIES encryption, PAL headers and maybe even the client certificates (at some point).

An issuer can initiate an Issuance Initiation Request which can be delivered synchronous to a wallet endpoint. When successful the issuer doesn't need to retry it. Any downtime of the wallet would then have to be handled by the issuer (but not the nuts-node).

Specification is currently in progress. Lots of stuff to fix though: https://bitbucket.org/openid/connect/issues?status=new&status=open&component=Credential%20Issuance
Also DIDs not supported yet

[woutslakhorst]

OIDVCI has gotten an update on 30th of December 2022. DIDs are now mentioned and supported.

Making the credential issuance a synchronous process would make this a non-issue

[gerardsn]

OpenID4VCI is being implemented and will obsolete the private transactions. Do the DidComm messages (kik-v) have the same problem? If not we can close the issue

[woutslakhorst]

OpenID4VCI is being implemented and will obsolete the private transactions. Do the DidComm messages (kik-v) have the same problem? If not we can close the issue

DidComm messaging is runtime so during a key rotation "a message" could fail but when attempted again it succeeds. Nothing will be permanently broken. So could be closed I guess.