Outside of the discussion in that document we have agreed to introduce a key rotation #18 mechanism, the precise details of which are currently TBD, but which - in any case - renders some of the points of discussion in that document moot. The remaining key issue is summarized below.
Summary
TBB wants it to be possible for a sharer to have more than one secret with any helper without the need to re-pair (and hence undertake KYC multiple times for the same helper) and without the need for a single secret to contain other secrets.
Proposed Resolution
TBB proposes that the protobuf definitions be amended to provide for two modes of operation: one-secret-per-encryption-context (same as it works today) or multiple-secrets-per-encryption-context.
To achieve this:
The secretId field (5) of DeRecMessage MAY contain 0 or be omitted to indicate that the secret id of operations on secrets is specified in a field of the message concerned, i.e. multiple-secrets-per-encryption-context is signalled by the absence or 0 value of this field..
The StoreShareRequestMessage and VerifyShareRequestMessage messages have a new secretId field which MUST be omitted or set to 0 if the secretId field of the DeRecMessage is not omitted or 0.
The StatusEnum message has a new response code multi-secret mode not supported.
Pairing and Unpairing and other operations work as they are specified today.
Conformance
Implementation of the single secret mode of working is REQUIRED, multi-secret mode is OPTIONAL. An implementation MUST signal that it doesn’t support the requested mode by replying with the error code multi-secret mode not supported .
There have been a number of exchanges on this topic, contained as proposals and comments in Proposal for Simplification of Communication Relationship between Sharer and Helper
Outside of the discussion in that document we have agreed to introduce a key rotation #18 mechanism, the precise details of which are currently TBD, but which - in any case - renders some of the points of discussion in that document moot. The remaining key issue is summarized below.
Summary
TBB wants it to be possible for a sharer to have more than one secret with any helper without the need to re-pair (and hence undertake KYC multiple times for the same helper) and without the need for a single secret to contain other secrets.
Proposed Resolution
TBB proposes that the protobuf definitions be amended to provide for two modes of operation:
one-secret-per-encryption-context(same as it works today) ormultiple-secrets-per-encryption-context.To achieve this:
secretIdfield (5) ofDeRecMessageMAY contain 0 or be omitted to indicate that the secret id of operations on secrets is specified in a field of the message concerned, i.e.multiple-secrets-per-encryption-contextis signalled by the absence or 0 value of this field..StoreShareRequestMessageandVerifyShareRequestMessagemessages have a newsecretIdfield which MUST be omitted or set to 0 if the secretId field of the DeRecMessage is not omitted or 0.multi-secret mode not supported.Conformance
Implementation of the single secret mode of working is REQUIRED, multi-secret mode is OPTIONAL. An implementation MUST signal that it doesn’t support the requested mode by replying with the error code multi-secret mode not supported .