Over the last few weeks I have been revisiting keychains, in the light of Apple’s latest documentation, particularly its Technical Note for developers. I hadn’t appreciated the many differences between the file-based keychains of old, and the newer Data Protection variety that came with iCloud Keychain ten years ago. Nor was I aware that “the file-based keychain is on the road to deprecation”, something that Apple hasn’t yet spelled out to its users. There’s a catch, though, in that not all processes can access the Data Protection keychain. Yet again, deprecation looks like it’s going to cause trouble.

Internally, the problem is that the Data Protection keychain is only available for use by processes running in a user context, like apps and their extensions, but not by those run by launchd as daemons, executing outside a user context. At present, if file-based keychains were to be removed, a lot of services would be unable to run.

What the Tech Note touches on but doesn’t explore any further is the consequence on users and those who support them. I had assumed that iCloud Keychain only stored passwords (both Internet and generic in scope), but apparently it has been able to store and sync certificates and keys as well since Big Sur. The reason that we can’t take advantage of this is that the only app that can manipulate keychains, Keychain Access, intentionally only shows password items in the Data Protection keychain.

I would dearly like to save my Apple developer signing certificates in my iCloud Keychain, which would save me having to install them locally into the login (file-based) keychain on each Mac that I develop on. Although my iCloud Keychain apparently has that ability, there’s no means to make it happen.

The situation with passkeys is also severely constrained: while Passwords settings, and its equivalent in Safari, give access to passkeys stored in the iCloud Keychain, Keychain Access doesn’t even admit to their existence. It’s all very well intending to deprecate file-based keychains, but hobbling the user’s only access to their successors doesn’t help us transition to the Data Protection keychain.

The closest equivalent in the command line to Keychain Access is security, whose keychain options are similarly unsuited to working with iCloud Keychain.

There are further concerns over command tools. The two types of keychain also differ in their access control methods. File-based keychains use access control lists that work fine with Mach-O binaries such as command tools, but the Data Protection keychain uses keychain access groups that are built from an app’s code signing entitlements, authorised by a provisioning profile. For that to be embedded with the code for a command tool, it has to be wrapped in a dummy app-like structure to turn it into a bundle. Apple explains how to do that for a Launch Daemon in this article.

On the basis of the description in this one Tech Note, the road ahead for the deprecation of file-based keychains looks far from being straightforward:

• A solution is required for processes run by launchd outside a user context.
• Command tools requiring access to the Data Protection keychain will require provisioning profiles, entitlements, and to be wrapped in a bundle.
• Any remaining apps (and currently that’s a lot of third-party products) will need to change the API they use to ensure they can access the Data Protection keychain. They will also need provisioning profiles and entitlements to do so.
• Users and support staff need a replacement for Keychain Access that works with all categories of secret in the Data Protection keychain, and a replacement for keychain features in the security command tool. In particular, they will need to be able to manipulate certificates in that keychain.

I just hope that whoever has the road-map for this transition is going to tell us well in advance. Looking back over the last few WWDCs, it looks like there’s still a great deal of the journey to be explained and scheduled.