NIST Special Publication 800-73-2 Interfaces for Personal Identity 

Verification – Part 4: The PIV 

Transitional Interface and Data 

Model Specification

September 2008

U.S. Department of Commerce

Carlos M. Gutierrez, Secretary

I N F O R M A T I O N S E C U R I T Y

National Institute of Standards and Technology

James M. Turner, Deputy Director 

Ramaswamy Chandramouli

James F. Dray

Hildegard Ferraiolo

Scott B. Guthery

William MacGregor

Ketan Mehta

Information Technology Laboratory

National Institute of Standards and Technology

Gaithersburg, MD, 20899-8930
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 4: 

 The PIV Transitional Interfaces and Data Model Specification 

 Page i 

Reports on Computer Systems Technology 

The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology 

(NIST) promotes the U.S. economy and public welfare by providing technical leadership for the 

Nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, 

proof of concept implementations, and technical analyses to advance the development and productive 

use of information technology. ITL’s responsibilities include the development of management, 

administrative, technical, and physical standards and guidelines for the cost-effective security and 

privacy of non-national security-related information in Federal information systems. This special 

publication 800-series reports on ITL’s research, guidelines, and outreach efforts in information system 

security, and its collaborative activities with industry, government, and academic organizations. 

National Institute of Standards and Technology Special Publication 800-73-2, Part 4, 

18 pages, (September 2008) 

Certain commercial entities, equipment, or materials may be identified in this document in order to 

describe an experimental procedure or concept adequately. Such identification is not intended to imply 

recommendation or endorsement by the National Institute of Standards and Technology, nor is it intended 

to imply that the entities, materials, or equipment are necessarily the best available for the purpose. 

NIST makes no representation as to whether or not one or more implementations of SP 800-73-2 is/are 

covered by existing patents. 
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 4: 

 The PIV Transitional Interfaces and Data Model Specification 

 Page ii 

Acknowledgements 

The authors (Ramaswamy Chandramouli, James Dray, Hildegard Ferraiolo, William MacGregor of 

NIST, Ketan Mehta of Mehta Inc., and Scott Guthery of Mobile Mind Inc) wish to thank their 

colleagues who reviewed drafts of this document and contributed to its development. Special thanks to 

the Government Smart Card Interagency Advisory Board (GSC-IAB) and InterNational Committee for 

Information Technology Standards (INCITS) for providing detailed technical inputs to the SP 800-73-2 

development process. The authors also gratefully acknowledge and appreciate the many contributions 

from the public and private sectors whose thoughtful and constructive comments improved the quality 

and usefulness of this publication. 
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 4: 

 The PIV Transitional Interfaces and Data Model Specification 

 Page iii 

TABLE OF CONTENTS 

U1.U UINTRODUCTIONU .......................................................................................................................................... 1

U1.1U UAUTHORITYU.................................................................................................................................................. 1

U1.2U UPURPOSEU ...................................................................................................................................................... 1

U1.3U USCOPEU .......................................................................................................................................................... 2

U1.4U UAUDIENCE AND ASSUMPTIONSU..................................................................................................................... 2

U1.5U UDOCUMENT OVERVIEW AND STRUCTUREU .................................................................................................... 2

U2.U UOVERVIEW AND MIGRATION CONSIDERATIONSU............................................................................ 3

U2.1U UMIGRATION CONSIDERATIONSU..................................................................................................................... 3

U2.2U UPIV DATA MODELU ....................................................................................................................................... 4

U2.3U UMANDATORY DATA ELEMENTSU ................................................................................................................... 5

U2.3.1U UCard Capability ContainerU ................................................................................................................ 5

U2.3.2U UCardholder Unique IdentifierU ............................................................................................................ 5

U2.3.3U UX.509 Certificate for PIV AuthenticationU........................................................................................... 6

U2.3.4U UCardholder FingerprintsU.................................................................................................................... 6

U2.3.5U USecurity ObjectU................................................................................................................................... 7

U2.4U UOPTIONAL DATA ELEMENTSU ........................................................................................................................ 7

U2.4.1U UCardholder Facial ImageU .................................................................................................................. 7

U2.4.2U UPrinted InformationU ........................................................................................................................... 7

