Open Radar

 
When invoking SecTrustEvaluate, the internal implementation of securityd tracks a variety of errors, which surfaces these details ultimately through to SecTrustCopyProperties(), via the kSecPropertyTypeError property.

While one can see the error strings provided ( https://opensource.apple.com/source/Security/Security-55178.0.1/sec/Security/SecTrust.c ), these are localized and do not represent a stable API.

As a result of this, applications are left with only a very coarse understanding of why certificate validation failed. For applications such as Chrome, which want to understand the nature and cause of errors as part of better understanding and enhancing the Web PKI (such as Adrienne Porter Felt's "Where the wild warnings are" - https://docs.google.com/presentation/d/1Qmpl-5epx0B5C2t4XsUTyjgbwab_rXfK_4iHqX3IC30/pub?start=false&loop=false&delayms=3000&slide=id.gf44795496_0_1 ), this information is not available.

Steps to Reproduce:
1. Use SecTrustEvaluate to defer validation to the OS
2. Attempt to use a stable, reliable API contract to determine why SecTrustEvaluate failed

Expected Results:
Expected: Some insight into the details. While it's unreasonable to expect iOS to provide a populated CSSM_TP_APPLE_EVIDENCE_INFO as OS X does for the SecTrust, something that has the same or similar level of detail would be available.

Actual Results:
Actual: No insight into the failure. Even things like date-based validity failures are opaque, leading to technotes such as https://developer.apple.com/library/ios/technotes/tn2232/_index.html 


Version:
9.3.1 (13E238)

Notes:
On OS X, one can (still) use the CSSM_TP_APPLE_EVIDENCE_INFO to obtain significant information to explain the failure. Unfortunately, iOS has not caught up here.

Configuration:
iPhone 6s