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

Verification – Part 1: End-Point 

PIV Card Application, 

Namespace, Data Model and 

Representation

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

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

James M. Turner, Deputy Director
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 1: End-Point PIV 

 Card Application Namespace, PIV Data Model and Representation 

 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 1, 

41 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 1: End-Point PIV 

 Card Application Namespace, PIV Data Model and Representation 

 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 1: End-Point PIV 

 Card Application Namespace, PIV Data Model and Representation 

 Page iii 

TABLE OF CONTENTS 

1. INTRODUCTION ..............................................................................................................................................1

1.1 AUTHORITY......................................................................................................................................................1

1.2 PURPOSE ..........................................................................................................................................................1

1.3 SCOPE ..............................................................................................................................................................2

1.4 AUDIENCE AND ASSUMPTIONS.........................................................................................................................2

1.5 DOCUMENT OVERVIEW AND STRUCTURE ........................................................................................................2

1.5.1 Appendices.............................................................................................................................................2

2. PIV CARD APPLICATION NAMESPACES..................................................................................................3

2.1 NAMESPACES OF THE PIV CARD APPLICATION................................................................................................3

2.2 PIV CARD APPLICATION AID..........................................................................................................................3

3. END-POINT PIV DATA MODEL ELEMENTS.............................................................................................4

3.1 MANDATORY DATA ELEMENTS .......................................................................................................................4

3.1.1 Card Capability Container....................................................................................................................4

3.1.2 Cardholder Unique Identifier................................................................................................................4

3.1.3 X.509 Certificate for PIV Authentication...............................................................................................5

3.1.4 Cardholder Fingerprints........................................................................................................................6

3.1.5 Security Object.......................................................................................................................................6

3.2 OPTIONAL DATA ELEMENTS ............................................................................................................................6

3.2.1 Cardholder Facial Image ......................................................................................................................6

3.2.2 Printed Information ...............................................................................................................................6

3.2.3 X.509 Certificate for Digital Signature..................................................................................................7

3.2.4 X.509 Certificate for Key Management .................................................................................................7

3.2.5 X.509 Certificate for Card Authentication.............................................................................................7

3.2.6 Discovery Object ...................................................................................................................................7

3.3 DATA OBJECT CONTAINERS AND ASSOCIATED ACCESS RULES AND INTERFACE MODES .................................8

4. END-POINT PIV DATA OBJECTS REPRESENTATION.........................................................................10

4.1 DATA OBJECTS DEFINITION ...........................................................................................................................10

4.1.1 Data Object Content............................................................................................................................10

4.2 OIDS AND TAGS OF PIV CARD APPLICATION DATA OBJECTS .......................................................................10

4.3 OBJECT IDENTIFIERS ......................................................................................................................................10

5. END-POINT DATA TYPES AND THEIR REPRESENTATION...............................................................12

5.1 KEY REFERENCES ..........................................................................................................................................12

5.2 PIV ALGORITHM IDENTIFIER .........................................................................................................................13

5.3 CRYPTOGRAPHIC MECHANISM IDENTIFIERS ..................................................................................................13

5.4 STATUS WORDS .............................................................................................................................................14

List of Appendices 

APPENDIX A— PIV DATA MODEL ....................................................................................................................15

APPENDIX B— PIV AUTHENTICATION MECHANISMS..............................................................................20

B.1 AUTHENTICATION MECHANISM DIAGRAMS ..............................................................................................21

B.1.1 Authentication using PIV Visual Credentials ......................................................................................21

B.1.2 Authentication using PIV CHUID .......................................................................................................22

B.1.3 Authentication using PIV Biometrics (BIO).........................................................................................24

B.1.4 Authentication using PIV Authentication Key......................................................................................26

B.1.5 Authentication using Card Authentication Key ...................................................................................27

B.2 SUMMARY TABLE......................................................................................................................................29

APPENDIX C— PIV ALGORITHM IDENTIFIER DISCOVERY.....................................................................30
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 1: End-Point PIV 

 Card Application Namespace, PIV Data Model and Representation 

 Page iv 

C.1 PIV ALGORITHM IDENTIFIER DISCOVERY FOR ASYMMETRIC CRYPTOGRAPHIC AUTHENTICATION ..........30

C.2 PIV ALGORITHM IDENTIFIER DISCOVERY FOR SYMMETRIC CRYPTOGRAPHIC AUTHENTICATION.............31

APPENDIX D— TERMS, ACRONYMS, AND NOTATION...............................................................................32

D.1 TERMS.......................................................................................................................................................32

D.2 ACRONYMS ...............................................................................................................................................33

D.3 NOTATION.................................................................................................................................................35

APPENDIX E— REFERENCES.............................................................................................................................36

List of Tables 

Table 1. Data Model Containers ..................................................................................................8

Table 2. Object Identifiers of the PIV Data Objects for Interoperable Use.................................11

Table 3. PIV Card Application Authentication and Key References ..........................................12

Table 4. Cryptographic Mechanism Identifiers...........................................................................13

Table 5. Status Words ...............................................................................................................14

Table 6. PIV Data Containers ....................................................................................................15

Table 7. Card Capability Container............................................................................................16

Table 8. Cardholder Unique Identifier........................................................................................16

Table 9. X.509 Certificate for PIV Authentication.......................................................................17

Table 10. Cardholder Fingerprints .............................................................................................17

Table 11. Security Object...........................................................................................................17

Table 12. Cardholder Facial Image............................................................................................17

Table 13. Printed Information.....................................................................................................18

Table 14. X.509 Certificate for Digital Signature........................................................................18

Table 15. X.509 Certificate for Key Management ......................................................................18

Table 16. X.509 Certificate for Card Authentication...................................................................19

Table 17. Discovery Object........................................................................................................19

Table 18. Summary of PIV Authentication Mechanisms............................................................29

List of Figures 

Figure B-1. Authentication using PIV Visual Credentials ...........................................................22

Figure B-2. Authentication using PIV CHUID.............................................................................23

Figure B-3. Authentication using PIV Biometrics (BIO)..............................................................24

Figure B-4. Authentication using PIV Biometrics Attended (BIO-A)...........................................25

