Interfaces for Personal Identity Verification (Working Draft)

1Introduction¶

Homeland Security Presidential Directive-12 (HSPD-12) called for the adoption of a common identification standard to govern the interoperable use of identity credentials to allow physical and logical access to federally controlled facilities and information systems. In response, Federal Information Processing Standard (FIPS) 201, Personal Identity Verification (PIV) of Federal Employees and Contractors 2, was developed to define reliable, government-wide identity credentials for use in applications such as access to federally controlled facilities and information systems. FIPS 201 supports multiple types of authenticators, including authenticators on smart cards (also known as PIV Cards) and derived PIV credential authenticators in various other form factors. This publication contains technical specifications to interface with PIV Cards to retrieve and use identity credentials. Other specifications, such as NIST Special Publication (SP) 800-157r1 (Revision 1), contain procedures and life cycle activities to issue, maintain, and use derived PIV credentials.

1.1Purpose¶

FIPS 201 defines processes for binding identities to authenticators, such as the PIV Card and derived PIV credentials used in the federal PIV system. SP 800-73-5 contains the technical specifications to interface with the PIV Card to retrieve and use the identity credentials. The specifications reflect the design goals of interoperability and PIV Card functions. The goals are addressed by specifying a PIV data model, card edge interface, and application programming interface. Moreover, this document enumerates requirements for the options and branches in international integrated circuit card (ICC) standards 34567. The specifications go further by constraining interpretations of the normative standards to ease implementation, facilitate interoperability, and ensure performance in a manner tailored for PIV applications.

1.2Scope¶

SP 800-73-5 specifies the PIV data model, application programming interface (API), and card interface requirements necessary to comply with the use cases, as defined in Section 6 of FIPS 201 and further described in this document. Interoperability is defined as the use of PIV identity credentials such that client-application programs, compliant card applications, and compliant ICCs CAN be used interchangeably by all information processing systems across federal agencies. SP 800-73-5 defines the PIV data elements’ identifiers, structure, and format, as well as the client API and card command interface for use with the PIV Card.

This document -- SP 800-73-5, Interfaces for Personal Identity Verification: Part 1 - PIV Card Application Namespace, Data Model, and Representation -- is a companion document to FIPS 201 and specifies the PIV Card Application Namespace, the PIV Data Model, and its logical representation on the PIV Card.

1.3Effective Date¶

These recommendations become effective upon final publication. New optional PIV Card features and deprecated PIV card features shall be phased in as part of new card stock acquisitions by federal department and agencies.

FIPS 201 compliance of PIV components and subsystems is provided in accordance with OMB through products and services from the U.S. General Services Administration’s (GSA) Interoperability Test Program and Approved Products and Services List.

1.4Audience and Assumptions¶

This document is intended for federal agencies and implementers of PIV systems. Readers are assumed to have a working knowledge of smart card standards and applications.

1.5Document Overview and Structure¶

All sections in this document are normative (i.e., mandatory for compliance) unless specified as informative (i.e., non-mandatory) and are structured as follows:

• Section 1, Introduction, provides the purpose, scope, effective date, audience, and assumptions of the document and outlines its structure.

• Section 2, PIV Card Application Namespaces, defines the three NIST-managed namespaces used by the PIV Card Application.

• Section 3, PIV Data Model Elements, describes the PIV Data Model elements in detail.

• Section 4, PIV Data Objects Representation, describes the format and coding of the PIV data structures used by the PIV client-application programming interface and the PIV Card Application.

• Section 5, Data Types and Their Representation, describes the data types found on the PIV client-application programming interface and the PIV Card Application card command interface.

• Appendix A provides container information for PIV Cards.

• Appendix B describes the PIV authentication mechanisms and is informative.

• Appendix C describes recommended procedures for key size and algorithm discovery and is informative.

• Appendix D provides the list of symbols, abbreviations and acronyms used in this document and is informative.

• Appendix E provides a glossary of terms and is informative.

• Appendix F describes the notation used in this document and is informative.

• Appendix G provides the revision history of the document and is informative.

2PIV Card Application Namespaces¶

2.1Namespaces of the PIV Card Application¶

Names used on the PIV interfaces are drawn from three namespaces managed by NIST:

1. Proprietary Identifier eXtension (PIX) of the NIST Registered Application Provider IDentifier (RID)

2. ASN.1 object identifiers (OIDs) in the personal identity verification subset of the OIDs managed by NIST

3. Basic Encoding Rules -- Cryptographic Algorithms and Key Sizes for PIV Tag Length Value (BER-TLV) tags of the NIST PIV coexistent tag allocation scheme

All unspecified names in these managed namespaces are reserved for future use.

All interindustry tags defined in ISO/IEC 7816, Information Technology -- Identification Cards -- Integrated Circuit(s) Card with Contacts 3, and used in the NIST coexistent tag allocation scheme without redefinition have the same meaning as they have in 3.

All unspecified values in the following identifier and value namespaces are reserved for future use:

• Algorithm identifiers

• Key reference values

• Cryptographic mechanism identifiers

2.2PIV Card Application AID¶

The Application IDentifier (AID) of the Personal Identity Verification Card Application (PIV Card Application) SHALL be:

A0 00 00 03 08 00 00 10 00 01 00

The AID of the PIV Card Application consists of the NIST RID A0 00 00 03 08 followed by the application portion of the NIST PIX indicating the PIV Card Application (00 00 10 00) and then the version portion of the NIST PIX 01 00 for the first version of the PIV Card Application. All other PIX sequences on the NIST RID are reserved for future use.

The PIV Card Application CAN be selected as the current application by providing the full AID as listed above or by providing the right-truncated version (i.e., without the two-byte version), as follows:

A0 00 00 03 08 00 00 10 00

3PIV Data Model Elements¶

This section describes the data elements for the personal identity verification data model.

A PIV Card Application SHALL contain seven mandatory interoperable data objects, two conditionally mandatory data objects, and MAY contain 27 optional data objects. The seven mandatory data objects for interoperable use are:

1. Card Capability Container

2. Card Holder Unique Identifier

3. X.509 Certificate for PIV Authentication

4. X.509 Certificate for Card Authentication

5. Cardholder Fingerprints

6. Cardholder Facial Image

7. Security Object

The two data objects that are mandatory if the cardholder has a government-issued email account at the time of credential issuance are:

1. X.509 Certificate for Digital Signature

2. X.509 Certificate for Key Management

The 27 optional data objects are:

• Printed Information

• Discovery Object

• Key History Object

• 20 retired X.509 Certificates for Key Management

• Cardholder Iris Images

• Biometric Information Templates Group Template

• Secure Messaging Certificate Signer

• Pairing Code Reference Data Container

3.1Mandatory Data Elements¶

This section describes the seven mandatory data objects for interagency interoperable use.

3.1.1Card Capability Container¶

The Card Capability Container (CCC) is a mandatory data object whose purpose is to facilitate the compatibility of Government Smart Card Interoperability Specification (GSC-IS) applications with PIV Cards.

The CCC supports minimum capability for retrieval of the data model and, optionally, the application information specified in 8. The data model of the PIV Card Application SHALL be identified by data model number 0x10. Deployed applications use 0x00 through 0x04. This enables the GSC-IS application domain to correctly identify a new data model namespace and structure as defined in this document.

For PIV Card Applications, the PIV data objects exist in a namespace tightly managed by NIST, and a CCC discovery mechanism is not needed by client applications that are not based on GSC-IS. Therefore, all mandatory data elements of the CCC except for the data model number MAY optionally have a length value set to zero bytes (i.e., no value field will be supplied). Unused optional data elements SHALL be absent. Other than the data model number, the contents of the CCC data elements are out of scope for this specification.

The Security Object enforces integrity of the CCC according to the issuer.

3.1.2Card Holder Unique Identifier (CHUID)¶

The Card Holder Unique Identifier (CHUID) data object is defined in accordance with the Technical Implementation Guidance: Smart Card Enabled Physical Access Control Systems (TIG SCEPACS) 9. For this specification, the CHUID is common between the contact and contactless interfaces. For dual chip implementations, the CHUID is copied in its entirety between the two chips.