U2.4.3U UX.509 Certificate for Digital SignatureU.............................................................................................. 7

U2.4.4U UX.509 Certificate for Key ManagementU ............................................................................................. 8

U2.4.5U UX.509 Certificate for Card AuthenticationU......................................................................................... 8

U2.4.6U UDiscovery ObjectU ............................................................................................................................... 8

U3.U UTRANSITION CARD INTERFACESU........................................................................................................ 10

U3.1U UMIDDLEWARE APPLICATION PROGRAMMING INTERFACEU .......................................................................... 10

U3.2U UCARD EDGE COMMANDSU............................................................................................................................ 10

List of Appendices 

UAPPENDIX A— TERMS, ACRONYMS, AND NOTATIONU........................................................................... 11

UA.1U UTERMSU................................................................................................................................................... 11

UA.2U UACRONYMSU ........................................................................................................................................... 11

UA.3U UNOTATIONU............................................................................................................................................. 12

UAPPENDIX B— REFERENCESU ......................................................................................................................... 14

List of Tables 

UTable 1. Data Model ContainersU ..................................................................................................4
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 4: 

 The PIV Transitional Interfaces and Data Model Specification

 Page 1 

1. 0BIntroduction 

The Homeland Security Presidential Directive 12 (HSPD-12) called for a common identification 

standard to be adopted governing the interoperable use of identity credentials to allow physical and 

logical access to Federal government locations and systems. The Personal Identity Verification (PIV) 

of Federal Employees and Contractors, Federal Information Processing Standard 201 (FIPS 201) [1] 

was developed to establish standards for identity credentials. Special Publication 800-73-2 (SP 800-

73-2) specifies interface requirements for retrieving and using the identity credentials from the PIV 

CardF

1

F and is a companion document to FIPS 201. 

1.1 3BAuthority 

This document has been developed by the National Institute of Standards and Technology (NIST) in 

furtherance of its statutory responsibilities under the Federal Information Security Management Act 

(FISMA) of 2002, Public Law 107-347. 

NIST is responsible for developing standards and guidelines, including minimum requirements, for 

providing adequate information security for all agency operations and assets, but such standards and 

guidelines shall not apply to national security systems. This recommendation is consistent with the 

requirements of the Office of Management and Budget (OMB) Circular A-130, Section 8b(3), 

Securing Agency Information Systems, as analyzed in A-130, Appendix IV: Analysis of Key 

Sections. Supplemental information is provided A-130, Appendix III. 

This recommendation has been prepared for use by federal agencies. It may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright though attribution is 

desirable. Nothing in this document should be taken to contradict standards and guidelines made 

mandatory and binding on Federal agencies by the Secretary of Commerce under statutory authority. 

Nor should this recommendation be interpreted as altering or superseding the existing authorities of 

the Secretary of Commerce, Director of the Office of Management and Budget (OMB), or any other 

Federal official. 

1.2 4BPurpose 

FIPS 201 defines procedures for the PIV lifecycle activities including identity proofing, registration, 

PIV Card issuance, and PIV Card usage. FIPS 201 also specifies that the identity credentials must be 

stored on a smart card. SP 800-73-2 contains technical specifications to interface with the smart 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, SP 800-73-2 enumerates 

requirements where the standards include options and branches. The specifications go further by 

constraining implementers’ interpretations of the normative standards. Such restrictions are designed 

to ease implementation, facilitate interoperability, and ensure performance, in a manner tailored for 

PIV applications. 

 

1

 A physical artifact (e.g., identity card, “smart” card) issued to an individual that contains stored identity credentials (e.g., 

photograph, cryptographic keys, biometric data) so that the claimed identity of the cardholder can be verified against 

the stored credentials by another person (human readable and verifiable) or an automated process (computer readable 

and verifiable). 
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 4: 

 The PIV Transitional Interfaces and Data Model Specification

 Page 2 

1.3 5BScope 

SP 800-73-2 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 elaborated in Appendix B of SP 800-73-2 Part 1. Interoperability is defined as the use of 

PIV identity credentials such that client-application programs, compliant card applications, and 

compliant integrated circuits cards (ICC) can be used interchangeable by all information processing 

system across Federal agencies. 

Part 2, 3 and 4 of SP 800-73-2 describes two realizations of the client application programming and 

