Smart Card/Security Key Credential Issuance

This tutorial helps you to learn more about the available options in the Smart Card/Security Key Credential Issuance section while creating a workflow.

The Unifyia platform complies with the National Institute of Standards and Technology (NIST) and FIPS 201-3 standards for the Personal Identity Verification (PIV), Personal Identity Verification Interoperable (PIV - I), Commercial Identity Verification (CIV), Derived PIV (DPIV), and Derived FIDO2 (DFIDO2) credential issuance on smart cards and security keys.

This section is the most critical and complex aspect of the workflow as it allows you to configure the chip personalization and printing options for devices such as smart cards or security keys. All the options selected in this section are executed during the chip personalization and printing steps during the issuance of an identity device. The visibility of certain configurations is dependent on the identity type and device profiles selected. Hence, ensure to first complete the general section configurations before configuring the parameters in this section.

What can you configure in this section?

  1. Select applets (PIV, FIDO2) to load on the smart card/security key if the selected device profile does not contain any applet.
  2. Configure personalization and printing options.
  3. If printing is to be done, then select visual designs based on the Identity type selected.
  4. If the smart card/security key contains both PIV and FIDO2 applets, select which application to use to issue credentials.
  5. Configure the certificate types to be issued from the selected Certificate Authorities.
  6. Enable key escrow for the key management certificate.
  7. Configure if revocation of the key management certificate needs to be disabled.
  8. Define if signing the data being saved in the smart card/security keys containers is mandatory using the content signing certificate.
  9. Set notifications for expiring certificates.
  10. If you are issuing a DPIV or DFIDO2 credential, configure if verification of the issuance status of the primary credential is essential.
  11. Configure if activation is required.
  12. You can configure to issue certificates to selected device profiles. Depending on the device profile, various issuance options are available. Select the option you would like to enable and specify the group(s) that should be granted access to perform the particular action.
  13. You can configure loading the applets if the smart card selected does not have PIV or FIDO2 applets which are required for personalization. For example, ZTPass on NXP P71D600 cards do not contain any applet. So, if you wish to issue such cards, you can select the type of applet to be loaded during the issuance process.

Applets

This section is visible only if you have selected the device profile as ZTPass on NXP P71D600. These devices do not contain any applet. Hence, it is essential to load PIV or FIDO2 applets on the card before personalization. If you have selected the JCOP4 and/or JCOP4.5 device profiles and checked the option Smart Card/Security Key Credential Issuance, then you need to select at least one or both of the below options based on your requirements:

  • Enable PIV Applet Loading: Select this option to load the PIV applet on the JCOP4 device before personalization.
  • Enable FIDO2 Applet Loading: Select this option to load the FIDO2 applet on the JCOP4 device before personalization. Enter the following details:
    • Attestation Certificate: Provide the Attestation Certificate in Hexadecimal Format. This certificate is authenticator specific or authenticator model-specific attestation certificate issued by the manufacturer.
    • Attestation Certificate Private Key: For the manufacturer-issued attestation certificate, provide the attestation certificate private key in Hexadecimal Format. This key will be used to validate the attestation.
    • AAGUID: Enter an AAGUID for the selected product type. An AAGUID (Authenticator Attestation Global Unique Identifier) is an identifier for FIDO2 security keys. The same AAGUID is assigned to security keys whose product type and firmware are the same. For AAGUIDs assigned to security keys, contact the manufacturing vendor. Some manufacturing vendors release AAGUIDs on their websites.

Chip Personalization and Printing

This section allows you to configure the chip personalization and ID printing options. You must choose at least one option to proceed.

  • Enable Chip Personalization: Check this option if you only want to allow the personalization of devices like smartcards or security keys. Select the group(s) that should be granted access to perform chip personalization.
  • Enable Chip Personalization + Visual ID Printing: Check this option if you intend to allow personalization and printing cards. Select the group(s) that should be granted access to perform this action.
  • Enable Visual ID Printing: Check this option to enable the printing of visual identities. Select the group(s) that should be granted access to print IDs.

FIDO2 Registration

The workflow allows you to enable the registration of Passkeys (FIDO2) credentials for the Unifyia platform and relying parties. This capability is especially valuable in environments that implement non-PKI or derived credentials in accordance with NIST guidelines, such as SP 800-63-4. Currently, the platform supports the integration of two relying parties - Microsoft Entra ID and Okta.

Prerequisites:

  • By default, a Passkey (FIDO2) Policy is already configured for the Unifyia platform. If required, update it as per your organization's requirements.
  • You can configure FIDO2 Registration for relying parties only after they have been integrated and a Passkey (FIDO2) policy has been set up for each one.
    • Start by integrating each relying party (such as Microsoft Entra ID and Okta) by configuring their connection parameters and provisioning APIs using the Passkeys (FIDO2) Provisioning feature on the Unifyia platform.
    • Then, configure a dedicated Passkeys (FIDO2) Policy for each relying party on the Unifyia platform.

