Description
Our current instantiation of the Parsec API contracts is based on v1.0.0 of PSA Crypto. The spec is, however, evolving - version 1.1.0 has already been released and includes new primitives that we could integrate into Parsec.
Making any changes to the contracts to introduce new primitives raises multiple compatibility questions:
- what happens when an old client/service attempts to communicate with a new service/client
- what happens when a new service tries to handle old key metadata
Hugues has already investigated some of these problems in this issue, however a fresh attempt to answer these questions would be useful.
The two big avenues for solving this are:
- add new elements in the existing contracts and interfaces, for example by adding new key types to the
KeyType
variant, and/or to therust-psa-crypto
keyType
. - add new contracts specific to 1.1.0, essentially duplicating the existing contracts and adjusting them according to the changes in 1.1.0
Solution (1) comes with potential interoperability and backwards compatibility issues in the client-service communication. Solution (2) comes with increased complexity in both clients and service, since the cryptographic operations will have two different transport mechanisms for the same underlying operations.
The outcome of this ticket should be a detailed understanding of the tradeoffs of the two approaches. This investigation can then be used to inform the final decision and design.