card command interfaces for personal identity verification: the transitional interfaces (this Part 4) and 

the end-point interfaces (Part 2 and 3). The transitional interface may be used by agencies with an 

existing identity card program as an optional intermediate step in evolving to the end-point interfaces. 

This part, Special Publication 800-73-2, Part 4 The PIV Transitional Interfaces and Data Model 

Specification contains informative links to specifications of the transitional PIV card command 

interface and client application programming interface of the transitional PIV card. Part 4 also 

describes the PIV Data Model that is common between End-Point and transitional interface 

specifications. 

1.4 6BAudience and Assumptions 

This document is targeted at Federal agencies and implementers of PIV systems. Readers are 

assumed to have a working knowledge of smart card standards and applications. 

1.5 7BDocument Overview and Structure 

All sections in this document are normative (i.e., mandatory for compliance) unless specified as 

informative (i.e., non-mandatory). Following is the structure of this document: 

Part 4 is organized as follows: 

+ Section 1, Introduction, provides the purpose, scope, audience, and assumptions of the 

document and outlines its structure. 

+ Section 2: Common Data Model and Migration Considerations provides the specification 

that is common to both the transitional and end-point interfaces. Section 2 also includes 

guidelines as to strategies for migrating from the transitional interfaces to the end-point 

interfaces. 

+ Section 3: The Transitional Interfaces provides links to transitional interface specification 

that are implemented today by agencies with legacy GSC-IS based card deployments. This 

section is informative. 

 Appendix A, Terms, Acronyms, and Notation, contains the list of Terms and Acronyms used 

in this document and explains notation in use. This section is informative. 

 Appendix B, References, contains the list of documents used as references by this document. 

This section is informative.
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 4: 

 The PIV Transitional Interfaces and Data Model Specification

 Page 3 

2. 1BOverview and Migration Considerations 

2.1 8BMigration Considerations 

SP 800-73-2 Parts 1 - 4 provide two interface specifications: 1) a transitional card specification as 

described in this Part 4; and 2) a FIPS 201 End-Point card specification as described in Parts 1- 3 of 

SP 800-73-2. Part 4 interface specifications are informative PIV profile derived from the 

Government Smart Card Interoperability Specification (GSC-IS), Version 2.1 [2]. It presents one 

possible path that agencies with existing GSC-IS based smart card deployments may choose to follow 

during the transition to End-Point PIV card deployment. All agencies must ultimately comply with 

End-Point specifications in accordance with the schedule provided by the Office of Management and 

Budget (OMB). End-Point deployment is therefore the end state of each agency's transition plan. 

Agencies may either elect to implement an approved transitional specification as specified in this 

document (Part 4), particularly when migrating from currently widely implemented identity card 

architectures to the End-Point specifications described in Parts 1- 3 of SP 800-73-2, or to implement 

the End-Point specification directly. NIST supports agency efforts towards government-wide PIVEnd-Point interoperability described in the Parts 1 - 3 specification. NIST also supports transition 

specifications of Part 4 for widely implemented deployments as they migrate towards the End-Point 

specifications. 

The migration path to End-Point implementation is based on continuity of the PIV data model. 

Exactly the same data appear on both the transitional and end-point interfaces. Therefore, description 

of the data for personal identity verification, the PIV data model, is duplicated from the Part 1 

(Section 3) in Section 2.2 belowF

2

F. 

Specific considerations associated with this migration path are highlighted below: 

+ The transitional specifications present a subset of the dual GSC-IS card edge interfaces. 

The End-Point specifications present a unified card edge interface that is technology 

independent and compliant with existing international standards. 

+ The End-Point specifications provide limited credential administration functionality. A 

unified and interoperable card management solution between issuing domains including 

the loading of new card applications is not provided. 

+ Named data objects within the data model may be directly accessed. If a data object is 

managed by the default application, it can be retrieved directly without selecting the 

application. This avoids a requirement to search through discovery to get named data 

objects. Otherwise, the (non-default) application managing the data object is selected and 

the data object is retrieved from this application. The GET DATA command described in 

Part 2 retrieves a data object in one command. 

+ The data model including the data model namespace is controlled by NIST and hence 

change management of well known and interoperable data objects will be managed by 