In addition to the requirements specified in TIG SCEPACS, the CHUID on the PIV Card SHALL meet the following requirements:

• The previously deprecated Authentication Key Map data element SHALL NOT be present in the CHUID.^[1]

• The Federal Agency Smart Credential Number (FASC-N) SHALL be in accordance with TIG SCEPACS 9 with the exception that credential series, individual credential issue, person identifier, organizational category, organizational identifier, and the person/organization association category MAY be populated with all zeros. The FASC-N SHALL NOT be modified post-issuance.

  • A subset of the FASC-N, the FASC-N Identifier, SHALL be the unique identifier as described in 9, Section 6.6: “The combination of an Agency Code, System Code, and Credential Number is a fully qualified number that is uniquely assigned to a single individual.” The Agency Code is assigned to each department or agency by SP 800-87, Codes for Identification of Federal and Federally-Assisted Organizations 10.

  • The subordinate System Code and Credential Number value assignment is subject to department or agency policy, provided that the FASC-N identifier (i.e., the concatenated Agency Code, System Code, and Credential Number) is unique for each card.

  • The same FASC-N value SHALL be used in all of the PIV data objects that include the FASC-N. To eliminate unnecessary use of personally identifiable information, the FASC-N’s Person Identifier (PI) field SHOULD NOT encode Social Security numbers (SSNs). TIG SCEPACS also specifies PACS interoperability requirements in the tenth paragraph of 9, Section 2.1: “For full interoperability of a PACS, it must at a minimum be able to distinguish fourteen digits (i.e., a combination of an Agency Code, System Code, and Credential Number) when matching FASC-N-based credentials to enrolled card holders.”

• The Global Unique Identification number (GUID) field must be present and SHALL include a Card Universally Unique Identifier (UUID) (see Section 3.4.1). The Card UUID SHALL NOT be modified post-issuance.

• The Expiration Date is mapped to the reserved for future use (RFU) tag 0x35, keeping that within the existing scope of the TIG SCEPACS specification. This field SHALL be 8 bytes in length and SHALL be encoded in ASCII as YYYYMMDD. The expiration date SHALL be the same as printed on the card. The expiration date SHALL NOT be modified post-issuance.

• The optional Cardholder UUID field is mapped to RFU tag 0x36. If present, it SHALL include a Cardholder UUID as described in Section 3.4.2. The Cardholder UUID SHALL NOT be modified post-issuance.

• The CHUID SHALL be signed in accordance with Section 3.1.2.1. The card issuer’s digital signature key SHALL be used to sign the CHUID, and the associated certificate SHALL be placed in the signature field of the CHUID.

3.1.2.1Asymmetric Signature Field in CHUID¶

FIPS 201 requires inclusion of the asymmetric signature field in the CHUID data object. The asymmetric signature data element of the CHUID SHALL be encoded as a Cryptographic Message Syntax (CMS) external digital signature, as defined in RFC 5652 11.

The issuer asymmetric signature field is implemented as a SignedData type, as specified in 11, and SHALL include the following information:

• The message SHALL include a version field specifying version v3.

• The digestAlgorithms field SHALL be as specified in NIST SP 800-78 12.

• The encapContentInfo SHALL:

  • Specify an eContentType of id-PIV-CHUIDSecurityObject

  • Omit the eContent field

• The certificates field SHALL include only a single X.509 certificate, which CAN be used to verify the signature in the SignerInfo field.

• The crls field SHALL be omitted.

• signerInfos SHALL be present and include only a single SignerInfo.

• The SignerInfo SHALL:

  • Use the issuerAndSerialNumber choice for SignerIdentifier

  • Specify a digestAlgorithm in accordance with NIST SP 800-78 12.

  • Include, at a minimum, the following signed attributes:

    • A MessageDigest attribute containing the hash computed in accordance with NIST SP 800-78 12.

    • A pivSigner-DN attribute containing the subject name that appears in the PKI certificate for the entity that signed the CHUID

  • Include the digital signature

The public key required to verify the digital signature SHALL be provided in the certificates field of the CMS external digital signature in a content signing certificate, which SHALL be issued under the id-fpki-common-pivcontentSigning policy of 13. The content signing certificate SHALL also include an extended key usage (extKeyUsage) extension asserting id-PIV-contentsigning. The content signing certificate SHALL NOT expire before the expiration of the card authentication certificate.

3.1.3X.509 Certificate for PIV Authentication¶

The X.509 Certificate for PIV Authentication and its associated private key, as defined in FIPS 201, is used to authenticate the card and the cardholder. The PIV Authentication private key and its corresponding certificate are only available over the contact interface or virtual contact interface (VCI). The read access control rule for the X.509 Certificate for PIV Authentication is “Always,” meaning that the certificate CAN be read without access control restrictions. The Public Key Infrastructure (PKI) cryptographic function (see Table 5) is protected with a Personal Identification Number (PIN) or on-card biometric comparison (OCC) access rule. In other words, private key operations using the PIV Authentication key require the PIN or OCC data to be submitted and verified, but a successful submission enables multiple private key operations without additional cardholder consent.

3.1.4X.509 Certificate for Card Authentication¶

FIPS 201 specifies the mandatory asymmetric Card Authentication key (CAK) as a private key that MAY be used to support physical access applications. The read access control rule of the corresponding X.509 Certificate for Card Authentication is “Always,” meaning that the certificate CAN be read without access control restrictions. The PKI cryptographic function (see Table 5) is under an “Always” access rule so private key operations CAN performed without access control restrictions. The asymmetric CAK is generated by the PIV Card Issuer in accordance with FIPS 140-2 requirements for key generation. An asymmetric CAK MAY be generated on-card or off-card. If an asymmetric CAK is generated off-card, the result of each key generation SHALL be injected into at most one PIV Card.

3.1.5Cardholder Fingerprints¶

The fingerprint data object specifies the primary and secondary fingerprints for off-card matching in accordance with FIPS 201 and NIST SP 800-76 14.

3.1.6Cardholder Facial Image¶

The facial image data object is used for automated facial authentication in attended and unattended modes (e.g., BIO-A or BIO), as well as automated facial authentication for PIV reissuance and verification data reset in accordance with FIPS 201-3. The facial image data object MAY also be used for visual authentication by a guard (VIS). However, this authentication mechanism has been deprecated in accordance with FIPS 201-3. The facial image data object SHALL be encoded as specified in NIST SP 800-76 14.

3.1.7Security Object¶

The Security Object is in accordance with Part 10 of Machine Readable Travel Documents (MRTD) 15. Tag 0xBA is used to map the ContainerIDs in the PIV data model to the 16 Data Groups specified in the MRTD. The mapping enables the Security Object to be fully compliant for future activities with identity documents.

The DG-number-to-Container-ID mapping object TLV in tag 0xBA encapsulates a series of three-byte sequences -- one for each PIV data object included in the Security Object. The first byte is the Data Group (DG) number, and the second and third bytes are the most and least significant bytes (respectively) of the Container ID value. The DG number assignment is arbitrary. However, the same number assignment applies to the DataGroupNumber in the DataGroupHash. This will ensure that the ContainerIDs in the mapping object refer to the correct hash values in the Security Object (0xBB).

The 0xBB Security Object is formatted according to 15. The Logical Data Structure (LDS) Security Object itself must be in ASN.1 DER format, formatted as specified in 15, Section 4.6.2.3. This structure is then inserted into the encapContentInfo field of the Cryptographic Message Syntax (CMS) object specified in 15, Section 4.6.2.2.

The card issuer’s content signing digital signature key used to sign the CHUID SHALL also be used to sign the Security Object. The signature field of the Security Object, tag 0xBB, SHALL omit the issuer’s content signing certificate since it is included in the CHUID. At a minimum, unsigned data objects SHALL be included in the Security Object if present, such as the Printed Information data object. For maximum protection against credential splicing attacks (credential substitution), it is recommended, however, that all PIV data objects be included in the Security Object except for the PIV X.509 certificates and the Secure Messaging Certificate Signer data object.

3.2Conditional Data Elements¶

The following two data elements are mandatory if the cardholder has a government-issued email account at the time of credential issuance. These two data elements, when implemented, SHALL conform to the specifications provided in this document.