Figure B-5. Authentication using PIV Authentication Key ..........................................................26

Figure B-6. Authentication using asymmetric Card Authentication Key.....................................27

Figure B-7. Authentication using symmetric Card Authentication Key.......................................28
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 1: End-Point PIV 

 Card Application Namespace, PIV Data Model and Representation 

1. Introduction 

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) contains technical specifications to interface with the 

smart card (PIV Card1

) to retrieve and use the identity credentials. 

1.1 Authority 

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 A130, 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 Purpose 

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 the 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). 

 Page 1 
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 1: End-Point PIV 

 Card Application Namespace, PIV Data Model and Representation 

 Page 2 

1.3 Scope 

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 described in this document. 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 interchangeably by all information processing systems 

across Federal agencies. SP 800-73-2 defines the PIV data elements identifiers, structure and 

format. SP 800-73-2 also describes the client application programming interface and card 

command interface for use of the PIV Card. 

This part, SP 800-73-2, Part 1 – End-Point PIV Card Application Namespace, Data Model and 

Representation, specifies the End-Point PIV Card Application Namespace, the PIV Data Model 

and its logical representation on the PIV Card and is a companion document to FIPS 201. 

1.4 Audience 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 Document 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: 

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

document and outlines its structure. 

+ Section 2, PIV Card Application Namespace, defines the three NIST managed 

namespaces used by the PIV Card Application. 

+ Section 3, End-Point PIV Data Model Elements, describes the PIV Data Model elements 

in detail. 

+ Section 4, End-Point 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, End-Point Data Types and Their Representation, provides the details of the 

data types found on the PIV client-application programming interface and the PIV Card 

Application card command interface. 

1.5.1 Appendices 

The appendices contain material that needs special formatting together with illustrative material 

to aid in understanding information in the body of the document.
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 1: End-Point PIV 

 Card Application Namespace, PIV Data Model and Representation 

2. PIV Card Application Namespaces 

2.1 Namespaces of the PIV Card Application 

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

+ Proprietary Identifier extension (PIX) of the NIST Registered Application Provider 

Identifier (RID) 

+ ASN.1 object identifiers (OIDs) in the personal verification subset of the OIDs managed 

by NIST 

+ Basic Encoding Rules – 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 [2], and used in the NIST coexistent tag allocation 

scheme without redefinition have the same meaning in the NIST PIV coexistent tag allocation 

scheme as they have in [2]. 

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

use: 

+ algorithm identifiers 

+ key reference values 

+ cryptographic mechanism identifiers 

2.2 PIV 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 including the trailing five bytes of the 

PIV Card Application AID 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; that is, without the two-byte version, as 

follows: 

'A0 00 00 03 08 00 00 10 00' 

 Page 3 
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 1: End-Point PIV 

 Card Application Namespace, PIV Data Model and Representation 

3. End-Point PIV Data Model Elements 

This section contains the description of the data elements for personal identity verification, the PIV 

data model. 

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 

3.1 Mandatory Data Elements 

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

3.1.1 Card Capability Container 

The Card Capability Container (CCC) is mandatory for compliance with the Government Smart Card 

Interoperability Specification (GSC-IS) [3]. 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. 

3.1.2 Cardholder 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 

 Page 4 
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 1: End-Point PIV 

 Card Application Namespace, PIV Data Model and Representation 

 

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 

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 SSN2

, 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 Map3

 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. 

3.1.3 X.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

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

3

 The Authentication Key Map is deprecated. It will be eliminated in a future revision of SP 800-73. 

 Page 5 
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 1: End-Point PIV 

 Card Application Namespace, PIV Data Model and Representation 

3.1.4 Cardholder 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. 

3.1.5 Security 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. 

3.2 Optional Data Elements 

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

provided in this document. 

3.2.1 Cardholder Facial Image 

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

recognition systems for automated identity verification. 

3.2.2 Printed 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. 

 Page 6 
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 1: End-Point PIV 

 Card Application Namespace, PIV Data Model and Representation 

 

3.2.3 X.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 

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

used for digital signature generation. 

3.2.4 X.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. 

3.2.5 X.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. 

3.2.6 Discovery 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 execution4

 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. 

4

 Command execution pertains to the VERIFY APDU and optionally to the CHANGE REFERENCE DATA APDU. 

 Page 7 
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 1: End-Point PIV 

 Card Application Namespace, PIV Data Model and Representation 

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. 

 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 

5

with 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. 

3.3 Data Object Containers and associated Access Rules and Interface Modes 

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 / Contactless6 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 0x0102 Always Contact O 

 

5 5

 Command execution pertains to the VERIFY APDU and optionally to the CHANGE REFERENCE DATA APDU. 6

 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. 

 Page 8 
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 1: End-Point PIV 

 Card Application Namespace, PIV Data Model and Representation 

Management 

X.509 Certificate for Card 

Authentication 

0x0500 Always Contact and Contactless O 

Discovery Object 0x6050 Always Contact and Contactless O 

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. 

 Page 9 
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 1: End-Point PIV 

 Card Application Namespace, PIV Data Model and Representation 

4. End-Point PIV Data Objects Representation 

4.1 Data Objects Definition 

A data object is an item of information seen on the card command interface for which are specified a 

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, Information technology – 

Abstract Syntax Notation One (ASN.1): Information object specification. [7] 

A data object whose data content is encoded as a BER-TLV data structure as in ISO/IEC 8825—

1:2002 – ASN.1 encoding rules [8] is called BER-TLV data object. 

4.1.1 Data 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 and also 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 End-Point Data objects are BER-TLV objects encoded as per [8], except that Tag values (Tvalues) of the PIV data object's inner tag assignments do not conform to BER-TLV requirements.7

This is due to the need to accommodate legacy tags inherited from the GSC-IS. 

4.2 OIDs and Tags of PIV Card Application Data Objects 

Table 2 lists the ASN.1 object identifiers and BER-TLV tags of the eleven PIV Card Application data 

objects for interoperable use. For the purpose of constructing PIV Card Application data object 

names in the CardApplicationURL in 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.3 Object Identifiers 

Each of the data objects in the PIV Card Application has been provided with a three-byte BER-TLV 

tag and an ASN.1 OID from the NIST personal verification arc. These object identifier assignments 

are given in Table 2. 

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”. 

 

7

 The exception does not apply to the Discovery Object, nor the Application Property Template (APT), since these objects 

use interindustry tags from ISO/IEC 7816-6. 

 Page 10 
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 1: End-Point PIV 

 Card Application Namespace, PIV Data Model and Representation 

A data object shall be identified on the PIV Card Application card command interface using its BERTLV tag. For example, the CHUID is identified on the card command interface to the PIV Card 

Application by the three-byte identifier '5FC102'. 

Table 1 lists the ACRs of the eleven PIV Card Application data objects for interoperable use. See 

table 6-3 in Special Publication 800-78 (SP 800-78) Cryptographic Algorithms and Key Sizes for 

Personal Identity Verification [9], for the key references and permitted algorithms associated with 

these authenticatable entities. 

Table 2. Object Identifiers of the PIV Data Objects for Interoperable Use 

Data Object for Interoperable Use ASN.1 OID BER-TLV Tag M/O 

Card Capability Container 2.16.840.1.101.3.7.1.219.0 '5FC107' M 

Cardholder Unique Identifier 2.16.840.1.101.3.7.2.48.0 '5FC102' M 

X.509 Certificate for PIV Authentication 2.16.840.1.101.3.7.2.1.1 '5FC105' M 

Cardholder Fingerprints 2.16.840.1.101.3.7.2.96.16 '5FC103' M 

Security Object 2.16.840.1.101.3.7.2.144.0 '5FC106' M 

Cardholder Facial Image 2.16.840.1.101.3.7.2.96.48 '5FC108' O 

Printed Information 2.16.840.1.101.3.7.2.48.1 '5FC109' O 

X.509 Certificate for Digital Signature 2.16.840.1.101.3.7.2.1.0 '5FC10A' O 

X.509 Certificate for Key Management 2.16.840.1.101.3.7.2.1.2 '5FC10B' O 

X.509 Certificate for Card Authentication 2.16.840.1.101.3.7.2.5.0 '5FC101' O 

Discovery Object 2.16.840.1.101.3.7.2.96.80 '7E' O 

 Page 11 
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 1: End-Point PIV 

 Card Application Namespace, PIV Data Model and Representation 

5. End-Point Data Types and Their Representation 

This section provides a description of the data types used in the PIV Client-Application Programming 

Interface (SP 800-73-2, Part 3) and PIV Card Command Interface (SP 800-73-2, 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.1 Key References 

A key reference is a one-byte identifier that specifies a cryptographic key according to its PIV Key 

Type. SP 800-78, Table 6-1, defines the key reference values that shall be used on the PIV interfaces. 

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. All other PIV 

Card Application key reference values are reserved for future use. 

Table 3. PIV Card Application Authentication and Key References 

Key Reference 

Value PIV Key Type 

Authenticatable 

Entity / 

Administrator 

Security 

Condition for 

Use 

Retry 

Reset 

Value 

Number of 

Unblocks 

'00' Global PIN Cardholder Always Platform 

Specific 

Platform 

Specific 

'80' Application PIN Cardholder Always 

Issuer 

Specific 

Issuer 

Specific 

'81' PIN Unblock Key 

PIV Card 

Application 

Administrator 

Always Issuer 

Specific 

Issuer 

Specific 

See Table 6-1 in SP 

800-78 

PIV 

Authentication 

Key 

PIV Card 

Application 

Administrator 

PIN N/A N/A 

See Table 6-1 in SP 

800-78 

Card 

Management 

Key8

PIV Card 

Application 

Administrator 

Always N/A N/A 

See Table 6-1 in SP 

800-78 

Digital Signature 

Key

PIV Card 

Application 

Administrator 

PIN Always N/A N/A 

See Table 6-1 in SP 

800-78 

Key Management 

Key

PIV Card 

Application 

Administrator 

PIN N/A N/A 

See Table 6-1 in SP 

800-78 

Card 

Authentication 

Key

PIV Card 

Application 

Administrator 

Always N/A N/A 

 

8

 Note: The Card Management key is the PIV Card Application Administration Key used for managing the PIV card 

application. 

 Page 12 
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 1: End-Point PIV 

 Card Application Namespace, PIV Data Model and Representation 

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. 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 

section 2.4.3 of Part 2. 

PIV Card Applications with the discovery object, and the first byte of the PIN Usage Policy value set 

to 0x60 as per section 3.2.6, shall reference the PIV Card Application PIN as well as 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. 

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

PIN. 

5.2 PIV Algorithm Identifier 

A PIV algorithm identifier shall be a one-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., CBC or ECB). SP 800-78, Table 6-2 lists 

the PIV algorithm identifiers for the cryptographic algorithms that may be recognized on the PIV 

interfaces. 

5.3 Cryptographic Mechanism Identifiers 

Cryptographic Mechanism Identifiers are defined in Table 4. These identifiers serve as data field 

inputs to the SP 800-73-2 Part 2 GENERATE ASYMMETRIC KEY PAIR card command and the SP 

800-73-2 Part 3 pivGenerateKeyPair() client API function call, which initiates the generation and 

storing of the asymmetric key pair. 

Table 4. Cryptographic Mechanism Identifiers 

Cryptographic 

Mechanism 

Identifier 

Description Parameter 

'00'-'05' RFU 

See Table 6-2 in 

SP 800-78 

RSA 1024 Optional public 

exponent encoded 

big-endian 

See Table 6-2 in 

SP 800-78 

RSA 2048 Optional public 

exponent encoded 

big-endian 

'08'-'10' RFU 

See Table 6-2 in 

SP 800-78 ECC: Curve P-256 None 

'12'-'13' RFU 

See Table 6-2 in 

SP 800-78 

ECC: Curve P-384 None 

 Page 13 
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 1: End-Point PIV 

 Card Application Namespace, PIV Data Model and Representation 

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

5.4 Status Words 

A Status Word (SW) shall be a 2-byte value returned by an entry point on the client-application 

programming interface or 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 both the client-application 

programming and card command interfaces and their interpretation are given in Table 5. The 

description of individual client-application programming interface entry points or card commands 

provide additional information for interpreting returned status words. 

Table 5. Status Words 

 SW1 SW2 Meaning 

'61' 'xx' Successful execution where SW2 encodes the number of response 

data bytes still available 

'63' 'CX' Verification failed, X indicates the number of further allowed retries or 

resets 

'69' '82' Security condition not satisfied 

'69' '83' Authentication method blocked 

'6A' '80' Incorrect parameter in command data field 

'6A' '81' Function not supported 

'6A' '84' Not enough memory 

'6A' '86' Incorrect parameter in P1 or P2 

'6A' '88' Referenced data or reference data not found 

'90' '00' Successful execution 

 Page 14 
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 1: End-Point PIV 

 Card Application Namespace, PIV Data Model and Representation 

Appendix A—PIV Data Model 

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

The SP800-73-2 End-Point 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, End-Point 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 shall be feasible. In the singlechip/dual-interface configuration, the PIV Card Application shall be provided the information 

regarding which interface is in use. In the dual-chip configuration, a separate PIV Card Application 

shall be loaded on each chip. 

Table 6. PIV Data Containers 

Container Description Container

ID 

BER-TLV 

Tag 

Container 

Minimum 

Capacity 

 (Bytes)*

Access 

Rule for 

Read 

Contact / 

Contactless M/O 

Card Capability Container 0xDB00 '5FC107' 297 Always Contact M 

Cardholder Unique Identifier 0x3000 '5FC102' 3414 Always Contact and 

Contactless 

M 

X.509 Certificate for PIV 

Authentication 

0x0101 '5FC105' 2005 Always Contact M 

Cardholder Fingerprints 0x6010 '5FC103' 4006 PIN Contact M 

Security Object 0x9000 '5FC106' 1031 Always Contact M 

Cardholder Facial Image 0x6030 '5FC108' 12710 PIN Contact O 

Printed Information 0x3001 '5FC109' 164 PIN Contact O 

X.509 Certificate for Digital 

Signature 

0x0100 '5FC10A' 2005 Always Contact O 

X.509 Certificate for Key 

Management 

0x0102 '5FC10B' 2005 Always Contact O 

X.509 Certificate for Card 

Authentication 

0x0500 '5FC101' 2005 Always Contact and 

Contactless 

O 

Discovery Object 0x6050 '7E' 20 Always Contact and 

Contactless 

O 

 

* The values in this column denote the guaranteed minimum capacities, in bytes, of the on-card storage containers. Cards 

 may be produced and determined conformant with larger containers. 

 Page 15 
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 1: End-Point PIV 

 Card Application Namespace, PIV Data Model and Representation 

Note that all data elements of the following data objects are mandatory unless specified as optional. 

Table 7. Card Capability Container 

Card Capability Container 0xDB00 

Data Element (TLV) Tag Type Max. Bytes*9

Card Identifier 0xF0 Fixed 21 

Capability Container version number 0xF1 Fixed 1 

Capability Grammar version number 0xF2 Fixed 1 

Applications CardURL 0xF3 Variable 128 

PKCS#15 0xF4 Fixed 1 

Registered Data Model number 0xF5 Fixed 1 

Access Control Rule Table 0xF6 Fixed 17 

Card APDUs 0xF7 Fixed 0 

Redirection Tag 0xFA Fixed 0 

Capability Tuples (CTs) 0xFB Fixed 0 

Status Tuples (STs) 0xFC Fixed 0 

Next CCC 0xFD Fixed 0 

Extended Application CardURL (optional) 0xE3 Fixed 48 

Security Object Buffer (optional) 0xB4 Fixed 48 

Error Detection Code 0xFE LRC 0 

Table 8. Cardholder Unique Identifier 

Cardholder Unique Identifier 0x3000 

Data Element (TLV) Tag Type Max. Bytes* 

Buffer Length (Optional) 0xEE Fixed 2 

FASC-N 0x30 Fixed Text 25 

Organization Identifier (Optional) 0x32 Fixed 4 

DUNS (Optional) 0x33 Fixed 9 

GUID 0x34 Fixed Numeric 16 

Expiration Date 0x35 Date (YYYYMMDD) 8 

Authentication Key Map (Optional) 0x3D Variable 512 

Issuer Asymmetric Signature 0x3E Variable 2816** 

Error Detection Code 0xFE LRC 0 

The Error Detection Code is the same element as the Longitudinal Redundancy Code (LRC) in 

TIG SCEPACS. Because TIG SCEPACS makes the LRC mandatory, it is present in the CHUID. 

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). 

 

* The values in the “Max. Bytes” columns denote the lengths of the value (V) fields of BER-TLV elements. 

** Recommended length: The signer certificate may cause the “Max. Bytes” value in the Issuer Asymmetric Signature field 

to be exceeded. 

 Page 16 
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 1: End-Point PIV 

 Card Application Namespace, PIV Data Model and Representation 

Table 9. X.509 Certificate for PIV Authentication 

X.509 Certificate for PIV Authentication 0x0101 

Data Element (TLV) Tag Type Max. Bytes*

Certificate 0x70 Variable 1856**

CertInfo 0x71 Fixed 1 

MSCUID (Optional) 0x72 Variable 38 

Error Detection Code 0xFE LRC 0 

Table 10. Cardholder Fingerprints 

Cardholder Fingerprints 0x6010 

Data Element (TLV) Tag Type Max. Bytes* 

Fingerprint I & II 0xBC Variable 4000*** 

Error Detection Code 0xFE LRC 0 

Table 11. Security Object 

Security Object 0x9000 

Data Element (TLV) Tag Type Max. Bytes* 

Mapping of DG to ContainerID 0xBA Variable 100 

Security Object 0xBB Variable 900 

Error Detection Code 0xFE LRC 0 

Table 12. Cardholder Facial Image 

Cardholder Facial Image 0x6030 

Data Element (TLV) Tag Type Max. Bytes*

Image for Visual Verification 0xBC Variable 12704**** 

Error Detection Code 0xFE LRC 0 

 

* The values in the “Max. Bytes” columns denote the lengths of the value (V) fields of BER-TLV elements. 

** Recommended length. Certificate size can exceed indicated length value. 

