Versions Compared

Version Old Version 35 New Version 36
Changes made by

David Banz

David Banz

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • 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

  • HSM supported for increased securitystorage: 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

...

  • included by default in config XML

  • HSM supported for increased securitystorage: 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

...

  • included by default in config XML

  • HSM supported for increased securitystorage: 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

  • HSM supported for increased securitystorage: 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

...

  • included by default in config XML

  • HSM supported for increased securitystorage: 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)

...

  • included by default in config XML

  • HSM is NOT supported (but not needed, either)           storage: pkcs12

Code Block
java.lang.UnsupportedOperationException: PrivateExponent cannot be extracted, key must be used with the iD2 provider
  at com.id2tech.security.provider.PrivateRsaKeyImpl.getPrivateExponent(PrivateRsaKeyImpl.java:66) ~[common-8.5.3.jar:10.2.6]
  at org.bouncycastle.jcajce.provider.asymmetric.rsa.RSAUtil.generatePrivateKeyParameter(Unknown Source) ~[bcprov-jdk18on-1.73.jar:1.73.0]
  at org.bouncycastle.jcajce.provider.asymmetric.rsa.DigestSignatureSpi.engineInitSign(Unknown Source) ~[bcprov-jdk18on-1.73.jar:1.73.0]
  at java.security.Signature$Delegate.engineInitSign(Signature.java:1351) ~[?:?]
  at java.security.Signature.initSign(Signature.java:636) ~[?:?]
  at org.bouncycastle.operator.jcajce.JcaContentSignerBuilder.build(Unknown Source) ~[bcpkix-jdk18on-1.73.jar:1.73.0]
  at de.nexus.pkiutils.Digest.signerFor(Digest.java:40) ~[vps-pki_utils-0.279.0.jar:0.279.0]
  at de.nexus.pkiutils.certificate.CertAuthority.getSigner(CertAuthority.java:252) ~[vps-pki_utils-0.279.0.jar:0.279.0]
  at de.nexus.pkiutils.certificate.CertAuthority.createCertificate(CertAuthority.java:147) ~[vps-pki_utils-0.279.0.jar:0.279.0]
  at de.vps.act.processexecution.hermod.AbstractHermodInstallCertificatesAction.createCertCommand(AbstractHermodInstallCertificatesAction.java:110) ~[vps-process_execution-0.279.0.jar:0.279.0]

...

  • included by default in config XML

  • HSM supported for increased securitystorage: 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

...

  • included by default in config XML

  • HSM supported for increased securitystorage: 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

...

  • included by default in config XML

  • 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 supportededstorage: 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...)

...

  • absent by default from XML configuration

  • see Encoding using Idopte middleware in Identity Manager

  • descriptor can be omitted entirely (not even a placeholder P12 needed) if Idopte middleware is not used, otherwise correct cert+keypair is required

  • Idopte webapp cert, issued by Idopte based on CSR for a customer-generated keypair

    • CSR extensions: at least one placeholder SAN URI (which PDA will send as Origin header), e.g.

  • validity does matter (checked by Idopte middleware), regular renewal needed

  • key type: RSA-2048, feedback from Idopte what else they would support pending....

  • algorithm: NONEwithRSA

    •  (assuming no ECC support, otherwise it could also be NONEwithECDSA - required for correct signing of the challenge)

  • HSM is NOT supportedstorage: pkcs12

    • IdopteMiddleware.signEnvChallenge() always uses BC provider, probably should use IKeyDescriptor.getProviderForPrivateKey() instead

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

...

  • absent by default from XML configuration

  • see Encoding using Idopte middleware in Identity Manager

  • descriptor can be omitted entirely (not even a placeholder P12 needed) if Idopte middleware is not used, otherwise correct cert+keypair is required

  • inside server client auth

  • algorithm attribute not used

    •  (we only use certificate and private key from the descriptor)

  • storage: pkcs12

    • not clear if HSM is supported or not (see SSL.java)

  • key type: RSA-2048 and up (4096 recommended)

    • unsure if ECC support or not...

  • validity DOES matter, connection to Inside server will fail when expired

  • unsure if self-signed certs would work (recommend to use CA)

  • trust DOES matter - must be trusted by Inside server

  • key usage: digitalSignature

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

...

  • absent by default from XML configuration

  • by default the property is empty, hence no descriptors  (and thus not even placeholder P12s) are needed, unless the feature is required

  • see Encodings using Personal Desktop Client middleware in Identity Manager (section "Read encrypted PINs")

  • keypairs of pin-encryption certificate for decrypting pin-blobs from pre-personalized cards to e.g. print pin letters for them

  • algorithm: RSA

  • key type: RSA-2048 (unsure if larger ones work), no ECC support!

  • issued by CM

  • HSM supported for increased securitystorage: pkcs12, HSM (recommended)

  • validity does not matter to IDM

  • trust does not matter to IDM

  • key usage: recommend keyEncipherment + dataEncipherment for information, but technically does not matter (IDM just needs the private key)

  • we only use the private key

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

...