3.2.1X.509 Certificate for Digital Signature¶

The X.509 Certificate for Digital Signature and its associated private key, as defined in FIPS 201, support the use of digital signatures for the purpose of document signing. The digital signature private key and its corresponding certificate are only available over the contact interface or VCI. The read access control rule for the X.509 Certificate for Digital Signing is “Always,” meaning that the certificate CAN be read without access control restrictions. The PKI cryptographic function (see Table 5) is protected with a “PIN Always” or “OCC Always” access rule. In other words, the PIN or OCC data must be submitted and verified every time immediately before a digital signature key operation. This ensures cardholder participation every time the private key is used for digital signature generation.^[2]

3.2.2X.509 Certificate for Key Management¶

The X.509 Certificate for Key Management and its associated private key, as defined in FIPS 201, support the use of encryption for the purpose of confidentiality. The key management private key and its corresponding certificate are only available over the contact interface or VCI. This key pair MAY be escrowed by the issuer for key recovery purposes. The read access control rule for the X.509 certificate is “Always,” meaning that the certificate CAN be read without access control restrictions. The PKI cryptographic function (see Table 5) is protected with a “PIN” or “OCC” access rule. In other words, once the PIN or OCC data is submitted and verified, subsequent key management key operations CAN be performed without requiring the PIN or OCC data again. This enables multiple private key operations without additional cardholder consent.

3.3Optional Data Elements¶

When implemented, the 27 optional data elements of FIPS 201 SHALL conform to the specifications provided in this document.

3.3.1Printed Information¶

All FIPS 201 mandatory information printed on the card is duplicated on the chip in that data object. The printed information data object SHALL NOT be modified post-issuance. The Security Object enforces integrity of this information according to the issuer. This provides specific protection that the card information must match the printed information, mitigating alteration risks on the printed media.

3.3.2Discovery Object¶

If implemented, the Discovery Object is the 0x7E interindustry ISO/IEC 7816-6 template that nests interindustry data objects. For the Discovery Object, the 0x7E template nests two mandatory BER-TLV structured interindustry data elements: 1) tag 0x4F contains the AID of the PIV Card Application, and 2) tag 0x5F2F lists the PIN Usage Policy.

Tag 0x4F encodes the PIV Card Application AID as follows:

4F 0B A0 00 00 03 08 00 00 10 00 01 00

Tag 0x5F2F encodes the PIN Usage Policy in two bytes:

• First byte:

  • Bit 7 is set to 1 to indicate that the mandatory PIV Card Application PIN satisfies the PIV Access Control Rules (ACRs) for command execution^[3] and data object access.

  • Bit 6 indicates whether the optional Global PIN satisfies the PIV ACRs for command execution and PIV data object access.

  • Bit 5 indicates whether the optional OCC satisfies the PIV ACRs for command execution and PIV data object access.

  • Bit 4 indicates whether the optional VCI is implemented.

  • Bit 3 is set to zero if the pairing code is required to establish a VCI and is set to one if a VCI is established without a pairing code.

  • Bits 8, 2, and 1 of the first byte SHALL be set to zero.

Table 1 lists the acceptable values for the first byte of the PIN Usage Policy and summarizes the meaning of each value.

• The second byte of the PIN Usage Policy encodes the cardholder’s PIN preference for PIV Cards with both the PIV Card Application PIN and the Global PIN enabled.

  • 0x10 indicates that the PIV Card Application PIN is the primary PIN used to satisfy the PIV ACRs for command execution and object access.

  • 0x20 indicates that the Global PIN is the primary PIN used to satisfy the PIV ACRs for command execution and object access.

Note: If Bit 6 of the first byte of the PIN Usage Policy is set to zero, then the second byte is RFU and SHALL be set to 0x00.

PIV Card Applications that implement the VCI or for which the Global PIN or OCC satisfy the PIV ACRs for PIV data object access and command execution SHALL implement the Discovery Object.

The encoding of the 0x7E Discovery Object is as follows:

{7E 12 {4F 0B A0 00 00 03 08 00 00 10 00 01 00} {5F 2F 02 xx yy}},

where xx and yy encode the first and second byte of the PIN Usage Policy, as described in this section.

The Security Object enforces integrity of the Discovery Object according to the issuer.

3.3.3Key History Object¶

Up to 20 retired key management private keys MAY be stored in the PIV Card Application. The Key History object provides information about the retired key management private keys that are present within the PIV Card Application.^[4] Retired key management private keys are private keys that correspond to X.509 Certificates for Key Management that have expired, have been revoked, or have otherwise been superseded. The Key History object SHALL be present in the PIV Card Application if the PIV Card Application contains any retired key management private keys but MAY be present even if no such keys are present in the PIV Card Application. For each retired key management private key in the PIV Card Application, the corresponding certificate MAY either be present within the PIV Card Application or MAY only be available from an online repository.

The Key History object includes two mandatory fields, keysWithOnCardCerts and keysWithOffCardCerts, and one optional field, offCardCertURL. The keysWithOnCardCerts field indicates the number of retired private keys within the PIV Card Application for which the corresponding certificates are also stored within the PIV Card Application. The keysWithOffCardCerts field indicates the number of retired private keys within the PIV Card Application for which the corresponding certificates are not stored within the PIV Card Application. The numeric values in both keysWithOnCardCerts and keysWithOffCardCerts are represented as unsigned binary integers. The offCardCertURL field contains a URL that points to a file containing the certificates that corresponding to all of the retired private keys within the PIV Card Application, including those for which the corresponding certificate is also stored within the PIV Card Application. The offCardCertURL field SHALL be present if the keysWithOffCardCerts value is greater than zero and SHALL be absent if the values of both keysWithOnCardCerts and keysWithOffCardCerts are zero. The offCardCertURL field MAY be present if the keysWithOffCardCerts value is zero but the keysWithOnCardCerts value is greater than zero.

The file that is pointed to by the offCardCertURL field SHALL contain the DER encoding of the following data structure:

 OffCardKeyHistoryFile ::= SEQUENCE SIZE (1..20) OF SEQUENCE {
      keyReference             OCTET STRING (SIZE(1))
      cert                     Certificate
}

where keyReference is the key reference for the private key on the card, and cert is the corresponding X.509 certificate.^[5] The offCardCertURL field SHALL have the following format:

http:// <DNS name> / <ASCII-HEX encoded SHA-256 hash of OffCardKeyHistoryFile>

The private keys for which the corresponding certificates are stored within the PIV Card Application SHALL be assigned to the lowest numbered key references reserved for retired key management private keys. For example, if keysWithOnCardCerts is 5, then the corresponding private keys SHALL be assigned to key references 82, 83, 84, 85, and 86.

The private keys for which the corresponding certificates are not stored within the PIV Card Application SHALL be assigned to the highest-numbered key references reserved for retired key management private keys. For example, if keysWithOffCardCerts is 3, then the corresponding private keys SHALL be assigned to key references 93, 94, and 95.

Private keys do not have to be stored within the PIV Card Application in the order of their age. However, if the certificates that corresponding to only some of the retired key management private keys are available within the PIV Card Application, then the certificates that are stored in the PIV Card Application SHALL be the ones that were most recently issued.

The Key History object is only available over the contact interface and VCI. The read access control rule for the Key History object is Always, meaning that it CAN be read without access control restrictions.

The Security Object enforces integrity of the Key History object according to the issuer.

3.3.4Retired X.509 Certificates for Key Management¶

These objects hold the X.509 Certificates for Key Management that corresponding to retired key management private keys, as described in Section 3.3.3. Retired key management private keys and their corresponding certificates are only available over the contact interface or VCI. The read access control rule for these certificates is “Always,” meaning that the certificates CAN be read without access control restrictions. The PKI cryptographic function (see Table 4) for all of the retired key management private keys is protected with a “PIN” or “OCC” access rule. In other words, once the PIN or OCC data is submitted and verified, subsequent key management key operations CAN be performed with any of the retired key management private keys without requiring the PIN or OCC data again. This enables multiple private key operations without additional cardholder consent.

3.3.5Cardholder Iris Images¶