*** Recommended length. The certificate that signed the Fingerprint I and II data element in the Cardholder Fingerprint 

data object can either be stored in the CHUID or in the Fingerprint I and II data element itself. If the latter, the “Max. 

Bytes” value quoted is a recommendation and the signer certificate in CBEFF_SIGNATURE_BLOCK can exceed the 

“Max. bytes”. 

****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 object itself. If the latter, the “Max. Bytes” value quoted is a recommendation and 

the signer certificate in CBEFF_SIGNATURE_BLOCK can exceed the “Max. bytes”. 

 Page 17 
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 1: End-Point PIV 

 Card Application Namespace, PIV Data Model and Representation 

Table 13. Printed Information 

Printed Information 0x3001 

Data Element (TLV) Tag Type Max. Bytes* 

Name 0x01 Fixed Text 32 

Employee Affiliation (Line 1) 0x02 Fixed Text 20 

Employee Affiliation (Line 2) 0x03 Fixed Text 20 

Expiration date 0x04 Date (YYYYMMMDD) 9 

Agency Card Serial Number 0x05 Fixed Text 10 

Issuer Identification 0x06 Fixed Text 15 

Organization Affiliation (Line 1) 

(Optional) 0x07 Fixed Text 20 

Organization Affiliation (Line 2) 

(Optional) 0x08 Fixed Text 20 

Error Detection Code 0xFE LRC 0 

Note: The Organization Affiliation fields (tags 0x07 and 0x08) are new optional data elements in the 

Printed Information data object. Employee Affiliation Line 2 (tag 0x03) is deprecated and will be 

eliminated in a future revision, as it does not have a corresponding text field on the face of the card. 

In order to successfully match the printed information for verification on Zone 8 (Employee 

Affiliation) and Zone 10 (Organization Affiliation) on the face of the card with the printed 

information represented stored electronically on card, agencies should use tags 0x02, 0x07 and 0x08. 

Table 14. X.509 Certificate for Digital Signature 

X.509 Certificate for Digital Signature 0x0100 

Data Element (TLV) Tag Type Max. Bytes* 

Certificate 0x70 Variable 1856** 

CertiInfo 0x71 Fixed 1 

MSCUID (Optional) 0x72 Variable 38 

Error Detection Code 0xFE LRC 0 

Table 15. X.509 Certificate for Key Management 

X.509 Certificate for Key Management 0x0102 

Data Element (TLV) Tag Type Max. Bytes* 

Certificate 0x70 Variable 1856** 

CertiInfo 0x71 Fixed 1 

MSCUID (Optional) 0x72 Variable 38 

Error Detection Code 0xFE LRC 0 

* The values in the “Max. Bytes” columns denote the lengths of the value (V) fields of BER-TLV elements. 

** Recommended length. Certificate size can exceed indicated length value. 

 Page 18 
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 1: End-Point PIV 

 Card Application Namespace, PIV Data Model and Representation 

Table 16. X.509 Certificate for Card Authentication 

X.509 Certificate for Card Authentication 0x0500 

Data Element (TLV) Tag Type Max. Bytes* 

Certificate 0x70 Variable 1856**

CertiInfo 0x71 Fixed 1 

MSCUID (Optional) 0x72 Variable 38 

Error Detection Code 0xFE LRC 0 

Table 17. Discovery Object 

Discovery Object (Tag ‘7E’) 0x6050 

Data El Data Element (TLV) Tag Length Max. Bytes* 

PIV Card Application AID 0x4F Fixed 12 

PIN Usage Policy 0x5F2F Fixed 3 

The CertInfo byte in certificates identified above shall be encoded as follows: 

CertInfo::= BIT STRING { 

CompressionTypeMsb(0), // 0 = no compression and 1 = gzip10 

 // compression. 

 CompressionTypeLsb(1), // shall be set to '0' for PIV Applications 

 IsX509(2), // shall be set to '0' for PIV Applications 

 RFU3(3), 

 RFU4(4), 

 RFU5(5), 

 RFU6(6), 

 RFU7(7) 

 } 

 

* The values in the “Max. Bytes” columns denote the lengths of the value (V) fields of BER-TLV elements. 

** Recommended length. Certificate size can exceed indicated length value. 10 Gzip formats are specified in RFC 1951 and RFC 1952 

 Page 19 
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 1: End-Point PIV 

 Card Application Namespace, PIV Data Model and Representation 

Appendix B—PIV Authentication Mechanisms 

To provide guidelines on the usage and behavior supported by the PIV Card, PIV authentication 

mechanisms and application scenarios are described in this section. FIPS 201 describes PIV 

authentication as the “process of establishing confidence in the identity of the cardholder presenting a 

PIV Card.” 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 as 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 

(such as visual credentials, CHUID, biometrics, PIV keys and certificates) held by the PIV Card. 

Credential validation mechanisms include: 

+ Visual inspection of PIV Card visual elements (such as the photo, the printed name, and rank, 

if present), 

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

Cardholder Validation (HolderV) — This is the process of establishing that the PIV Card is in the 

possession of the individual to whom the card has been 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 visual characteristics of the cardholder, and the live fingerprint samples provided by the 

cardholder. Thus, mechanisms for PIV cardholder validation include: 

+ Presentation of a PIV Card by the cardholder, 

+ Matching the visual characteristics of the cardholder with the photo on the PIV Card, 

+ Matching the PIN provided with the PIN on the PIV Card, 

 Page 20 
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 1: End-Point PIV 

 Card Application Namespace, PIV Data Model and Representation 

+ Matching the live fingerprint samples provided by the cardholder, with the biometric 

information embedded within the PIV Card. 

B.1 Authentication Mechanism Diagrams 

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 upon 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. 

B.1.1 Authentication using PIV Visual Credentials 

This is the authentication mechanism where a human guard authenticates the cardholder using the 

visual credentials held by the PIV Card, and is illustrated in Figure B-1. 

 Page 21 
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 1: End-Point PIV 

 Card Application Namespace, PIV Data Model and Representation 

REJECT

REJECT

REJECT CARDHOLDER 

AUTHENTICATED

No Yes

Human Guard PIV Application API PIV Card Edge

COUNTERFEIT, 

TAMPER

AND FORGERY 

CHECK (CardV)

PRESENT CARD 

(HolderV)

CHECK CARD 

EXPIRATION

(CredV)

CHECK

CARD VISUAL 

CHARACTERIS TICS 

(e.g . Facial Image)

(HolderV)

Figure B-1. Authentication using PIV Visual Credentials 

B.1.2 Authentication using PIV CHUID 

The PIV CHUID may be used for authentication in several variations. The use of the PIV Card to 

implement the CHUID authentication mechanism is illustrated in Figure B-2. The minimum set of 

data that must be transmitted from the PIV Application on the Local System to the host is application 

dependent and therefore not defined in this Specification. 

 Page 22 
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 1: End-Point PIV 

 Card Application Namespace, PIV Data Model and Representation 

Authentication using CHUID

PIV Application 

on Local System Validation API PIV Card Edge 

PRESENT CARD 

(HolderV) Connect 

Begin Transaction 

Select Select Application 

Application 

PIV Card App ID and Version 

Figure B-2. Authentication using PIV CHUID

RETRIEVE CHUID Read Value CHUID 

Read CHUID 

CHUID Returned REJECT No 

CARDHOLDER 

IDENTIFIER

No Yes 

VALIDATE 

EXPIRATION (CredV) 

VERIFY SIGNATURE 

(CredV) End Transaction (Optional) 

Disconnect 

REJECT 

 Page 23 
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 1: End-Point PIV 

 Card Application Namespace, PIV Data Model and Representation 

B.1.3 Authentication using PIV Biometrics (BIO)

The general authentication mechanism using the PIV biometrics is illustrated in Figure B-3. 

PRESENT CARD 

(HolderV) Connect

Begin Transaction

Select Application

Select Application

PIV Card App ID and Version

ACQUIRE PIN

(HolderV)

Read Value (BIO)

Read BIO

BIO Returned

Verify PIN

Verify PIN

ACK

Read Value (CHUID)

Read CHUID

CHUID Returned

RETRIEVE BIO

VERIFY SIGNATURE 

(CredV)

(Optional)

REJECT

ACQUIRE BIO 

(HolderV)

REJECT CARDHOLDER 

IDENTIFIER

No Yes

Validation PIV Application 

on Local System API PIV Card Edge

End Transact ion

Read Value (CHUID)

Read CHUID

Disconnect

RETRIEVE CHUID

VERIFY EXPIRATION REJECT (CredV)

REJECT

Compare Bio 

(HolderV) and 

Compare Bio FASCN and CHUID 

FASC-N (CredV)

Figure B-3. Authentication using PIV Biometrics (BIO)

 Page 24 
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 1: End-Point PIV 

 Card Application Namespace, PIV Data Model and Representation 

The assurance of authentication using the PIV biometric 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 B-4. 

PRESENT CARD 

(HolderV) Connect

Begin Transaction

Select Application

Select Application

PIV Card App ID and Version

ACQUIRE PIN

(HolderV)

Read Value (BIO)

Read BIO

BIO Returned

Verify PIN

Verify PIN

ACK

Read Value (CHUID)

Read CHUID

CHUID Returned

RETRIEVE BIO

VERIFY SIGNATURE 

(CredV)

(Optional)

REJECT

ACQUIRE BIO in 

the presence of an 

Attendant

(HolderV)

REJECT CARDHOLDER 

IDENTIFIER

No Yes

Validation PIV Application 

on Local System API PIV Card Edge

End Transaction

Disconnect

Read Value (CHUID)

Read CHUID

RETRIEVE CHUID

VERIFY EXPIRATION 

(CredV) REJECT

Compare Bio 

(HolderV) and 

Compare Bio FASCN and CHUID 

FASC-N (CredV)

REJECT

Figure B-4. Authentication using PIV Biometrics Attended (BIO-A) 

 Page 25 
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 1: End-Point PIV 

 Card Application Namespace, PIV Data Model and Representation 

B.1.4 Authentication using PIV Authentication Key 

The authentication mechanism using the PIV Authentication Key is illustrated in Figure B-5. 

PRESENT CARD

(HolderV) Connect

Begin Transaction

Select Application

Select Application

PIV Card App ID and Version

ACQUIRE PIN 

(HolderV)

Read Value (PIV Auth Certificate)

Read PIV Auth Certificate

PIV Auth Certificate Returned

Verify PIN Verify PIN

ACK

RETRIEVE PIV AUTH 

CERTIFICATE

VALIDATE CERTIFICATE 

(Signature, Expiration and 

Revocation) (CredV)

REJECT

REJECT

REJECT CARDHOLDER 

IDENTIFIER

No Yes

Validation PIV Application 

on Local System API PIV Card Edge

End Transaction

Disconnect

Revocation

Request Card Signature

Sign Nonce

Signed Nonce Returned

RETRIEVE Algorithm ID 

and Key Size for Signature 

Request

RETRIEVE FASC-N 

from the Certificate

VERIFY SIGNED 

DATA - card 

possesses private 

key

(CardV)

Figure B-5. Authentication using PIV Authentication Key 

 Page 26 
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 1: End-Point PIV 

 Card Application Namespace, PIV Data Model and Representation 

B.1.5 Authentication using Card Authentication Key 

Authentication mechanisms using the Card Authentication Key are illustrated in Figures B-6 and B-7. 

Figure B-6 illustrates the use of an asymmetric Card Authentication Key, while figure B-7 uses a 

symmetric Card Authentication Key for the authentication mechanism. Both mechanisms provide 

“SOME” confidence in the assurance of the identity. 

PRESENT CARD

(HolderV) Connect

Begin Transaction

Select Application

Select Application

PIV Card App ID and Version

Read Value (Card Auth Certificate)

Read Card Auth Certificate

Card Auth Certificate Returned

RETRIEVE Card AUTH 

CERTIFICATE

VALIDATE 