NIST in the process of managing the overall data model. As a first step in namespace 

management, the data object identifiers of GSC-IS and transitional systems in the range 

 

2

Although the same data objects are present on the end-point and transitional interfaces, different 

representations for the same data objects may be used. 
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 4: 

 The PIV Transitional Interfaces and Data Model Specification

 Page 4 

'0000' through '9FFF' will be explicitly managed by NIST and data object identifiers of 

GSC-IS and transitional systems in the range 'A000' through 'FFFF' are placed under 

control of the card issuer. 

+ Each application managing one or more of the directly addressable data model data 

objects will have a version number enabling the relying application to determine the level 

of the information contained within the object. The version of the End-Point PIV Card 

Application is encoded in its full Application IDentifier (AID) which is returned when 

this application is selected. This is in addition to the Card Capability Container (CCC) 

style data model naming facility carried over from GSC-IS. 

+ Agency-specific applications can be included on cards containing PIV applications. 

These applications may define and manage their own namespaces that are used when the 

application is used. Such applications will have application identifiers outside the 

application namespace managed by NIST; that is, application identifiers not rooted on the 

NIST Registered application provider IDentifier (RID). 

2.2 9BPIV Data Model 

Table 1 defines a high level view of the data model. Each on-card storage container is labeled either 

as Mandatory (M) or Optional (O). This data model is designed to enable and support dual interface 

cards. Note that access conditions based on the interface mode (contact vs. contactless) take 

precedence over all Access Rules defined in Table 1, Column 3. 

Table 1. Data Model Containers 

Container Name Container

ID 

Access 

Rule for 

Read 

Contact / ContactlessF

3

F M/O 

Card Capability Container 0xDB00 Always Contact M 

Cardholder Unique Identifier 0x3000 Always Contact and Contactless M 

X.509 Certificate for PIV 

Authentication 

0x0101 Always Contact M 

Cardholder Fingerprints 0x6010 PIN Contact M 

Security Object 0x9000 Always Contact M 

Cardholder Facial Image 0x6030 PIN Contact O 

Printed Information 0x3001 PIN Contact O 

X.509 Certificate for Digital 

Signature 

0x0100 Always Contact O 

X.509 Certificate for Key 

Management 

0x0102 Always Contact O 

X.509 Certificate for Card 

Authentication 

0x0500 Always Contact and Contactless O 

Discovery Object 0x6050 Always Contact and Contactless O 

Part 1, 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 and in accordance with SP 800-73-2 

naming conventions. 

 

3

 Contact interface mode means the container is accessible through contact interface only. Contact and contactless interface 

mode means the container can be accessed from either interface. 
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 4: 

 The PIV Transitional Interfaces and Data Model Specification

 Page 5 

A PIV Card Application shall contain five mandatory interoperable data objects and may contain six 

optional interoperable data objects. The five mandatory data objects for interoperable use are as 

follows: 

1. Card Capability Container 

2. Cardholder Unique Identifier 

3. X.509 Certificate for PIV Authentication 

4. Cardholder Fingerprints 

5. Security Object 

The six optional data objects for interoperable use are as follows: 

1. Cardholder Facial Image 

2. Printed Information 

3. X.509 Certificate for Digital Signature 

4. X.509 Certificate for Key Management 

5. X.509 Certificate for Card Authentication 

6. Discovery Object 

2.3 10BMandatory Data Elements 

The five mandatory data objects support FIPS 201 minimum mandatory compliance. 

2.3.1 14BCard Capability Container 

The Card Capability Container (CCC) is mandatory for compliance with GSC-IS. It supports 

minimum capabilities for retrieval of data model and application information. 

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 name space and structure as defined in this document. 

2.3.2 15BCardholder Unique Identifier 

The Cardholder Unique Identifier (CHUID) data object is defined in accordance with the Technical 

Implementation Guidance: Smart Card Enabled Physical Access Control Systems (TIG SCEPACS) 

[4]. For this specification, the CHUID is common between the contact and contactless chips. 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 Buffer Length field is an optional TLV element. This element is the length in bytes 

of the entire CHUID, excluding the Buffer Length element itself, but including the 

CHUID's Asymmetric Signature element. The calculation of the asymmetric signature 