The following options can be configured:

  • Enable FIDO2 Passkeys issuance for platform: Check this option to enable the registration and issuance of Passkeys (FIDO2) credentials for the Unifyia platform users.
  • Enable FIDO2 Passkeys provisioning for relying parties: Check this option to enable the registration and issuance of Passkeys (FIDO2) credentials for the integrated relying parties. The Relying Parties dropdown is enabled.
  • Relying Parties: This dropdown lists all the integrated relying parties. You must select at least one relying party for auto-provisioning and registration of the FIDO2 Passkeys. You can also select multiple relying parties by enabling the checkbox option within the dropdown. Even if the relying parties have already been assigned to a workflow, you can reassign the same relying parties to additional workflows without any restrictions.

Select Visual Designs

This section is enabled only if you have selected a printing option that has visual ID printing. The groups that you have selected under the General section are auto-populated. Select a visual design for each group from the listed options in the drop-down. Based on the identity type selected, the visual designs are populated. For instance, if you've selected to issue a PIV ID, then the PIV ID visual design will be presented in the drop-down list. You can include multiple designs for a single identity type and proceed with issuance accordingly provided that you have already added the required visual designs.

Certificates

Include this section in the workflow to configure the issuance of various certificates for smart cards and security keys during personalization. These certificates serve purposes such as certificate-based authentication, digital signatures, and more. Within this section, you can specify settings to receive notifications for expiring certificates. Additionally, you have the flexibility to configure the issuance of different types of certificates: either from a single certificate authority or from different certificate authorities for each certificate.

Certificate Types

The following are the certificates that can be configured and used for various functions.

  • Card Authentication - This certificate is used to identify the card. It is a certificate and key pair that can be used to verify that the credential was issued by an authorized entity, has not expired, and has not been revoked.
  • PIV Authentication - This certificate is usually known as a user authentication certificate as this identifies the user and is used in Windows login (smart card logon), Web SSO, etc.
  • Digital Signature - This is a digital signing certificate used for signing emails and documents.
  • Encryption - This is a key management certificate and is used to encrypt sensitive data that is stored on the PIV card. It facilitates the secure storage of cryptographic keys on the PIV card. For more information read about the Key Management Certificate.

Configuring Certificates

Follow the steps below to configure the certificates for the smart devices:

  • Certificate Type: Select the type of the certificate to be issued. There are four types of certificates that you can issue – Card Authentication, PIV Authentication, Digital Signature, and Encryption.
  • CA Server: Select the Certificate Authority from which the certificate needs to be issued.
  • Certificate Profile: Select the certificate profile created in the Certification Authority.
  • Escrow: This option is available only for the encryption (Key Management) certificate. Select this option if the encryption or the key management certificate needs to be escrowed and moved to the retired containers. Enabling this option allows you to support key and certificate recovery during future device issuances leveraging the same workflow. Key Escrow for the Key Management certificate occurs at the certificate authority. Key Escrow for the other 3 certificates is not available for security best practice. For more information read about the Key Management Certificate.
  • Disable Revocation: This option is available only for the encryption (Key Management) certificate. Select this option if you want to disable the revocation of key management certificates on the expiry of the identity device. For more information read about the Key Management Certificate.
  • Algorithm: Select the algorithm type, e.g., ECDSA, RSA.
  • Key Size: Select the key size based on the selected algorithm, e.g., 256, 2048. Currently, the platform supports ECDSA 256 and RSA 2048 key sizes.
  • Subject DN: Select Subject Distinguished Name (Subject DN) attributes to define a format for the DN pattern for each certificate. Check the boxes for the required attribtues. Currently, the application supports common name (cn), organizational unit (ou), organization (o), and email address (emailAddress). Based on the selected attribtues the subject DN format is defined. For example, if you have selected common name (cn), organizational unit (ou), and organization (o). then the subject DN format is cn,ou,o.
  • SAN: Select the list icon under the Subject Alternative Name (SAN) and define the identifiers that you require to be included in the X.509 certificate to identify the person the certificate represents. You may select one or more Subject Alternative Name (SAN) entries. The following are the supported SAN entries:
    • Other Name (UPN): Other Name genereally refers to a flexible and extensible field that allows for the inclusion of alternative identities not covered by standard SAN types. Other Name (UPN) option enables you to include the UPN in the certificate to identify the person the certificate represents.
    • Other Name (FASC-N): Other Name (FASC-N) option enables you to include the FASC-N in the certificate to identify the person the certificate represents.
    • RFC822 Name: Refers to an email address.
    • Uniform Resource Identifier (URI): It is a string that uniquely identifies a particular resource. Can be a URL (Uniform Resource Locator) or URN (Uniform Resource Name).
  • Actions: Select the Plus icon to add a row to configure another certificate type and set the values as explained above. You can add a maximum of four certificate types. Select the Cross icon to delete a row.

Additional Configurations

    NOTE
    The userPrincipalName user attribute mapper must be added while configuring the directory to read the UPN and map it to UPN attribute of the authentication certificate.
  • Common Name: Enable this option by moving the slider to the right side. A dropdown that lists the available formats for the common name is enabled. Select the required format. This ensures that the selected common format is included in the SubjectDN of the certificates. Available formats are:
    • CN=firstname lastname, e.g., Jane Smith
    • CN=firstname lastname intended usage short,e.g., Jane Smith Auth
    • CN=firstname lastname intended usage, e.g., Jane Smith Authentication
    • CN=firstname lastname (Affiliate), e.g., Jane Smith (Affiliate)
    • CN=firstname initial. Lastname, e.g., Jane A. Smith
    • CN=firstname middlename lastname, e.g., Jane Alex Smith
    • CN=lastname.firstname.middlename, e.g., Smith.Jane.Alex
    • CN=firstname lastname - intended usage – expiry, e.g., Jane Smith - Signature - Expires 01/15/2025
    • CN=firstname lastname - intended usage - agency identifier, e.g., Jane Smith - Signature – 123456
    • CN=firstname lastname - intended usage - SKI identifier, e.g., Jane Smith - Authentication – 123456
  • Read the UPN value from the user's parent directory and map it to the UPN attribute of the authentication certificate: User Principal Name (UPN) is used to uniquely identify a user. Enabling this checkbox will ensure that the UPN attribute is read from the user’s parent directory and mapped to the User Principal Name (UPN) attribute of the authentication certificate to support integrated authentication scenarios. The UPN is formatted much like an email address and typically consists of the user's logon name, the "@" symbol, and the domain name, e.g., jdoe@domain.com
  • Save the issuance status of the credential to the selected directories: Enabling this checkbox will allow the issuance status of the newly issued credentials to be written back to the selected directory using the selected user attribute post-issuance. Depending on the certificate attribute format selected, the corresponding value will be prepared and subsequently written back to the directory. You may specify a single directory or multiple directories, the respective user attribute mappers and certificate attribute formats to write back to the LDAP directories.

    For example, you have set the first user attribute mapper (e.g., username) and certificate attribute as X09:<I>{ISSUER_DN}<SR>{SUBJECT_SERIAL_NUMBER} with the directory LDAPAD1. Select the + icon to add another row and select the second directory, for instance, LDAPAD2, then select the second user attribute mapper (e.g., lastname) and the corresponding certificate attribute for it as X09:<I>{ISSUER_DN}<SR>{SUBJECT_SERIAL_NUMBER}. Based on the above configuration, the issuance status of the derived credential is updated in both the selected directories.

    • Directory: Select the name of the directory to which the issuance status of the credential must be written back.
    • User Attribute Mapper: You can manually map the issued certificates to a user in the directory by selecting the user attribute mapper. The issuance status in the selected certificate attribtue format will be written back to the directory.
    • Certificate Attribute: Select the format in which the issued certificate attribute value must be prepared and subsequently written back to the directory. The below format is recommended as this is considered one of the strong mapping types recommended by Microsoft.
    • Format: X09:<I>{ISSUER_DN}<SR>{SUBJECT_SERIAL_NUMBER}

    • Reverse certificate mapping as recommended by Microsoft for altSecurityIdentities: This option allows you to mandate the reverse certificate mapping method to build the value for the Certificate attribute. Microsoft recommends this as a best practice.
    • Search User Attribute: Select the user attribute using which the user must be searched while writing back to the directory. The available options are email and UPN. It is advisable to use UPN as it is unique per user in a specific directory.
  • Sign data written to card/token containers with issuer signing certificate: Select this option to sign the data written to the smart card/security key containers with issuer signing certificate for additional security. For this to be executed, ensure to upload the Content Signing Certificate.
  • Notify users of any certificates expiring in: Select a value to indicate when to start sending the notification to the users informing them about the expiring certificates. For example, if the value is set to 5, then 5 days before the expiration of the certificates, the user is warned about the expiring certificates.
  • Email Notification Frequency: Select a value to set the frequency of sending notifications to the user about the expiring certificates.

Activation

Check the Require verification before activation if verification is necessary before activating the PIV device, particularly when the issuance is conducted by an operator without the user being present. As a security measure, devices are locked before being sent to the customer, and users are required to activate the device upon receipt. This section also allows you to configure verification policy options for activation. If you only check the Require verification before activation option without selecting any verification policy, the Verify with PIN option will be chosen by default. Currently, the platform supports activation using PIN only.

  • Verify with PIN: This option is checked by default. This enables activation of the identity device by entering the activation PIN sent to the registered email of the ID holder.

You have completed the data and biometrics enrollment configurations requried for the workflow. The next step is to configure the ID Wallet Configurations details.