Looks like I wasn't using the right SHA1 for my cert when calling codesign. I figured I could get the cert information by using security export-smartcard -i [card] | grep sha1 sha1 : <dc 5f 8d 16 0f cd 03 42 ae 06 1d 70 71 6e 11 4b d4 38 d6 68> After a bit of string manipulation: DC5F8D160FCD0342AE061D70716E114BD438D668 Now when I'm calling codesign -s "DC5F8D160FCD0342AE061D70716E114BD438D668" -f foobar I can see the sign method of my TKTokenSession being called. tl;dr: New identity doesn't show up in Keychain, but it doesn't mean the OS can't use it. However you need to make sure you're using the right SHA1.

Yes all good, sorry for the noise!

Unfortunately, I’ve already tried similar approaches. Even when explicitly setting a minimum macOS version of 15.0 in the distribution file, productsign still insists on using SHA1: <allowed-os-versions> <os-version min="15.0"/> </allowed-os-versions> So far, this hasn’t had any effect on the digest algorithm used during signing.

@DTS Engineer So far, I haven’t been able to get productsign to work with anything other than algid:sign:RSA:digest-PKCS1v15:SHA1. Is there any way we could get a definitive confirmation on whether alternative algorithms are supported or not? This would help us decide where to focus our efforts — either on the macOS side, or on working with our provider to temporarily support SHA1 (which they’ve deprecated for security reasons).

Thanks for the clear answer — I really appreciate it. In the meantime, I’ll follow up with our provider (AWS KMS) to see if using SHA1 is still possible today. Also, as requested, here’s the bug report I submitted regarding this issue: FB17682555.

@DTS Engineer Quick question — is the verification logic already able to verify .pkg files signed with SHA256? If not, that would mean even if Apple updates productsign to stop using NIST-disallowed algorithms, we still wouldn't be able to ship those .pkg files to users who haven't received the corresponding verification update. Curious to hear your thoughts on this.