[Mac] allow revocation checking for all certificates |
||
Issue descriptionCurrently certificate revocation on Mac is being checked with flag CSSM_TP_ACTION_REQUIRE_REV_PER_CERT set. This flag requires positive confirmation of cert's revocation status either by CRL or OCSP, even if neither is configured in the cert. While Chrome only performs revocation checks for EV certificates (and for these revocation info is required, so it might be intended to fail if it is not there), it would be useful to provide a way to check revocation for *all* certificates. There is a patch available (https://chromium-review.googlesource.com/c/chromium/src/+/808966) which removes CSSM_TP_ACTION_REQUIRE_REV_PER_CERT and replaces it with REQUIRE_CRL_IF_PRESENT and OCSP_REQUIRE_IF_RESP_PRESENT, these will cause failure only if the certificate has CrlDistributionPoints (for CRL) or AuthorityInfoAccess extension (for OCSP). This will, however, make the revocation check pass also for EV certificates w/o revocation info. One idea might be to provide a flag (in cert_verifier.h) which will change the behavior depending on external preference. Another idea includes keeping CSSM_TP_ACTION_REQUIRE_REV_PER_CERT for EV certs and changing it to _IF_PRESENT version for non-EV. What do you think?
,
Dec 7 2017
The behavior of fail-if-no-revocation-info seems to be Mac-specific, there is no such problem on Windows or Linux. All revocation errors are soft-fails, only the security is downgraded (please correct me if I am wrong). Can you point me to some review introducing this new verifier? Thanks!
,
Dec 7 2017
http://opensource.apple.com - they rewrote it and no longer use the CDSA interfaces for path building or configuration - all of those APIs are deprecated. A shim layer exists to take some of the CDSA options to configure the behaviour, but distinct OCSP and CRL configuration has been folded into a single configuration.
,
Dec 11 2017
Thanks, that is useful. Do you know when Chromium is going to switch to this new non-deprecated API? If the switch is going to happen soon I think there is no point in introducing changes proposed here.
,
Dec 11 2017
I think there's some confusion. Internally, macOS now translates the deprecated API (CDSA/CSSM) calls into the current API (trustd), and similarly translates results back from the current API into the deprecated results. The current API does not offer that flexibility, and so there's not a 1:1 translation. You can see this yourself at https://opensource.apple.com. In short, adding new calls using the deprecated APIs - such as you propose - won't work and/or should not be expected to work. You'd need to examine if the present API supports your case. In this case, examine the Security.framework calls for the non-deprecated aspects - but anything involving CDSA or CSSM is deprecated and, more often than not, not likely to converge. Writing unit tests for this and running on 10.11+ should also show this.
,
Jan 2 2018
Sorry for the delay. Thanks for clarification. I guess we can drop the FR.
,
Jan 2 2018
|
||
►
Sign in to add a comment |
||
Comment 1 by rsleevi@chromium.org
, Dec 6 2017