Hello Apple Technical Support, We need a documented feasibility clarification before implementing a native macOS app running in the logged-in user's context. The app needs to generate and persist a software RSA 3072-bit private key in the Data Protection Keychain (DPK), for RS256 (RSASSA-PKCS1-v1_5 with SHA-256). The required properties are effective private-key non-exportability and signing-only use, enforced beyond our app's choice not to call export or other cryptographic operations. We also need a supported way to verify these properties without attempting any private-key export. We distinguish these requirements from access-group authorization, kSecAttrSynchronizable=false, ThisDeviceOnly accessibility, and hardware-bound keys. We recognize that access groups are a different boundary from exact CDHash/build exclusivity; we do not claim that exclusivity is satisfied. Group membership alone does not establish the requested key properties, including for another process legitimately entitled to the same group. Environment: recorded static header provenance is MacOSX27.0.sdk (Command Line Tools), not a successful build or runtime validation. Target macOS version and build: Apple M4, 16GB in memory, macOS Tahoe version 26.6.2. No DPK implementation or experiment is being submitted as evidence. Please clarify these four points: Is there an officially supported API/attribute combination to generate and persist this software RSA3072 key in DPK with enforceable non-exportability and signing-only use (no decrypt, unwrap or derive)? If yes, please identify the exact APIs, attribute placement and values, applicable macOS/SDK versions, and enforcement limits. Please distinguish actual key restrictions from requested attributes or app-side policy. How does that combination, if supported, relate to the generic macOS kSecKeyExtractable=false exception documented for SecKeyCopyExternalRepresentation [1], versus the Apple DTS explanation that raw bytes of standard DPK keys can be obtained through that API [2]? Does the exception apply to software RSA keys generated in DPK, or only to other key implementations? Please distinguish kSecKeyExtractable from kSecAttrIsExtractable where relevant. Which supported attributes, query APIs or other evidence establish effective non-exportability and signing-only restrictions without attempting export? Please specify whether SecKeyCopyAttributes or an item query guarantees the required fields for this key/store combination, and how absent or unsupported fields must be interpreted. We will not treat a missing field as false or infer enforcement from creation inputs. If this combination is not supported for software RSA in DPK, please confirm that limitation explicitly and distinguish it from hardware-bound keys. We are not asking to substitute Secure Enclave/EC or another algorithm, and do not assume hardware guarantees apply to software RSA. References: [1] SecKeyCopyExternalRepresentation https://developer.apple.com/documentation/security/seckeycopyexternalrepresentation(::) [2] Apple DTS reply (June 2023), Developer Forums thread 731001 https://developer.apple.com/forums/thread/731001 [3] TN3137: On Mac keychain APIs and implementations https://developer.apple.com/documentation/technotes/tn3137-on-mac-keychains [4] Protecting keys with the Secure Enclave https://developer.apple.com/documentation/security/protecting-keys-with-the-secure-enclave An applicable technical answer with references and limits, or an explicit statement that this combination is unsupported, would resolve the feasibility question. If support or a non-exporting verification method cannot be established, we will keep support NOT_ESTABLISHED and implementation blocked. A successful signature or access-group isolation alone would not close it. Thank you. fapontec