You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 the rust-psa-crypto key Type.
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.
The text was updated successfully, but these errors were encountered:
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:
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:
KeyType
variant, and/or to therust-psa-crypto
keyType
.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.
The text was updated successfully, but these errors were encountered: