I’m trying to clarify the supported authorization semantics for a private key in a file-based Keychain.
I’ve read the existing Apple guidance around SecAccess / trusted applications and the commonly documented codesign setup that combines a trusted-application ACL with an apple: partition list. I think I understand those pieces individually, but I haven’t been able to find a public contract for how they compose when both are present.
My case has three legitimate users of the same private key:
- a project-owned, reviewed helper that performs a bounded private-key challenge;
- /usr/bin/codesign;
- /usr/bin/productbuild.
I want to grant no broader access than those callers and their required signing operations, and I don’t want to infer authorization semantics merely because a particular configuration happens to work on one macOS release.
So my main question is:
When a private-key ACL contains both trusted-application restrictions and a partition list, are these independent conditions that must both be satisfied by the calling process?
In particular, suppose the trusted-application ACL explicitly contains my non-Apple helper, while the partition list contains only apple:. Is the helper expected to be denied because it does not satisfy the partition condition, despite being explicitly trusted by the ACL?
If so, is there a supported partition configuration for a key that must be usable by both a specifically trusted non-Apple helper and Apple signing tools such as codesign / productbuild, without broadening access to an application class?
I’m specifically looking for the supported contract here. A successful experiment would be useful qualification evidence later, but I don’t want to use that experiment to infer undocumented authorization semantics.
Thanks.