opentdf
✨ Adds `sid` to KeyAccess objects
Proposed Changes
- This allows both copies and spits for keys.
- Adds a section on how they are to be used, with samples
Checklist
- [ ] A clear description of the change has been included in this PR.
- [ ] A clear description of whether this change is a Major, Minor, Patch or cosmetic change as per the Versioning Guidelines has been included in this PR.
- [ ] All schema validation tests have been updated appropriately and are passing.
- [ ] MAJOR/MINOR VERSION CHANGES ONLY: This PR should be made in branches prefixed with
draft-<change> - [ ] MAJOR/MINOR VERSION CHANGES ONLY: A link to a reference implementation (PR or set of PRs) of the change has been included in this PR.
- [ ] MAJOR/MINOR VERSION CHANGES ONLY: A writeup has been included discussing the motivation and impact of this change.
- [ ] MAJOR/MINOR VERSION CHANGES ONLY: The minimum wait time has elapsed.
- [ ] DRAFT MERGE ONLY: Draft Semver has been updated in the VERSION file (optional)
- [ ] DRAFT MERGE ONLY: Tagged this branch with new semver version and an annotation describing the change (ex:
git tag -s 4.1.0 -m "Spec version 4.1.0 - did a thing") - [ ] DRAFT MERGE ONLY: Version numbers have been updated as per the Versioning Guidelines.
- [ ] This change otherwise adheres to the project Contribution Guidelines.
@dmihalcik-virtru Is this the right way to think about this.
No Split ID
Same DEK is shared and not split
Same Split IDs
DEK is XOR'd
Group'd Split IDs
DEK is XOR'd once per group of split ids.
So you could have group kas working in group a but you might need to use local.hsm in group b?
yes. A weakness of the proposed approach is you have to have there is the same split for different sets of KASes you want to share them with. Thus the 'hybrid' example still has to do two rewraps and an xor for accessing the DEK via the local server, even though that provides no additional security.
these changes will be in https://github.com/opentdf/spec/pull/37. closing this in favor of 37.