The iris images data object specifies compact images of the cardholder’s irises. The images are suitable for use in iris recognition systems for automated identity verification. The iris images data object SHALL be encoded as specified in NIST SP 800-76 14.

3.3.6Biometric Information Templates Group Template¶

The Biometric Information Templates (BIT) Group data object encodes the configuration information of the OCC data. The encoding of the BIT Group Template SHALL be as specified in Table 7 of NIST SP 800-76 14. When OCC satisfies the PIV ACRs for PIV data objects access and command execution, both the Discovery Object and the BIT Group Template data object SHALL be present, and bit 5 of the first byte of the PIN Usage Policy SHALL be set. The BIT Group Template MAY be present when OCC does not satisfy the PIV ACRs for PIV data objects access but, if present, SHALL contain no BITs.^[6] The Security Object enforces integrity of the BIT Group Template data object according to the issuer.

3.3.7Secure Messaging Certificate Signer¶

The Secure Messaging Certificate Signer data object, which SHALL be present if the PIV Card supports secure messaging for non-card management operations, contains the certificates needed to verify the signature on the secure messaging card verifiable certificate (CVC), as specified in SP 800-73-5 Part 2, Sec. 4.1.5.

The public key required to verify the digital signature of the secure messaging CVC is an ECC key. It SHALL be provided in either an X.509 Certificate for Content Signing or an Intermediate CVC. If the public key required to verify the digital signature of the secure messaging CVC is provided in an Intermediate CVC, then the format of the Intermediate CVC SHALL be as specified in SP 800-73-5 Part 2, Sec. 4.1.5, and the public key required to verify the digital signature of the Intermediate CVC SHALL be provided in an X.509 Certificate for Content Signing.

The X.509 Certificate for Content Signing SHALL be a digital signature certificate issued under the id-fpki-common-piv-contentSigning policy of 13. The X.509 Certificate for Content Signing SHALL also include an extended key usage (extKeyUsage) extension asserting id-PIV-content-signing. Additional descriptions for the PIV object identifiers are provided in Appendix B of FIPS 201-3. The X.509 Certificate for Content Signing needed to verify the digital signature of a secure messaging CVC or Intermediate CVC of a valid PIV Card^[7] SHALL NOT be expired.

Note that the option to include an Intermediate CVC is included as a temporary measure to accommodate the use of certification authorities that do not support the issuance of X.509 certificates that contain elliptic curve subject public keys. A future version of SP 800-73 is expected to deprecate the Intermediate CVC data element.

3.3.8Pairing Code Reference Data Container¶

The Pairing Code Reference Data Container, which SHALL be present if the PIV Card supports the virtual contact interface, includes a copy of the PIV Card’s pairing code (see Section 5.1.3). The Security Object enforces the integrity of the Pairing Code Reference Data Container according to the issuer.

3.4Inclusion of Universally Unique Identifiers (UUIDs)¶

This specification provides support for two UUIDs on a PIV Card. The Card UUID is unique for each card, and it SHALL be present on all PIV Cards. The Cardholder UUID is a persistent identifier for the cardholder, and it is optional to implement. The requirements for these UUIDs are provided in the following subsections.

3.4.1Card UUID¶

FIPS 201 requires PIV Cards to include a Card UUID. The Card UUID SHALL be included on PIV Cards as follows:

1. The value of the GUID data element of the CHUID data object SHALL be a 16-byte binary representation of a valid UUID 16. The UUID SHALL be version 1, 4, or 5, as specified in RFC 4122, Section 4.1.3 16.

2. The same 16-byte binary representation of the UUID value SHALL be present as the value of an entryUUID attribute, as defined in RFC 4122 16, in any CMS-signed data object that is required to contain a pivFASC-N attribute on a PIV Card (i.e., in the mandatory cardholder fingerprint template and facial image data objects as well as in the optional cardholder iris images data object when present.

3. If the PIV Card supports secure messaging and/or authentication using the secure messaging key, then the same 16-byte binary representation of the UUID value SHALL be used as the Subject Identifier in the secure messaging CVC, as specified in SP 800-73-5 Part 2, Sec. 4.1.5.

4. The string representation of the same UUID value SHALL be present in the X.509 Certificate for PIV Authentication and the X.509 Certificate for Card Authentication in the subjectAltName extension encoded as a URI, as specified by RFC 4122, Section 3 16.

3.4.2Cardholder UUID¶

Optionally, a Cardholder UUID value MAY be included in the SAN extension of the X.509 certificate for PIV Authentication. The Cardholder UUID value SHALL be a 16-byte binary representation of a valid UUID encoded as a Uniform Resource Name (URN) and version 4, as specified in RFC 4122, Section 4.1.3 16. The identifier should be limited in scope to identify a PIV credential holder to their PIV credentials issued during PIV eligibility. The same Cardholder UUID value MAY optionally be present in the CHUID data object, as defined in Sec. 3.1.2.

3.5Data Object Containers and Associated Access Rules and Interface Modes¶

Table 2 defines a high-level view of the data model. Each on-card storage container is labeled as mandatory (M), optional (O), or conditional (C). The conditional data objects are the digital signature key and the key management key, which are mandatory if the cardholder has a government-issued email account at the time of credential issuance. This data model is designed to enable and support dual interface cards. For dual chip implementations for any container that can be accessed over both the contact interface and the contactless interface (including the virtual contact interface), the data object SHALL be copied into the corresponding containers on both chips.^[8][9]

Appendix A provides a detailed spreadsheet for the data model. ContainerIDs and tags within the containers for each data object are defined by this data model in accordance with SP 800-73-5 naming conventions.

4PIV Data Objects Representation¶

4.1Data Objects Definition¶

A data object is an item of information seen on the card command interface that has a specified name, a description of logical content, a format, and a coding. Each data object has a globally unique name called its object identifier (OID), as defined in ISO/IEC 8824-2:2002 17.

A data object whose data content is encoded as a BER-TLV data structure, as in ISO/IEC 8825-1:2002 18, is called a BER-TLV data object.

4.1.1Data Object Content¶

The content of a data object is the sequence of bytes that are said to be contained in or to be the value of the data object. The number of bytes in this byte sequence is referred to as the length of the data content as well as the size of the data object. The first byte in the sequence is regarded as being at byte position or offset zero in the content of the data object.

The data content of a BER-TLV data object MAY consist of other BER-TLV data objects. In this case, the tag of the data object indicates that the data object is a constructed data object. A BER-TLV data object that is not a constructed data object is called a primitive data object.

The PIV data objects are BER-TLV objects encoded as per 18. However, tag values of the PIV data object’s inner tag assignments do not conform to BER-TLV requirements^[10] due to the need to accommodate legacy tags inherited from 8.

Before the card is issued, data objects that are created but not used SHALL be set to zero-length value.

4.2OIDs and Tags of PIV Card Application Data Objects¶

Table 3 lists the ASN.1 object identifiers and BER-TLV tags of the thirty-six PIV Card Application data objects. For the purpose of constructing PIV Card Application data object names in the CardApplicationURL in the CCC of the PIV Card Application, the NIST RID (A0 00 00 03 08) SHALL be used and the card application type SHALL be set to 00.

4.3Object Identifiers¶

Each of the data objects in the PIV Card Application has been provided with a BER-TLV tag and an ASN.1 OID from the NIST personal identity verification arc. These object identifier assignments are given in Table 3.

A data object SHALL be identified on the PIV client-application programming interface using its OID. An object identifier on the PIV client-application programming interface SHALL be a dot-delimited string of the integer components of the OID. For example, the representation of the OID of the CHUID on the PIV client-application programming interface is 2.16.840.1.101.3.7.2.48.0.

A data object SHALL be identified on the PIV Card Application card command interface using its BER-TLV tag. For example, the CHUID is identified on the card command interface to the PIV Card Application by the three-byte identifier 5FC102.

Table 2 lists the ACRs of the thirty-six PIV Card Application data objects.

5Data Types and Their Representation¶

This section describes the data types used in the PIV Client Application Programming Interface (SP 800-73-5, Part 3) and PIV Card Command Interface (SP 800-73-5, Part 2). Unless otherwise indicated, the representation SHALL be the same on both interfaces.

The data types are defined in Part 1 rather than in Parts 2 and 3 in order to achieve smart card platform independence from Part 1. Thus, non-government smart card programs can readily adopt the interface specifications in Parts 2 and 3 while customizing Part 1 to their own data model, data types, and namespaces.

5.1Key References¶

A key reference is a 1-byte reference data identifier that specifies a cryptographic key or PIN according to its PIV Key Type. Table 4, Table 5, and SP 800-78, Table 8 12, define the key reference values that SHALL be used on the PIV interfaces^[11]. For example, the key reference values are used in a cryptographic protocol, such as an authentication or a signing protocol. Key references are only assigned to private and secret (symmetric) keys, PINs, PIN Unblocking Keys (PUKs), OCC, and the pairing code. All other PIV Card Application key reference values are reserved for future use.

In accordance with FIPS 201, no more than 10 consecutive activation retries for each of the activation methods (i.e., PIN and OCC attempts) SHALL be permitted. Issuers MAY further restrict the maximum retry limit to a lower value, as indicated in Table 4 below.^[12]

Secure messaging (SM) is defined in Section 5.4, and VCI is defined in Section 5.5. Table 2 of SP 800-73-5 Part 2 specifies the security conditions for each command.

When represented as a byte, the key reference occupies bits b8 and b5-b1, while b7 and b6 SHALL be set to 0. If b8 is 0, then the key reference names global reference data. If b8 is 1, then the key reference names application-specific reference data.

The access control rules for PIV data object access SHALL reference the PIV Card Application PIN and MAY optionally reference the cardholder Global PIN or OCC data. If the Global PIN is used by the PIV Card Application, then the Global PIN format SHALL follow the PIV Card Application PIN format defined in Sec. 2.4.3 of SP 800-73-5 Part 2.

PIV Card Applications with the Discovery Object and Bit 6 of the first byte of the PIN Usage Policy value set to one, as per Section 3.3.2, SHALL reference the PIV Card Application PIN and the cardholder Global PIN in the access control rules for PIV data object access. Additionally, the PIV Card Application card commands CAN change the status of the Global PIN and MAY change its reference data while the PIV Card Application is the currently selected application.

The rest of the document uses “PIN” to mean either the PIV Card Application PIN or the Global PIN.

5.1.1OCC Data¶

This document does not specify how the biometric reference data and comparison parameters are stored internally on the card. Moreover, the export of the biometric reference data SHALL NOT be allowed. Configuration data related to the biometric reference data MAY be read from the tag 0x7F61 BIT Group template data object (see Section 3.3.6). Configuration data is defined in Table 7 of NIST SP800-76 14. The fingerprints used for OCC MAY be taken from the full set of fingerprints collected for PIV background investigations and SHOULD be imaged from fingers not imaged for off-card one-to-one comparison.

5.1.2PIV Secure Messaging Key¶

If the PIV Card supports secure messaging, the PIV Secure Messaging key SHALL be generated on the PIV Card, and the PIV Card SHALL NOT permit exportation of the PIV Secure Messaging key. The cryptographic operations that use the PIV Secure Messaging key SHALL be available through the contact and contactless interfaces of the PIV Card. The PKI cryptographic function (see Table 5) is under an “Always” access rule, and, thus private key operations (i.e., use of the key to establish session keys for secure messaging) CAN be performed without access control restrictions.

The PIV Card SHALL store a corresponding secure messaging CVC to support validation of the public key by the relying party. The format for the secure messaging CVC SHALL be as specified in SP 800-73-5 Part 2, Sec. 4.1.5. The public key required to verify the digital signature of the secure messaging CVC SHALL be provided in a certificate in the Secure Messaging Certificate Signer data object, as specified in Section 3.3.7).

