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?
- Select applets (PIV, FIDO2) to load on the smart card/security key if the selected device
profile does not contain any applet.
- Configure personalization and printing options.
- If printing is to be done, then select visual designs based on the Identity type selected.
- If the smart card/security key contains both PIV and FIDO2 applets, select which application to
use to issue credentials.
- Configure the certificate types to be issued from the selected Certificate Authorities.
- Enable key escrow for the key management certificate.
- Configure if revocation of the key management certificate needs to be disabled.
- Define if signing the data being saved in the smart card/security keys containers is mandatory
using the content signing certificate.
- Set notifications for expiring certificates.
- If you are issuing a DPIV or DFIDO2 credential, configure if verification of the issuance status
of the primary credential is essential.
- Configure if activation is required.
- 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.
- 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.
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.
The Unifyia platform uses a Certificate Authority (CA) to issue four types of
certificates – PIV Authentication, Card Authentication, Digital Signature, and the
Key Management Certificate. A Key Management Certificate is a digital certificate used
to manage and secure keys within a system. It is crucial for handling key-related
operations such as encryption, decryption, signing, and verifying digital signatures.
The private keys of the Key Management Certificate issued by a Certificate Authority are
stored on the Certificate Authority if escrowed. The Unifyia platform offers two
configuration options for the Key Management Certificate – Escrow and Disable
Revocation. Let’s explore these two options in detail:
Escrow
When you enable the Escrow option for the Key Management certificate in a workflow on the
Unifyia platform, the private keys for the certificates are stored on the CA server.
These keys are retrieved during the reissuance of an identity device if the original
device is lost, damaged, or stolen, or when issuing an additional device for the same
user. If the option is disabled, a new certificate is generated and installed for each
device issued.
Disable Revocation
When you enable the Disable Revocation option, the key management certificate remains
valid even if the identity device has expired. This helps the organizations to maintain
uninterrupted access to services relying on the Key Management certificate.
Organizations can avoid the need to frequently update and manage certificate statuses.
This simplifies certificate lifecycle management, especially in environments with many
devices and certificates.
Multiple Identity
Devices Issuance - Escrow and
Disable Revocation Use Cases
This section explains how the Key Management certificate is managed with the Escrow and
Disable Revocation options while issuing multiple identity devices.
- When a user is issued multiple devices, a single Key Management certificate is
issued by the CA and shared across all devices if the Key Escrow option is enabled
in a workflow. However, the other three certificates (Card Authentication, PIV
Authentication, and Digital Signature) are issued independently for each device and
cannot be shared among the available devices.
- If the Card Authentication, PIV Authentication, or Digital Signature certificates
expire or are nearing expiration, you can renew the device. This will regenerate and
load the new Card Authentication, PIV Authentication, and Digital Signature
certificates into the device. If the Key Management certificate expires, all
certificates, including the Key Management Certificate, will be regenerated and
loaded into the device.
- An expired or revoked Key Management certificate is moved to the retired container
of the device if the Escrow option is enabled.
- If the Disable Revocation option is enabled for the Key Management Certificate,
actions like Revoke, and Reactivate do not affect the Key Management Certificate.
When renewing any expired certificates, the three certificates are regenerated and
loaded into the device, but the existing active Key Management Certificate is
retrieved from the CA and placed in the device.
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.
- 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.