CERTIFICATE (Signature, 

(Expiration and 

Revocation) (CredV)

REJECT

VERIFY SIGNED 

DATA - card 

possesses private 

key

(CardV)

REJECT CARDHOLDER 

IDENTIFIER

No Yes

Validation

PIV Application 

on Local System API PIV Card Edge

End Transaction

Disconnect

Revocation

Request Card Signature

Sign Nonce

Signed Nonce Returned

RETRIEVE Algorithm ID 

and Key Size for Signature 

Request

(See Appendix C.1)

ISSUER 

VERIFICATION

Figure B-6. Authentication using an asymmetric Card Authentication Key

 Page 27 
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 1: End-Point PIV 

 Card Application Namespace, PIV Data Model and Representation 

 Page 28 

PRESENT CARD

(HolderV) Connect

Begin Transaction

Select Application

Select Application

PIV Card App ID and Version

Read Value CHUID

Read CHUID

CHUID Returned

RETRIEVE CHUID

(See Appendix C.2)

VERIFY RESPONSE 

DATA - card 

possesses secret key

(CardV)

REJECT CARDHOLDER 

IDENTIFIER

No Yes

Validation PIV Application 

on Local System API PIV Card Edge

End Transaction

Disconnect

Send Challenge 

Send Challenge 

Returned Response

RETRIEVE symmetric 

Key ID and algorithm 

ID 

(See Appendix C.2)

RETRIEVE FASC-N 

(see Appendix C.2)

Issue Challenge

Figure B-7. Authentication using a symmetric Card Authentication Key
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 1: End-Point PIV 

 Card Application Namespace, PIV Data Model and Representation 

B.2 Summary Table 

The following table summarizes the types of validation activities that are included in each of the PIV 

authentication mechanisms described earlier in this section. 

Table 18. Summary of PIV Authentication Mechanisms 

PIV Authentication 

Mechanism 

Card Validation 

Steps (CardV) 

Credential Validation 

Steps (CredV) 

Cardholder Validation Steps 

(HolderV) 

PIV Visual 

Authentication 

Counterfeit, tamper 

and forgery check 

Expiration check Possession of Card 

Match of card visual 

characteristics with cardholder 

PIV CHUID Expiration check 

CHUID signature check 

(optional) 

Possession of Card 

Symmetric Card 

Authentication Key

Perform challenge 

and response with a 

PIV symmetric key 

Possession of Card 

Asymmetric Card 

Authentication Key

Perform challenge 

and response with a 

PIV asymmetric 

Card Authentication 

key, and validate 

signature on 

response 

Card expiration check 

Certificate validation of a 

PIV certificate 

Possession of Card 

PIV Authentication Key 

 

Perform challenge 

and response with a 

PIV asymmetric key, 

and validate 

signature on 

response 

Card expiration check 

Certificate validation of a 

PIV certificate 

Possession of Card 

Match PIN provided by 

Cardholder 

PIV Biometric Expiration check 

CHUID signature check 

(optional) 

PIV Bio signature check 

(optional) 

Match CHUID FASC-N 

with PIV Bio FASC-N 

Possession of Card 

Match PIN provided by 

Cardholder 

Match Cardholder bio with PIV 

bio 

PIV Biometric (Attended) Expiration check 

CHUID signature check 

(optional) 

PIV Bio signature check 

(optional) 

Match CHUID FASC-N 

with PIV Bio FASC-N 

Possession of Card 

Match PIN provided by 

Cardholder 

Match of Cardholder bio to PIV 

bio in view of attendant

 

 Page 29 
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 1: End-Point PIV 

 Card Application Namespace, PIV Data Model and Representation 

Appendix C—PIV Algorithm Identifier Discovery 

Relying Parties interact with many PIV Cards with the same native key-type implemented by 

different key sizes and algorithms11. For example, a relying party performing the authentication 

mechanism described in B.1.4 (Authentication using the PIV Authentication Key), can expect to 

perform a challenge and response cryptographic authentication with 1) a PIV Card with RSA 1024 bit 

PIV Authentication Key, 2) a PIV Card with RSA 2048 bit PIV Authentication Key or 3) a PIV Card 

with an elliptic curve key (P-256) PIV Authentication 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. 

C.1 PIV Algorithm Identifier Discovery for Asymmetric 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. The PIV algorithm identifier, on the other hand, 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. The relying party, 

prior to the challenge command, retrieved and parsed the X.509 certificate from the card in order to 

1) optionally validate the certificate and 2) extract the public key for the pending decryption and 

matching of the signed nonce once returned from the card. It is during the parsing of the X.509 

certificate that the PIV algorithm identifier can be identified in two steps12: 

Step 1: Algorithm Type Discovery: 

The X.509 certificate stores the public key in the SubjectPublicKeyInfo field. The same field 

also stores the X.509 AlgorithmIdentifier object identifiers (OIDs). This OID identifies the 

algorithm (RSA, or ECC) as listed in table 3-5 of SP 800-78. 

Step 2: Key Size Discovery:13

The public key of the certificate holder is stored in the X.509 SubjectPublicKeyInfo field. By 

reading the modulus n bit string, in case of a RSA key, or the Curve Point string, in case of an 

elliptic curve public key, the corresponding private key size is implicitly known since both 

public and private keys are of the same length. 

 

11 Table 3.1 , SP 800-78 list the various PIV algorithm identifiers to choose one for each PIV key type 

12 The PIV algorithm identifiers specify both the key and the algorithm for the key references, Thus both values have to be 

discovered in order to derive the PIV algorithm identifier 13 If the AlgorithmIdentifier OID indicates an elliptic curve algorithm and its EcpkParameters does not indicate implicit 

inherited from the issuer’s certificate, then the namedCurve field in the EcpkParameters encodes the curve as per table 

3.6 of SP 800-78. The associated named curve, indicates the key size x of curve P-xxx. This is an alternative method to 

discover the key size for an elliptic curve keys. 

 Page 30 
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 1: End-Point PIV 

 Card Application Namespace, PIV Data Model and Representation 

As a final step, the discovered X.509 algorithm OID and key size are mapped to the PIV Algorithm 

Identifiers as defined in SP 800-78 table 6-2. The relying party then proceeds to issue the general 

authenticate command to the card. 

C.2 PIV Algorithm Identifier Discovery for Symmetric Cryptographic Authentication 

In the absence of a X.509 certificate, as is the case with symmetric cryptography, the PIV algorithm 

identifier discovery mechanism has to rely on a lookup table residing at 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 shall be Agency Code || System Code || Credential 

