Follow-up discovered while fixing the Key Management Admin privilege escalation (PR #329).
Severity: Low (defense-in-depth)
Problem
spp.encryption.key.encrypted_key carries a field-level groups= restriction, but spp.asymmetric.key.encrypted_private_key (spp_key_management/models/asymmetric_key_support.py) has no field-level gate — an inconsistency between the two key models.
No exposure today: the spp.asymmetric.key model ACL is restricted to group_key_admin / base.group_system only (no operator or internal-user rows), and a key admin can decrypt the private key through the sanctioned KeyManager path anyway. This is defense-in-depth / consistency, not an active leak.
Proposed fix
Add a field-level groups= to encrypted_private_key matching the (post-#329) gate on encrypted_key, so both wrapped-key fields are protected the same way at the field layer. Natural to fold into the KMS-provider hardening change.
Related: #329.
Follow-up discovered while fixing the Key Management Admin privilege escalation (PR #329).
Severity: Low (defense-in-depth)
Problem
spp.encryption.key.encrypted_keycarries a field-levelgroups=restriction, butspp.asymmetric.key.encrypted_private_key(spp_key_management/models/asymmetric_key_support.py) has no field-level gate — an inconsistency between the two key models.No exposure today: the
spp.asymmetric.keymodel ACL is restricted togroup_key_admin/base.group_systemonly (no operator or internal-user rows), and a key admin can decrypt the private key through the sanctionedKeyManagerpath anyway. This is defense-in-depth / consistency, not an active leak.Proposed fix
Add a field-level
groups=toencrypted_private_keymatching the (post-#329) gate onencrypted_key, so both wrapped-key fields are protected the same way at the field layer. Natural to fold into the KMS-provider hardening change.Related: #329.