Shibboleth Common - Java
  1. Shibboleth Common - Java
  2. SC-136

Add support for controlling the PKIXParameters "RevocationEnabled" flag through the IdP's TrustEngine configuration

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.3.0
    • Fix Version/s: 1.3.0
    • Component/s: Configuration
    • Labels:
      None

      Description

      This is a "sub"-issue of SIDPT-1, which I'm spinning of into an own item, so that it can hopefully be considered for inclusion in the 2.3 release of the IdP.

      Currently, there's no way to control the RevocationEnabled flag of the PKIXParameters when a trust engine is built by the IdP. Quoting http://download.oracle.com/javase/1.4.2/docs/api/java/security/cert/PKIXParameters.html#setRevocationEnabled%28boolean%29

      "Sets the RevocationEnabled flag. If this flag is true, the default revocation checking mechanism of the underlying PKIX service provider will be used. If this flag is false, the default revocation checking mechanism will be disabled (not used)."

      For the 2.3 release, it would be useful to have an additional attribute for the <security:TrustEngine> element which allows the IdP admin to control the value of that flag. I realize that this can't be used to configure the underlying PKIX provider in a way suggested in SIDPT-1, but for the time being, I would consider it sufficient to add support for a "revocationEnabled" attribute (boolean, with "true" and "false" as its values) to the edu.internet2.middleware.shibboleth.common.config.security.AbstractPKIXValidationInformationBeanDefinitionParser, which in turn would call the respective methods of org.opensaml.xml.security.x509.CertPathPKIXValidationOptions (as implemented with JXT-40)... or whatever is needed to push that flag to the PKIX provider, in the end.

      PKIX provider options are often configurable through system properties (e.g. "com.sun.security.enableCRLDP", "onlyCheckRevocationOfEECert"), which is fine - but as far as I'm aware of, there's no straightforward way right now to control the revocationEnabled flag with the IdP configuration. This is what this issue is about.

        Activity

        Kaspar Brand created issue -
        Hide
        Brent Putman added a comment -
        Well, what you are asking for is pretty much the entirety of what SIDPT-1 is about. It is solely about the config tooling necessary to wire the PKIXValidationOptions (really the CertPathPKIXValidationOptions) into the trust engine. It is not about anything else. And the reason for all of that option is precisely what you have outlined: to get the trust engine to allow the Java Security provider specific options (system properties, etc) to be used.

        I'm not the arbiter of scheduling work, but if it's decided that we should do anything along these lines for v2, we should just move SIDPT-1 back to v2, where it was originally, and just do the whole bean parser and related config tooling, not just this one flag. The delta between the 2 is insignificant.
        Show
        Brent Putman added a comment - Well, what you are asking for is pretty much the entirety of what SIDPT-1 is about. It is solely about the config tooling necessary to wire the PKIXValidationOptions (really the CertPathPKIXValidationOptions) into the trust engine. It is not about anything else. And the reason for all of that option is precisely what you have outlined: to get the trust engine to allow the Java Security provider specific options (system properties, etc) to be used. I'm not the arbiter of scheduling work, but if it's decided that we should do anything along these lines for v2, we should just move SIDPT-1 back to v2, where it was originally, and just do the whole bean parser and related config tooling, not just this one flag. The delta between the 2 is insignificant.
        Hide
        Brent Putman added a comment -
        This has been added in r964.

        It's not just the revocationEnabled property, but all the PKIX options exposed by CertPathPKIXValidationOptions class.

        The PKIX trust engine elements in relying-party.xml now take a PKIXValidationOptions element, with a possible subtype specialization of xsi:type="CertPathPKIXValidationOptionsType" that exposes all the config options as attributes.
        Show
        Brent Putman added a comment - This has been added in r964. It's not just the revocationEnabled property, but all the PKIX options exposed by CertPathPKIXValidationOptions class. The PKIX trust engine elements in relying-party.xml now take a PKIXValidationOptions element, with a possible subtype specialization of xsi:type="CertPathPKIXValidationOptionsType" that exposes all the config options as attributes.
        Brent Putman made changes -
        Field Original Value New Value
        Status Open [ 1 ] Closed [ 6 ]
        Assignee Chad La Joie [ lajoie@georgetown.edu ] Brent Putman [ putmanb ]
        Fix Version/s 1.3.0 [ 10389 ]
        Resolution Fixed [ 1 ]

          People

          • Assignee:
            Brent Putman
            Reporter:
            Kaspar Brand
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: