Page Comparison

...

...

• use-case: Encrypt and decrypt fields in the Identity Manager database

• configured in these applications

  • Identity Manager Admin (previously know as PRIME Designer)

  • Identity Manager Operator (previously known as PRIME Explorer)

• configured in these special-case tools

  • batch_secretfieldstore_change_encryption_key

    (repair tool for secret fields)

  • batch_migration_smartact_to_prime

    (for migration of data from Identity Manager's/PRIME's predecessor SmartAct, it has additional requirements for decrypting secret fields and config entries from the source system)

• included by default in config XML

• placeholder keys forbidden for productive use

  • loss of confidentiality

  • the key can only be changed with the tool batch_secretfieldstore_change_encryption_key once the first secret is stored in the database

• storage: pkcs12, HSM (recommended)

• versioning: not supported, always uses version 1

• supported asymClipher values:

  • for HSM

    • RSA/ECB/OAEPWithSHA-384AndMGF1Padding

    • RSA/ECB/OAEPWithSHA-512AndMGF1Padding

  • for PKCS#12

    • RSA/None/OAEPWithSHA384AndMGF1Padding

    • RSA/None/OAEPWithSHA512AndMGF1Padding

• supported keys:

  • RSA 2048

  • RSA 3072

  • RSA 4096 (recommended)

• certificate requirements:

  • no special requirements, as only the key-pair is used

    • may be self-signed

    • key usage is not checked (recommended for informational purposes: set dataEncipherment)

    • validity is ignored

    • certificate does not need to be trusted

ConfigZipEncrypter

...

• storage: pkcs12, HSM (recommended)

• no versioning, always uses version 1

• placeholder P12 is allowed only if zip encryption is disabled

• supported asymClipher values:

  • for HSM

    • RSA/ECB/OAEPWithSHA-384AndMGF1Padding

    • RSA/ECB/OAEPWithSHA-512AndMGF1Padding

  • for PKCS#12

    • RSA/None/OAEPWithSHA384AndMGF1Padding

    • RSA/None/OAEPWithSHA512AndMGF1Padding

  • NOTE: but you cannot reconfigure the asymCipher after exporting an encrypted ZIP, as config import of such a ZIP will fail!

• key requirements:

  • RSA 2048

  • RSA 3072

  • RSA 4096 (recommended)

• certificate requirements:

  • no special requirements, as only the key-pair is used

    • may be self-signed

    • key usage is not checked (recommended for informational purposes: set dataEncipherment + keyEncipherment )

    • validity is ignored

    • certificate does not need to be trusted

ConfigZipSigner

...

• storage: pkcs12, HSM (recommended)

• placeholder P12 is allowed if zip signing+verification is disabled

• Versioning is possible, but unnecessary. It is sufficient that the certificate that signed the old configs is trusted via the IDM truststore.    

• must NOT be self-signed!

• key usage: digitalSignature MUST be present if KeyUsage is critical (explicit check in our code!, Signer.java)

• issuing CA cert MUST be in IDM truststore

• issues if not configured as above:
  export is blocked unless "zipPacker.signZip=false"
  verification does not work, ZIP appears unsigned

• key type: RSA-2048 and up (4096 recommended), no ECC support!

• digest: SHA-256
        (selecting SHA-38 or SHA-512 only affects MANIFEST.MF, other parts use SHA-256 always)

• validity: at your discretion, but bear in mind... 

  • if expired, export is blocked unless "zipPacker.signZip=false"

  • if expired on upload: "Verification failed. The certificate has expired."

...

• included by default in config XML

• storage: pkcs12, HSM (recommended)

• NEVER placeholder cert!

• tooling needed to fix if initially wrong key

• versioning supported

• key usage: digitalSignature MUST be present if KeyUsage is critical (explicit check in our code and JRE code, Signer.java, Signature.java)

• trust does not matter

• MAY be self-signed

• key type: RSA-2048 and up (4096 recommended), no ECC support!

• digest: SHA-256, SHA-384, SHA-512
  WARNING! changing the digest after history entries have been written requires a new version of the descriptor!
        IDM startup will fail otherwise!

