...
The following lists detailed requirements for how each descriptor shall be bootstrapped on a productive system, as well as the risks associated with failing to do so properly.
EncryptedFields
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 config
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
HSM supported for increased security
no 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
key requirementssupported 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
included by default in config XML config
HSM supported for increased security
no versioning, always uses version 1
placeholder P12 is allowed only if zip encryption is disabled
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!
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
included by default in config XML config
HSM supported for increased security
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 unsignedkey 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."
ObjectHistorySigner
included by default in config XML config
HSM supported for increased security
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
included by default in config XML config
HSM supported for increased security
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.4key 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-sizesvalidity: 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)
hermodDeviceEnc
included by default in config XML config
HSM is NOT supported (but not needed, either)
...
SelfServiceJWTSigner
included by default in config XML config
HSM supported for increased security
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 config
HSM supported for increased security
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
included by default in config XML config
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
HSM supporteded
(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...)
...