5.1.3Pairing Code¶

If the PIV Card supports the virtual contact interface, then it SHALL implement support for the pairing code. If implemented, the pairing code SHALL consist of eight decimal digits, and it SHALL be generated at random by the PIV Card Issuer. The results of each random pairing code generation SHALL be loaded onto -- at most -- one PIV Card and CANNOT be changed by the cardholder. The pairing code value for a PIV Card SHALL be stored in the Pairing Code Reference Data Container (see Section 3.3.8) on the card and MAY be printed on the back of the card in an agency-specific text area (i.e., Zones 9B or 10B). PIV Card Issuers MAY choose to provide the pairing code value to the cardholder in another manner, such as printing it on a slip of paper rather than printing it on the back of the card.^[13]

Unlike the PIV Card Application PIN or the Global PIN, there are no restrictions on the caching of the pairing code by client applications. It is recommended that a client application that needs to communicate with a PIV Card over its virtual contact interface obtain the card’s pairing code during a registration step by asking the cardholder to enter the value or by reading it from the card over the contact interface from the Pairing Code Reference Data Container and then cache the pairing code until the card expires.^[14] The client application MAY then connect to the card and establish a virtual contact interface with it whenever the card is within read-range of the client application’s contactless card reader without needing to prompt the cardholder.

5.2PIV Algorithm Identifier¶

A PIV algorithm identifier is a 1-byte identifier of a cryptographic algorithm. The identifier specifies a cryptographic algorithm and key size. For symmetric cryptographic operations, the algorithm identifier also specifies a mode of operation (i.e., ECB). SP 800-78, Table 9 lists the PIV algorithm identifiers for the cryptographic algorithms that MAY be recognized on the PIV interfaces.

5.3Cryptographic Mechanism Identifiers¶

Cryptographic mechanism identifiers are defined in Table 6. These identifiers serve as inputs to the GENERATE ASYMMETRIC KEY PAIR card command and the SP 800-73-5 Part 3 pivGenerateKeyPair() client API function call, which initiates the generation and storage of the asymmetric key pair.

Higher strength keys are advised per SP 800-56 Part 1 starting in 2031. See SP 800-78-5, Tables 9 and 10, which reflect support for higher strength keys for PIV cards and supporting systems, where applicable.

All other cryptographic mechanism identifier values are reserved for future use.

5.4Secure Messaging and Authentication Using a Secure Messaging Key (SM-AUTH)¶

A PIV Card Application MAY optionally support SM. When secure messaging is established, the PIV Card Application is authenticated to the relying system, and a set of symmetric session keys are established. The symmetric session keys are used to provide confidentiality and integrity protection for the card commands that are sent to the card using secure messaging as well as for the responses from the PIV Card.

If implemented, SM for non-card management operations SHALL only be established using the PIV Secure Messaging key specified in Table 5 and the SM protocol in accordance with the specifications in Sec. 4 of SP 800-73-5 Part 2.

A PIV Card Application may optionally support authentication using the Secure Messaging key (SM-AUTH). When SM-AUTH is supported, the PIV Card and, therefore the cardholder is authenticated to the relying system.

5.5Virtual Contact Interface¶

The term “virtual contact interface (VCI)” is used in this document as shorthand for a security condition. As described in access control rules in this document and in SP 800-73-5 Part 2, all non-card management operations that are allowed over the contact interface MAY be carried out over the contactless interface if the VCI security condition is satisfied. Support for the VCI is optional.

The VCI security condition supports two different configurations for the establishment of the VCI. In the default (and recommended) configuration, the VCI is only established after both secure messaging has been established and the pairing code has been presented to the card using secure messaging. In the non-default configuration, the VCI is established through secure messaging without any further steps.

The VCI security condition is:

(command is submitted over secure messaging) AND (the Discovery Object is present) AND (Bit 4 of the first byte of the PIN Usage Policy is one) AND ((the security status indicator associated with the pairing code is TRUE) OR (Bit 3 of the first byte of the PIN Usage Policy is one))

PIV Card Applications that support the VCI SHALL support the configuration in which Bit 3 of the first byte of the PIN Usage Policy is set to zero (i.e., the configuration in which submission of the pairing code to the PIV Card Application is required to establish the VCI) and MAY additionally support the configuration in which Bit 3 of the first byte of the PIN Usage Policy is set to one. Card management systems (CMS) SHALL be configured to set Bit 3 of the first byte of the PIN Usage Policy to zero by default whenever the Discovery Object is present.

Requiring that the pairing code be submitted to the PIV Card Application in order to establish the VCI protects the previously contact-restricted X.509 certificates from skimming^[15] and also protects PIN-based card activation from being blocked. While it is recommended that the default configuration of CMSs remain unchanged, the configuration of a CMS MAY be changed to set Bit 3 of the first byte of the PIN Usage Policy to one (i.e., to configure PIV Cards to establish VCIs without the submission of a pairing code) if the configuration change is approved by the designated approving authority (DAA) and if compensating controls are implemented to ensure that personally identifiable information (e.g., name, email address, and organization) CANNOT be skimmed from the PIV Card when in close proximity when the card is outside of its protective sleeve.

A DAA’s decision to approve the issuance of PIV Cards that implement the VCI without requiring the pairing code SHALL be based on a risk assessment that weighs the perceived benefit against the risk of unauthorized disclosure of cardholder data exposing previously contact-restricted X.509 certificates to skimming. The previously contact-restricted X.509 certificates include information about the cardholder, such as name and email address. Compensating controls SHALL be captured in the appropriate system security plan.^[16] Systems that accept externally issued PIV Cards SHALL be able to accept PIV Cards with either VCI configuration.

5.6Status Words¶

A status word (SW) is a 2-byte value returned by a card command at the card edge. The first byte of a status word is referred to as SW1, and the second byte of a status word is referred to as SW2.

Recognized values of all SW1-SW2 pairs used as return values on the card command interface and their interpretation are given in Table 7. The descriptions of individual card commands provide additional information for interpreting returned status words.

References¶

The PIV data model number is 0x10, and the data model version number is 0x01.

The SP 800-73-5 specification does not provide mechanisms to read partial contents of a PIV data object. Individual access to the TLV elements within a container is not supported. For each container, compliant cards SHALL return all TLV elements of the container in the order listed in this appendix.

Both single-chip/dual-interface and dual-chip implementations are feasible. In the single-chip/dual-interface configuration, the PIV Card Application SHALL be provided with information regarding which interface is in use. In the dual-chip configuration, a separate PIV Card Application SHALL be loaded on each chip.^[17]

Note that all data elements of the following data objects are mandatory unless specified as optional or conditional. Also note that in all tables that follow, the values in the “Max. Bytes” columns denote the lengths of the value (V) fields of BER-TLV elements.

Note that he previously deprecated optional Extended Application CardURL and Security Object Buffer data elements have been eliminated in this version of SP 800-73.

Note that the Buffer Length, Organizational Identifier, and DUNS data elements have been eliminated in this version of SP 800-73.

The Error Detection Code is the same element as the Longitudinal Redundancy Code (LRC) in Technical Implementation Guidance: Smart Card Enabled Physical Access Control Systems (TIG SCEPACS) 9. It is present in the CHUID because TIG SCEPACS makes the LRC mandatory. However, this document makes no use of the Error Detection Code, and, therefore the length of the TLV value is set to 0 bytes (i.e., no value will be supplied).

Note that the MSCUID data element has been eliminated in this version. The certicate “Max. Bytes” column is the recommended length. The certificate size can exceed the indicated length value.

The fingerprint “Max. Bytes” column is the recommended length. The certificate that signed the Fingerprint I & II data element in the Cardholder Fingerprints data object can either be stored in the CHUID or in the Fingerprint I & II data element itself. For the latter, the “Max. Bytes” value quoted is a recommendation, and the signer certificate in CBEFF_SIGNATURE_BLOCK can exceed the “Max. Bytes.” Note that the use of separate content signing keys for biometric data and CHUID has been deprecated in FIPS 201-3. In future revisions, the CHUID and biometric elements will be signed with the same key. The content signing certificate will not be found in this data element but instead will be contained in the CHUID data element. Hence, the size will be as indicated in the table.

The facial image “Max. Bytes” column is the recommended length. The certificate that signed the Facial Image data element (tag 0xBC) can be stored in the CHUID or in the Facial Image data element itself. For the latter, the “Max. Bytes” value quoted is a recommendation, and the signer certificate in CBEFF_SIGNATURE_BLOCK can exceed the “Max. Bytes.” Note that the use of separate content signing keys for biometric data and CHUID has been deprecated in FIPS 201-3. In future revisions, the CHUID and biometric elements will be signed with the same key. The content signing certificate will not be found in this data element but instead will be contained in the CHUID data element. Hence, the size will be as indicated in the table.

Agencies SHOULD use tags 0x02, 0x07 and 0x08 to successfully match the printed information for verification on Zone 8F (Employee Affiliation) and Zone 10F (Agency, Department, or Organization) on the face of the card with the printed information stored electronically on the card.

Note that the MSCUID data element has been eliminated in this version. The certificate “Max. Bytes” column is the recommended length. The certificate size can exceed the indicated length value.

Note that the MSCUID data element has been eliminated in this version.

Note that the MSCUID data element has been eliminated in this version of SP 800-73. The certificate “Max. Bytes” column is the recommended length. The certificate size can exceed the indicated length value.

Note the numeric values indicated in keysWithOnCardCerts and keysWithOffCardCerts are represented as unsigned binary integers. The offCardCertURL data element shall be present if keysWithOffCardCerts is greater than zero and shall be absent if both keysWithOnCardCerts and keysWithOffCardCerts are zero. The offCardCertURL may be present if keyWithOffCardCerts is zero but keysWithOnCardCerts is greater than zero.

Note that the optional MSCUID data element was deprecated in a previous version and eliminated in this version of SP 800-73. However, historic retired key management certificates MAY still include the MSCUID element, so it is retained as an optional data element above. This applies to all of the retired key management key objects represented in Table 21 through Table 40.

Note the certificate “Max. Bytes” column in the Retired X.509 Certificate for Key Management tables are the recommended lengths. The certificate size can exceed the indicated length value.

Note the certificate “Max. Bytes” column is the recommended length. The certificate size can exceed the indicated length value.

The CertInfo byte in the certificate data objects identified in this appendix SHALL be encoded as follows:

CompressionTypeMsb SHALL be 0 if the certificate is encoded in uncompressed form and 1 if the certificate is encoded using GZIP compression.^[18] CompressionTypeLsb and IsX509 SHALL be set to 0 for PIV Card Applications. Thus, for a certificate encoded in uncompressed form, CertInfo SHALL be 0x00. For a certificate encoded using GZIP compression, CertInfo SHALL be 0x01.

The Images for Iris “Max. Bytes” column is the recommended length. The certificate that signed the Images for Iris data element (tag 0xBC) can be stored in the CHUID or in the Images for Iris data element itself. For the latter, the “Max. Bytes” value quoted is a recommendation, and the signer certificate in CBEFF_SIGNATURE_BLOCK can exceed the “Max. Bytes.” Note that the use of separate content signing keys for biometric data and CHUID has been deprecated in FIPS 201-3. In future revisions, the CHUID and biometric elements will be signed with the same key. The content signing certificate will not be found in this data element but instead will be contained in the CHUID data element. Hence, the size will be as indicated in the table

The CertInfo byte in the Secure Messaging Certificate Signer data object SHALL provide information about the X.509 Certificate for Content Signing. The Intermediate CVC, if present, shall be stored in uncompressed form. The Intermediate CVC shall be absent if the X.509 Certificate for Content Signing contains the public key needed to verify the signature on the secure messaging CVC and shall be present otherwise.

PIV authentication mechanisms and application scenarios are described in this section to provide guidelines on the usage and behavior supported by the PIV Card. FIPS 201 describes PIV authentication as “the process of establishing confidence in the identity of the cardholder presenting a PIV Card” 2. The fundamental goal of using the PIV Card is to authenticate the identity of the cardholder to a system or person that is controlling access to a protected resource or facility. This end goal MAY be reached by various combinations of one or more of the validation steps described below:

• Card Validation (CardV) -- This is the process of verifying that a PIV Card is authentic (i.e., not a counterfeit card). Card validation mechanisms include:

  • Visual inspection of the tamper-proofing and tamper-resistant features of the PIV Card, per Section 4.1.2 of FIPS 201

  • Use of cryptographic challenge-response schemes with symmetric keys

  • Use of asymmetric authentication schemes to validate private keys embedded within the PIV Card

