fix(windows): associate machine-scoped TPM keys with stored certificates

[darkfronza]

Summary

On Windows, certificates stored for machine-scoped TPM (Microsoft Platform Crypto Provider) keys were left without an associated private key, making them unusable (e.g. for Wi-Fi/EAP-TLS, VPN). This was surfaced by the step-agent's windows-key-scope work, which moves the agent's AK — and therefore its attested endpoint keys — to the local machine keyset.

Root cause

The certificate→key association ran exclusively through CryptFindCertificateKeyProvInfo (discovery), which fails here for two compounding reasons:

1. It is skipped. kms/platform's transformToTPMKMS sets skip-find-certificate-key=true on Windows by default, so discovery never runs for these certificates.
2. It cannot find the key anyway. CryptFindCertificateKeyProvInfo does not search the local machine keyset, so it cannot discover a machine-scoped PCP/TPM key even when asked.

Keeping endpoint keys user-scoped isn't an option: tpm.AttestKey requires an attested key to share its AK's scope (an attest-session constraint), and the AK is machine-scoped.

Fix — associate explicitly instead of by discovery

• tpmkms hands the CAPI layer the exact key when storing to the Windows certificate store: its CNG container name (tpm.ApplicationKeyName, the app--prefixed key name used to persist the key), the TPM provider, and whether the key lives in the local machine keyset.
• capi sets CERT_KEY_PROV_INFO_PROP_ID directly via setCertificateKeyProvInfo when a container name is supplied. This needs no container enumeration, so it never prompts for a smart card and runs even when skip-find-certificate-key is set; it marks the prov info with CRYPT_MACHINE_KEYSET for machine-scoped keys.
• The CRYPT_KEY_PROV_INFO struct is corrected to pointer/DWORD fields so it can be used to set the property (it was int-typed and effectively read-only).
• The discovery fallback (used when no key is named) now searches both the user and machine keysets for machine-location certificates.
• tpm.ApplicationKeyName is exported as the single source of truth for the persisted application-key name, shared with tpmkms.

Testing

• GOOS=windows go build ./kms/... ./tpm/... and host go build both clean; go vet shows only a pre-existing unsafe.Pointer line; tpm name tests pass.
• Verified end-to-end on a Windows host with a TPM: a freshly-issued hardware-attested endpoint certificate now has its private key linked in LocalMachine\My (previously orphaned).

🤖 Generated with Claude Code

[maraino]

I would try to avoid the new parameter, we know using tpmkms parameter what would be the value of the key-machine-keyset, let's use the same logic, adding the already existing key-scope if needed.

I also have some comments about Microsoft naming.

[darkfronza]

Thanks for the review. Pushed b0e2839 addressing the feedback:

• Dropped the new key-machine-keyset parameter; tpmkms forwards the existing key-scope and capi resolves the keyset itself (same logic as tpmkms.isMachineKey(), falling back to store-location).
• Discovery fallback now restricts to the matching keyset by scope instead of setting both flags.
• Renamed the uriAttributes.containerName field to keyContainerName.
• Removed the runtime.KeepAlive calls in setCertificateKeyProvInfo.

One thing worth a look: the discovery fallback now restricts to the scope's keyset both ways (machine→machine, user→user), whereas before it searched both. It's more precise and matches the "a machine cert shouldn't probe the user container" point, but it's a subtle behavior change for the general (non-tpmkms) StoreCertificate discovery path. Since the tpmkms path now uses explicit association and rarely hits discovery, the risk is low — happy to revert just that part to the both-keysets default if you'd prefer.

The fix is verified working end-to-end on a Windows TPM host (attested endpoint cert now has its private key linked in LocalMachine\My).

[maraino]

Looks good, but I think we might leave keysetFlags as 0 by default if u.isMachineKeySet() is false. See comment.

[maraino]

It can be ok, but I'm not sure if it will be better to use both by default, I think leaving the keysetFlags to 0 will do it.

[maraino]

For reference see https://learn.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-cryptfindcertificatekeyprovinfo

[darkfronza]

Updated on 25d69a9

[maraino]

lgtm

[darkfronza]

Pushed 25d69a9 to make the key-discovery fallback backward-compatible.

Context: CryptFindCertificateKeyProvInfo searches both the user and machine key containers when no keyset flag is passed — that's its documented default ("The default is to search both the user and machine containers") and what this library did before the PR. My earlier revision defaulted the discovery path to CRYPT_FIND_USER_KEYSET_FLAG, which narrowed that to user-only — a behavior change for existing callers that don't specify a key scope.

Change: the discovery fallback now defaults to 0 (both containers) and only restricts when the key scope is actually known:

var keysetFlags uint32 // 0 = search both containers (CryptFindCertificateKeyProvInfo default)
switch {
case u.isUserKeyset():    // explicit key-scope=user
    keysetFlags = CRYPT_FIND_USER_KEYSET_FLAG
case u.isMachineKeyset(): // key-scope=machine, or store-location=machine fallback
    keysetFlags = CRYPT_FIND_MACHINE_KEYSET_FLAG
}

Behavior:

key-scope	store-location	search	vs. pre-PR
(unset)	user (default)	both	preserved
(unset)	machine	machine	narrowed (intended)
user	any	user	narrowed
machine	any	machine	narrowed

So the common legacy case (no key-scope, default store) keeps the both-containers search, and we only narrow on an explicit signal.

One deliberate asymmetry: the new isUserKeyset() checks only explicit key-scope, while isMachineKeyset() keeps its store-location=machine fallback. That's intentional — adding a user-side fallback would make the defaulted store-location=user over-restrict to user-only and defeat the back-compat goal. The only edge it doesn't cover is an (exotic) machine-store cert whose key is in the user keyset, discovered without a container name; the explicit-association path — which the agent always takes — is unaffected.

For background, this is consistent with the canonical Windows behavior: a certificate's store location and its private key's keyset are independent axes (the link is the cert's CERT_KEY_PROV_INFO_PROP_ID / CRYPT_KEY_PROV_INFO, which has no store field), so it's correct to leave the keyset unspecified — and let discovery search both — unless the caller tells us the scope.