...
| Note |
|---|
Correct bootstrapping is required for productive use! Only dev- and test systems may use placeholders (e.g. created with bootstrap.zip package and the corresponding Docker container). |
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)
storage: pkcs12, HSM (recommended)
versioning: not supported, always uses version 1
supported asymClipher values:
for HSM
RSA/ECB/OAEPWithSHA-384AndMGF1PaddingRSA/ECB/OAEPWithSHA-512AndMGF1Padding
for PKCS#12
RSA/None/OAEPWithSHA384AndMGF1PaddingRSA/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
...
| Note |
|---|
Correct bootstrapping may be required for productive use, depending in on the use-case. Dev- and test systems may use placeholders (e.g. created with bootstrap.zip package and the corresponding Docker container). |
use-case: encrypt and decrypt config ZIP packages
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-384AndMGF1PaddingRSA/ECB/OAEPWithSHA-512AndMGF1Padding
for PKCS#12
RSA/None/OAEPWithSHA384AndMGF1PaddingRSA/None/OAEPWithSHA512AndMGF1Padding
NOTE: but 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
...
| Note |
|---|
Correct bootstrapping may be required for productive use, depending in on the use-case. Dev- and test systems may use placeholders (e.g. created with bootstrap.zip package and the corresponding Docker container). |
use-case: sign and verify config ZIP packages
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-38 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
...
| Note |
|---|
Correct bootstrapping is required for productive use! Only dev- and test systems may use placeholders (e.g. created with bootstrap.zip package and the corresponding Docker container). |
use-case: sign and verify 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 keys forbidden for productive use
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
key requirements:
supported types:
RSA 2048
RSA 3072
RSA 4096 (recommended)
certificate requirements:
if key usage extension is critical, then digitalSignature must is required
may be self-signed
validity is ignored
certificate does not need to be trusted
...
| Note |
|---|
Correct bootstrapping may be required for productive use, depending in on the use-case. Dev- and test systems may use placeholders (e.g. created with bootstrap.zip package and the corresponding Docker container). |
use-case: send signed e-mails from IDM
configured in this application:
Identity Manager Operator
storage: pkcs12, HSM (recommended)
versioning: supported, but unnecessary
supported algorithm values:
for RSA keys only
SHA256withRSA
SHA384withRSA
SHA512withRSA
for ECC keys only
SHA256withECDSA
SHA384withECDSA
SHA512withECDSA
general requirements:
placeholders allowed only if email signing is not used
e-mail verification will fail if not issued by a trusted S/MIME CA
integrity of e-mails sent by IDM may be at risk if placeholder key is used
key requirements:
supported types:
RSA 2048
RSA 3072
RSA 4096
ECC NIST P-256
ECC NIST P-384
ECC NIST P-521
certificate requirements:
proper S/MIME certificate with configured IDM e-mail sender address in DN's E field and/or SAN RFC-822 entry
if subject DN email field is absent, SAN extension must be critical!
IDM up to 23.10.x only accepted SAN and ignoreed DN.E (fixed in IDM 24.R1)
must not be self-signed!
key usage: if present, must be critical and at least either digitalSignature or nonRepudiation
validity: adhering to CAB-Forum requirements from https://cabforum.org/working-groups/smime/requirements/#632-certificate-operational-periods-and-key-pair-usage-periods (825 days max. at the time of writing)
hermodDeviceEnc
| Note |
|---|
| Info |
Bootstrapping required for productive use, depending in the use-casetechnical reasons, but with relaxed security requirements compared to other use-cases. |
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 (recommended for 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
...
| Note |
|---|
Correct bootstrapping is required for productive use! Only dev- and test systems may use placeholders (e.g. created with bootstrap.zip package and the corresponding Docker container). |
use-case: sign and verify JWT token for IDM SelfService REST endpoints of IDM Operator
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
...
| Note |
|---|
Correct bootstrapping may be required for productive use, depending in on the use-case. Dev- and test systems may use placeholders (e.g. created with bootstrap.zip package and the corresponding Docker container). |
use case: signing content for Visual ID provisioning to Smart ID Mobile App
configured in this application:
Identity Manager Operator (see Set up visual ID layout in Identity Manager)
storage: pkcs12, HSM (recommended)
versioning: possible, but unnecessary
general requirements:
placeholder allowed only if Visual ID is not used
if the certificate configured here is not trusted by the end-user (mobile-) device, then Visual ID provisioning will fail
forgery of Visual ID possible if placeholder key is used and also trusted by the end-user device
key requirements:
supported types:
RSA 2048
RSA 3072
RSA 4096 (recommended)
certificate requirements:
must not be self-signed!
key usage is not checked (recommended for informational purposes: set digitalSignature)
issuing CA cert must to be trusted by the app onto which to provision Visual IDs
validity: at your discretion (make sure you do not forget to renew before the expiry date!), validity is checked on the SDK side
versioning not needed (always uses the default (i.e. highest) version)
...