be.fgov.ehealth.etee.crypto.decrypt

## Class DataUnsealerBuilder

- java.lang.Object
- - be.fgov.ehealth.etee.crypto.decrypt.DataUnsealerBuilder

-     public final class DataUnsealerBuilder
      extends java.lang.Object

  This builder will create and configure an instance of `DataUnsealer`. When building `DataUnsealer` you will be guided in small and easy steps:

  1. First step: Choose an OCSP-policy. This policy determines if it's required to do an OCSP-check on the certificate when sealing a message. During this step you can also configure how the OCSP-check will be done by providing a map with OCSPOptions.

  These options will default to the following options:

  - `OCSPOption.OCSP_URI` - Defaults to the URL to be found in the certificate.
  - `OCSPOption.TRUST_STORE` - Defaults to given trust store for unsealing messages.
  - `OCSPOption.INJECT_RESPONSE` - Defaults to false
  - `OCSPOption.CLOCK_SKEW` - Defaults to 300000 (5 minutes in milliseconds)
  - `OCSPOption.CONNECTION_TIMEOUT` - Defaults to 3000 (3 seconds in milliseconds)
  - `OCSPOption.READ_TIMEOUT` - Defaults to 3000 (3 seconds in milliseconds)
  - `OCSPOption.CONNECTION_USER_INTERACTION` - Defaults to true
  See `OCSPOption` for more details on the options.

  More information on the OCSPOptions can be found on the documentation of `OCSPOption`.

  2. Second step: Choose the signing policies that you want to accept. You will also need to provide a `KeyStore` with certificate that you trust. You can pass some `SigningOption` as well. See `SigningPolicy` for available policies.

  These options will default to the following options:

  - `SigningOption.CLOCK_SKEW` - Defaults to 300000 (5 minutes in milliseconds)
  - `SigningOption.TSA_TRUST_STORE` - Defaults to given trust store for unsealing messages.
  - `SigningOption.SIGNING_TIME_TRUST_IMPLICIT` - Defaults to false
  - `SigningOption.SIGNING_TIME_EXPIRATION` - Defaults to 5 minutes
  - `SigningOption.NON_REPUDIATION` - Defaults to False (by default we are lax. In a lot of use cases there is no need for non repudiation in a legal setting). If set to true `NotificationError.INNER_CERTIFICATE_HAS_INVALID_KEYUSAGE` will be added to the result in case a certificate was used that has no such KeyUsage. If set to false, also 'digitalSignature' will be accepted as KeyUsage. Only set this to 'true' for use cases that require non repudiation in a legal setting.
  See `SigningOption` for more details on the options.

  3. Third step: Choose a public key `EncryptionPolicy`. You will have to provide a list of encryption credentials to be able to decrypt messages.
  To find the correct key to decrypt, the DataUnsealer will extract the 'RecipientIdentifier' from the KeyTransRecipientInfo block of the sealed data and try to match it with the identifier of the given encryption credential(s). If a match is found, the private key of that given encryption credential will be used to decrypt the message.
  There are 2 options for a match:

  - Messages encrypted with an X509Certificate of the receiver: The RecipientIdentifier will contain the issuer and serialnumber of the certificate. In this case, at least an `EncryptionCredential` with a keyId matching the serialnumber of the Certificate must be passed to this builder, together with the matching private key.
  - Messages encrypted with a registered PublicKey of the receiver: The RecipientIdentifier will contain the subjectKeyIdentifier (i.e. identifier used by a subject to register his key in a repository) of the receiver's key. In this case, at least an EncryptionCredential with a keyId matching the subjectKeyIdentifier of the PublicKey must be passed to this builder, together with the matching private key.
  To support multiple active keys or key roll-over for a receiver of messages, multiple EncryptionCredentials can be passed to this builder. If all keys are managed in one keystore, you can use `KeyManager` to extract all credentials from the keystore (the alias should be the keyId) and pass them to this builder using `EncryptionCredentials`.

  4. Fourth step: Choose a secret key `EncryptionPolicy`.

  5. The build step: The final step, this step will create and configure your `DataUnsealer`

  Notes: This builder will make sure that your security configuration is set up properly, view `SecurityConfiguration` for more information.

- - ### Nested Class Summary

    Nested Classes
    Modifier and Type | Class and Description
    --- | ---
    `static interface` | `DataUnsealerBuilder.BuildStep` Build the `DataUnsealer`
    `static interface` | `DataUnsealerBuilder.OCSPPolicyStep` First step: Choose an OCSP-policy.
    `static interface` | `DataUnsealerBuilder.PublicKeyPolicyStep` Third step: Choose a public key `EncryptionPolicy`.
    `static interface` | `DataUnsealerBuilder.SecretKeyPolicyStep` Fourth step: Choose a secret key `EncryptionPolicy`.
    `static interface` | `DataUnsealerBuilder.SigningPolicyStep` Second step: Choose the signing policies that you want to accept.

  - ### Method Summary

    All Methods Static Methods Concrete Methods
    Modifier and Type | Method and Description
    --- | ---
    `static DataUnsealerBuilder.OCSPPolicyStep` | `newBuilder()` You will be guided in the steps to create a `DataUnsealer`.

    - ### Methods inherited from class java.lang.Object

      `equals, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait`

- - ### Method Detail

    - #### newBuilder

          public static DataUnsealerBuilder.OCSPPolicyStep newBuilder()

      You will be guided in the steps to create a `DataUnsealer`.
      Returns:
        the next step.

Copyright © 2025 eHealth. All rights reserved.