-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
✨ Adds sid
to KeyAccess objects
#32
base: main
Are you sure you want to change the base?
Conversation
This allows both copies and spits for keys. Also, adds a section on how they are to be used, with samples
@dmihalcik-virtru Is this the right way to think about this. No Split IDSame Same Split IDs
Group'd Split IDs
So you could have group kas working in group |
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. |
split
id to KeyAccess objectssid
to KeyAccess objects
Implementation of opentdf/spec#32 This is a proposal to allow customizing how a client shares key data across multiple KASes. With a split, you can copy the same share to multiple providers, allowing for robustness if a given KAS is unavailable - or if a decrypting user or application does not have authorization with that KAS.
Implementation of opentdf/spec#32 This is a proposal to allow customizing how a client shares key data across multiple KASes. With a split, you can copy the same share to multiple providers, allowing for robustness if a given KAS is unavailable - or if a decrypting user or application does not have authorization with that KAS.
Implementation of opentdf/spec#32 This is a proposal to allow customizing how a client shares key data across multiple KASes. With a split, you can copy the same share to multiple providers, allowing for robustness if a given KAS is unavailable - or if a decrypting user or application does not have authorization with that KAS.
Implementation of opentdf/spec#32 This is a proposal to allow customizing how a client shares key data across multiple KASes. With a split, you can copy the same share to multiple providers, allowing for robustness if a given KAS is unavailable - or if a decrypting user or application does not have authorization with that KAS.
Implementation of opentdf/spec#32 This is a proposal to allow customizing how a client shares key data across multiple KASes. With a split, you can copy the same share to multiple providers, allowing for robustness if a given KAS is unavailable - or if a decrypting user or application does not have authorization with that KAS.
Implementation of opentdf/spec#32 This is a proposal to allow customizing how a client shares key data across multiple KASes. With a split, you can copy the same share to multiple providers, allowing for robustness if a given KAS is unavailable - or if a decrypting user or application does not have authorization with that KAS.
Implementation of opentdf/spec#32 This is a proposal to allow customizing how a client shares key data across multiple KASes. With a split, you can copy the same share to multiple providers, allowing for robustness if a given KAS is unavailable - or if a decrypting user or application does not have authorization with that KAS.
Implementation of opentdf/spec#32 This is a proposal to allow customizing how a client shares key data across multiple KASes. With a split, you can copy the same share to multiple providers, allowing for robustness if a given KAS is unavailable - or if a decrypting user or application does not have authorization with that KAS.
Proposed Changes
Checklist
draft-<change>
git tag -s 4.1.0 -m "Spec version 4.1.0 - did a thing"
)