• Credential Validation (CredV) -- This is the process of verifying the various types of credentials (e.g., visual credentials, biometrics, and certificates) held by the PIV Card. Credential validation mechanisms include:

  • Verification of certificates on the PIV Card

  • Verification of signatures on the PIV biometrics and the CHUID

  • Checking the expiration date

  • Checking the revocation status of the credentials on the PIV Card

  • Visual inspection of PIV Card visual elements^[19] (e.g., the photo, the printed name, rank).

• Cardholder Validation (HolderV) -- This is the process of establishing that the PIV Card is in the possession of the individual to whom the card was issued. Classically, identity authentication is achieved using one or more of these factors: a) something you have, b) something you know, and c) something you are. The assurance of the authentication process increases with the number of factors used. In the case of the PIV Card, these three factors translate as follows: a) something you have -- possession of a PIV Card, b) something you know -- knowledge of the PIN, and c) something you are -- the live fingerprint, facial image, or iris image samples provided by the cardholder. Thus, mechanisms for PIV cardholder validation include:

  • Presentation of a PIV Card by the cardholder

  • Matching the PIN provided with the PIN on the PIV Card

  • Matching the live fingerprint, facial image, or iris image samples provided by the cardholder with the biometric information embedded within the PIV Card

  • Matching the visual characteristics of the cardholder with the photo on the PIV Card^[20]

This section describes the activities and interactions involved in interoperable usage and authentication of the PIV Card. The authentication mechanisms represent how a relying party will authenticate the cardholder (regardless of which agency issued the card) in order to provide access to its systems or facilities. These activities and interactions are represented in functional authentication mechanism diagrams. These diagrams are not intended to provide syntactical commands or API function names.

Each of the PIV authentication mechanisms described in this section can be broken into a sequence of one or more validation steps where Card, Credential, and Cardholder validation is performed. In the illustrations, the validation steps are marked as CardV, CredV, and HolderV to signify Card, Credential, and Cardholder validation, respectively.

Depending on the assurance provided by the actual sequence of validation steps in a given PIV authentication mechanism, relying parties can make appropriate decisions for granting access to protected resources based on a risk analysis.

The assurance of authentication using PIV biometrics CAN be further increased if the live biometric sample is collected in an attended environment with a human overseeing the process. The attended biometric authentication mechanism (BIO-A) is illustrated in Figure 2.

Figure 3 shows the authentication mechanism using the PIV Authentication key.

