OCSP certificate revocation
New class X509RevocationTrustManager
Configurable certificate revocation using OCSP. This will be implemented using PKIXRevocationChecker.
Configuration will be done using Builder class and will include:
Current configuration in X509CRLExtendedTrustManager
OCSP Responder URI for overriding default, where the default is retrieved from AIA extension (RFC5280) or from
Default revocation mechanism (OCSP/CRL) in a form of prefer-crls (by default OCSP if preferred)
Fallback behaviour - cases for unavailable CRL / OCSP responder services
Checking of leaf certificates only
Deprecating X509CRLExtendedTrustManager, both mechanisms will share one class for fallback purposes and easier configuration
Current subsystem CRL configuration:
<trust-manager name="trust-with-ocsp-crl" algorithm="PKIX" key-store="ElytronCaTruststore"> <certificate-revocation-list path="crl.pem" maximum-cert-path="2"/> </trust-manager>
Proposed subsystem configuration:
<trust-manager name="trust-with-ocsp-crl" algorithm="PKIX" key-store="ElytronCaTruststore" soft-fail="true" only-leaf-cert="true" maximum-cert-path="2"> <certificate-revocation-list path="crl.pem"/> <ocsp responder="responderUri" prefer-crls="true" responder-certificate="certalias" responder-keystore="responder-store"/> </trust-manager>
New subsystem configuration elements:
soft-failcan pass certificates, where revocation status could not be obtained due to network or internal responder error. This is optional false by default.
only-leaf-certwill check revocation status of only the leaf certificate. This is optional and false by default.
trust-manager, as this can be used by OCSP without CRL configured.
responderthis overrides OCSP Responder URI resolved from certificate.
prefer-crlswhen both OCSP and CRL is configured, OCSP will be executed first by default. When
prefer-crlsis true, CRL will be checked first instead.
responder-keystorealternative keystore for responder certificate.
responder-certificatemust be defined.
responder-certificatealias for responder certificate located int
trust-managerkeystore if responder-keystore is not defined Order of revocation mechanisms (if both are defined) will be based on attribute of
prefer-crls, defaults to false (OCSP prioritized by default).
Other configuration is done using security properties of elytron subsystem, see: https://docs.oracle.com/javase/8/docs/technotes/guides/security/certpath/CertPathProgGuide.html#AppC
Elytron client configuration
Current elytron-client configuration:
<ssl-context name="ssl-crl-context"> <trust-store key-store-name="ca"/> <certificate-revocation-list path="crl.pem" maximum-cert-path=4/> </ssl-context>
Proposed elytron-client configuration:
<ssl-context name="ssl-crl-context"> <trust-store key-store-name="ca"/> <trust-manager algorithm="PKIX" maximum-cert-path=4 soft-fail="true" only-leaf-cert="true"/> <certificate-revocation-list path="crl.pem"/> <ocsp responder="responderUri" prefer-crls="true" responder-certificate="certalias" responder-keystore="responder-store"/> </ssl-context>
Note: This RFE does not officially support OCSP stamping, but as the stamping support released with JDK9 JEP249 is configured using Security and System properties, it will be possible to configure and use it. Issues related to OCSP stamping will likely have another RFE with tests and more documentation.
OCSP tests in Elytron using mock OCSP Responder