MDJ 2020.02.19: Keychain Access deserves better

The Weekly Attitudinal returns, and we’re sorry

After careful consideration, we realized we needed to hand off the end of this security series to The Weekly Attitudinal, MDJ ’s right-by-definition opinion feature, because it has a bit more freedom to move beyond the fully-documented and into the realm of possibilities and probabilities.

This was a mistake, and we apologize for it.

After being removed from mothballs for the first time in a decade, the Attitudinal immediately absconded on what we can only assume is the kind of party spree that would cause you to change your name rather than tell your children about. Perhaps we should have expected this.

Nonetheless, after finding the perpetrators and repairing the damage, the Attitudinal is back at what it does best: annoying everyone, not just us.  It has lots to say but only made it through Keychain Access before passing out, mumbling about missing all the good fast food. The points here deserve your attention, though: Keychain Access is your window into the private keys and certificates of your system, and it manages to show you everything and tell you nothing. The Attitudinal argues that this is insufficient.

The Weekly Attitudinal:
Keychain Access should unlock more

First, a note to the publisher: who expects to be reanimated after a 10-year slumber and immediately start writing about Public Key Infrastructure? The jerks who run this place are just lucky the Attitudinal hangs around here.

The courtesy of at least a Popeye’s Chicken Sandwich would have been nice.

Where’s the design?

If you’ve ever had the privilege of installing an SSL certificate on a Web server, some of what MDJ has been discussing this month should have rung a bell, or worse, triggered flashbacks.  For most developers, Xcode handles the details of requesting Developer ID certificates, storing them in the keychain, and attaching them as needed to notarization or other requests.  If not, you get to use Keychain Access.

Believe it or not, that’s still better than what most certificate handlers deal with daily. Nearly every Web provider and CA have pages like this one for SSLs.com, explaining the multiple formats in which certificates may be stored, transmitted, or deployed. If the certificate you have is not in the format you need, you can either ask the CA to reissue it in the right format (if they even do that), or you can learn a bunch of arcane command-line tools, or you can (gulp) trust online certificate converters to do what they say and nothing more (like storing key files or password).

Therefore, your Attitudinal’s first question is: why?

The “Web of trust” model most commonly associated with PGP (and its open-source implementation, GPG) has lost the IT battle. Certificates with keys and restrictions and hierarchical authority models are here to stay—so why can’t anyone interpret them? The documentation for what can and cannot be in a certificate is RFC 5280, and every person who’s ever read it was paid to do so because it is 151 pages of passive-voice assertions and extended Backus-Naur form metasyntax notations. Wikipedia says these notations “can be used to express a context-free grammar,” and your Attitudinal cannot think of a better description for these PKI RFCs.

And this is the good version. RFC 5280 supersedes RFCs 4630, 4625, and 3280, which itself replaces RFC 2459, a proposal that started circulating as a draft in 1996. This standard is substantially newer than email and yet suffers from some of the same design issues that have hampered email in the 21st century.

For example: it generally envisions certificates and keys as files, ostensibly to be placed in secure directories granting access only to the software that needs to read them, just as the original email servers (and many to this day) treat messages as text files in a user’s “mail” folder. But today, most of your email is stored in a database where it is indexed and compressed. Most of the certificates on your Mac are stored in the keychain, and probably not as text blobs. Modern developers want to work with certificates as objects, and macOS obliges them.

Citations Needed

But the Attitudinal asserts that Keychain Access and the Security framework are not enough in 2020. The Attitudinal acknowledges that macOS’ certificate display, available when you click the padlock in the URL field in Safari for any SSL-secured site or by double-clicking a certificate in Keychain Access, is as comprehensive and by-the-book as they come. It is a good presentation of data but an inadequate presentation of information.

You can change the settings that allow using any certificate for SSL or secure MIME or IPsec, but Keychain Access does not tell you which applications would use any of those functions, so you have no idea what changing those settings would do. That may be safe, but it’s not enough. Think about your contacts and calendars: in macOS Catalina, programs must ask your permission to access that data, and the Security & Privacy preferences pane keeps a list of which programs have requested and obtained that access.