Number of the FASC-N. 

The optional card authentication key can be a symmetric key or an asymmetric key. A relying party 

has no prior knowledge of 1) the key’s existence and 2) the key’s symmetric or asymmetric 

implementation. The following routine discovers the Card Authentication Key’s native 

implementation: 

1) Attempt to read the X.509 Certificate for Card Authentication. 

+ If the first step succeeds, the Card Authentication Key is asymmetric. The 

asymmetric PIV algorithm identifier discovery (C.1) mechanism should be followed. 

+ If the first step fails, the Card Authentication Key a) does not exist or b) is a 

symmetric key. 

2) Read the CHUID and extract the Agency Code || System code || Credential Number from 

the CHUID’s FASC-N. 

3) Attempt to retrieve the PIV algorithm identifier from the local lookup table. 

+ If a valid PIV algorithm identifier is returned, the Card Authentication Key is 

symmetric. 

+ If no algorithm identifier is returned, the PIV Card does not implement the key. 

 Page 31 
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 1: End-Point PIV 

 Card Application Namespace, PIV Data Model and Representation 

Appendix D—Terms, Acronyms, and Notation 

D.1 Terms 

Algorithm Identifier A PIV algorithm identifier is a one-byte identifier that specifies a 

cryptographic algorithm and key size. For symmetric cryptographic 

operations, the algorithm identifier also specifies a mode of operation (i.e., 

CBC or ECB). 

Application Identifier A globally unique identifier of a card application as defined in ISO/IEC 

7816-4. 

Application Session The period of time within a card session between when a card application is 

selected and a different card application is selected or the card session ends. 

Authenticatable Entity An entity that can successfully participate in an authentication protocol with 

a card application. 

BER-TLV Data Object A data object coded according to ISO/IEC 8825-2.

Card An integrated circuit card. 

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

application identifier. 

Client Application A computer program running on a computer in communication with a card 

interface device. 

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. 

Interface Device Synonym for card interface device. 

Key Reference A key reference is a one-byte identifier that specifies a cryptographic key 

according to its PIV Key Type. The identifier is part of cryptographic 

material used in a cryptographic protocol such as an authentication or a 

signing protocol. 

MSCUID An optional legacy identifier included for compatibility with Common 

Access Card and Government Smart Card Interoperability Specifications. 

Object Identifier A globally unique identifier of a data object as defined in ISO/IEC 8824-2. 

PIV Key Type A type of a Key. The PIV Key Types are 1) PIV Authentication Key, 2) PIV 

Card Authentication Key, 3) PIV Digital Signature Key, 4) The PIV Key 

Management Key and 5) The Card Application Administration Key. 

Relying Party An entity that relies upon the subscriber’s credentials, typically to process a 

transaction or grant access to information or a system. 

 Page 32 
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 1: End-Point PIV 

 Card Application Namespace, PIV Data Model and Representation 

Status Word Two bytes returned by an integrated circuit card after processing any 

command that signify the success of or errors encountered during said 

processing. 

D.2 Acronyms 

ACR Access Control Rule 

AID Application Identifier 

APDU Application Protocol Data Unit 

API Application Programming Interface 

ASN.1 Abstract Syntax Notation 

BER Basic Encoding Rules 

CBC Cipher Block Chaining 

CBEFF Common Biometric Exchange Formats Framework 

CCC Card Capability Container 

CHUID Cardholder Unique Identifier 

DER Distinguished Encoding Rules 

DES Data Encryption Standard 

ECB Electronic Code Book 

ECC Elliptic Curve Cryptography 

ECDSA Elliptic Curve Digital Signature Algorithm 

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 

GSC-IAB Government Smart Card Interagency Advisory Board 

HSPD Homeland Security Presidential Directive 

 Page 33 
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 1: End-Point PIV 

 Card Application Namespace, PIV Data Model and Representation 

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 

LRC Longitudinal Redundancy Code 

MRTD Machine Readable Travel Document 

MSB Most Significant Bit 

NIST National Institute of Standards and Technology 

OID Object Identifier 

OMB Office of Management and Budget 

PACS Physical Access Control System 

PIN Personal Identification Number 

PI Person Identifier, a field in the FASC-N 

PIV Personal Identity Verification 

PIX Proprietary Identifier Extension 

PKCS Public Key Cryptography Standard 

PKI Public Key Infrastructure 

PUK PIN Unblocking Key 

RFU Reserved for Future Use 

RID Registered application provider IDentifier 

RSA Rivest, Shamir, Aldeman 

SCEPACS Smart Card Enabled Physical Access Control System 

SCP ETSI Smart Card Project 

SP Special Publication 

 Page 34 
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 1: End-Point PIV 

 Card Application Namespace, PIV Data Model and Representation 

SW1 First byte of a two-byte status word 

SW2 Second byte of a two-byte status word 

TIG Technical Implementation Guidance 

TLV Tag-Length-Value 

URL Uniform Resource Locator 

D.3 Notation 

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. 

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

(M) or may be present (O). 

BER-TLV data object tags are represented as byte sequences as described above. Thus, for example, 

'4F' is the interindustry data object tag for an application identifier and '7F 60' is the interindustry data 

object tag for the biometric information template. 

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 [10].

 Page 35 
Special Publication 800-73-2 Interfaces for Personal Identity Verification Part 1: End-Point PIV 

 Card Application Namespace, PIV Data Model and Representation 

 Page 36 

Appendix E—References 

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

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

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

Integrated circuit(s) cards with contacts. 

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

6887 – 2003 Edition, July 16, 2003. 

[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. (see 

http://www.smart.gov/information/TIG_SCEPACS_v2.2.pdf) 

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

Organizations, April 2008. (See http://csrc.nist.gov) 

[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] ISO/IEC 8824-2:2002, Information technology -- Abstract Syntax Notation One (ASN.1): 

Information object specification. 

[8] ISO/IEC 8825-1:2002, Information technology — ASN.1 encoding rules: Specification of Basic 

Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER). 

 

[9] NIST Special Publication 800-78-1, Cryptographic Algorithms and Key Sizes for Personal 

Identity Verification, May 2007. (See http://csrc.nist.gov) 

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