Revocation-status source for Apple Code Signing Certification Authority (serial 0x21)

What’s your high-level goal here?

The Apple PKI page has links to various CA policy docs, but those are only part of the picture. Apple operating systems have various other mechanisms to prevent code from running, so you’re unlikely to get a meaningful signal via the certificate revocation path.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thank you, Quinn. Our high-level goal is to establish a supported, auditable verification procedure for an unmodified Apple-supplied Command Line Tools Python executable used by local development tooling. We want to distinguish code-signature integrity and Apple origin, the result of the relevant macOS trust or execution-policy assessment, and any independently available certificate-revocation evidence. We are not trying to replace macOS trust evaluation with a standalone CRL check, bypass an operating-system decision, change trust settings, or re-sign Apple binaries. For this first-party Apple command-line executable, which supported verification procedure and retained diagnostic evidence would you recommend? What does that evidence establish, and what should we avoid inferring from it? Our narrower certificate question remains whether Apple publishes current revocation-status evidence covering this exact legacy intermediate, or documents that such evidence is not publicly available. We would keep that limitation separate from the operating system’s assessment.

So you’re specifically concerned with the copy of Python installed by the Command Line Tools package? That is, the Command Line Tools package that folks download from our Developer > Downloads > More Downloads page?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Yes — exactly. I’m referring specifically to the copy of Python installed by Apple’s standalone Command Line Tools package obtained from Developer > Downloads > More Downloads. In particular, I mean the unmodified Apple-delivered Python framework/executable under /Library/Developer/CommandLineTools/..., not the Python copy inside Xcode.app, not a macOS system Python, and not a Homebrew or other third-party installation. My goal is to have a supported, auditable procedure for that specific Apple-delivered executable that distinguishes:

1. code-signature integrity and origin;
2. whether macOS currently accepts it under the system’s trust/execution policy; and
3. if independent revocation evidence for its signing chain is required, what Apple-supported source or procedure should be used for that evidence.

I’m not trying to replace macOS trust evaluation, modify trust settings, bypass execution policy, or re-sign the binary. Thanks for narrowing the scope.

Thanks for the clarification. I’m pretty sure I have answers for at least some of your questions, but I want to ask one more question before that…

You want to run this check on the Mac, right? That is, you want to run code on a specific Mac that checks that the /Library/Developer/CommandLineTools stuff installed on that Mac is valid?

I’m asking because such a check can take advantage of macOS machinery that’s not available, say, if you were trying to run the check on some Linux server.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Yes — exactly. The check would run locally on the specific Mac whose standalone Command Line Tools installation we want to validate. In particular, we want to inspect the Apple-delivered Python under /Library/Developer/CommandLineTools/... as installed on that Mac. The check can absolutely take advantage of macOS system frameworks, trust services, code-signing APIs, or other Apple-supported local machinery available on that Mac. We do not need the procedure to be portable to Linux or to work as an offline remote verifier. Our preference is for a non-destructive, auditable procedure that does not modify trust settings, bypass execution policy, or re-sign anything. If macOS already provides a supported way to determine that the installed CLT Python is valid and currently accepted under the system’s code-signing/trust policy, that is exactly the procedure we are looking for.

OK, so there are three parts to this:

• Is the code signature valid?
• Is it code you think it is? That is, checking the code’s identity.
• Would macOS let it run? That is, will it pass Gatekeeper?

Check that the code signature is valid is pretty straightforward application of the codesign tool (with the --verify option) or the SecCode API. Alternatively, you can do the same thing with the SecCode API.

Checking the code’s identity requires some policy choices on your part. Consider this:

% codesign -d -vvv Python3.framework                           
…
Identifier=com.apple.python3
…
CDHash=7ba32e264b885ea828d2175063de50fb97732acd
…
Authority=Software Signing
Authority=Apple Code Signing Certification Authority
Authority=Apple Root CA
…
TeamIdentifier=59GAB85EFG
…

There are various strategies you can apply:

• You can check for a specific instance of the code. You usually do that with a cdhash value. TN3126 Inside Code Signing: Hashes explains that concept in more detail.
• You can check the Team ID and code signing identity. This is the classic way you might check the identity of third-party code. In this case Team ID 59GAB85EFG is associated with Apple’s developer tools and the code signing identity is com.apple.python3.
• You can capture its designated requirement (DR) as part of your development process, and then check that DR at runtime.
• You can check a specific certificate.

None of these are right per se. It’s kinda up to you.

All of these can be expressed in code signing requirements, as explained in TN3127 Inside Code Signing: Requirements. For example, here’s how you check a cdhash

% codesign -v -vvv -R '=cdhash = H"7ba32e264b885ea828d2175063de50fb97732acd"' Python3.framework
Python3.framework: valid on disk
Python3.framework: satisfies its Designated Requirement
Python3.framework: explicit requirement satisfied

and here’s how you’d get the DR:

% codesign -d -r - Python3.framework 
Executable=/Users/quinn/Desktop/CLTs/Python3.framework/Versions/Current/Python3
designated => identifier "com.apple.python3" and anchor apple

and how you might check it later on:

% codesign -v -vvv -R '=identifier "com.apple.python3" and anchor apple' Python3.framework
Python3.framework: valid on disk
Python3.framework: satisfies its Designated Requirement
Python3.framework: explicit requirement satisfied

And such requirements can also be checked by the SecCode API.

I suspect that the DR is the best option because that’s how Apple has chosen to identify this code. The other option that’s attractive well is to check for a specific cdhash. It a hassle, because you have to update your allowlist every time Apple releases new tools, but it’s really strict.

Finally, there’s the question of whether the code will pass Gatekeeper. My favourite option for this is gktool:

% gktool scan Python3.framework 
Progress: 41132032/41132032
Scan completed, and would be allowed but the user still needs to approve it on first launch.

No muss, no fuss!

However, the drawback to this approach is that the output in very much intended for humans. AFAICT there’s no way to get a machine-readable version.

On alternative is spctl. For the details, see the second half of Testing a Notarised Product. However, I’ve found spctl to be a challenging tool to work with, for various reasons.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thanks, Quinn. We followed your advice for Apple CLT Python3.framework. Both codesign --verify --strict --deep and an explicit requirement (identifier "com.apple.python3" and anchor apple) passed outside our restricted sandbox. gktool scan reported: "Scan completed and software is allowed by system policy." The earlier CSSMERR_TP_NOT_TRUSTED remains unexplained, not evidence of a bad signature. Your guidance was very helpful.