Turn off TLS 1.2 temporarily to fix a regression in

Pass CRYPT_ACQUIRE_PREFER_NCRYPT_KEY_FLAG instead of
CRYPT_ACQUIRE_ALLOW_NCRYPT_KEY_FLAG to
CryptAcquireCertificatePrivateKey to fix a regression in
client authentication if TLS 1.2 is negotiated.

If a client private key is stored in a CAPI provider of
the PROV_RSA_FULL provider type, it cannot sign SHA-256
hashes. Using the private key through CNG solves this
problem.

R=rsleevi@chromium.org
BUG=246043
TEST=See bug 246043

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=203798

[Ryan Sleevi, 2013-06-03 23:48:51]

LGTM.

Per our F2F conversion, the relevant flag to look at is
CRYPT_ACQUIRE_PREFER_NCRYPT_KEY_FLAG

My order of preference would be to prefer NCrypt keys - for which the Microsoft
KSP fully supports legacy CAPI CSP keys - over changing out
CryptAcquireCertificatePrivateKey to be our own implementation that tries to
mirror it.

[wtc, 2013-06-04 00:00:26]

rsleevi: thanks a lot for the suggestion. Please review patch
set 2.

[Ryan Sleevi, 2013-06-04 00:06:59]

I can't remember if prefer implies allow or if you need to pass both. You
may wish to double check...
On Jun 3, 2013 5:00 PM, <wtc@chromium.org> wrote:

> rsleevi: thanks a lot for the suggestion. Please review patch
> set 2.
>
>
https://codereview.chromium.**org/16335021/<https://codereview.chromium.org/1...
>

[wtc, 2013-06-04 00:09:39]

"Prefer" tries CNG and CAPI in the opposite order to "allow".
(Under some circumstances "prefer" is silently changed to
"allow".) So it is not necessary to specify both flags.

[Ryan Sleevi, 2013-06-04 00:11:42]

Lgtm
On Jun 3, 2013 5:09 PM, <wtc@chromium.org> wrote:

> "Prefer" tries CNG and CAPI in the opposite order to "allow".
> (Under some circumstances "prefer" is silently changed to
> "allow".) So it is not necessary to specify both flags.
>
>
https://codereview.chromium.**org/16335021/<https://codereview.chromium.org/1...
>

[wtc, 2013-06-04 00:24:49]

Committed patchset #2 manually as r203798 (presubmit successful).