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
for _, validLabel := range usage.Labels {
for _, label := range labels {
if label == validLabel {
return true
}
}
}
return false
As a refinement of this, it could match all labels instead. I'm not sure I see a reason not to do this, and it allows for stricter access control when secrets have multiple labels. For example, if there are three secrets with labels like so 1:(A, B); 2:(A, C); and 3:(B, C), I would be able to delegate for someone to decrypt 1 but not 2 or 2 but not 3. Presently, this is not possible.
This is a low-priority enhancement - I don't see any near-term need to have multiple labels, I just noticed this while trying to match the label-handling behavior somewhere else, was surprised, and wanted to document it.
The text was updated successfully, but these errors were encountered:
Currently, Red October considers that delegations "apply" to a decryption usage if any label in the delegation matches a label in the ciphertext: From https://github.com/cloudflare/redoctober/blob/master/keycache/keycache.go#L64-L71:
As a refinement of this, it could match all labels instead. I'm not sure I see a reason not to do this, and it allows for stricter access control when secrets have multiple labels. For example, if there are three secrets with labels like so 1:(A, B); 2:(A, C); and 3:(B, C), I would be able to delegate for someone to decrypt 1 but not 2 or 2 but not 3. Presently, this is not possible.
This is a low-priority enhancement - I don't see any near-term need to have multiple labels, I just noticed this while trying to match the label-handling behavior somewhere else, was surprised, and wanted to document it.
The text was updated successfully, but these errors were encountered: