Comment: One suggestion is to rename the heading to “Sign and encrypt engine descriptors”. What do you think David Banz?

...

Detailed Overview Of Descriptors

Comment: Perhaps we can rewrite the heading to “Descriptors overview”. What do you think David Banz?

The engine’s descriptors are the following:

...

...

...

...

...

...

...

...

...

...

...

...

Here each Each descriptor is described in detail in the sections below, including requirements how it shall be bootstrapped.

EncryptedFields

• use-case: Encryption and decryption of fields in the Identity Manager database

• required: always

• 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)

• 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

• general requirements:

  • placeholder keys/certs forbidden for productive use

    • confidentiality of database secrets would be at risk

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

• key requirements:

  • supported types:

    • 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

• use-case: Encryption of the configuration files

• required: always

• configured in these applications

  • Identity Manager Admin / (earlier know as PRIME Designer)

  • Identity Manager Operator / (earlier known as PRIME Explorer)

• 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

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

• general requirements:

  • placeholder allowed only if config ZIP encryption is disabled

    • after changing the key you cannot decrypt previously exported config ZIPs that use encryption

• key requirements:

  • supported types:

    • 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

• use-case: Signing and validation of the configuration files

• configured in these applications:

  • Identity Manager Admin

  • Identity Manager Operator

• certificate requirements:

  • if key usage extension is critical, then digitalSignature is required

  • issuing certificate has to be installed in the Identity Manager trust-store

  • certificate must not be self-signed

• storage: pkcs12, HSM (recommended)

• versioning: possible, but unnecessary (It is sufficient that the certificate that signed the old configs is trusted via the IDM truststore)

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

  • SHA-256

• general requirements:

  • placeholder allowed only if config ZIP signing and verification is disabled

• key requirements:

  • supported types:

    • RSA 2048

    • RSA 3072

    • RSA 4096 (recommended)

• certificate requirements:

  • if key usage extension is critical, then digitalSignature is required

  • issuing CA cert must be in IDM truststore

  • must not be self-signed!

  • validity considerations:

    • if expired download is blocked unless ZIP signing is disabled

    • if expired config upload will fail with the message "Verification failed. The certificate has expired."

• issues if not configured as above:

  • export is blocked unless unless ZIP signing is disabled

  • verification does not work, ZIP appears unsigned

ObjectHistorySigner

• use-case: Signing and verification of the object history

• configured in these applications:

  • Identity Manager Admin (technically not used here, but required for startup due to bean requirements - subject to change in future releases)

  • Identity Manager Operator

• configured in these special-case tools:

  • batch_re-sign_history

    (repair tool for history signature)

  • batch_migration_smartact_to_prime

    (for migration of data from Identity Manager's/PRIME's predecessor SmartAct)

• storage: pkcs12, HSM (recommended)

• versioning: supported (signatures created with old versions can still be verified)

• supported digest values: (changing the digest after history entries have been written requires a new version of the descriptor or startup will fail!)

  • SHA-256

  • SHA-384

  • SHA-512

• general requirements:

  • placeholder allowed only if history verification is disabled (via activitiHistoryCleanerJobTrigger.cronExpression set to a date in the distant future, see List of Identity Manager system properties and Quartz CronTrigger tutorial )

    • integrity of history signature would be as risk

    • re-signing requires use of the batch_re-sign_history tool once the first history entry is created

    • if you plan on enabling it at a later date, it is recommended not to use a placeholder

• key requirements:

  • supported types:

    • RSA 2048

    • RSA 3072

    • RSA 4096 (recommended)

• certificate requirements:

  • if key usage extension is critical, then digitalSignature is required

  • may be self-signed

  • validity is ignored

  • certificate does not need to be trusted

SignEmailDescriptor

...

• use-case: generate dummy certificate for transient key-pairs generated on a target device when provisioning Smart ID Mobile / Desktop App profiles (the certificates themselves are merely used as transport container for the key-usage parameter)

• configured in this application:

  • Identity Manager Operator

• storage: pkcs12

• versioning: possible, but unnecessary

• supported algorithm values:

  • for RSA keys only

    • SHA256withRSA  

    • SHA384withRSA

    • SHA512withRSA

  • for ECC keys only

    • SHA256withECDSA

    • SHA384withECDSA

    • SHA512withECDSA

• general requirements:

  • placeholders allowed

• key requirements:

  • supported types:

    • RSA 2048

    • RSA 3072

    • RSA 4096

    • ECC NIST P-256 (best performance)

    • ECC NIST P-384

    • ECC NIST P-521

• certificate requirements

  • may be self-signed

  • validity is ignored

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

  • certificate does not need to be trusted

SelfServiceJWTSigner

• use-case: Authentication of Smart ID Self-Service users to the Identity Manager backend

• configured in this application:

  • Identity Manager Operator

• storage: pkcs12, HSM (recommended)

• versioning: possible, but unnecessary

• general requirements:

  • placeholder keys forbidden for productive use

    • even if IDM SelfService is not deployed the related REST endpoints could face the risk of unauthenticated access

• key requirements:

  • supported types:

    • RSA 2048

    • RSA 3072

    • RSA 4096 (recommended)

• certificate requirements:

  • may be self-signed

  • validity is ignored

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

  • certificate does not need to be trusted

ContentProviderJWSSigner

...