must exclude the Buffer Length element if it is present. 

+ The Federal Agency Smart Credential Number (FASC-N) shall be in accordance with 

TIG SCEPACS[4]. A subset of FASC-N, the FASC-N Identifier, shall be the unique 

identifier as described in [4, 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 
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 4: 

 The PIV Transitional Interfaces and Data Model Specification

 Page 6 

individual”. The Agency Code is assigned to each Department or Agency by Special 

Publication 800-87 (SP 800-87) Codes for the Identification of Federal and FederallyAssisted Organizations [5]. 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 the PIV data objects 

that include the FASC-N. To eliminate unnecessary use of the SSNF

4

F, the FASC-N’s 

Person Identifier (PI) field should not encode the SSN. TIG SCEPACS also specifies 

PACS interoperability requirements in section 2.1, 10th paragraph of [4, 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 Identifier (GUID) field must be present, and may include either an 

issuer assigned IPv6 address or be coded as all zeros. The GUID is included to enable 

future migration away from the FASC-N into a robust numbering scheme for all issued 

credentials. 

+ The DUNS and Organizational Code fields are optional. 

+ The Authentication Key MapF

5

F is specified as an optional field which enables the 

application to discover the key reference. 

+ 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 as YYYYMMDD. 

+ The CHUID is signed in accordance with FIPS 201. 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. 

2.3.3 16BX.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 read access control rule for the X.509 

Certificate for PIV Authentication is “Always,” meaning the certificate can be read without access 

control restrictions. The Public Key Infrastructure (PKI) cryptographic function (see Table 3) is 

protected with a "PIN" access rule. In other words, private key operations using the PIV 

Authentication Key require the Personal Identification Number (PIN) to be submitted, but a 

successful PIN submission enables multiple private key operations without additional cardholder 

consent. 

2.3.4 17BCardholder Fingerprints 

The fingerprint data object specifies the primary and secondary fingerprints in accordance with the 

FIPS 201. The Common Biometric Exchange Formats Framework (CBEFF) header shall contain the 

FASC-N and shall require the Integrity Option. The header shall not require the Confidentiality 

Option. 

 

4

 See the attachment to OMB M-07-16, Section 2: “Reduce the Use of Social Security Numbers”. 

5

 The Authentication Key Map is deprecated. It will be eliminated in a future revision of SP 800-73. 
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 4: 

 The PIV Transitional Interfaces and Data Model Specification

 Page 7 

2.3.5 18BSecurity Object 

The Security Object is in accordance with Appendix C of PKI for Machine Readable Travel 

Documents (MRTD) Offering ICC Read-Only Access Version 1.1 [6]. 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 triples - 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(s) in the DataGroupHash(es). This will ensure 

that the ContainerIDs in the mapping object refers to the correct hash value in the Security Object 

(0xBB). 

The 0xBB Security Object is formatted according to the MRTD [5, Appendix C]. The LDS Security 

Object itself must be in ASN.1 DER format, formatted as specified in [5, Appendix C.2]. This 

structure is then inserted into the encapContentInfo field of the Cryptographic Message Syntax 

(CMS) object specified in [5, Appendix C.1]. 

The card issuer's 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 certificate, since 

it is included in the CHUID. At a minimum, unsigned data objects, such as the Printed Information 

data object, shall be included in the Security Object if present. For maximum protection against 

credential splicing attacks (credential substitution), it is recommended, however, that all PIV data 

objects, except the PIV X.509 certificates, be included in the Security Object. 

2.4 1BOptional Data Elements 

The six optional data elements of FIPS 201, when implemented, shall conform to the specifications 

provided in this document. 

2.4.1 19BCardholder Facial Image 

The photo on the chip supports human verification only. It is not intended to support facial 

recognition systems for automated identity verification. 

2.4.2 20BPrinted Information 

All FIPS 201 mandatory information printed on the card is duplicated on the chip in this data object. 

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. 

2.4.3 21BX.509 Certificate for Digital Signature 

The X.509 Certificate for Digital Signature and its associate private key, as defined in FIPS 201, 

support the use of digital signatures for the purpose of document signing. The read access control rule 

for the X.509 Certificate is “Always”, meaning the certificate can be read without access control 

restrictions. The Public Key Infrastructure (PKI) cryptographic function is protected with a “PIN 

Always” access rule. In other words, the PIN must be submitted every time immediately before a 
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 4: 

 The PIV Transitional Interfaces and Data Model Specification

 Page 8 

Digital Signature Key operation. This ensures cardholder participation every time the private key is 

used for digital signature generation. 

2.4.4 2BX.509 Certificate for Key Management 

The X.509 Certificate for Key Management and its associate private key, as defined in FIPS 201, 

support the use of encryption for the purpose of confidentiality. This key pair is escrowed by the 

issuer for key recovery purposes. The read access control rule for the X.509 Certificate is “Always”, 

meaning the certificate can be read without access control restrictions. The PKI cryptographic 

function is protected with a “PIN” access rule. In other words, once the PIN is submitted, subsequent 

Key Management Key operations can be performed without requiring the PIN again. This enables 

multiple private key operations without additional cardholder consent. 

2.4.5 23BX.509 Certificate for Card Authentication 

FIPS 201 specifies the optional Card Authentication Key (CAK) as an asymmetric or symmetric key 

that is used to support additional physical access applications. For an asymmetric CAK, the read 

access control rule of the corresponding X.509 Certificate for Card Authentication is “Always”, 

meaning the certificate can be read without access control restrictions. Private (asymmetric) key 

operations or secret symmetric cryptographic operation is defined as “Always”. In other words, the 

private or secret key can be used without access control restrictions. With extremely high probability, 

each PIV Card shall contain a unique CAK. 

2.4.6 24BDiscovery Object 

The Discovery Object, if implemented, is the 0x7E interindustry ISO/IEC 7816-6 template that nests 

interindustry data objects. For the Discovery Object, the 0x7E template nests two 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 as follows: 

First byte: 0x40 indicates that the PIV Card Application PIN alone satisfies the PIV 

Access Control Rules (ACRs) for command executionF

6

F and object 

access. 

0x60 indicates that both the PIV Card Application PIN and Global PIN 

satisfy the PIV ACRs for command execution and PIV data object 

access. 

Bits 5 through 1 of the first byte are RFU. 

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: 

Second byte: 0x10 indicates that the PIV Card Application PIN is the primary PIN used 

to satisfy the PIV ACRs for command execution and object access. 

 

6

 Command execution pertains to the VERIFY APDU and optionally to the CHANGE REFERENCE DATA APDU. 
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 4: 

 The PIV Transitional Interfaces and Data Model Specification

 Page 9 

 0x20 indicates that the Global PIN is the primary PIN to satisfy the PIV 

ACRs for command execution and object access. 

Note: If the first byte is set to 0x40, then second byte is RFU and shall be set to 0x00. 

PIV Card Application that satisfy the PIV ACRs for PIV data object access and command execution 

F

7

Fwith both PIV Card Application PIN and Global PIN shall implement the Discovery Object with the 

PIN Usage Policy set to 0x60 zz where zz is set to either 0x10 or 0x20. 

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 Discovery Object according to the issuer. 

 

7 7

 Command execution pertains to the VERIFY APDU and optionally to the CHANGE REFERENCE DATA APDU. 
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 4: 

 The PIV Transitional Interfaces and Data Model Specification

 Page 10 

3. 2BTransition Card Interfaces 

3.1 12BMiddleware Application Programming Interface 

Reference [8] is an example of a transitional (GSC-IS) middleware API specification. 

3.2 13BCard Edge Commands 

Reference [9] is an example of a transitional (GSC-IS) card edge command specification. 
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 4: 

 The PIV Transitional Interfaces and Data Model Specification

 Page 11 

Appendix A—25BTerms, Acronyms, and Notation 

A.1 27BTerms 

Card An integrated circuit card. 

Card Application A set of data objects and card commands that can be selected using an 

application identifier. 

Data Object An item of information seen at the card command interface for which are 

specified a name, a description of logical content, a format and a coding. 

A.2 28BAcronyms 

APDU Application Protocol Data Unit 

BSI Basic Services Interface 

CBEFF Common Biometric Exchange Formats Framework 

CCC Card Capability Container 

CHUID Cardholder Unique IDentifier 

FASC-N Federal Agency Smart Credential Number 

FIPS Federal Information Processing Standards 

FISMA Federal Information Security Management Act 

GSC-IAB Government Smart Card Interagency Advisory Board 

GSC-IS Government Smart Card Interoperability Specification 

GUID Global Unique Identification Number 

HSPD Homeland Security Presidential Directive 

ICC Integrated Circuit Card 

IEC International Electrotechnical Commission 

INCITS InterNational Committee for Information Technology Standards 

ISO International Standards Organization 

ITL Information Technology Laboratory 

LSB Least Significant Bit 
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 4: 

 The PIV Transitional Interfaces and Data Model Specification

 Page 12 

MRTD Machine Readable Travel Document 

MSB Most Significant Bit 

NIST National Institute of Standards and Technology 

OMB Office of Management and Budget 

PACS Physical Access Control System 

PIN Personal Identification Number 

PIV Personal Identity Verification 

PKCS Public Key Cryptography Standard 

PKI Public Key Infrastructure 

RFU Reserved for Future Use 

RID Registered application provider IDentifier 

RSA Rivest, Shamir, Adleman 

SP Special Publication 

TIG Technical Implementation Guidance 

VM Virtual Machine 

A.3 29BNotation 

The sixteen hexadecimal digits shall be denoted using the alphanumeric characters 0, 1, 2..., A, B, C, 

D, E, and F. A byte consists of two hexadecimal digits, for example, '2D'. A sequence of bytes may 

be enclosed in single quotation marks, for example 'A0 00 00 01 16' rather than given as a sequence 

of individual bytes, '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 reserved for future use shall be 

set to 0. 

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

Data objects in templates are described as being mandatory (M), optional (O) or conditional (C). 

'Mandatory' means the data object shall appear in the template. 'Optional' means the data object may 

appear in the template. In the case of 'conditional' data objects, the conditions under which they are 

required are provided in a footnote to the table. 
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 4: 

 The PIV Transitional Interfaces and Data Model Specification

 Page 13 

In other tables the M/O column identifies properties of the PIV Card Application that shall be present 

(M) or may be present (O). 

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 

"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this standard are to be 

interpreted as described in IETF RFC 2119, Key Words for Use in RFCs to Indicate Requirement 

Levels [7]. 
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 4: 

 The PIV Transitional Interfaces and Data Model Specification

 Page 14 

Appendix B—26BReferences 

[1] Federal Information Processing Standard 201-1, Change Notice 1, Personal Identity Verification 

(PIV) of Federal Employees and Contractors, March 2006. (See HUhttp://csrc.nist.govUH) 

[2] Government Smart Card Interoperability Specification, Version 2.1, NIST Interagency Report 

6887 – 2003 Edition, July 16, 2003. 

[3] ISO/IEC 7816 (Parts 4, 5, 6, 8, and 9), Information technology — Identification cards — 

Integrated circuit(s) cards with contacts. 

[4] PACS v2.2, Technical Implementation Guidance: Smart Card Enabled Physical Access Control 

Systems, Version 2.2, The Government Smart Card Interagency Advisory Board’s Physical Security 

Interagency Interoperability Working Group, July 27, 2004. 

HUhttp://www.smart.gov/information/TIG_SCEPACS_v2.2.pdfU

[5] NIST Special Publication 800-87, Codes for the Identification of Federal and Federally-Assisted 

Organizations, April 2008. (See Uhttp://csrc.nist.govU) 

[6] PKI for Machine Readable Travel Documents Offering ICC Read-Only Access Version - 1.1 Date 

- October 01, 2004. Published by authority of the Secretary General, International Civil Aviation 

Organization 

[7] IETF RFC 2119, “Key Words for Use in RFCs to Indicate Requirement Levels,” March, 1997. 

[8] DoD CAC Middleware Requirements Release 3.0, Version 1.0, Access Card Office, March 21, 

2006. HUhttp://www.smart.gov/iab/documents/DoDcacMiddlewareRequirements.pdfUH.

[9] DoD Implementation Guide for CAC Next Generation (NG), Version 2.6, DMDC Card 

Technologies & Identity Solutions Division (CTIS), November, 2006. 

HUhttp://www.smart.gov/iab/documents/CACngImplementationGuide.pdfUH.