25640484: Feature: The ability to provide a caller-supplied callback function during SecTrustEvaluate

[openradar-mirror]

Description

Summary: SecTrustEvaluate, in an application, dispatches to securityd to perform the path building and evaluation under a given policy (e.g. TLS). securityd leverages SecCertificatePath's to explore the certificate graph, attempting to score the most preferable chain along the way. Provided that at least one certificate chain validates, SecTrustEvaluate will return success.

However, applications have no means to extend the policy settings provided to the SecTrustRef. That is, consider the Apple-provided SSL/TLS policy: it will always check for id-kp-serverAuth in the leaf (if EKU is present and requesting TLS server validation) and validate the hostname (if requesting TLS server validation). Unfortunately, it won't check to see if the EKUs are consistent along the certificate path (and non-standard behaviour that Microsoft, Mozilla, and Google have adopted as a security mitigation for reducing the scope of authority of sub-CAs), nor is the application able to influence the selection of intermediates or cross-certificates (for example, if a sub-CA is revoked due to bad acting, or a root CA still trusted by iOS being used for insecure purposes)

Compare this to the NSS (libpkix or mozilla::pkix) APIs. An NSS caller is allowed to supply a chain callback, which, during the path building/evaluation, will be invoked with a 'candidate chain'. The candidate chain is one that complies with all of the policies built in to NSS / requested by the caller using the stable API - but the caller is given an opportunity to reject this. If an application rejects the candidate chain, NSS will continue exploring other nodes within the certificate graph.

Alternatively, compare this with CryptoAPI from Microsoft. While CryptoAPI provides significantly more extensive opportunities (including the ability to permanently extend the set of policies used to validate, and/or override the default Microsoft implementation), perhaps most relevant to this feature request is the ability to install a custom "Revocation Provider", which can make determinations about individual certificates or entire certificate chains. This offers a somewhat more robust API, in that it can prevent unnecessary exploration of the path graph if an intermediate is known to be rejected.

You can see examples of how these APIs are used by applications such as Chrome, which uses them to integrate CRLSets and ensure the appropriate blacklisting of known-revoked intermediates.

CryptoAPI implementation - https://chromium.googlesource.com/chromium/src/+/5332a63125aa1dead5af575d57a63c17013db1a6/net/cert/cert_verify_proc_win.cc#620 ( see https://msdn.microsoft.com/en-us/library/ms995348.aspx for general MSDN documentation on how this implementation works)

NSS implementation - https://chromium.googlesource.com/chromium/src/+/56139459f834b6b4ac3aad37b466d9ae997ff15c/net/cert/cert_verify_proc_nss.cc#355 invoked by https://chromium.googlesource.com/chromium/src/+/56139459f834b6b4ac3aad37b466d9ae997ff15c/net/cert/cert_verify_proc_nss.cc#872

Steps to Reproduce:

1. Attempt to verify a certificate which has multiple paths to possible trust anchors
2. Attempt to revoke one or more of these paths

Expected Results: Expected: Applications can influence path building and the chain returned (provided that the underlying implementation is happy with the path)

Actual Results: Actual: Application has no influence, and can only apply policies on the final path.

Applications can attempt to work around this by doing something heinously gross ( e.g. https://chromium.googlesource.com/chromium/src/+/bedc26167ab5402cf9e4a51afeeeb90ababb9da0/net/cert/cert_verify_proc_mac.cc#566 ), but even that is not a reliable solution.

Version: 9.3.1 (13E238)

Notes: Ideally, a combination of both API approaches would be provided. The Microsoft approach is quite useful for revocation, but unfortunately unsuitable for applying application-level policies (such as the enforcement of EKU constraints). The NSS approach is quite useful for that use case, but unfortunately is invoked significantly more often, because there is no way to surface back to NSS which of the certificates in the candidate chains was unacceptable.

That is, consider a path graph in https://chromium.googlesource.com/chromium/src/+/56139459f834b6b4ac3aad37b466d9ae997ff15c/net/data/ssl/scripts/generate-multi-root-test-chains.sh#7 - if C is revoked (while evaluating the trust path of A->B->C->D), there's no point in exploring (A->B->C->E), and instead, the client should attempt to discover the path of (A->B->F->E)

Configuration: iPhone 6s

Product Version: 9.3.1 Created: 2016-04-09T07:45:27.705430 Originated: 2016-04-09T00:00:00 Open Radar Link: http://www.openradar.me/25640484

[openradar-mirror]

Modified: 2016-04-09T07:45:27.705610

[openradar-mirror]

Modified: 2016-04-09T07:45:27.705610