Open Radar

 
This is a duplicate of rdar://28981392

Summary:
When importing a private key into a keychain applications that were explicitly whitelisted with the "-T" flag require additional authorization to use the imported key.

Steps to Reproduce:
1. Use `/usr/bin/security import key.p12 -T "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" -k ~/Library/Keychains/login.keychain` to import a private key into the user's keychain, using the documented "-T" flag to allow Google Chrome to use the private key without further authorization
2. Also import the matching certificate into the user's keychain, forming a valid identity
3. Confirm that the identity is present in the user's keychain using Keychain Access.app and is valid
4. Launch Google Chrome and navigate to a URL requiring the just imported client identity (cert + private key in Keychain)

Expected Results:
Google Chrome should use the client certificate and private key without further authorization requirements.

Actual Results:
Google Chrome (via SecurityAgent) asks whether the user wants to Allow, Always Allow or Deny accessing the private key from the identity in the user's keychain.

Regression:
This issue does not exist prior to macOS 10.12 Sierra and in testing has been verified to not occur on either OS X 10.11 or 10.10.

Notes:
It has been determined that by running security with the "set-key-partition-list" verb which appears to be new in macOS 10.12 like so: `security set-key-partition-list -l "Imported Private Key" -S teamid:EQHXZ8M8AV -s ~/Library/Keychains/login.keychain` a "second layer" ACL can be applied to whitelist all of Google Inc.'s applications via its Team ID (EQHXZ8M8AV). This requirement is not documented anywhere and is complicated by the fact that the "set-key-partition-list" verb requires the user's password either interactively or as part of the command line invocation. This requirement makes the verb impossible to automate without compromising security by supplying a plaintext password as part of the automation.