4.3 Configuring MyID for non-Federal issuers (PIV-I and CIV)
You can issue PIV, PIV-I and CIV smart cards in the same MyID installation. However there are some differences in how MyID should be configured, and methods used for adding user data.
It is also possible to issue other non-PIV credential types, such as certificates for mobile devices, Microsoft Virtual Smart Cards or software certificates from the same system.
4.3.1 PIV support levels
The following table describes each PIV support level that can be achieved with MyID, and describes some of the difference between each.
PIV support level |
Description |
User data entry method |
In PIV |
In core |
---|---|---|---|---|
FIPS 201 PIV |
Use of PIV card technology for federal agencies following FIPS 201 requirements. Agency code is present but not 9999. Specific PKI requirements for trust to the federal bridge. Note: You must ensure any additional processes required for identity proofing and registration take place, in accordance with FIPS-201 guidelines where applicable, before marking the user record as User Data Approved. |
LDAP, PIV Lifecycle API, or Manual |
Yes |
No |
PIV-I |
Use of PIV card technology for associates or contractors to Federal agencies. Agency code is 9999. Specific PKI requirements for trust to the federal bridge. |
LDAP, PIV Lifecycle API, or Manual |
Yes |
No |
CIV – with CHUID or Applet personalization |
Use of PIV card technology, where the format and source of the CHUID and PIV applet data is the same as PIV or PIV‑I. PIV Attributes required for card issuance. Agency code is 9999. No specific PKI requirements. |
LDAP, PIV Lifecycle API, or Manual |
Yes |
No |
Custom CIV |
The format or source of the CHUID and PIV applet data is different to PIV or PIV-I. PIV attribute values on card may be hard coded to predetermined values. |
As Project Requirement |
No |
Yes* |
CIV – certificates only |
Use of PIV card technology, with no CHUID or PIV applet data personalization. No PIV attributes required. |
LDAP, Core Lifecycle API or Manual |
Yes |
Yes |
Non-PIV |
Not using PIV card technology. No PIV attributes required. |
LDAP, Core Lifecycle API or Manual |
Yes |
Yes |
* With CIV module installed. Further customization may be needed.
Due to differing requirements between PIV, PIV-I and CIV there are some additional aspects of configuration and user data that must be considered.
-
Card Type and Data Format
In order to issue cards that are PIV-Interoperable or CIV, a PIV card supported by MyID must be used. Non-PIV cards will not be able to support the required data structures. When configuring the credential profile for these cards, ensure that the correct data model is used.
-
NACI Checks
If the Non Federal Issuer has chosen not to undertake the National Agency Check with Written Inquiries (NACI), the ‘NACI Status’ field used during enrollment of the Applicant should be left at ‘Not Requested’.
-
Certificate Policies
Certificates used on PIV-I cards must not be configured to include the FASC-N attribute. The UUID attribute should be present in the Card Authentication Certificate and the Authentication Certificate, and be issued from a Certificate Authority that is cross-certified with the Federal Bridge Certification Authority (FBCA). This is essential in order to establish the trust relationship with Federal Agencies.
The PIV-I Authentication Certificate and the Card Authentication Certificate are not required for PIV Compatible cards.
Certificate Profiles to be used on PIV-I or CIV cards should also not be configured to include NACI (piv-interim) attribute where these checks are not undertaken during enrollment.
-
Group Configuration
A Non-Federal Issuer must use the agency code ‘9999’, system code ‘9999’ and provide a DUNS value.
-
Card Layouts
The layout and images present on a PIV-I or CIV card must be easily distinguishable from a PIV card and are expected to include the Issuing or Sponsoring Organization (for example, Company name), Card holder Photograph, Card holder Full Name and Card Expiration Date. At a minimum, images or logos on a PIV-I Card shall not be placed entirely within Zone 11, Agency Seal, as defined by FIPS 201. You can use the Card Layout Editor in MyID to create and amend the card layouts – see the Designing card layouts section in the Administration Guide for details.
4.3.2 Issuing cards to the correct users
You must ensure that FIPS 201 PIV and PIV-I cards can only be issued to genuine PIV Applicants who have been through all the relevant enrollment business processes in accordance with FIPS 201.
You must set up the credential profiles for FIPS 201 to require that the user account has the Require user data to be approved option set. This ensures that only user accounts who have been through appropriate processes for enrollment and verification (managed using an external system such as an IDMS) can receive FIPS 201 PIV cards.
You must make sure that FIPS 201 PIV certificate policies and printed card layouts are only assigned to credential profiles that have the Require user data to be approved option set.
You must restrict the roles that are permitted to issue and receive the FIPS 201 PIV and PIV-I credential profiles; you can request cards using the MyID GUI in addition to the Lifecycle API – the available profiles for selection are restricted based on the roles held by the current operator requesting the card, and the person selected to receive the card.
4.3.3 Maintaining multiple populations in a single system
Separation between PIV, PIV-I and CIV card holders can be achieved by registering each Non-Federal Issuer as a separate Group within MyID. Operator access to each group can be controlled using Scope rules, and if necessary ‘Administrative Groups’. Further information about these features can be found in the Scope and security and Administrative groups sections of the Administration Guide.
Security may be extended further by creating specific roles for each Group, and restricting roles that can belong to the group to those that can issue, manage or be issued PIV-I or CIV cards. Credential profiles for PIV-I or CIV cards can then also be restricted to these roles. This will ensure the role separation that is required to distinguish cards issued using the FIPS 201 process and those that are PIV‑I or CIV.
The following diagram illustrates a recommended configuration for an installation supporting issuance of PIV and PIV-I cards:
4.3.4 Adding applicants
The method you use to add applicants to MyID depends on the type of user.
Note: If you attempt to issue cards where the credential profile in MyID uses a data model that requires PIV attributes, but the attributes are not present on the user account, card issuance will fail.
-
FIPS 201 PIV, PIV-I, and CIV (with CHUID or applet personalization)
-
User accounts must be imported using MyID Core API (or the Lifecycle API) to set the PIV attributes, manually added using the Add Person screen, or imported from LDAP using the Edit Person (Directory) screen. The additional role of PIV Applicant is used to identify these user accounts.
-
In order to receive a FIPS 201 level PIV card, the User Data Approved flag must be set. Use of this flag in combination with the requirement for it in the credential profile can be used to tailor the issuance processes to suit your organization.
For example, CIV credential profiles may still use a PIV data model, but not require User Data Approved to be set due to a more flexible enrollment policy.
-
Assign them to a group that has PIV agency attributes defined, or import these as part of the data in the Lifecycle API.
-
If the users in the group are part of a federal agency, set the appropriate agency code.
-
If the users in the group are not part of a federal agency, set the Agency code to 9999.
-
-
CIV (certificates only) and non-PIV
-
PIV user attributes are not needed. You can use the CMS Lifecycle API schema, or manually add user accounts using Add Person or Edit Person (with import from directory). You cannot add PIV attributes using the user interface.
-
Users can be assigned to groups that have PIV attributes – but there will be no use of the attributes during card issuance.
-
4.3.5 Operator permissions
You must ensure that applicants with PIV attributes can be administered only by operators who have been permitted to do so.
User accounts that hold the PIV Applicant role (as set at import) cannot be edited using the Edit Person screen. Instead, you can use the PIV applicant editing screens. See section 5.15, Editing PIV applicants for details.
PIV attributes are visible in View Person and during card issuance and management operations.
If access to these records is to be limited, you can set group and scope restrictions to control access to user accounts. By putting PIV applicants in a specific group or group hierarchy, you can limit access to these applicants based on MyID scope restrictions. If access to these users is needed by operators outside of this group hierarchy, you can use the Administrative Groups feature to assign access.
4.3.6 Business rules
Specific business rules that apply to FIPS 201 PIV, PIV-I and CIV cardholders that will not affect other users managed by MyID:
-
Card issuance rules (signing certificate expiry, biometric expiry, mandatory biometrics).
-
Card re-issuance rules (requirement for re-enrollment before card re-issue).
-
Post issuance update rules (prevent FASC-N or UUID recreation when updating a card).
4.3.7 Authentication
As non-PIV and CIV may have no requirement for the user to register biometric data, you must ensure that authentication settings are configured appropriately to provide the required levels of security in self service operations.
4.3.8 Summary of requirements for PIV-I and CIV
When issuing PIV-I and CIV cards, make the following changes:
-
PIV-I
-
When setting up the group, set the following fields on the Agency tab:
-
Issuing Agency – set to 9999.
-
Site Code – set to 9999.
-
-
The certificates must contain the FASC-N.
-
The cards must not look like FIPS 201 cards – do not use the PIV cards layouts.
-
Select PivDataModel.xml from the Card Format drop-down list in the credential profile.
-
-
CIV (with CHUID or Applet personalization)
-
When setting up the group, set the following fields on the Agency tab:
-
Issuing Agency – set to 9999.
-
Site Code – set to 9999.
-
-
The certificates must not contain the FASC-N.
-
The cards must not look like FIPS 201 cards – do not use the PIV cards layouts.
-
Select PivDataModel.xml from the Card Format drop-down list in the credential profile.
-
-
CIV (with certificates only)
-
When setting up the group, set the following fields on the Agency tab:
-
Issuing Agency – set to 9999.
-
Site Code – set to 9999.
-
-
The certificates must not contain the FASC-N.
-
The cards must not look like FIPS 201 cards – do not use the PIV card layouts.
-
Select CivCertificatesOnly.xml or CivCertificatesOnlyCompressed.xml from the Card Format drop-down list in the credential profile.
-