Keychain Access doesn’t tell you this because it cannot—the existing APIs don’t even have the option of asking programs why they need certificates. Yet this is the direction of consent—not necessarily to force developers meekly to request access to certificates they stored in your keychain, but to provide information that lets you know why that certificate is in that keychain.

Without this kind of info, Keychain Access could have let you delete the system’s own root certificates, so Apple moved them to a different keychain to protect them. If your system has been around long enough and migrated enough times, you may have a locked “PrivateEncryptedDatak” keychain that was created by the old Adobe AIR applications, probably to keep those items from cluttering up your login keychain.

That might not have been a problem if you could know why the items were there! OK, technically, you can see some of that now: open a password item in Keychain Access and click the “Access Control” tab to see a list of applications allowed to use that item. Absent unusual circumstances, the first item in that list is the program that created the keychain item. Did you not know that? That’s part of the problem!

What Could Be

The Attitudinal imagines a Keychain Access where the main window shows you that information, provided the list is an item of one (and uses standard ellipses or other indications when there is more than one). Instead of showing you just expiration dates, how about “last accessed” dates so you have some idea about whether you need the 70 items named either “iMessage Signing Key” or “iMessage Decryption Key” in your keychain? (Do not ask the Attitudinal; it has no clue.)

Applying the same standards to certificates would be an excellent first step. Ask programs to attach their own information to certificate objects in Security framework, so Keychain Access can tell you if a certificate belongs to the system, or to Adobe Creative Cloud, or to a program you stopped using years ago. Maybe Installer packages could install certificates directly, and Keychain Access could search the receipts to warn you if you try to delete one that was installed that way.

Alas, there is no easy solution to the certificate display interface. It will require expert and challenging designs to show users the information in their certificates and not just the data. The Attitudinal can imagine certain easy additions, though. You can see key algorithms like “Elliptic Curve Public Key,” but Apple could tell us if it knows those algorithms are outdated or compromised. Most certificates have both SHA-256 and SHA-1 fingerprints because older software requires the earlier, now-insecure hashing algorithm. Why can’t the system warn us if a certificate only has SHA-1?

Each certificate already contains information on its originating certificate authority and policies, as defined in the X.509 standard and its standard extensions. The Attitudinal is no PKI expert, but believes that either by X.509 extensions or by extra information provided to the Security framework, macOS could and should ask those installing certificates to indicate who they are (like “1Password.app”), what the certificate does, and a URI with plain HTML data (no animations, please!) providing more information. Combine all this with a “last accessed” date and looking at a certificate in Keychain Access might not be a waste of time.

It would, however, still show you a lot of hexadecimal data and standard extension fields that mean nothing to most users. The Attitudinal would forfend—forfend!—hiding these fields just because they’re hard to understand, and applauds Apple for not having done so. Because some of these fields are extensions, the system cannot always know what the values in those fields mean. Apple could, though, encourage certificate authorities to provide URI fields that define those extensions if they are not part of the standard. Most of the URIs in certificates today link to other certificate-related binary files; it’s about time that some of them linked to information to help users as well as system admins.

Need to know

You can’t know what to do with certificates unless you understand why they’re present, who installed them, and the purpose for which they’re used. Someone or some company with influence and big feet needs to take the lead in making sure every certificate installation meets all of these requirements. Apple could do so at the same time it provided certificate management tools to everyone in iOS, giving a developer base (one much more significant than macOS) reason to start thinking about and implementing changes like these. You deserve enough information to understand security on your own devices.

Which brings your Attitudinal to…

Publisher’s Note: We customarily run the Attitudinal’s drafts through filters that remove politics, profanity, and references to the personal proclivities of named individuals. After doing that to the next part of the Attitudinal’s report—on the Developer ID system—we were left with 17 sentence fragments, 14 of which contained the words “lazy” and “sucks” with no subject. We have ordered a revision that we intend to publish tomorrow, availability of chicken sandwiches permitting.