• algorithm cannot be changed after the fact - deployment will break!

• validity: does not matter, still works when expired

SignEmailDescriptor

...

• storage: pkcs12, HSM (recommended)

• placeholder P12 is allowed if email signing is not used

• must NOT be self-signed!

• versioning possible, but unnecessary

• RFC says: proper S/MIME cert with correct sender e-mail configured in subject DN's E field and/or SAN RFC-822
      (if subject DN email field is absent, SAN must be critical),
  however IDM up to 23.10.x only accepts certs with SAN and ignores DN.E (fixed now)

• key usage: if present, must be critical at least either digitalSignature or nonRepudiation (either works with IDM, too)
      cert extensions outlined in
      https://www.rfc-editor.org/rfc/rfc8550#section-4.4

• key type: RSA-2048 and up (4096 recommended) with algo SHA256withRSA  / SHA384withRSA / SHA512withRSA
          or ECC NIST P-256, P-384, P-521 with algo SHA256withECDSA / SHA384withECDSA / SHA512withECDSA
         CAB-Forum specifies key size and curves:https://cabforum.org/working-groups/smime/requirements/#615-key-sizes

• validity: adhering to CAB-Forum requirements:
      https://cabforum.org/working-groups/smime/requirements/#632-certificate-operational-periods-and-key-pair-usage-periods
      (825 days max at the time of writing)

...

• no security relevance (a dummy certificate is used as transport container for the key-usage instead of putting it into e.g. a JSON field)

• trust does not matter

• versioning not needed (always uses the default (i.e. highest) version)

• no extensions (recommended to add KU digitalSignature for informative reasons)

• MAY be self-signed

• key type: RSA-2048 and up with algo SHA256withRSA  / SHA384withRSA / SHA512withRSA
          or ECC NIST P-256, P-384, P-521 with algo SHA256withECDSA / SHA384withECDSA / SHA512withECDSA        
          (for best performance: choose P-256 with SHA256withECDSA)

• validity: does not matter, still works when expired

SelfServiceJWTSigner

• included by default in config XML

• storage: pkcs12, HSM (recommended)

• placeholder P12 is allowed if selfservice is not used

• key usage: does not matter (but digitalSignature recommended)

• MAY be self-signed

• versioning not needed (always uses the default (i.e. highest) version)

• trust does not matter (not needed in IDM keystore - engineSignEncryptConfig suffices)

• used internally by Operator only, both issues tokens and verifies them

• key type: RSA-2048 and up (4096 recommended), no ECC support!

• validity: does not matter, still works when expired

ContentProviderJWSSigner

• included by default in config XML

• storage: pkcs12, HSM (recommended)

• placeholder P12 is fine if IDM is not used to provision Visual IDs

• must NOT be self-signed!

• versioning not needed (always uses the default (i.e. highest) version)

• key usage: (according to Martin Lund no special reqs, but put digitalSignature there)

• issuing CA cert must to be trusted by the app onto which to provision Visual IDs

• key type: RSA-2048 and up (4096 recommended), no ECC support!

• validity: at your discretion (make sure you do not forget to renew before the expiry date!), validity is checked on the SDK side

Misc. attestation key descriptors

...

• Names:

  • att_external-attestation-1 (mobile only)

  •  att_external-attestation-2 (mobile only)

  •  att_external-attestation-3 (mobile only)

  •  att_external-attestation-4 (mobile only)

  •  att_ATTESTATION (mobile+desktop, default)

• P12s have no private keys, only dummy cert where we only care about the public key

• storage: pkcs12, HSM (recommended)
  (for Utimaco first export cert from p12 to BINARY CER file, then import that into HSM)

• only public part with dummy cert generated by tool https://doc.nexusgroup.com/pub/configure-custom-attestation-keys

• we just verify based on the key, so the dummy cert and its validity does not matter

• key type: RSA-2048 and up (4096 recommended), no ECC support!

• algorithm param can be blank

• versioning supported (so technically you do not need to use multiple descriptors for rollover support...)

...