Details
-
Enhancement
-
Resolution: Fixed
-
P3
-
8
-
b102
-
Verified
Description
JEP 124 introduced a new PKIXRevocationChecker class that allows a developer to have more control over revocation configuration.
While implementing the feature to enable revocation checking for WebStart and Plugin for 7u25, I discovered there were a couple of important features that were missing and should be added:
1. There was no way to indicate that you only wanted OCSP or CRLs to be used to check revocation status. OCSP has some privacy concerns, so we should allow an option to choose one or the other. An option to disable the fallback mechanism (NO_FALLBACK) would be sufficient. If set on its own, only OCSP would be tried, and if set in conjunction with the PREFER_CRLS option, only CRLs would be tried.
2. The SOFT_FAIL option is somewhat vague. The description needs to be more detailed as to what network errors are ignored, and how it is applies when both OCSP and CRLs are tried.
3. When revocation checking passes, sometimes you want to return additional information to the user. For example, if the SOFT_FAIL option is enabled, you may want to know if the revocation check passed because the revocation server was unreachable or failed because of some network issue so that you can display these as warnings to the user. Currently, it is not possible to distinguish that. A method will be added to return this information.
While implementing the feature to enable revocation checking for WebStart and Plugin for 7u25, I discovered there were a couple of important features that were missing and should be added:
1. There was no way to indicate that you only wanted OCSP or CRLs to be used to check revocation status. OCSP has some privacy concerns, so we should allow an option to choose one or the other. An option to disable the fallback mechanism (NO_FALLBACK) would be sufficient. If set on its own, only OCSP would be tried, and if set in conjunction with the PREFER_CRLS option, only CRLs would be tried.
2. The SOFT_FAIL option is somewhat vague. The description needs to be more detailed as to what network errors are ignored, and how it is applies when both OCSP and CRLs are tried.
3. When revocation checking passes, sometimes you want to return additional information to the user. For example, if the SOFT_FAIL option is enabled, you may want to know if the revocation check passed because the revocation server was unreachable or failed because of some network issue so that you can display these as warnings to the user. Currently, it is not possible to distinguish that. A method will be added to return this information.
Attachments
Issue Links
- relates to
-
JDK-8023362 Don't allow soft-fail behavior if OCSP responder returns "unauthorized"
- Closed