Authentication mechanisms using the Card Authentication key are illustrated in Figure 4 and Figure 5. Figure 4 illustrates the use of the mandatory asymmetric Card Authentication key, while (#pt1-fig-symmetric-card-auth-key-deprecated) uses the deprecated, optional symmetric Card Authentication key for the authentication mechanism. Note that the symmetric card authentication key has been deprecated in FIPS 201-3 and MAY be removed in a future version of the standard.

The OCC-AUTH authentication mechanism is implemented by performing OCC over secure messaging. The PIV Application authenticates the PIV Card as part of the process of establishing secure messaging. When the live-scan fingerprint biometric is supplied to the card for OCC over secure messaging, both the request and the response are protected using message authentication codes (MAC), allowing the PIV Application on the local system to verify that the response has not been altered and that it was created by the PIV Card that was authenticated during the establishment of secure messaging.

The OCC-AUTH authentication mechanism is performed by establishing secure messaging as described in Sec. 4 of SP 800-73-5 Part 2 and then performing the VERIFY command, as illustrated in Figure 6.

Figure 7 shows the deprecated authentication mechanism in which a human guard authenticates the cardholder using the visual credentials held by the PIV Card. The authentication mechanism has been deprecated in FIPS 201-3 and MAY be removed from a future edition of the standard.

The content of this section has been removed since the CHUID as an authentication mechanism is no longer allowed under FIPS-201. However, the CHUID data element itself remains on-card to support other authentication mechanisms. For example, the BIO and BIO-A authentication mechanisms use the CHUID data element as a source for the card’s expiration date. The CHUID data element also provides the content signing certificate for these authentication mechanisms as well as unique identifiers for PACS ACLs.

If the PIV Card supports the secure messaging protocol, then the secure messaging key, corresponding CVC, and key establishment protocol (see Sec. 4 of SP 800-73-5 Part 2) CAN be used for authentication of the PIV Card and the cardholder (SM-AUTH). The secure messaging protocol authenticates the PIV Card via the secure messaging key. Any established session keys SHALL be zeroized after authentication if bits b3 and b4 of subsequent command CLA bytes are set to zero.

Figure 8 shows the authentication mechanism using the secure messaging key.

Table 46 summarizes the types of validation activities that are included in each of the PIV authentication mechanisms described earlier in this section.

Relying parties interact with many PIV Cards with the same native key type implemented by different key sizes and algorithms.^[21] For example, a relying party performing the authentication mechanism described in Appendix B.1.2 CAN expect to perform a challenge and response cryptographic authentication with a 3072-bit or a 2048-bit RSA key or an ECDSA (Curve P-256 or Curve P-384) key.

This appendix describes recommended procedures for key size and algorithm discovery (PIV algorithm ID discovery) to facilitate cryptographic authentication initiated by the relying party to make appropriate decisions for granting access to logical networks and systems as well as physical access control systems. The discovery procedure is defined in terms of asymmetric and symmetric cryptographic authentication.

As illustrated in the authentication mechanisms in Appendix B, an asymmetric cryptographic authentication involves issuing a challenge (request to sign a nonce) to the PIV Card. The relying party issuing the command provides the nonce to be signed, the key reference, and the PIV algorithm identifier as parameters of the command. The nonce is random data generated by the relying party, and the key reference is known. In contrast, the PIV algorithm identifier is unknown to the relying party and needs to be identified in order to issue the challenge command. The PIV algorithm identifier CAN be derived from the previous steps of the authentication mechanism. Prior to issuing the challenge command, the relying party retrieved and parsed the X.509 certificate from the card to validate the certificate and extract the public key for the pending verification of the signed nonce once returned from the card. The PIV algorithm identifier CAN be identified during the parsing of the X.509 certificate in two steps:^[22]

Step 1: Algorithm Type Discovery

The X.509 certificate stores the public key in the subjectPublicKeyInfo field. The subjectPublicKeyInfo data structure has an algorithm field, which includes an OID that identifies the public key’s algorithm (RSA or ECC), as listed in Table 4 of SP 800-78.

Step 2: Key Size Discovery

If the algorithm type determined in Step 1 is ECC, then the key size is determined by the elliptic curve on which the key has been generated, which is P-256 or P-384 for all elliptic curve PIV Authentication keys and Card Authentication keys.

If the algorithm type determined in Step 1 is RSA, then the key size is determined by the public key’s modulus. The public key appears in the subjectPublicKey field of subjectPublicKeyInfo and is encoded as a sequence that includes both the key’s modulus and public exponent.

As a final step, the discovered X.509 algorithm OID and key size are mapped to the PIV algorithm identifiers, as defined in Table 9 of SP 800-78. The relying party then proceeds to issue the GENERAL AUTHENTICATE command to the card.

In the absence of an X.509 certificate, as is the case with symmetric cryptography, the PIV algorithm identifier discovery mechanism has to rely on a lookup table that resides on the local system. The table maps a unique card identifier and key reference (inputs) to an associated PIV algorithm identifier (output). The unique identifier supplied by the card MAY be the Agency Code || System Code || Credential Number of the FASC-N or the Card UUID.

The symmetric Card Authentication key is optional to implement, and a relying party has no prior knowledge of the key’s existence. The following routine discovers the Card Authentication key’s native implementation:

• Read the CHUID, and extract either the Card UUID or the Agency Code || System code || Credential Number from the CHUID’s FASC-N.

• Retrieve the PIV algorithm identifier from the local lookup table. If no algorithm identifier is returned, authentication CANNOT be performed using the optional symmetric Card Authentication key, either because the PIV Card does not implement the key or the local system CANNOT authenticate the response from the card.

The Application Property Template included in the response to the SELECT command optionally includes a tag 0xAC, which indicates what cryptographic algorithms the PIV Card Application supports. The presence of algorithm identifier 27 or 2E indicates that the corresponding cipher suite is supported by the PIV Card Application for secure messaging and that the PIV Card Application possesses a PIV Secure Messaging key of the appropriate size for the specified cipher suite.

The 16 hexadecimal digits SHALL be denoted using the alphanumeric characters 0, 1, 2, ..., 9, A, B, C, D, E, and F. A byte consists of two hexadecimal digits, such as '2D'. The two hexadecimal digits are represented as 2D or as 0x2D. A sequence of bytes MAY be enclosed (e.g., A0 00 00 01 16) rather than given as a sequence of individual bytes (e.g., A0 00 00 01 16).

A byte can also be represented by bits b8 to b1, where b8 is the most significant bit (MSB) and b1 is the least significant bit (LSB) of the byte. In textual or graphic representations, the leftmost bit is the MSB. Thus, for example, the most significant bit b8 of 80 is 1, and the least significant bit b1 is 0.

All bytes specified as RFU SHALL be set to 00, and all bits specified as RFU SHALL be set to 0.

All lengths SHALL be measured in number of bytes unless otherwise noted.

The expression $X \land Y$ is a bitwise AND operation between bytes $X$ and $Y$.

The symbol $||$ means a concatenation of byte strings. For example, if $X$ is 00 01 02 and $Y$ is 03 04 05, then $X || Y$ is 00 01 02 03 04 05.

Data objects in templates are described as being mandatory (M), optional (O), or conditional (C). Mandatory means that the data object SHALL appear in the template. Optional means that the data object MAY appear in the template. For conditional data objects, the conditions under which they are required are provided.

In other tables, the M/O/C column identifies the properties of the PIV Card Application that SHALL be present (M), MAY be present (O), or are conditionally required to be present (C).

BER-TLV data object tags are represented as byte sequences, as described above. Thus, for example, 0x4F is the interindustry data object tag for an application identifier, and 0x7F61 is the interindustry data object tag for the Biometric Information Templates Group template.

This document uses the following typographical conventions in text:

• Specific terms in CAPITALS represent normative requirements. When these same terms are not in CAPITALS, the term does not represent a normative requirement.

• The terms SHALL and SHALL NOT indicate requirements to be strictly followed in order to conform to the publication and from which no deviation is permitted.

• The terms SHOULD and SHOULD NOT indicate that among several possibilities, one is recommended as particularly suitable without mentioning or excluding others, that a certain course of action is preferred but not necessarily required, or that --- in the negative form --- a certain possibility or course of action is discouraged but not prohibited.

• The terms MAY and NEED NOT indicate a course of action that is permissible within the limits of the publication.

• The terms CAN and CANNOT indicate a material, physical, or causal possibility or capability or -- in the negative -- the absence of that possibility or capability.

SP 800-73
Release Date: April 2005

• Initial Release

SP 800-73-1
Release Date: April 2006

• Incorporated Errata

SP 800-73-2
Release Date: September 2008

• Separated SP 800-73 into four Parts:

  1. End-Point PIV Card Application Namespace, Data Model, and Representation

  2. End-Point PIV Card Application Card Command Interface

  3. End-Point PIV Client Application Programming Interface

  4. The PIV Transitional Interface and Data Model Specification

• All PIV cryptographic key types, cryptographic algorithm identifiers, and key sizes previously listed in SP 800-73-1 are now specified in SP 800-78, Cryptographic Algorithms and Key Sizes for Personal Identity Verification

• Removed default algorithms. Each PIV Key Type CAN be implemented from a small subset of algorithms and key sizes, as specified in Table 1 of SP 800-78.

• Added optional Discovery Object (Part 1, Sec. 3.2.6)

• Added optional capability to use the Global PIN (in addition to the PIV Card Application PIN) with the PIV Card Application (Part 1, Sec. 3.2.6)

• Added pivMiddlewareVersion API function (Part 3, Sec. 3.1.1)

• Deprecated the CHUID data object’s Authentication Key Map data element

• Deprecated the Printed Information data object’s Employee Affiliation Line 2 data element (tag 0x03)

• Removed size limits on signed data object containers (Part 1, Appendix A)

SP 800-73-3
Release Date: February 2010

• Added preamble sections: I — Revision History; II — Configuration Management; III — NPIVP Conformance Testing (Part 1)

• Removed the CHUID data object’s Authentication Key Map data element

• Removed the Printed Information data object’s Employee Affiliation Line 2 data element (tag 0x03)

• Deprecated IPv6 as optional value for the CHUID’s GUID data element (Part 1, Sec. 3.2.1)

• Added Key History capability (Part 1, Sec. 3.2.7)

• Added ECDH key agreement scheme (Part 2, Sec. 3.2.4)

• Added UUID feature for non-Federal issuer cards (Part 1, Sec. 3.3)

• Expanded Part 2, Appendix A (GENERAL AUTHENTICATE examples) to illustrate ECDSA signatures and key establishment schemes

• Added an optional cardholder iris images data object (specified in SP 800-76-2)

• Added Appendix C, PIV Algorithm Identifier Discovery

• Updated PIV Middleware version number in Part 3

SP 800-73-4
Release Date: April 2015

• Removed Part 4 (PIV Transitional Data Model and Interfaces)

• Removed “End-Point” from Parts 1–3

• Added Sec. 1.3 “Effective Date”

• Made asymmetric Card Authentication key mandatory

• Made digital signature key and key management key conditionally mandatory

• Made facial image data object mandatory

• Introduced optional secure messaging

• Introduced optional virtual contact interface (VCI)

• Added support for pairing code to establish VCI

• Made Card UUID mandatory and removed IPv6 / zero GUID options

• Added card-level PIN length enforcement requirements

• Added optional Cardholder UUID

• Removed NFI card encoding information

• Added optional on-card biometric comparison (OCC)

• Added signature verification and certification path validation requirements

• Added OCC Biometric Information (BIT) Group template

• Added Secure Messaging Signer Certificate Data Object

• Added Pairing Code Reference Data Container

• Deprecated legacy CHUID and certificate data elements (MSCUID, etc.)

• Updated Middleware version number

• Expanded Algorithm Identifier Discovery for Secure Messaging

• Expanded GENERAL AUTHENTICATE examples to illustrate VCI

SP 800-73-4 (Errata Update)
Release Date: February 8, 2016

• Relaxed interface requirements for RESET RETRY COUNTER, PUT DATA, and GENERATE ASYMMETRIC KEY PAIR over contactless interface

• Allowed VERIFY with additional key references for card management

• Removed requirement for specific error status words (6A 81, 69 82) for interface violations

• Allowed CHANGE REFERENCE DATA with additional key references

• Allowed RESET RETRY DATA with additional key references

• Updated retry counts in Authentication Data References table

SP 800-73pt1-5
Release Date: July 2024

• Removed the previously deprecated Extended Application CardURL and Security Object Buffer elements from the Card Capability Container

• Removed the previously deprecated Buffer Length, DUNS, and Organizational Identifier elements from the CHUID data object

• Removed the previously deprecated MSCUID element from all X.509v3 Certificate data objects other than certificates for retired key management keys

• Deprecated SYM-CAK and VIS authentication mechanisms

• Removed previously deprecated CHUID authentication mechanism

• Added SM-AUTH as an additional, optional single-factor authentication mechanism

• Deprecated use of separate content signing keys for biometric data and CHUID

• Restricted the number of consecutive activation retries (PIN and OCC) to 10 or fewer

• Marked Part 3 as optional

• Added the use of the facial image biometric for automated facial comparison through BIO and BIO-A authentication mechanisms

• Enabled OCC reset through CHANGE REFERENCE DATA command in Part 2

• Updated allowed cryptographic algorithms to match SP 800-78-5

• Specified fingerprint sourcing requirements for OCC

• Updated container minimum capacity for many PIV Data Containers

• Deleted incompatibility details from the Configuration Management section

• Clarified immutability of Card UUID, Expiration Date, and Cardholder UUID post-issuance

• Clarified that NPIVP conformance testing will no longer be performed for PIV Middleware

• Moved errata changes in SP 800-73-4 into the Revision History

• Added an optional Cardholder UUID to the PIV Authentication Certificate (may also be represented in the CHUID data object)