`8.1` Failure Review

NIST PIV and digital identity SP 800-85A-4 against SP 800-85A-2
All changes in this version

modified 8 Test and Compliance Process part of 8

Title

Failure Review

Control changed

Before · SP 800-85A-2

After · SP 800-85A-4

The test will be repeated once for components that do not pass the tests. After the retest, the tester prepares for each failure a discrepancy report that summarizes the purpose of the test, the progression of steps, and the responses received from the tested components. The discrepancy report will be internally reviewed and discussed by the test lab before an official response is sent to the vendor. Vendors who object to the results presented in the discrepancy report must explain their reason for the objection. If the reason necessitates another retest, the test laboratory may consider repeating the test. Otherwise, the test lab will seek the guidance of the NIST personnel on the failure, before the component is returned to the vendor to be corrected. Appendix A—Derived Test Requirements

A.1 End-Point Concepts and Constructs (Chapter 2, Part 2 of SP 800-73-3)

A.1.1 Platform Requirements

AS01.01: The PIV Card Application shall place the following requirements on the ICC platform on which it is implemented or installed:

x Global security status that includes the security status of a global cardholder PIN x Application selection using a truncated Application Identifier (AID) x Ability to reset the security status of an individual application x Indication to applications as to which physical communication interface – contact versus contactless- is in use x Support for the default selection of an application upon warm or cold reset.

A.1.2 Card Applications

AS01.02: Each command that appears on the card command interface shall be implemented by a card application that is resident in the ICC.

Note: This assertion is not separately tested – collection of DTRs for all commands implicitly tests this assertion.

AS01.03: Each card application shall have a globally unique name called its AID [ISO/IEC 7816, Part 4].

Note: This assertion is tested as part of the AS05.05 through AS05.10.

AS01.04: Except for the default applications, access to the card commands and data objects of a card application shall be gained by selecting the card application using its application identifier.

Note: This assertion is tested as part of AS05.11.

AS01.05: The Proprietary Identifier eXtension (PIX) of the AID shall contain an encoding of the version of the card application.

Note: This assertion is tested as part of the AS05.05 through AS05.10. A.1.2.1 Personal Identity Verification Card Application

AS01.06: The AID of the Personal Identity Verification Card Application (PIV Card Application) shall be: ‘A0 00 00 03 08 00 00 10 00 01 00’

Note: This assertion is tested as part of the AS05.05 through AS05.10.

AS01.07: For the first version of the PIV Card Application, t he AID shall consist of the NIST Registered application provider IDentifier (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’.

Note: This assertion is tested as part of the AS05.05 through AS05.10.

A.1.2.2 Default Selected Card Application

AS01.08: The card platform shall support a default selected card application. In other words, there shall be a currently selected application immediately after a cold or warm rest.

VE01.08.01: The vendor shall specify in its documentation the default selected card application.

TE01.08.01: The tester shall validate that there is a default selected card application which is the one specified by the vendor in VE01.08.01.

A.1.3 Security Architecture

A.1.3.1 Access Control Rule

AS01.09: The access control rule shall consist of an access mode and a security condition.

AS01.10: The action described by the access mode can be performed on the data object if and only if the security condition evaluates to TRUE for the current values of the security status. AS01.11: If there is no access control rule with an access mode describing a particular action, then that action shall never be performed on the data object.

A.1.3.2 Security Status

AS01.12: Associated with each authenticatable entity shall be a set of one or more Boolean variables each called a security status indicator of the authenticatable entity.

Note: The security status indicators will be tested indirectly through the functional testing.

AS01.13: The security status indicator of an authenticatable entity shall be TRUE if the credentials associated with the security status indicator of the authenticatable entity have been authenticated and FALSE otherwise.

Note: The security status indicators will be tested indirectly through the functional testing.

AS01.14: The successful execution of an authentication protocol shall set the security status indicator associated with the credentials used in the protocol to TRUE.

Note: The security status indicators will be tested indirectly through the functional testing.

AS01.15: A security status indicator shall be said to be a global security status indicator if it not changed when the currently selected application changes from one application to another.

AS01.16: A security status indicator is said to be an application security status indicator if it is set to FALSE when the currently selected application changes from one application to another.

VE01.16.01: The vendor shall specify in its documentation that the application security status indicators will be set to FALSE when the currently selected application changes from one application to another.

TE01.16.01: The tester shall visually validate that the vendor documentation contains the requirement stated in VE01.16.01. A.1.3.3 Authentication of an Individual

AS01.17: Personal identification numbers (PIV Card Application PINs and PUKs) presented to the card command interface shall be 8 bytes long.

Note: This assertion is tested as part of AS05.22A.

AS01.18: If the actual PIN length is less than 8 bytes, it shall be padded to 8 bytes with ‘FF’ and appended to the actual PIN. The bytes comprising the PIV Card Application PIN shall be limited to values 0x30 – 0x39, the ASCII values for the decimal digits '0' – '9'. The bytes comprising the PUK shall be limited to the values 0x00 – 0xFE (i.e., shall not include 'FF'). If the Global PIN is used by the PIV Card Application then the above encoding, length, and padding requirements for the PIV Card Application PIN shall apply to the Global PIN.

Note: This assertion is tested as part of AS05.22A.

A.1.4 PIV Card Application Status Variables

AS01.19: When the PIV Card Application is the currently selected application, the following status variables shall be associated with it.

x Status Variable: Global Security Status Indicators– must always be defined. Can be used by all applications on the card platform. Maintained by: card platform. x Status Variable: Currently selected application – must always be defined. The platform shall support the selection of a card application using a possibly right-truncated application identifier and there shall always be a currently selected application. Maintained by: card platform. x Status Variable: Application security status Indicators – must always be defined. These indicators are local to the PIV Card Application. Maintained by: PIV Card Application.

A 1.5 Card Platform Configuration

AS01.20: Both single-chip/dual-interface and dual-chip implementations shall be feasible.

AS01.21: In the single-chip/dual-interface configuration, the PIV Card Application shall be provided the information regarding which interface is in use. VE01.21.01: The card operating system should inform the PIV Card Application the communication interface in use.

TE01.21.01: The tester shall validate that the card platform informs the PIV Card Application of the interface being used.

Note: This assertion is not separately tested. This assertion is indirectly tested by verifying whether the card application returns ‘6A 81’ for those commands that cannot be exercised through contactless interface. The tester shall verify response code ‘6A 81’ is returned.

TE01.21.02: The tester shall validate that the PIV Card Application checks that a contact interface is being used for contact-only APDUs.

Note: This assertion is not separately tested. This assertion is indirectly tested by verifying whether the card application returns ‘6A 81’ for those commands that cannot be exercised through contactless interface. The tester shall verify that response code ‘6A 81’ is returned.

AS01.22: In the dual-chip configuration, a separate PIV Card Application shall be loaded on each chip.

A.2 End-Point Data Objects (Part 1, Chapter 4 of SP 800-73-3)

A.2.1 PIV Card Application Data Objects

AS02.01: A PIV Card Application shall contain five mandatory data objects and twenty- eight optional data object for interoperable use.

x The five mandatory data objects are the following: 1. Card Capability Container 2. Card Holder Unique Identifier 3. X.509 Certificate for PIV Authentication 4. Cardholder Fingerprints 5. Security Object

x The twenty-eight optional data objects for interoperable use are the following: 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 7. Key History Object 8. twenty retired X.509 Certificates for Key Management and 9. Cardholder Iris Image A.2.2 OIDs and Tags of PIV Card Application Data Objects

AS02.02: For the purpose of constructing PIV Card Application data object names in the CardApplicationURL in Card Capability Container (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’.

Note: This assertion is tested as part of AS02.03.

AS02.03: For all data objects present on the card, the object identifiers (OIDs) used by PIV Client Application to refer to them, and associated BER-TLV tags used by PIV Card Command Interface shall conform to the entries in Table 2, Part 1 of SP 800-73-2.

VE02.03.01: The vendor shall state in its documentation the list of all the data objects present on the card along with the OIDs and BER-TLV tags associated with them.

TE02.03.01: The tester shall validate that the OIDs and BER-TLV tags of all the data objects present on the card conform to the Table 2, Part 1 of SP 800-73-3, and accurately represent the actual data objects observed by the tester as being implemented on the card.

A.3 End-Point Data Types and Their Representations

A.3.1 Algorithm Identifier

AS03.01: The algorithm identifiers for the cryptographic algorithms implemented on the card shall conform to entries in Table 6-2 of SP 800-78-2.

VE03.01.01: The vendor shall state the identifiers associated with all the algorithms supported by the card.

TE03.01.01: The tester shall validate the presence of all algorithm identifiers implemented on the vendor documentation and the card, and that they comply with Tables 3-1, 5.1 and 6.2 of SP 800-78-2. A.3.2 Application Property Template

AS03.02: Upon selection, the PIV Card Application shall return the application property template described in tables 3 and 4, Part 2 of SP 800-73-3.

VE03.02.01: The vendor shall provide in its documentation the PIV card application property template along with their TLVs.

TE03.02.01: The tester shall visually validate that the information provided in response to VE03.02.01 is in conformance with tables 3 and 4, Part 2 of SP 800-73-3.

TE03.02.02: The tester shall validate that the information provided in VE03.02.01 is actually implemented by the card.

A.3.3 Authenticator

AS03.03: The authenticator BER-TLV used on the PIV client application programming interface shall have the structure described in Table 3, Part 3 of SP 800-73-3.

VE03.03.01: The vendor shall provide a list of all the authenticators along with their tags and possible values, when applicable.

TE03.03.01: The tester shall visually validate that the vendor documentation states the correct tags for the “reference data” and “Key Reference” as shown in Table 3, Part 3 of SP 800-73-3.

TE03.03.02: The tester shall validate that the card returns the correct tags and values in the authenticator data object as specified in Table 3, Part 3 of SP 800-73-3.

A.3.4 Connection Description

AS03.04: The connection description BER-TLV used on the PIV client application programming interface shall have the structure described in table 2, Part 3 of SP 800-73-3.

VE03.04.01: The vendor shall provide in its documentation the format and content of the Connection Description Templates implemented by the card.

TE03.04.01: The tester shall validate the presence of the information provided in VE03.04.01 and that the Connection Description Template sent to the card conforms to Table 2, Part 3 of SP 800-73-3.

AS03.05: At most one selection from the ‘8x’ series and one selection from the ‘9x’ series shall appear in the connection description template as specified in AS03.04.

Note: This assertion is tested as part of AS03.04.

A.3.5 Key References

AS03.06: The key reference, when represented as a byte, occupies b8 and b5-b1 while b7 and b6 shall be set to 0.

AS03.07: The key references used on all PIV interfaces shall be from the list found in Table 6-1 of SP 800-78-2 (for cryptographic key references) or Table 3, Part 1 of SP 800- 73-3 (for PIN references).

AS03.08: The only key reference allowed in the P1 parameter of the RESET RETRY COUNTER command is the PIV Card Application PIN.

VE03.08.01: The vendor shall specify in its documentation that the card conforms to the assertion stated in AS03.08.

TE03.08.01: The tester shall select the PIV Card Application and attempt to reset the Global PIN retry counter with the RESET RETRY Counter command and validate that the global PIN retry counter was not reset.

TE03.08.02: The tester shall visually validate the presence of the information required in VE03.08.01. A.3.6 Status Words

AS03.09: A status word 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.

Note: This assertion is not separately tested – since it is part of the process of testing status words (return codes) for every command in PIV Client API and PIV card command interfaces.

AS03.010: Recognized values of all SW1-SW2 pairs used as return values on both the PIV client application programming and PIV card command interfaces shall be from the list provided in Table 5, Part 1 of SP 800-73-3.

AS03.011: A data object shall be identified on the PIV client application programming interface using its OID.

AS03.012: An object identifier on the PIV client application programming interface shall be a dot-delimited string of the integer components of the OID.

AS03.013: A data object shall be identified on the PIV Card Application card command interface using its BER-TLV tag.

A.4 End-Point Client Application Programming Interface (Part 3 of SP 800-73-3)

AS04.01: Entry points on the PIV client application programming interface shall include all functions listed in Table 1, Part 3 of SP 800-73-3.

Note: This assertion is tested as part of AS04.02 through AS04.11.

A.4.1 Entry Points for Communication

Required Vendor Information & Required Test Procedures

To test the entry points or commands that should be supported by client application, the only information that the vendor has to provide is the PIV Card Application version that the client application supports. All parameter values for exercising the commands have to be obtained from the PIV Card Application vendor documentation, using the mapping of client application entry point commands to the PIV Card Application card commands. This mapping is given in Table A-1 below. Hence this section contains only tester requirements in terms of Required Test Procedures.

Client Application Entry Points PIV Card Application Card Command 5 Mapping Description

pivConnect No equivalent command For establishing a connection session with card reader. pivDisconnect No equivalent command For disconnecting a connection session with the card reader pivSelectCardApplication SELECT Passes the AID value. Sets the value for ‘Currently Selected Application’ on the PIV card. Establishes the PIV Card Application security status. pivLogIntoCardApplication VERIFY Provides the key reference for PIV Card Application PIN as well as the PIN string and passes. Sets/Updates the PIV Card Application Security Status on the card pivLogOutOfCardApplication RESET (not specified in SP 800-73-3) Resets the PIV Card Application Security Status on the card pivGetData GET DATA Maps the Object Identifier (OID) to BER-TLV tag for the selected object pivPutData PUT DATA Maps the OID to BER-TLV tag for the selected object pivGenerateKeyPair GENERATE ASYMMETRIC KEY PAIR Passes the Key Reference and Cryptographic Mechanism identifier values pivCrypt GENERAL AUTHENTICATE Passes the Key Reference, Cryptographic Algorithm reference and the string to be acted upon. Sets/Updates the PIV Card Application Security Status on the card pivMiddlewareVersion No equivalent command Returns the PIV Middleware Version supported by the PIV Middleware IUT

Table A-1 PIV Command Mapping

A.4.1.1 pivConnect

AS04.02: The pivConnect’s purpose is to connect the client application programming interface and hence the client application itself to the PIV Card Application on a

5 It is assumed that some of these functions will use GET RESPONSE and chaining to accomplish the read or write to the card. specific ICC.

TE04.02.01: The tester shall validate that the client application implements the pivConnect as per SP 800-73-3, Part 3.

A.4.1.2 pivDisconnect

AS04.03: The pivDisconnect’s purpose is to disconnect the client application programming interface from the PIV Card Application and the ICC containing the PIV Card Application.

TE04.03.01: The tester shall validate that the client application implements the pivDisconnect as per SP 800-73-3 Part 3.

A.4.2 Entry Points for Data Access

A.4.2.1 pivSelectCardApplication

AS04.04: The pivSelectCardApplication sets the currently selected card application and establishes the PIV Card Application security state.

TE04.04.01: The tester shall validate that the client application implements the pivSelectCardApplication as per SP 800-73-3, Part 3.

A.4.2.2 pivLogIntoCardApplication

AS04.05: The pivLogIntoCardApplication sets/updates the security state within the PIV Card Application.

TE04.05.01: The tester shall validate that the client application implements the pivLogIntoCardApplication as per SP 800-73-3 Part 3.

A.4.2.3 pivGetData

AS04.06: The pivGetData returns the entire data content of the named data object.

TE04.06.01: The tester shall validate that the client application implements the pivGetData as per SP 800-73-3 Part 3.

A.4.2.4 pivLogoutOfCardApplication

AS04.07: The pivLogoutOfCardApplication resets the application security state of the PIV Card Application.

TE04.07.01: The tester shall validate that the client application implements the pivLogoutOfCardApplication as per SP 800-73-3 Part 3. A.4.3 Entry Points for Cryptographic Operations

A.4.3.1 pivCrypt

AS04.08: pivCrypt perform a cryptographic operation such as encryption or signing on a sequence of bytes.

TE04.08.01: The tester shall validate that the client application implements the pivCrypt as per SP 800-73-3 Part 3.

A.4.4 Entry Points for Credential Initialization and Administration

A.4.4.1 pivPutData

AS04.09: The pivPutData replaces the entire data content of the named data object with the provided data.

TE04.09.01: The tester shall validate that the client application implements the pivPutData as per SP 800-73-3 Part 3.

A.4.4.2 pivGenerateKeyPair

AS04.10: The pivGenerateKeyPair generates an asymmetric key pair in the currently selected application.

TE04.10.01: The tester shall validate that the client application implements the pivGenerateKeyPair as per SP 800-73-3 Part 3.

A.4.4.3 pivMiddlewareVersion

AS04.11: SP 800-73-3 Part 3 conformant PIV Middleware shall implement all PIV Middleware functions listed in Table 1 of SP 800-73-3 and be able to recognize and process all mandatory and optional PIV data objects. The pivMiddlewareVersion returns the PIV Middleware version string. For SP 800-73-3 Part 3 conformant PIV Middleware, the parameter returns “800-73-3 Client API”.

TE04.11.01: The tester shall validate that the client application supports all functions listed in table 1 of SP 800-73-3 and implements the pivMiddlewareVersion as per SP 800- 73-3 Part 3 by returning the “800-73-3 Client API” parameter string.

A.5 End-Point PIV Card Application Card Command Interface (Part 2 of SP 800- 73-3) AS05.01: All PIV Card Application card commands listed in Table 2, Part 2 of SP 800-73- 3 shall be supported by a PIV Card Application.

VE05.01.01: The vendor shall provide the list of all PIV Card Application card commands, along with the interface(s) (contact or contactless) they support, the security condition(s) they are subject to and their support for command chaining as implemented by the card.

TE05.01.01: The tester shall validate that the information presented in response to VE05.01.01 by the vendor complies with Table 2, Part 2 of SP 800-73-3.

TE05.01.02: The tester shall validate that the card implements all the commands as required in Table 2, Part 2 of SP 800-73-3.

TE05.01.03: The tester shall validate that the commands are implemented only through the interfaces allowed as shown in Table 2, Part 2 of SP 800-73-3.

TE05.01.04: The tester shall validate that the commands are implemented only after the security condition associated with them are satisfied, as shown in the table, via the specified interface.

TE05.01.05: The tester shall validate that only the commands as indicated in the table are allowed for chaining via the interface supported after the security condition is satisfied.

AS05.02: Card commands indicated with a 'Yes' in the Command Chaining column shall support command chaining for transmitting a data string too long for a single command as defined in ISO/IEC 7816-4 [6].

Note: This assertion is tested as part of AS05.01.

AS05.03: The PIV Card Application shall return the status word of ‘6A81’ (Function not supported) when it receives a card command on the contactless interface marked “No” in the Contactless Interface column in the table in AS05.01.

Note: This assertion is tested as part of AS05.01.

AS05.04: Cryptographic protocols using private/secret keys requiring PIN security condition shall not be used on the contactless interface .

Note: This assertion is tested as part of AS05.01.

A.5.1 PIV Card Application Card Commands for Data Access

A.5.1.1 SELECT Card Command AS05.05: The PIV Card Application shall be selected by providing its application identifier ‘A0 00 00 03 08 00 00 10 00 vv vv’ in the data field of the SELECT command where 'vv vv' is the version of the PIV Card Application to be made the currently selected application.

VE05.05.01: The vendor shall specify in its documentation the PIV Card Application Identifier.

TE05.05.01: The tester shall validate that the PIV Card Application is selected by providing its application identifier as specified in VE05.05.01.

AS05.06: There shall be at most one PIV Card Application on any ICC.

VE05.06.01: The vendor shall state in its documentation that there is only one PIV Card Application on the ICC.

TE05.06.01: The tester shall visually validate the vendor documentation for the information provided in VE05.06.01.

AS05.07: The PIV Card Application can also be made the currently selected application by providing a right-truncated version; that is, without the two-byte version number, 'vv vv'; in the data field of the SELECT command 'A0 00 00 03 08 00 00 10 00’

VE05.07.01: The vendor shall specify in its documentation whether the card implements the application selection by the right-truncated version.

TE05.07.01: The tester shall visually validate that the information in VE05.07.01 is present in the vendor documentation.

TE05.07.02: The tester shall validate that the PIV application is selectable by the right- truncated SELECT command. AS05.08: The complete AID, including the two-byte version, of the PIV Card Application that became the currently selected application upon successful execution of the SELECT command shall be returned in the application property template.

Note: This assertion is tested as part of AS03.02.

AS05.09: If the currently selected application is the PIV Card Application when the SELECT APPLICATION command is given and the AID in the data field of the SELECT APPLICATION is either the AID of the PIV Card Application or its right-truncated version thereof, then the PIV Card Application shall continue to be the currently selected application and the setting of all security status indicators in the PIV Card Application shall be unchanged.

VE05.09.01: The vendor shall provide information in its documentation validating the compliance with the statement in AS05.09.

TE05.09.01: The tester shall validate that when the currently selected application is the PIV Card Application and the SELECT command is sent with an AID that is either the AID of the PIV Card Application or its right-truncated version, then the PIV Card Application shall continue to be the currently selected application and the setting of all security status indicators in the PIV Card Application shall be unchanged.

AS.05.10 If the currently selected application is the PIV Card Application when the SELECT APPLICATION command is given and the AID in the data field of the SELECT APPLICATION is an invalid AID not supported by the PIV card then the PIV Card Application shall continue to be the currently selected application and the setting of all security status indicators in the PIV Card Application shall remain unchanged.

VE05.10.01: The vendor shall provide information in its documentation validating the compliance with the statement in AS05.10.

TE05.10.01: The tester shall validate that when the currently selected application is the PIV Card Application, and the SELECT APPLICATION command is sent with an AID that is not a valid AID supported by the card, then the PIV Card Application continues to be the currently selected application and the setting of all security status indicators in the PIV Card Application shall be unchanged. AS.05.11: If the currently selected application is the PIV Card Application when the SELECT command is given and the AID in the data field of the SELECT APPLICATION is not the PIV card Application (nor the right-truncated version thereof), but a valid AID supported by the ICC, then the PIV Card Application shall be deselected and all PIV Card Application security status indicators shall be set to FALSE.

VE05.11.01: If the ICC supports another card application, the vendor shall provide information in its documentation validating the compliance with the statement in AS05.11.

TE05.11.01: If the ICC supports another card application, the tester shall validate that when the currently selected application is the PIV Card Application and the SELECT APPLICATION command is sent with an AID different from the PIV Card Application AID (or its right- truncated version), but is a valid AID supported by the ICC, then PIV Card Application shall be deselected and its security status indicators shall be set to FALSE.

A.5.1.2 GET DATA Card Command

AS.05.12 The GET DATA card command retrieves the data content of the single data object whose tag is given in the data field.

Note: This assertion is tested as part of AS05.01.

AS05.12A: The GET DATA card command retrieves the data content of the data object only after the access rule associated with the data object (Appendix A, Table 6, Part 1 of SP 800-73-3) evaluates to TRUE.

VE05.12A.01: The vendor shall specify in its documentation the access rule for each of the data objects or make a reference to Table 6 in Appendix A, Part 1 of SP 800-73-3.

TE05.12A.01: For implementations without the Discovery Object or implementations with the Discovery Object implemented and the PIN usage policy’s first byte set to 0x40: The Tester shall validate that all data objects that require a PIN shall only be accessible after a successful validation of the PIV Card Application PIN through the VERIFY command.

TE05.12A.02: For implementations with the Discovery Object implemented and the PIN usage policy first byte set to 0x60: 1) The Tester shall validate that all data objects that require a PIN shall be accessible after a successful VERIFY with the PIV Card Application PIN. 2) The Tester also shall validate that all data objects that require a PIN shall be accessible after a successful VERIFY with the Global PIN.

TE05.12A.03: The Tester shall validate that all data objects whose access rule is “Always Read” shall be accessible with or without PIV Card Application PIN validation or Global PIN validation (if implemented as indicated in the Discovery Object).

A.5.2 PIV Card Application Card Commands for Authentication

A.5.2.1 VERIFY Card Command

AS.05.13: PIV Card Application that satisfy the PIV ACRs for PIV data object access and command execution 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.

VE05.13.01: The vendor shall confirm that the PIV Card Application PIN can be used for PIV data object access and command execution. If the Global PIN (in addition to the PIV Card Application PIN) is used for data access and command execution while the PIV Card Application is the currently selected application, the vendor shall state in its documentation that the card supports the assertion made in AS05.13.

TE05.13.01: The tester shall validate that the PIV Card Application PIN can be used for PIV data object access and command execution. The tester shall validate that when the Global PIN satisfies the PIV ACRs for PIV data object access and command execution with both PIV Card Application PIN and Global PIN then: 1) the Discovery Object is implemented with the PIN Usage Policy set to 0x60 zz, where zz is set to either 0x10 or 0x20 and 2) the Global PIN can be used for PIV data object access and command execution.

AS.05.14: Key reference '80' specific to the PIV Card Application (i.e., local key references) and, optionally, the Global PIN with key reference '00' are the only key references that may be verified by the PIV Card Application’s VERIFY command.

Note: This assertion is tested as part of AS05.013.

AS.05.15: Key reference '80' shall be verified by the PIV Card Application VERIFY command.

Note: This assertion is tested as part of AS05.13. AS.05.16: If the PIV Card Application contains the Discovery Object as described in Part 1 of SP 800-73-3, and the first byte of the PIN Usage Policy value is set to 0x60, then key reference '00' shall be able to be verified by the PIV Card Application VERIFY command.

VE05.16.01: The vendor shall specify in its documentation if the Global PIN is implemented with the VERIFY command to satisfy access control rules to read PIN protected PIV data objects. If implemented, the vendor shall also specify the Discovery Object to be present on card with the first byte of the PIN Usage Policy value set to 0x60.

TE05.16.01: The tester shall validate that if global PIN is implemented with the VERIFY command, then the Discovery Object is present on the card with the first byte of the PIN Usage Policy value set to 0x60.

AS.05.17: If the current value of the retry counter associated with the key reference is zero, then the comparison shall not be made and the PIV Card Application shall return the status word ‘69 83’ (Authentication method blocked).

VE05.17.01: The vendor shall specify in its documentation the reset value of the retry counters associated with all the key references implemented on the card.

TE05.17.01: The tester shall validate that the PIV Card Application returns ‘69 83’ (Authentication method blocked) in response to the VERIFY command, when the retry counter associated with the key reference is zero.

AS05.18: If the authentication data in the command data field does not satisfy the criteria in Section 2.4.3, then the card command shall fail, and the PIV Card Application shall return the status word '6A 80'.

VE05.18.01: The vendor shall specify in its documentation the conditions (and associated status word) when the command will fail. TE05.18.01: The tester shall validate that when the authentication data in the command data field does not satisfy the criteria in Section 2.4.3, SP 800-73-3 Part 1, the card command fails, and the PIV Card Application returns the status word '6A 80'.

AS05.19: If the authentication data in the command data field does not match reference data associated with the key reference then the card command shall fail.

VE05.19.01: The vendor shall specify in its documentation the conditions (and associated status word) when the command will fail.

TE05.19.01: The tester shall validate that when the authentication data in the command data field does not match the reference data, the card command fails, and the PIV Card Application returns the status word '6A 80.

AS05.20 If the card command succeeds, then the security status of the key reference shall be set to TRUE and the retry counter associated with the key reference shall be set to the reset retry value associated with the key reference.

VE05.20.01: Same as VE05.17.01.

TE05.20.01: The tester shall validate that the retry counter associated with the key reference shall be set to the reset retry value specified by the vendor in VE05.20.01 (not decremented), when the VERIFY command succeeds.

AS05.21: If the card command fails, then the security status of the key reference shall be set to FALSE and the retry counter associated with the key reference shall be decremented by one.

VE05.21.01: The vendor shall state in its documentation that the card supports the assertion made in AS05.21. TE05.21.01: The tester shall validate that when the VERIFY command fails, the retry counter associated with the key reference is decremented by one.

AS05.22A: If the PIN value in the reference data field of the command field is not padded to 8 bytes, the PIV Card Application shall return the status word '6A 80'.

VE05.22.01A: The vendor shall state in its documentation that the card supports the assertion made in AS05.22A.

TE05.22.01A: The tester shall validate that the vendor documentation contains the information required in VE05.22.01A and the card returns status word ‘6A 80’, when the PIN information in the reference data field of the command is not padded to 8 bytes.

AS05.22B: If the key reference is set to a value other than what is supported by the card, the PIV Card Application shall return the status word ‘6A 88’ (Reference Data not found).

VE05.22.01B: The vendor shall state in its documentation that the card supports the assertion made in AS05.22B.

TE05.22.01B: The tester shall validate that the vendor documentation contains the information required in VE05.22.01B and the card returns status word ‘6A 88’, when the key reference is set to a value other than what is supported by the card.

A.5.2.2 CHANGE REFERENCE DATA Card Command

AS05.23 and AS05.24: Only reference data associated with key references ‘80’ and ‘81’ specific to the PIV Card Application (i.e., local key reference) and the Global PIN with key reference ‘00’ may be changed by the PIV card Application Change Reference Data command. Key reference ‘80’ reference data shall be changed by the PIV Card Application CHANGE REFERENCE DATA command. The ability to change reference data associated with key references '81' and '00' using the PIV Card Application CHANGE REFERENCE DATA command is optional.

VE05.23 and VE05.24: The vendor shall state in its documentation that the card supports the assertion made in AS05.023 and AS05.24. TE05.23.01 and TE05.24.01: The tester shall validate that reference data associated with key reference ‘80’ can be changed by the PIV Card Application’s CHANGE REFERENCE DATA command. If the Discovery Object is implemented with PIN Usage Policy first byte set to 0x60, and the implementation supports changing the Global PIN with the CHANGE REFERENCE DATA command, then the tester shall also validate that key reference ‘00’ reference data can be changed by the CHANGE REFERENCE DATA command.

AS05.25: If the current value of the retry counter associated with the key reference is zero, then the reference data associated with the key reference shall not be changed and the PIV Card Application shall return the status word ‘69 83’ (Authentication method blocked).

VE05.25.01: The vendor shall state in its documentation that the card supports the assertion made in AS05.016.

TE05.25.01: The tester shall validate that when the current value of the retry counter associated with the key reference is zero, the reference data associated with the key reference does not change and the PIV Card Application returns ‘69 83’ (Authentication method blocked).

AS05.26 If the card command succeeds, then the security status of the key reference shall be set to TRUE and the retry counter associated with the key reference shall be set to the reset retry value associated with the key reference.

VE05.26.01: The vendor shall state in its documentation that the card supports the assertion made in AS05.26.

TE05.26.01: The tester shall validate that the vendor documentation states the required information in VE05.26.01 and the retry counter associated with the key reference shall be set to the reset retry value associated with the key reference when the command succeeds.

AS05.27: If the card command fails, then the security status of the key reference shall be set to FALSE and the retry counter associated with the key reference shall be decremented by one. VE05.27.01: The vendor shall state in its documentation that the card supports the assertion made in AS05.18.

TE05.27.01: The tester shall validate that the vendor documentation contains the information required in VE05.27.01 and the retry counter associated with the key reference shall be decremented by one if the card command fails.

AS05.28: If the either the current reference data or the new reference data in the command data field of the command does not satisfy the criteria in Section 2.4.3, Part 2 of SP 800-73-3, the PIV Card Application shall not change the reference data associated with the key reference and shall return the status word '6A 80'.

VE05.28.01: The vendor shall state in its documentation that the card supports the assertion made in AS05. 28.

TE05.28.01: The tester shall validate that 1) the vendor documentation contains the information required in VE05.19.01, 2) the old PIN is not changed, and 3) the card returns status word ‘6A 80’ when the PIN information in the reference data field of the command is not padded to 8 bytes.

AS05.28A: If the key reference is set to a value other than what is supported by the card, the PIV Card Application … shall return the status word ‘6A 88’ (Key Reference not found).

VE05.28.01.A: The vendor shall state in its documentation that the card supports the assertion made in AS05.28A.

TE05.28.01A: The tester shall validate that the vendor documentation contains the information required in VE05.28.01A, the old PIN is not changed, and the card returns status word ‘6A 88’, when the key reference is set to a value other than what is supported by the card.

A.5.2.3 RESET RETRY COUNTER Card Command

AS05.29: The only key reference allowed in the P1 parameter of the RESET RETRY COUNTER command is the PIV Card Application PIN. .

Note: This assertion is not tested separately.

AS05.30: If the current value of the PUK’s retry counter is zero then the PIN’s retry counter shall not be reset and the PIV Card Application shall return the status word ‘69 83’ (Authentication method blocked).

VE05.30.01: same as VE05.17.01.

VE05.30.02: The vendor shall specify in its documentation that the RESET RETRY COUNTER card command will not reset the retry counter and the card will return ‘69 83’ (Authentication method blocked) when the PUK’s retry counter associated with the key reference is zero.

TE05.30.01: The tester shall validate that the information requested in VE05.30.02 and VE05.30.01 are present in the vendor documentation. (NOTE: Testing this condition will leave the card unusable for further tests since the reset counter is zero).

AS05.31: If the card command succeeds, then the PIN’s retry counter shall be set to its reset retry value. Optionally, the PUK’s retry counter may be set to its initial reset retry value. The security status of the PIN’s key reference shall not be changed.

VE05.31.01: same as VE05.17.01

VE05.31.02: The vendor shall specify in its documentation that the card supports the assertion made in AS05.31.

TE05.31.01: The tester shall validate that when the card command succeeds, the PIN’s retry counter is set to the PIN’s reset retry value specified in VE05.31.01, and the security status of the PIN’s key reference is not changed. If the PUK’s retry counter can be reset, the tester shall validate that the PUK’s retry counter was reset to its initial reset retry value.

AS05.32: If the card command fails, then the security status of the PIN’s key reference shall be set to FALSE and the PUK’s retry counter shall be decremented by one. VE05.32.01: The vendor shall state in its documentation that card supports the assertion made in AS05.032.

TE05.32.01: The tester shall validate that the information requested in VE05.32.01 is present in the vendor documentation, the security status of the PIN’s key reference is set to FALSE and the PUK’s retry counter is decremented by one.

AS05.33: If the either the reset retry counter reference data (PUK) or the new reference data (PIN) in the command field of the command does not satisfy the criteria in Section 2.4.3, Part 2 of SP 800-73-3, the PIV Card Application shall not reset the retry counter associated with the PIN and shall return the status word '6A 80'.

VE05.33.01: The vendor shall state in its documentation that the card supports the assertion made in AS05.33.

TE05.33.01: The tester shall validate that the vendor documentation includes the information required in VE05.24.01 and that when either the PUK or the PIN of the command does not satisfy the criteria in Section 2.4.3 Part 2 of SP 800-73-3, the PIN’s retry counter is not reset and the card returns ‘6A 80.’

AS05.33A: If the key reference value is other than what is supported by the card, the PIV Card Application shall … return the status word ‘6A 88’ (Key Reference not found).

VE05.33.01A: The vendor shall state in its documentation that the card supports the assertion made in AS05.33A.

TE05.33.01A: The tester shall validate that the vendor documentation includes the information required in VE05.33.01A and that when the key reference value is other than what is supported by the card, the card returns ‘6A 88’.

A.5.2.4 GENERAL AUTHENTICATE Card Command

AS05.34: The GENERAL AUTHENTICATE card command performs a cryptographic operation such as an authentication protocol using the data provided in the data field of the command and returns the result of the cryptographic operation in the response data field. 1) The GENERAL AUTHENTICATE command shall be used with the PIV authentication Keys (‘9A’, ‘9B’ ‘9E’) to authenticate the card or a card application to the client application (INTERNAL AUTHENTICATE), to authenticate an entity to the card (EXTERNAL AUTHENTICATE), and to perform a mutual authentication between the card and an entity external to the card (MUTUAL AUTHENTICATE

2) The GENERAL AUTHENTICATE command shall be used with the PIV Digital Signature Key (‘9C’) to realize the signing functionality on the PIV client application programming interface. Data to be signed is expected to be hashed off- card.

3) The GENERAL AUTHENTICATE command shall be used with the PIV Key Management Key ('9D') and the retired PIV Key Management Keys ('82' – '95') to realize key establishment schemes specified in SP 800-78 (ECDH and RSA).

VE05.34.01: The vendor shall specify in its documentation the types of cryptographic operations (authentication, key establishment, signing) supported by the card.

TE05.34.01: The tester shall validate that the GENERAL AUTHENTICATE command is implemented to authenticate the Card to the client application.

TE05.34.02: The tester shall validate that the GENERAL AUTHENTICATE command is implemented to authenticate the client application to the card.

TE05.34.03: The tester shall validate that the GENERAL AUTHENTICATE command is implemented to mutually authenticate the Card to the client application and the client application to the card.

TE05.34.04: If the 9C key is implemented, the tester shall validate that the GENERAL AUTHENTICATE command is implemented to realize signing functionality.

TE05.34.05: If the 9D key is implemented, the tester shall validate that the GENERAL AUTHENTICATE command is implemented to support the RSA key transport or Elliptic Curve Diffie Hellman key establishment schemes specified in SP800-78.

AS05.35: The GENERAL AUTHENTICATE command shall be implemented to realize the signing functionality on the PIV client application programming interface.

AS05.35 is satisfied by AS05:34 and its TE05.34.04. AS05.36: If an invalid value of algorithm reference (P1) and/or key reference (P2) is sent to the card, the PIV Card Application shall return the status word '6A 86'.

VE05.36.01: The vendor shall state in its documentation that the card supports the assertion made in AS05.36.

TE05.36.01: The tester shall validate that the vendor documentation contains the information required in VE05.36.01 and the card returns status word ‘6A 86’, when an invalid value of algorithm reference (P1) or key reference (P2) is sent to the card.

AS05.36A: If an invalid value is sent in the data field, the PIV Card Application shall return the status word '6A 80'.

VE05.36.01A: The vendor shall state in its documentation that the card supports the assertion made in AS05.36A.

TE05.36.01A: The tester shall validate that the vendor documentation contains the information required in VE05.36.01A and the card returns status word ‘6A 80’ when an invalid value in data field of the command is sent to the card.

AS05.36B: If the command is used to authenticate the Card to the client application using a PIN-protected PIV key, without prior PIN verification, the PIV Card Application shall return the status word '69 82'.

VE05.36.01B: The vendor shall state in its documentation that the card supports the assertion made in AS05.36B.

TE05.36.01B: The tester shall validate that the vendor documentation contains the information required in VE05.36.01B and the card returns status word ’69 82 whenever the command is used to authenticate the card to the client application using a PIN protected key without prior PIN verification.

AS05.36C: If a card command other than the GENERAL AUTHENTICATE command is received by the PIV Card Application before the termination of a GENERAL AUTHENTICATE chain, the PIV Card Application shall rollback to the state it was in immediately prior to the reception of the first command in the interrupted chain.

VE05.36.01C: The vendor shall specify in its documentation that the card supports the assertion made in AS05.36C.

TE05.36.01C: The tester shall validate by inspection of the vendor documentation that the PIV Card Application reverts back to the state it was in if a command other than GENERAL AUTHENTICATE is received before the termination of a GENERAL AUTHENTICATE chain.

A.5.3 PIV Card Application Card Commands for Credential Initialization and Administration

A.5.3.1 PUT DATA Card Command

AS05.37: The PUT DATA card command completely replaces the data content of a single data object in the PIV Card Application with new content.

VE05.37.01: The vendor shall specify in its documentation the format, encoding, and the parameters of the PUT DATA command supported by the card.

TE05.37.01: The tester shall validate that the card complies with the PUT DATA command as defined in SP 800-73-3, Part 2.

A.5.3.2 GENERATE ASYMMETRIC KEY PAIR Card Command

AS05.38 The GENERATE ASYMMETRIC KEY PAIR card command initiates the generation and storing in the card of the reference data of an asymmetric key pair, i.e., a public key and a private key, and the command returns the public key.

VE05.38.01: The vendor shall specify in its documentation the cryptographic mechanism identifiers (specified in table 4, Part 1 of SP 800-73-3) that have been implemented on the card. TE05.38.01: The tester shall validate that the card implements the algorithms associated with identifiers specified as part of VE05.38.01 requirement and that the public key returned is formatted based on data object tags specified in Table 9, Part 2 of SP 800-73-3.

AS05.39: The public key of the generated key pair is returned as the response to the command.

Note: This assertion is tested as part of AS05.38.

AS05.40: If there is reference data currently associated with the key reference, it is replaced in full by the generated data.

VE05.40.01: The vendor shall provide the contents of the public key data on the card.

TE05.40.01: The tester shall validate that the initial contents of the public key data is replaced in full by the generated data, following a GENERATE ASYMMETRIC KEY PAIR command. Appendix B—PIV Client API Test Assertions

Test Assertion Template Purpose A quick description of the test and why it is being run Target The PIV function call being tested Reference(s) References to the SP 800-73-3 or other relevant publications Precondition(s) Anything that must be done or known prior to executing the scenario Sequence of steps for making a function call Expected Result(s) What the expected execution path yields in terms of progress and values Post Condition(s) A description of both client and card application state once the test scenario completes

B.1 Connection Test Assertions

B.1.1 Valid Path Test Assertions

B.1.1.1 Initiate Exclusive Connection Purpose Confirms that an exclusive connection can be obtained by a calling application to the PIV Card Application on a specific ICC Target pivConnect Reference(s) 1. SP 800-73-3 Part 3, Section 3.1.2 2. AS03.04, AS04.01, AS04.02 Precondition(s) 1. A valid connection description is provided for the card application 2. There exists a valid physical connection between an instance of the PIV Card and the host of the calling applicationThe test will be repeated once for components that do not pass the tests. After the retest, the tester prepares, for each failure, a discrepancy report that summarizes the purpose of the test, the progression of steps, and the responses received from the tested components. The discrepancy report will be internally reviewed and discussed by the test lab before an official response is sent to the vendor. Vendors who object to the results presented in the discrepancy report must explain their reason for the objection. If the reason necessitates another retest, the test laboratory may consider repeating the test. Otherwise, the test lab will seek the guidance of the NIST personnel on the failure before the component is returned to the vendor to be corrected. Derived Test Requirements

All DTRs that are new to Revision 4 of this document are new requirements introduced in SP 800- 73-4 . These are referenced with the suffix -R4 (e.g., AS0 X -R4). Updated DTRs that existed previously are requirements updated in SP 800-73-4 and these retain their original identifiers.

A.1 Concepts and Constructs

A.1.1 Platform Requirements

AS01.01: The PIV Card Application shall place the following requirements on the ICC platform on which it is implemented or installed:

+ global security status that includes the security status of a global cardholder PIN. + application selection using a truncated Application Identifier (AID). + ability to reset the security status of an individual application. + indication to applications as to which physical communication interface – contact versus contactless – is in use. + support for the default selection of an application upon warm or cold reset.

Note: This assertion is not separately tested.

A.1.2 Card Applications

AS01.02: Each command that appears on the card command interface shall be implemented by a card application that is resident on the ICC.

Note: This assertion is not separately tested – collection of DTRs for all commands implicitly tests this assertion.

AS01.03: Each card application shall have a globally unique name called its Application Identifier (AID) [ ISO/IEC 7816 , Part 4].

Note: This assertion is tested as part of AS05.05 through AS05.10 .

AS01.04: Except for the default applications, access to the card commands and data objects of a card application shall be gained by selecting the card application using its application identifier.

Note: This assertion is tested as part of AS05.11 .

AS01.05: The Proprietary Identifier eXtension (PIX) of the AID shall contain an encoding of the version of the card application.

Note: This assertion is tested as part of the AS05.05 through AS05.10 . A.1.2.1 Personal Identity Verification Card Application

AS01.06: The AID of the PIV Card Application shall be: 'A0 00 00 03 08 00 00 10 00 01 00'.

Note: This assertion is tested as part of the AS05.05 through AS05.10 .

AS01.07: The AID of the PIV Card Application shall consist of the NIST Registered application provider IDentifier (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.

Note: This assertion is tested as part of the AS05.05 through AS05.10 .

A.1.2.2 Default Selected Card Application

AS01.08: The card platform shall support a default selected card application. In other words, there shall be a currently selected application immediately after a cold or warm reset.

VE01.08.01: The vendor shall specify in its documentation the default selected card application.

TE01.08.01: The tester shall review the vendor’s documentation and validate that there is a default selected card application, which matches with the one specified by the vendor in VE01.08.01 .

A.1.3 Security Architecture

A.1.3.1 Access Control Rule

AS01.09: An access control rule shall consist of an access mode and a security condition.

Note: This assertion is not separately tested.

AS01.10: The action described by the access mode can be performed on the data object if and only if the security condition evaluates to TRUE for the current values of the security statuses.

Note: This assertion is not separately tested.

AS01.11: If there is no access control rule with an access mode describing a particular action, then that action shall never be performed on the data object.

Note: This assertion is not separately tested. A.1.3.2 Security Status

AS01.12: Associated with each authenticable entity shall be a set of one or more Boolean variables, each called a security status indicator of the authenticable entity.

Note: The security status indicators are tested indirectly through the functional testing.

AS01.13: The security status indicator of an authenticable entity shall be TRUE if the credentials associated with the security status indicator of the authenticable entity have been authenticated and FALSE otherwise.

Note: The security status indicators are tested indirectly through the functional testing.

AS01.14: A successful execution of an authentication protocol shall set the security status indicator associated with the credential used in the protocol to TRUE.

Note: The security status indicators are tested indirectly through the functional testing.

AS01.14A-R4: An aborted or failed execution of an authentication protocol shall set the security status indicator associated with the credential used in the protocol to FALSE.

Note: The security status indicators are tested indirectly through the functional testing.

AS01.15: A security status indicator shall be said to be a global security status indicator if it is not changed when the currently selected application changes from one application to another. In essence, when changing from one application to another, the global security status indicators shall remain unchanged.

Note: This assertion is not separately tested.

AS01.16: A security status indicator is said to be an application security status indicator if it is set to FALSE when the currently selected application changes from one application to another.

VE01.16.01: The vendor shall specify in its documentation that the application security status indicators are set to FALSE when the currently selected application changes from one application to another.

TE01.16.01: The tester shall review the vendor’s documentation and validate that it contains the requirement stated in VE01.16.01 .

AS01.16A-R4: The security status indicators associated with the PIV Card Application PIN, the PIN Unblocking Key (PUK), OCC, pairing code, and the PIV Card Application Administration Key are application security status indicators for the PIV Card Application, whereas the security status indicator associated with the Global PIN is a global security status indicator .

VE01.16A-R4.01: The vendor shall specify in its documentation that the security status indicators associated with the PIV Card Application PIN, the PIN Unblocking Key (PUK), OCC, pairing code, and the PIV Card Application Administration Key are application security status indicators for the PIV Card Application, whereas the security status indicator associated with the Global PIN is a global security status indicator.

TE01.16A-R4.01: The tester shall review the vendor’s documentation and validate that it contains the requirement stated in VE01.16A-R4.01 .

A.1.3.3 Authentication of an Individual

AS01.17: The pairing code shall be exactly 8 bytes in length and the PIV Card Application PIN shall be between 6 and 8 bytes in length.

Note: This assertion is tested as part of AS05.22A .

AS01.18: If the actual length of PIV Card Application PIN is less than 8 bytes it shall be padded to 8 bytes with 'FF' when presented to the card command interface. The 'FF' padding bytes shall be appended to the actual value of the PIN.

Note: This assertion is tested as part of AS05.22A .

AS01.18A-R4: The bytes comprising the PIV Card Application PIN and pairing code shall be limited to values 0x30 – 0x39, the ASCII values for the decimal digits '0' – '9'.

Note: This assertion is tested as part of AS05.22A .

AS01.18B-R4: The PIV Card Application shall enforce the minimum length requirement of six bytes for the PIV Card Application PIN (i.e., shall verify that at least the first six bytes of the value presented to the card command interface are in the range 0x30 – 0x39) as well as the other formatting requirements specified in Section 2.4.3 of Part 2 of SP 800-73-4 .

Note: This assertion is tested as part of AS05.22A .

AS01.18C-R4: The PUK shall be 8 bytes in length, and may be any 8-byte binary value. That is, the bytes comprising the PUK may have any value 0x00 – 0xFF.

Note: This assertion is tested as part of AS05.22A . AS01.18D-R4: If the Global PIN is used by the PIV Card Application, then the above encoding, length, padding, and enforcement of minimum PIN length requirements for the PIV Card Application PIN shall apply to the Global PIN.

Note: This assertion is tested as part of AS05.22A .

A.1.4 Status of PIV Card Application

AS01.19: The state of the PIV Card Application shall be as follows, when the PIV Card Application is the currently selected application:

1. The “global security status” indicator shall always be defined. It can be used by all applications on the card platform and is maintained by PIV Platform. 2. The “currently selected application” shall always be defined. The platform shall support the selection of a card application using the full application identifier or by providing the right truncated version and there shall always be a currently selected application. The “currently selected application” is maintained by the PIV Platform. 3. The “application security status” indicator shall always be defined. These indicators are local to the PIV Card Application and are maintained by the PIV Card Application.

Note: This assertion is not separately tested.

A.1.5 Card Platform Configuration

AS01.20: Both single-chip/dual-interface and dual-chip implementations are acceptable.

Note : This assertion is not separately tested.

AS01.21: In the single-chip/dual-interface configuration, the PIV Card Application shall be provided the information regarding which interface is in use.

VE01.21.01: The card operating system should inform the PIV Card Application the communication interface in use.

TE01.21.01: The tester shall validate that the card platform informs the PIV Card Application of the interface being used.

Note: This assertion is not separately tested. This assertion is indirectly tested by verifying whether the card application returns an appropriate error response code for those commands that cannot be exercised through contactless interface. The tester shall verify an appropriate response code is returned.

TE01.21.02: The tester shall validate that the PIV Card Application checks that a contact interface is being used for contact-only APDUs.

Note: This assertion is not separately tested. This assertion is indirectly tested by verifying whether the card application returns an appropriate error response code for those commands that cannot be exercised through contactless interface when VCI is not in use and the commands are not contact only commands.

AS01.22: In the dual-chip configuration, a separate PIV Card Application shall be loaded on each chip.

Note: This assertion is not separately tested.

A.2 PIV Data Model

A.2.1 PIV Card Data Objects

AS02.01: A PIV Card Application shall contain seven mandatory interoperable data objects, two conditionally mandatory data objects (if the cardholder has a government-issued email account at time of credential issuance) and twenty-seven optional data objects for interoperable use.

• The seven mandatory data objects are the following: 1. Card Capability Container; 2. Card Holder Unique Identifier; 3. X.509 Certificate for PIV Authentication; 4. X.509 Certificate for Card Authentication; 5. Cardholder Fingerprints; 6. Cardholder Facial Image; and 7. Security Object

• The two conditionally mandatory data objects are the following: 1. X.509 Certificate for Digital Signature; and 2. X.509 Certificate for Key Management .

• The twenty-seven optional data objects for interoperable use are the following: 1. Printed Information; 2. Discovery Object; 3. Key History Object; 4. 20 retired X.509 Certificates for Key Management; 5. Cardholder Iris Images; 6. Biometric Information Templates Group Template; 7. Secure Messaging Certificate Signer; and 8. Pairing Code Reference Data Container.

Note: This assertion is not separately tested.

A.2.2 OIDs and Tags of PIV Card Application Data Objects

AS02.02: For the purpose of constructing PIV Card Application data object names in the CardApplicationURL in the Card Capability Container 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'. Note: This assertion is not separately tested as it is being deprecated.

AS02.03: For all data objects present on the card, the object identifiers (OIDs) used by PIV Middleware to refer to them, and associated BER-TLV tags used by PIV Card Application command interface shall conform to the entries in Table 3, Part 1 of SP 800-73-4 .

VE02.03.01: The vendor shall state in its documentation the list of all the data objects present on the card along with the BER-TLV tags associated with them.

VE02.03.01A: The vendor shall state in its documentation the list of all OIDs used by the PIV Middleware to refer to PIV data objects and the associated BER-TLV tags to which they refer.

TE02.03.01: The tester shall validate that the BER-TLV tags of all the data objects present on the card conform to the Table 3, Part 1 of SP 800-73-4 , and accurately represent the actual data objects observed by the tester as being implemented on the card.

TE02.03.01A: The tester shall validate that all of the OIDs in Table 3, Part 1 of SP 800-73-4 can be used to read PIV data objects from a PIV Card using the pivGetData function.

A.3 Data Types and Their Representations

A.3.1 PIV Algorithm Identifier

AS03.01: The algorithm identifiers for the cryptographic algorithms implemented on the card shall conform to entries in Table 6-2 of SP 800-78-4 .

VE03.01.01: The vendor shall state in its documentation the identifiers associated with all the algorithms supported by the card.

TE03.01.01: The tester shall review the vendor’s documentation and validate the algorithm identifiers implemented on the card as being compliant with Tables 6-2 and 6-3 of SP 800-78-4 .

A.3.2 Application Property Template

AS03.02: Upon selection, the PIV Card Application shall return the application property template described in Table 3, Part 2 of SP 800-73-4 . TE03.02.01: The tester shall validate that the information returned upon selection of the PIV application is in conformance with Table 3, Part 2 of SP 800-73-4 .

A.3.3 Authenticator

AS03.03: The authenticator BER-TLV used on the PIV client application programming interface shall have the structure described in Table 3, Part 3 of SP 800-73-4 .

VE03.03.01: The vendor shall provide in its documentation a list of all the authenticators along with their tags and possible values, when applicable.

TE03.03.01: The tester shall review and validate the vendor’s documentation to ensure that it states the correct tags for the “Reference Data” and “Key Reference” as specified in Table 3, Part 3 of SP 800-73-4 .

A.3.4 Connection Description

AS03.04: Moved to Appendix A.4.1.1 ( AS04.02A-R4 ).

AS03.05: Withdrawn

A.3.5 Key References

AS03.06: The key reference, when represented as a byte, occupies bits b8 and b5-b1, while b7 and b6 shall be set to 0.

Note: This assertion is not separately tested.

AS03.07: The key references used on all PIV interfaces shall be from the list found in Tables 4a and 4b, Part 1 of SP 800-73-4 and SP 800-78-4 , Table 6-1.

Note: This assertion is not separately tested.

AS03.08: Withdrawn

A.3.6 WITHDRAWN - Status Words

A.3.7 OCC Data AS03.09-R4: If OCC is implemented, the export of the biometric reference data shall not be allowed.

VE03.09-R4.01: The vendor shall state in its documentation that the exportation of the biometric reference data is not allowed by the card.

TE03.09-R4.01: The tester shall review the vendor’s documentation and validate that the exportation of the biometric reference data is not allowed by the card.

A.4 Client Application Programming Interface

A.4.1 Entry Points for Communication

AS04.01: Entry points on the PIV client API shall include all functions listed in Table 1, Part 3 of SP 800-73-4 for middleware that supports secure messaging. For middleware that does not support secure messaging entry points on the PIV client API shall include all functions listed in Table 1, Part 3 of SP 800-73-4 with the exception of pivEstablishSecureMessaging.

Note: This assertion is tested as part of AS04.02 through AS04.10A-R4 .

Required Vendor Information & Required Test Procedures

To test the entry points or commands that are supported by the PIV Middleware the only information that the vendor has to provide is the PIV Middleware version. All parameter values for exercising the commands have to be obtained from the vendor documentation, using the mapping of PIV Middleware functions to the PIV Card Application card commands that are listed in Table A-1 below. Hence this section contains only tester requirements in terms of Required Test Procedures.

Table A-1: PIV Command Mapping PIV MiddlewarePIV Middleware Functions Section PIV Card Application Card Command 4 Mapping Description

pivConnect A.4.1.1 No equivalent command For establishing a connection session with the card reader. pivDisconnect A.4.1.2 No equivalent command For disconnecting a connection session with the card reader.

4 It is assumed that some of these functions will use GET RESPONSE and chaining to accomplish the read or write to the card. PIV MiddlewarePIV Middleware Functions Section PIV Card Application Card Command 4 Mapping Description

pivSelectCardApplication A.4.2.1 SELECT Passes the AID value. Sets the value for ‘Currently Selected Application’ on the PIV Card. Establishes the PIV Card Application security status. pivLogIntoCardApplication A.4.2.2 VERIFY Provides the key reference for PIV Card Application PIN, Global PIN, pairng code, or OCC as well as its corresponding value. Sets/updates the PIV Card Application security status on the card; optionally (according to discovery object) establishes VCI with pairing code after pivEstablishSecureMessaging is invoked. pivLogOutOfCardApplication A.4.2.4 VERIFY Resets the security status on all local key references. pivGetData A.4.2.3 GET DATA Maps the OID to BER-TLV tag for the selected object. pivPutData A.4.4.1 PUT DATA Maps the OID to BER-TLV tag for the selected object. pivGenerateKeyPair A.4.4.2 GENERATE ASYMMETRIC KEY PAIR Passes the key reference and cryptographic mechanism identifier value. pivCrypt A.4.3.1 GENERAL AUTHENTICATE Passes the key reference, cryptographic algorithm reference and the string to be acted upon. Sets/updates the PIV Card Application security status on the card, if applicable. pivMiddlewareVersion A4.1.3 No equivalent command Returns the PIV Middleware version supported by the PIV Middleware IUT. pivEstablishSecureMessaging A.4.2.5 GENERAL AUTHENTICATE 5 Passes the key reference and cryptographic algorithm reference to the PIV Card Application in order to establish secure messaging. Establishes, controls, and maintains the session key.

A.4.1.1 pivConnect

AS04.02: The purpose of pivConnect is to connect the PIV API to the PIV Card Application on a specific ICC.

5 In order to establish a VCI, pivLogIntoCardApplication may be required (as indicated in the Discovery Object) after successful execution of pivEstablishSecureMessaging. TE04.02.01: The tester shall validate that the PIV Middleware implements pivConnect as per SP 800-73-4 , Part 3.

AS04.02A-R4: The connection description BER-TLV used on the PIV client API shall have the structure described in Table 2, Part 3 of SP 800-73-4 .

VE04.02A-R4.01: The vendor shall provide in its documentation the format and content of the connection description templates implemented.

TE04.02A-R4.01: The tester shall review the vendor’s documentation to confirm the presence of the information provided in VE04.02A-R4.01 and that the connection description template conforms to Table 2, Part 3 of SP 800-73-4 .

A.4.1.2 pivDisconnect

AS04.03: The purpose of pivDisconnect is to disconnect the PIV API from the PIV Card Application and the ICC containing the PIV Card Application.

TE04.03.01: The tester shall validate that the PIV Middleware implements pivDisconnect as per SP 800-73-4 Part 3.

AS04.03A-R4: If secure messaging has been established then the PIV Middleware shall zeroize the secure messaging session keys when the pivDisconnect command is sent.

VE04.03A-R4.01: The vendor shall specify in its documentation that the PIV Middleware zeroizes the secure messaging session keys as a part of the implementation of pivDisconnect.

TE04.03A-R4.01: The tester shall review the vendor’s documentation and validate that it asserts that the PIV Middleware zeroizes the secure messaging session keys as part of the implementation of pivDisconnect.

A.4.1.3 pivMiddlewareVersion

AS04.03B-R4: PIV Middleware that returns a versionString of “800-73-4 Client API with SM” shall implement all PIV Middleware functions listed in Table 1 of SP 800-73-4 Part 3 and be able to recognize and process all mandatory and optional PIV data objects. PIV Middleware that returns a versionString of “800-73-4 Client API” shall implement all PIV Middleware functions listed in Table 1 except pivEstablishSecureMessaging and shall be able to recognize and process all mandatory and optional PIV data objects. The pivMiddlewareVersion’s purpose is to return the PIV Middleware version string. For SP 800- 73-4 Part 3 conformant PIV Middleware, the parameter returns “800-73-4 Client API” or “800-73-4 Client API with SM” if optional secure messaging is supported.

TE04.03B-R4.01: The tester shall validate that the PIV Middleware supports all functions listed in Table 1 of SP 800-73-4 Part 3 and implements the pivMiddlewareVersion as per SP 800-73-4 Part 3 by returning the appropriate parameter string “800-73-4 Client API” parameter string or “800-73-4 Client API with SM” if optional secure messaging is supported.

A.4.2 Entry Points for Data Access

A.4.2.1 pivSelectCardApplication

AS04.04: The purpose of pivSelectCardApplication is to set the PIV Card Application as the currently selected card application and establish the PIV Card Application’s security state.

TE04.04.01: The tester shall validate that the PIV Middleware implements pivSelectCardApplication as per SP 800-73-4 , Part 3.

AS04.04A-R4: If the length of application properties is longer than the buffer allocated by the PIV client application, then the PIV Middleware shall return PIV_INSUFFICIENT_BUFFER, but shall still set APLength to the length of the application properties.

TE04.04A-R4.01: The tester shall ensure that the PIV Middleware returns PIV_INSUFFICIENT_BUFFER if the length of application properties is longer than the buffer allocated by the client application.

A.4.2.2 pivLogIntoCardApplication

AS04.05: The purpose of pivLogIntoCardApplication is to set the security state within the PIV Card Application.

TE04.05.01: The tester shall validate that the PIV Middleware implements the pivLogIntoCardApplication as per SP 800-73-4 Part 3. AS04.05A-R4: The PIV Middleware shall not submit authenticators to the PIV Card over a contactless interface without secure messaging. If secure messaging has not been established, then the pivLogIntoCardApplication function shall return PIV_SECURITY_CONDITIONS_NOT_SATISFIED.

VE04.05A-R4: The vendor shall state in its documentation that the card supports the assertions made in AS04.05A-R4 .

TE04.05A-R4.01: The tester shall validate that that the vendor documentation contains the information required in VE04.05A-R4 .

A.4.2.3 pivGetData

AS04.06: The purpose of pivGetData is to return the entire data content of the named data object.

TE04.06.01: The tester shall validate that the PIV Middleware implements the pivGetData as per SP 800-73-4 Part 3.

AS04.06A-R4: If the length of the retrieved data is longer than the buffer allocated by the client application, then the PIV Middleware shall return PIV_INSUFFICIENT_BUFFER, but shall still set DataLength to the length of the retrieved data.

TE04.06A-R4.01: The tester shall ensure that the PIV Middleware returns PIV_INSUFFICIENT_BUFFER if the length of the retrieved data is longer than the buffer allocated by the client application

A.4.2.4 pivLogoutOfCardApplication

AS04.07: The purpose of pivLogoutOfCardApplication is to reset the application security state/status of the PIV Card Application.

TE04.07.01: The tester shall validate that the PIV Middleware implements the pivLogoutOfCardApplication as per SP 800-73-4 Part 3. A.4.2.5 pivEstablishSecureMessaging

AS04.07A-R4: The purpose of pivEstablishSecureMessaging is to e stablish secure messaging with the PIV Card Application. 6

TE04.07A-R4.01: The tester shall validate that the PIV Middleware implements the pivEstablishSecureMessaging as per SP 800-73-4 Part 3.

AS04.07B-R4: After successful execution of the key establishment protocol, the PIV Middleware shall perform all subsequent GET DATA, VERIFY, and GENERAL AUTHENTICATE commands over secure messaging, with the exception of any subsequent uses of the GENERAL AUTHENTICATE command to perform the key establishment protocol.

TE04.07B-R4.01: The tester shall validate that upon successful execution of the key establishment protocol the GET DATA, VERIFY, and GENERAL AUTHENTICATE commands are only sent to the card using secure messaging when the pivGetData, pivLogIntoCardApplication, and pivCrypt middleware functions are called.

AS04.07C-R4: The session keys established after successful execution of the key establishment protocol in Section 4.1 of SP 800-73-4 Part 2 shall be zeroized in the following circumstances: (i) the card is reset; (ii) an error occurs in secure messaging; or (iii) new session keys are requested by the client application by sending a GENERAL AUTHENTICATE command to the card to perform the key establishment protocol using the PIV Secure Messaging key.

VE04.07C-R4.01: The vendor shall state in its documentation that the card supports the assertions made in AS04.07C-R4 .

TE04.07C-R4.01: The tester shall validate that the vendor documentation contains the information required in VE04.07C-R4.01 .

A.4.3 Entry Points for Cryptographic Operations

A.4.3.1 pivCrypt

6 The PIV Middleware maintains the session keys and performs the cryptographic operations for secure messaging. AS04.08: The purpose of pivCrypt is to perform a cryptographic operation such as encryption or signing on a sequence of bytes. 7

TE04.08.01: The tester shall validate that the PIV Middleware implements the pivCrypt as per SP 800-73-4 Part 3.

AS04.08A-R4: If the value of keyReference is '04' (PIV Secure Messaging key) then the PIV Middleware shall return PIV_INVALID_KEYREF_OR_ALGORITHM .

Note: This assertion is tested as part of AS04.08 .

AS04.08B-R4: If the length of the algorithm output is longer than the buffer allocated by the client application, then the PIV Middleware shall return PIV_INSUFFICIENT_BUFFER, but shall still set outputLength to the length of the algorithm output .

TE04.08B-R4.01: The tester shall ensure that the PIV Middleware returns PIV_INSUFFICIENT_BUFFER if the length of the algorithm output is longer than the buffer allocated by the client application.

A.4.4 Entry Points for Credential Initialization and Administration

A.4.4.1 pivPutData

AS04.09: The purpose of pivPutData is to replace the entire data content of the named data object with the provided data.

TE04.09.01: The tester shall validate that the PIV Middleware implements the pivPutData as per SP 800-73-4 Part 3.

AS04.09A-R4: The PIV Middleware shall not submit data provided to the pivPutData function over the contactless interface. If the PIV Middleware is not communicating with the PIV Card via the card’s contact interface then the pivPutData function shall return PIV_FUNCTION_NOT_SUPPORTED.

7 The pivCrypt function does not perform any cryptographic operations itself. It provides the interface to the GENERAL AUTHENTICATE command to perform cryptographic operations on card. All cryptographic operations, except SM on the client side, are performed outside the PIV Middleware. VE04.09A-R4: The vendor shall state in its documentation that the card supports the assertions made in AS04.09A-R4 .

TE04.09A-R4.01: The tester shall validate that that the vendor documentation contains the information required in VE04.09A-R4 .

A.4.4.2 pivGenerateKeyPair

AS04.10: The purpose of pivGenerateKeyPair is to generate an asymmetric key pair in the currently selected card application.

TE04.10.01: The tester shall validate that the PIV Middleware implements the pivGenerateKeyPair as per SP 800-73-4 Part 3.

AS04.10A-R4: If the length of public key related data retrieved from the PIV Card is longer than the buffer allocated by the client application, then the PIV Middleware shall return PIV_INSUFFICIENT_BUFFER, but shall still set KeyLength to the length of the public key related data retrieved from the PIV Card.

TE04.10A-R4.01: The tester shall ensure that the PIV Middleware returns PIV_INSUFFICIENT_BUFFER if the length of public key related data retrieved from the PIV Card is longer than the buffer allocated by the client application.

AS04.11-R4: The PIV Middleware shall not submit data provided to the pivGenerateKeyPair function over the contactless interface. If the PIV Middleware is not communicating with the PIV Card via the card’s contact interface then the pivGenerateKeyPair function shall return PIV_FUNCTION_NOT_SUPPORTED.

VE04.11-R4.01: The vendor shall state in its documentation that the card supports the assertions made in AS04.11-R4.01 .

TE04.11-R4.01: The tester shall validate that that the vendor documentation contains the information required in VE04.11-R4.01 .

A.4.4.3 pivMiddlewareVersion The Derived Test Requirements, and their associated required test procedures, for the pivMiddlewareVersion client application command have been moved to Appendix A.4.1.3 .

A.5 PIV Card Application Card Command Interface

AS05.01: All PIV Card Application card commands listed in Table 2, Part 2 of SP 800-73-4 shall be supported by a PIV Card Application.

VE05.01.01: The vendor shall provide the list of all PIV Card Application card commands, along with the interface(s) (contact or contactless, SM, VCI) they support, the security condition(s) they are subject to and their support for command chaining as implemented by the card.

TE05.01.01: The tester shall review the vendor’s documentation and validate that the information presented in response to VE05.01.01 by the vendor complies with Table 2, Part 2 of SP 800-73-4 .

TE05.01.02: The tester shall validate that the card implements all the commands as required in Table 2, Part 2 of SP 800-73-4 .

TE05.01.03: The tester shall validate that the commands are implemented only through the interfaces allowed as shown in Table 2, Part 2 of SP 800-73-4 .

TE05.01.04: The tester shall validate that the commands are performed only if the security conditions associated with them are satisfied, as shown in the table, via the specified interface.

TE05.01.05: The tester shall validate that the commands as indicated in the table are allowed for chaining via the interface supported after the security condition is satisfied.

AS05.02: Card commands indicated with a 'Yes' in the Command Chaining column of Table 2, Part 2 of SP 800-73-4 shall support command chaining for transmitting a data string too long for a single command as defined in ISO/IEC 7816-4 [6].

Note: This assertion is tested as part of AS05.01 .

AS05.03: The PIV Card Application shall return the status word of '6A 81' (Function not supported) when it receives a card command on the contactless interface marked “No” in the Contactless Interface column in Table 2, Part 2 of SP 800-73-4 . The PIV Card Application may return a different status word (e.g., '69 82') if the card command can be performed over the contactless interface in support of card management. The PIV Card Application will only perform the command in support of card management if the requirements specified in Section 2.9.2 of FIPS 201-2 are satisfied.

Note: This assertion is tested as part of AS05.01 . AS05.04: Cryptographic protocols using private/secret keys that require the “PIN” or “OCC” security condition shall only be used on the contactless interface after a Virtual Contact Interface (VCI) has been established.

Note: This assertion is tested as part of AS05.01 .

A.5.1 PIV Card Application Card Commands for Data Access

A.5.1.1 SELECT Card Command

AS05.05: The PIV Card Application shall be selected by providing its application identifier, 'A0 00 00 03 08 00 00 10 00 10 00', in the data field of the SELECT command.

VE05.05.01: The vendor shall specify in its documentation the PIV Card Application Identifier.

TE05.05.01: The tester shall validate that the PIV Card Application is selected by providing its application identifier as specified in AS05.05 .

AS05.06: There shall be at most one PIV Card Application on any ICC.

VE05.06.01: The vendor shall state in its documentation that there is only one PIV Card Application on the ICC.

TE05.06.01: The tester shall review and validate the vendor’s documentation as stated in VE05.06.01 .

AS05.07: The PIV Card Application can also be made the currently selected application by providing a right-truncated version – that is, without the two-byte version number, '10 00' – in the data field of the SELECT command 'A0 00 00 03 08 00 00 10 00'

VE05.07.01: The vendor shall provide the list of valid AIDs that the card supports and the mechanism(s) implemented to select the PIV Card Application.

TE05.07.01: The tester shall review and validate that the information provided in VE05.07.01 . TE05.07.02: The tester shall validate that the PIV application is selectable by the right-truncated AID in the SELECT command.

AS05.08: The complete AID, including the two-byte version, of the PIV Card Application that became the currently selected application upon successful execution of the SELECT command (using the full or right-truncated PIV AID) shall be returned in the application property template.

Note: This assertion is tested as part of AS03.02 .

AS05.09: If the currently selected application is the PIV Card Application when the SELECT command is sent and the AID in the data field of the SELECT command is either the AID of the PIV Card Application or its right-truncated version thereof, then the PIV Card Application shall continue to be the currently selected card application and the setting of all security status indicators in the PIV Card Application shall be unchanged.

VE05.09.01: The vendor shall provide information in its documentation stating compliance as required by AS05.09 .

TE05.09.01: The tester shall validate that when the currently selected application is the PIV Card Application and the SELECT command is sent with an AID that is either the AID of the PIV Card Application or its right-truncated version, then the PIV Card Application continues to be the currently selected application and the setting of all security status indicators in the PIV Card Application remains unchanged.

AS05.10: If the currently selected application is the PIV Card Application when the SELECT command is sent and the AID in the data field of the SELECT command is an invalid AID not supported by the ICC then the PIV Card Application shall remain the currently selected application and all PIV Card Application security status indicators shall remain unchanged.

VE05.10.01: The vendor shall provide information in its documentation validating the compliance with the statement in AS05.10 .

TE05.10.01: The tester shall validate that when the currently selected application is the PIV Card Application and the SELECT command is sent with an AID that is not a valid AID supported by the card, then the PIV Card Application continues to be the currently selected application and the setting of all security status indicators in the PIV Card Application remains unchanged. AS05.11: If the currently selected application is the PIV Card Application when the SELECT command is given and the AID in the data field of the SELECT command is not the PIV Card Application (nor the right-truncated version thereof), but a valid AID supported by the ICC, then the PIV Card Application shall be deselected and all the PIV Card Application security status indicators in the PIV Card Application shall be set to FALSE.

VE05.11.01: The vendor shall provide information in its documentation validating the compliance with the statement in AS05.11 .

TE05.11.01: The tester shall validate that when the currently selected application is the PIV Card Application and the SELECT command is sent with a valid AID supported by the ICC that is different from the PIV Card Application AID (or its right-truncated version), then PIV Card Application is deselected and its security status indicators are set to FALSE.

AS05.11A-R4: A PIV Card Application may use a subset of the cryptographic algorithms defined in SP 800-78-4 . Tag 0xAC encodes the cryptographic algorithms supported by the PIV Card Application. The encoding of tag 0xAC shall be as specified in Table 5, Part 2 of SP 800- 73-4 . Each instance of tag 0x80 shall encapsulate one algorithm. The presence of algorithm identifier '27' or '2E' indicates that the corresponding cipher suite is supported by the PIV Card Application for secure messaging and that the PIV Card Application possesses a PIV Secure Messaging key of the appropriate size for the specified cipher suite. Tag 0xAC shall be present and indicate algorithm identifier 0x27 or 0x2E (but not both) when the PIV Card Application supports secure Messaging.

Note : This assertion is tested as part of AS05.34 .

A.5.1.2 GET DATA Card Command

AS05.12: The GET DATA card command retrieves the data content of the single data object whose tag is given in the data field.

Note: This assertion is tested as part of AS05.01 .

AS05.12A: The GET DATA card command retrieves the data content of the data object only after the access rule associated with the data object (Appendix A, Table 7, Part 1 of SP 800-73- 4 ) evaluates to TRUE.

VE05.12A.01: The vendor shall specify in its documentation the access rule for each of the data objects or make a reference to Table 7 in Appendix A, Part 1 of SP 800-73-4 . TE05.12A.01: For implementations without the Discovery Object or implementations with the Discovery Object implemented and Bit 6 of the first byte of the PIN Usage Policy set to zero, the tester shall validate that all data objects that require a PIN are only accessible after a successful validation of the PIV Card Application PIN through the VERIFY command.

TE05.12A.02: For implementations with the Discovery Object implemented and Bit 6 of the first byte of the PIN Usage Policy set to one: 1) the tester shall validate that all data objects are accessible after a successful VERIFY with the PIV Card Application PIN; and 2) the tester shall validate that all data objects that require a PIN are accessible after a successful VERIFY with the Global PIN.

TE05.12A.02A-R4: For implementations with the Discovery Object implemented and Bit 5 of the first byte of the PIN Usage Policy set to one, the tester shall validate that the appropriate data objects are accessible after a successful VERIFY with OCC.

TE05.12A.03: The tester shall validate that all data objects whose access rule is “Always” are accessible with or without PIV Card Application PIN validation, Global PIN validation (if implemented as indicated in the Discovery Object), or OCC validation (if implemented as indicated in the Discovery Object) using the permitted interface.

A.5.2 PIV Card Application Card Commands for Authentication

A.5.2.1 VERIFY Card Command

AS05.13: PIV Card Applications for which both the PIV Card Application PIN and the Global PIN satisfy the PIV ACRs for PIV data object access and command execution shall implement the Discovery Object with the PIN Usage Policy set to 0x60 zz, 0x6C zz, 0x70 zz, or 0x7C zz, where zz is either 0x10 or 0x20, and may optionally implement the Discovery Object with the PIN Usage Policy set to 0x68 zz or 0x78 zz, where zz is either 0x10 or 0x20.

VE05.13.01: The vendor shall confirm that the PIV Card Application PIN can be used for PIV data object access and command execution. If the Global PIN (in addition to the PIV Card Application PIN) is used for data access and command execution while the PIV Card Application is the currently selected application, the vendor shall state in its documentation that the card supports the assertion made in AS05.13 .

TE05.13.01: The tester shall validate that the PIV Card Application PIN can be used for PIV data object access and command execution. The tester shall validate that when the Global PIN satisfies the PIV ACRs for PIV data object access and command execution then: 1) the Discovery Object is implemented with the PIN Usage Policy set to 0x60 zz, 0x68 zz, 0x6C zz, 0x70 zz, 0x78 zz, or 0x7C zz, where zz is set to either 0x10 or 0x20; and 2) the Global PIN can be used for PIV data object access and command execution.

AS05.13A-R4: PIV Card Applications for which OCC satisfies the PIV ACRs for PIV data object access and command execution shall implement the Discovery Object with the first byte of the PIN Usage Policy set to 0x50, 0x58, 0x5C, 0x70, 0x78, or 0x7C.

VE05.13A-R4.01: If OCC (in addition to the PIV Card Application PIN, and possibly the Global PIN) is used for data access and command execution while the PIV Card Application is the currently selected application, the vendor shall state in its documentation that the card supports the assertion made in AS05.13A-R4 .

TE05.13A-R4.01: The tester shall validate that when OCC satisfies the PIV ACRs for PIV data object access and command execution then: 1) the Discovery Object is implemented with the first byte of the PIN Usage Policy set to 0x50, 0x58, 0x5C, 0x70, 0x78, or 0x7C; and 2) OCC can be used for PIV data object access and command execution.

AS05.13B-R4: PIV Card Applications that implement the VCI shall implement the Discovery Object with the first byte of the PIN Usage Policy set to 0x4C, 0x5C, 0x6C, or 0x7C, and may optionally also implement the Discovery Object with the first byte of the PIN Usage Policy set to 0x48, 0x58, 0x68, or 0x78.

VE05.13B-R4.01: If the PIV Card Application implements the VCI, the vendor shall state in its documentation that the card supports the assertion made in AS05.13B-R4 .

TE05.13B-R4.01: The tester shall validate that PIV Card Applications that implement the VCI implement the Discovery Object with the first byte of the PIN Usage Policy set to 0x4C, 0x5C, 0x6C, or 0x7C (see Table 1 of SP 800-73-4 Part 1).

AS05.14: Key reference '80' specific to the PIV Card Application (i.e., local key references) and, optionally, the Global PIN with key reference '00', the OCC data (key references '96' and '97'), and pairing code (key reference '98') are the only key references that may be verified by the PIV Card Application’s VERIFY command. The PIV Card Application may allow other key references to be verified by the PIV Card Application’s VERIFY command, if they are used for card management operations. VE05.14.01: The vendor shall state in its documentation that the card supports the assertion made in AS05.14 .

TE05.14.01: The tester shall review the vendor’s documentation and validate that it contains the information required in VE05.14.01 .

AS05.15: Key reference '80' shall be able to be verified by the PIV Card Application VERIFY command.

Note: This assertion is tested as part of AS05.13 .

AS05.16: If the PIV Card Application contains the Discovery Object as described in Part 1 of SP 800-73-4 and Bit 6 of the first byte of the PIN Usage Policy value is one, then key reference '00' shall be able to be verified by the PIV Card Application VERIFY command.

VE05.16.01: The vendor shall specify in its documentation if the Global PIN is implemented with the VERIFY command to satisfy access control rules to read PIN protected PIV data objects. If implemented, the vendor shall also specify the Discovery Object to be present on card with Bit 6 of the first byte of the PIN Usage Policy value set to one.

TE05.16.01: The tester shall validate that if the PIV Card Application contains the Discovery Object and Bit 6 of the first byte of the PIN Usage Policy value is one, then key reference '00' is able to be verified by the PIV Card Application VERIFY command.

AS05.16A-R4: If the key reference is '98' and the authentication data in the command data field does not match the reference data associated with the key reference, the command shall fail and the PIV Card Application shall return the status word '63 00'. If the authentication data in the command data field does not satisfy the criteria in Section 2.4.3 of Part 2 of SP 800- 73-4 , then the PIV Card Application may return the status word '6A 80' instead of '63 00'. If status word '6A 80' is returned, the security status of the key reference shall remain unchanged. If status word '63 00' is returned, the security status of the key reference shall be set to FALSE.

TE05.16A-R4.01: The tester shall validate that the card implements AS05.16A-R4 as specified. AS05.17: If the key reference is '00', '80', '96', or '97' and the current value of the retry counter associated with the key reference is zero, then the comparison shall not be made and the PIV Card Application shall return the status word '69 83'. In order to protect against blocking over the contactless interface, PIV Card Applications that implement secure messaging shall define an issuer-specified intermediate retry value for each of these key references and return '69 83' if the command is submitted over the contactless interface (over secure messaging or the VCI, as required for the key reference) and the current value of the retry counter associated with the key reference is at or below the issuer-specified intermediate retry value. If status word '69 83' is returned, then the comparison shall not be made, and the security status and the retry counter of the key reference shall remain unchanged.

VE05.17.01: The vendor shall specify in its documentation the reset value of the retry counters associated with all the key references implemented on the card.

TE05.17.01: The tester shall validate that the PIV Card Application returns '69 83' in response to the VERIFY command when the retry counter associated with the key reference is zero.

AS05.18: The card command shall fail if the key reference is '00' or '80' and the VERIFY command is not submitted over either the contact interface or the VCI or if the key reference is '96', '97', or '98' and the VERIFY command is submitted over the contactless interface without secure messaging. In either case, the security status and the retry counter of the key reference shall remain unchanged.

VE05.18.01: The vendor shall specify in its documentation the conditions (and associated status word) when the command will fail.

TE05.18.01: The tester shall validate that if the key reference is '00' or '80' and the VERIFY command is not submitted over either the contact interface or the VCI, or if the key reference is '96', '97', or '98' and the VERIFY command is submitted over the contactless interface without secure messaging, then the card command fails and the security status and the retry counter of the key reference remain unchanged.

AS05.18A-R4: If the key reference is '96' or '97' and the authentication data in the command data field is not of length 3N, where N satisfies the requirements for minimum and maximum number of minutiae specified in the BIT, then the card command shall fail, and the PIV Card Application shall return the status word '6A 80'. The security status and the retry counter of the key reference shall remain unchanged. VE05.18A-R4.01: The vendor shall specify in its documentation that if the key reference is '96' or '97' and the authentication data in the command data field is not of length 3N, where N satisfies the requirements for minimum and maximum number of minutiae specified in the BIT, then the card command fails, the PIV Card Application returns the status word '6A 80', and the security status and the retry counter of the key reference remain unchanged.

TE05.18A-R4.01: The tester shall validate that the card implements AS05.18A-R4 as specified.

AS05.19: If the key reference is '00', '80', '96', or '97' and the authentication data in the command data field is properly formatted and does not match reference data associated with the key reference, then the card command shall fail, the PIV Card Application shall return the status word '63 CX', the security status of the key reference shall be set to FALSE, and the retry counter associated with the key reference shall be decremented by one.

VE05.19.01: The vendor shall state in its documentation that the card supports the assertion made in AS05.19 .

TE05.19.01: The tester shall validate that when the VERIFY command fails the retry counter associated with the key reference is decremented by one.

AS05.20: If the card command succeeds then the security status of the key reference shall be set to TRUE. If the key reference is '00', '80', '96', or '97' then the retry counter associated with the key reference shall be set to the reset retry value associated with the key reference.

Note: This vendor information is reviewed as part of VE05.17.01 .

Note: This assertion is tested as part of AS05.17 .

AS05.21: Moved requirement into AS05.19 .

AS05.22A: If the PIN value in the reference data field of the command field is not padded to 8 bytes, the PIV Card Application shall return the status word '6A 80'. VE05.22A.01: The vendor shall state in its documentation that the card supports the assertion made in AS05.22A .

TE05.22A.01: The tester shall review the vendor’s documentation and validate that it contains the information required in VE05.22A.01 and the card returns status word '6A 80' when the PIN information in the reference data field of the command is not padded to 8 bytes.

AS05.22B: If the key reference is set to a value other than what is supported by the card, the PIV Card Application shall return the status word '6A 88' (key reference not found).

VE05.22B.01: The vendor shall state in its documentation that the card supports the assertion made in AS05.22B .

TE05.22B.01: The tester shall review the vendor’s documentation and validate that it contains the information required in VE05.22B.01 .

AS05.22C-R4: The VERIFY command shall reset the security status of the key reference in P2 when the P1 parameter is 'FF' and both L c and the data field are absent. The security status of the key reference specified in P2 shall be set to FALSE and the retry counter associated with the key reference shall remain unchanged.

VE05.22C-R4.01: The vendor shall state in its documentation that the card supports the assertion made in AS05.22C-R4 .

TE05.22C-R4.01: The tester shall validate that when using the VERIFY command the security status of the key reference in P2 is reset when the P1 parameter is 'FF' and both L c and the data field are absent. The tester shall also validate that in this scenario the retry counter remains unchanged.

AS05.22D-R4: If the key reference is '00' or '80' and the authentication data in the command data field does not satisfy the criteria in Section 2.4.3 of Part 2 of SP 800-73-4 , then the card command shall fail and the PIV Card Application shall return either the status word '6A 80' or '63 CX'. If status word '6A 80' is returned, the security status and the retry counter of the key reference shall remain unchanged. If status word '63 CX' is returned, the security status of the key reference shall be set to FALSE and the retry counter associated with the key reference shall be decremented by one. VE05.22D-R4.01: The vendor shall state in its documentation that the card supports the assertions made in AS05.22D-R4

TE05.22D-R4.01: The tester shall validate that: 1) the vendor documentation contains the information required in VE05.22D-R4.01 ; and 2) the card returns status word '6A 80' or '63 CX' based on the conditions mentioned in AS05.22D-R4 .

A.5.2.2 CHANGE REFERENCE DATA Card Command

AS05.23: Only reference data associated with key references '80' and '81' specific to the PIV Card Application (i.e., local key reference) and the Global PIN with key reference '00' may be changed by the PIV Card Application CHANGE REFERENCE DATA command. Key reference '80' reference data shall be changed by the PIV Card Application CHANGE REFERENCE DATA command. The ability to change reference data associated with key references '81' and '00' using the PIV Card Application CHANGE REFERENCE DATA command is optional. The PIV Card Application may allow the reference data associated with other key references to be changed by the PIV Card Application CHANGE REFERENCE DATA, if PIV Card Application will only perform the command with other key references if the requirements specified in Section 2.9.2 of FIPS 201-2 are satisfied.

VE05.23.01: The vendor shall state in its documentation that the card supports the assertion made in AS05.23 .

TE05.23.01: The tester shall validate that reference data associated with key reference '80' can be changed by the PIV Card Application’s CHANGE REFERENCE DATA command. If the Discovery Object is implemented with Bit 6 of the first byte of the PIN Usage Policy set to one and the implementation supports changing the Global PIN with the CHANGE REFERENCE DATA command, then the tester shall also validate that key reference '00' reference data can be changed by the CHANGE REFERENCE DATA command. If the PUK can be changed with CHANGE REFERENCE DATA, the tester shall validate that reference data associated with key reference '81' can be changed by the PIV Card Application CHANGE REFERENCE DATA command.

AS05.24: WITHDRAWN

AS05.24A-R4: If key reference '81' is specified and the command is submitted over the contactless interface (including SM or VCI), then the card command shall fail. If key reference '00' or '80' is specified and the command is not submitted over either the contact interface or the VCI, then the card command shall fail. In each case, the security status and the retry counter of the key reference shall remain unchanged.

VE05.24A-R4.01: The vendor shall state in its documentation that the card supports the assertion made in AS05.24A-R4 .

TE05.24A-R4.01: The tester shall validate that if the CHANGE REFERENCE DATA command is submitted over the contactless interface (including SM or VCI) with key reference '81', the PIV Card Application fails. The tester shall validate that if the CHANGE REFERENCE DATA command, with key reference '00' or '80', is submitted over the contactless interface, but not the VCI, then the card command fails. In both cases, the tester shall validate that the security status and the retry counter of the key reference remain unchanged.

AS05.25: If the current value of the retry counter associated with the key reference is zero, then the reference data associated with the key reference shall not be changed and the PIV Card Application shall return the status word '69 83' (Reference data change operation blocked). If the command is submitted over the contactless interface (VCI) and the current value of the retry counter associated with the key reference is at or below the issuer-specified intermediate retry value (see Section 3.2.1 of Part 2 of SP 800-73-4 ), then the reference data associated with the key reference shall not be changed and the PIV Card Application shall return the status word '69 83'.

VE05.25.01: The vendor shall state in its documentation that the card supports the assertion made in AS05.25 .

TE05.25.01: The tester shall validate that when the current value of the retry counter associated with the key reference is zero, the reference data associated with the key reference does not change and the PIV Card Application returns '69 83' (Reference data change operation blocked). The tester shall validate that when the CHANGE REFERENCE DATA command is submitted over the VCI and the current value of the retry counter associated with the key reference is at or below the issuer- specified intermediate retry value, the reference data associated with the key reference does not change and the PIV Card Application returns '69 83'.

AS05.25A-R4: If the authentication data in the command data field does not match the current value of the reference data or if either the authentication data or the new reference data in the command data field of the command does not satisfy the criteria in Section 2.4.3 of Part 2 of SP 800-73-4 , the PIV Card Application shall not change the reference data associated with the key reference and shall return either status word '6A 80' or '63 CX', with the following restrictions: (a) If the authentication data in the command data field satisfies the criteria in Section 2.4.3 of Part 2 of SP 800-73-4 and matches the current value of the reference data, but the new reference data in the command data field of the command does not satisfy the criteria in Section 2.4.3 of Part 2 of SP 800-73-4 the PIV Card Application shall return status word '6A 80'.

(b) If the authentication data in the command data field does not match the current value of the reference data, but both the authentication data and the new reference data in the command data field of the command satisfy the criteria in Section 2.4.3 of Part 2 of SP 800-73-4 , the PIV Card Application shall return status word '63 CX'.

(c) If status word '6A 80' is returned, the security status and retry counter associated with the key reference shall remain unchanged.

VE05.25A-R4.01: The vendor shall state in its documentation that the card supports the assertions made in AS05.25A-R4 .

TE05.25A-R4.01: The tester shall validate that: 1) the vendor documentation contains the information required in VE05.25A-R4.01 ; and 2) the card returns status word '6A 80' or '63 CX' based on the conditions mentioned in AS05.25A-R4 .

AS05.26: If the card command succeeds, then the security status of the key reference shall be set to TRUE and the retry counter associated with the key reference shall be set to the reset retry value associated with the key reference.

VE05.26.01: The vendor shall state in its documentation that the card supports the assertion made in AS05.26 .

TE05.26.01: The tester shall validate that the vendor documentation states the required information in VE05.26.01 and the retry counter associated with the key reference is set to the reset retry value associated with the key reference when the command succeeds.

AS05.27: If status word '63 CX' is returned, the security status of the key reference shall be set to FALSE and the retry counter associated with the key reference shall be decremented by one. VE05.27.01: The vendor shall state in its documentation that the card supports the assertion made in AS05.27 .

TE05.27.01: The tester shall validate that the vendor’s documentation contains the information required in VE05.27.01 and the retry counter associated with the key reference is decremented by one if the card command fails.

AS05.28: Moved to AS05.25A-R4 .

AS05.28A: If the key reference is set to a value other than what is supported by the card, the PIV Card Application shall return the status word '6A 88'.

VE05.28A.01: The vendor shall state in its documentation that the card supports the assertion made in AS05.28A .

TE05.28A.01: The tester shall validate that the vendor’s documentation contains the information required in VE05.28A.01 .

A.5.2.3 RESET RETRY COUNTER Card Command

AS05.29: The only key reference allowed in the P2 parameter of the RESET RETRY COUNTER command is the PIV Card Application PIN. The PIV Card Application may allow the reference data associated with other key references to be changed by the PIV Card Application RESET RETRY COUNTER, if PIV Card Application will only perform the command with other key references if the requirements specified in Section 2.9.2 of FIPS 201-2 are satisfied. If a key reference is specified in P2 that is not supported by the card, the PIV Card Application shall return the status word '6A 88'.

VE05.29.01: The vendor shall state in its documentation that the card supports the assertion made in AS05.29 .

TE05.29.01: The tester shall review the vendor’s documentation and validate that includes the information required in VE05.29.01 . AS05.30: If the current value of the PUK’s retry counter is zero then the PIN’s retry counter shall not be reset and the PIV Card Application shall return the status word '69 83'.

VE05.30.01: This information is requested as part of VE05.17.01 .

VE05.30.02: The vendor shall specify in its documentation that the RESET RETRY COUNTER card command will not reset the PIN’s retry counter and the card will return '69 83' (Reset operation blocked) when the PUK’s retry counter is zero.

TE05.30.01: The tester shall review the vendor’s documentation and validate that the information requested in VE05.30.02 and VE05.30.01 are present. (NOTE: Testing this condition will leave the card unusable for further tests of the RESET RETRY COUNTER command since the reset counter is zero).

AS05.31: If the card command succeeds, then the PIN’s retry counter shall be set to its reset retry value. Optionally, the PUK’s retry counter may be set to its initial reset retry value. The security status of the PIN’s key reference shall not be changed.

VE05.31.01: This information is requested as part of VE05.17.01 .

VE05.31.02: The vendor shall specify in its documentation that the card supports the assertion made in AS05.31 .

TE05.31.01: The tester shall validate that when the card command succeeds, the PIN’s retry counter is set to the PIN’s reset retry value specified in VE05.31.01 , and the security status of the PIN’s key reference is not changed. If the PUK’s retry counter can be reset, the tester shall validate that the PUK’s retry counter was reset to its initial reset retry value.

AS05.32: If the PIV Card Application returns status word '63 CX' then the retry counter associated with the PIN shall not be reset, the security status of the PIN’s key reference shall be set to FALSE, and the PUK’s retry counter shall be decremented by one.

VE05.32.01: The vendor shall state in its documentation that card supports the assertion made in AS05.32 . TE05.32.01: The tester shall validate that if the PIV Card Application returns '63 CX', then the retry counter associated with the PIN is not reset, the security status of the PIN’s key reference is set to FALSE, and the PUK’s retry counter is decremented by one.

AS05.33: If the reset retry counter authentication data (PUK) in the command data field of the command does not match reference data associated with the PUK, then the PIV Card Application shall return the status word '63 CX'. If the new reference data (PIN) in the command data field of the command does not satisfy the criteria in Section 2.4.3 of Part 2 of SP 800-73-4 , then the PIV Card Application shall return the status word '6A 80'. If the reset retry counter authentication data (PUK) in the command data field of the command does not match reference data associated with the PUK and the new reference data (PIN) in the command data field of the command does not satisfy the criteria in Section 2.4.3 of Part 2 of SP 800-73-4 , then the PIV Card Application shall return either status word '6A 80' or '63 CX'. If the PIV Card Application returns status word '6A 80', then the retry counter associated with the PIN shall not be reset, the security status of the PIN’s key reference shall remain unchanged, and the PUK’s retry counter shall remain unchanged.

VE05.33.01: The vendor shall state in its documentation that the card supports the assertion made in AS05.33 .

TE05.33.01: The tester shall review and validate that the vendor’s documentation includes the information required in VE05.33.01 and the tester shall also validate that card inplements the RESET RETRY COUNTER card command in a manner consistent with AS05.33 by ensuring the following conditions:

(a) If the new reference data (PIN) in the command data field of the command satisfies the criteria in Section 2.4.3 of Part 2 of SP 800-73-4 , but the reset retry counter authentication data (PUK) in the command data field of the command does not match reference data associated with the PUK, then the PIV Card Application returns the status word '63 CX'. (b) If the reset retry counter authentication data (PUK) in the command data field of the command matches reference data associated with the PUK, but the new reference data (PIN) in the command data field of the command does not satisfy the criteria in Section 2.4.3 of Part 2 of SP 800-73-4 , then the PIV Card Application returns the status word '6A 80'. (c) If the reset retry counter authentication data (PUK) in the command data field of the command does not match reference data associated with the PUK and the new reference data (PIN) in the command data field of the command does not satisfy the criteria in Section 2.4.3 of Part 2 of SP 800-73-4 , then the PIV Card Application returns either status word '6A 80' or '63 CX'. (d) If the PIV Card Application returns status word '6A 80', then the retry counter associated with the PIN is not reset, the security status of the PIN’s key reference remains unchanged, and the PUK’s retry counter remains unchanged.

AS05.33A: Moved requirement into AS05.29 .

A.5.2.4 GENERAL AUTHENTICATE Card Command

AS05.34: The GENERAL AUTHENTICATE card command performs a cryptographic operation, such as an authentication protocol, using the data provided in the data field of the command and returns the result of the cryptographic operation in the response data field. 1) The GENERAL AUTHENTICATE command shall be used with the PIV authentication keys ('9A', '9B', '9E') to authenticate the card or a card application to the client application (INTERNAL AUTHENTICATE), to authenticate an entity to the card (EXTERNAL AUTHENTICATE), and to perform a mutual authentication between the card and an entity external to the card (MUTUAL AUTHENTICATE). 2) The GENERAL AUTHENTICATE command shall be used with the digital signature key ('9C') to realize the signing functionality on the PIV client application programming interface. Data to be signed is expected to be hashed off card. 3) The GENERAL AUTHENTICATE command shall be used with the key management key ('9D') and the retired key management keys ('82' – '95') to realize key establishment primitives specified in SP 800-78-4 (ECDH and RSA). 4) The GENERAL AUTHENTICATE command shall be used with the PIV Secure Messaging key ('04') and cryptographic algorithm identifier '27' or '2E' to establish session keys for secure messaging as specified in Section 4 of SP 800-73-4 , Part 2. If key reference '04' is specified in P2 then algorithm identifiers in P1 other than '27' and '2E' shall not be permitted and the PIV Card Application shall return the status word '6A 86'.

VE05.34.01: The vendor shall specify in its documentation the types of cryptographic operations (authentication, key establishment primitives, signing primitives, and secure messaging) supported by the card.

TE05.34.01: The tester shall validate that the GENERAL AUTHENTICATE command is implemented to authenticate the card to the client application (Pertains to AS05.34 -(1)).

TE05.34.02: The tester shall validate that the GENERAL AUTHENTICATE command is implemented to authenticate the client application to the card (Pertains to AS05.34 -(1)). TE05.34.03: The tester shall validate that the GENERAL AUTHENTICATE command is implemented to mutually authenticate the card to the client application and the client application to the card (Pertains to AS05.34 -(1)).

TE05.34.04: The tester shall validate that the GENERAL AUTHENTICATE command is implemented to realize signing functionality (Pertains to AS05.34 -(2)).

TE05.34.05: The tester shall validate that the GENERAL AUTHENTICATE command is implemented to support the RSA key transport or Elliptic Curve Diffie-Hellman key agreement primitives specified in SP 800-78-4 (Pertains to AS05.34 -(3)).

TE05.34.06: If the '04' key is implemented, the tester shall validate that the GENERAL AUTHENTICATE command is implemented to support only cryptographic algorithm identifiers '27' and/or '2E' to establish session keys for secure messaging. The tester shall validate that if key reference '04' is specified in P2 and an algorithm identifier other than '27' or '2E' is specified in P1 then the card returns the status word '6A 86' (Pertains to AS05.34 -(4)).

AS05.35: The GENERAL AUTHENTICATE command shall be implemented to realize the signing functionality on the PIV client application programming interface.

Note: This assertion is tested as part of AS05.34 .

AS05.36: If an invalid value of algorithm reference (P1) and/or key reference (P2) is sent to the card, the PIV Card Application shall return the status word '6A 86'.

VE05.36.01: The vendor shall state in its documentation that the card supports the assertion made in AS05.36 .

TE05.36.01: The tester shall review the vendor’s documentation and validate that it contains the information required in VE05.36.01 and the card returns status word '6A 86' when an invalid value of algorithm reference (P1) or key reference (P2) is sent to the card.

AS05.36A: If an invalid value is sent in the data field, the PIV Card Application shall return the status word '6A 80'.

VE05.36A.01: The vendor shall state in its documentation that the card supports the assertion made in AS05.36A . TE05.36A.01: The tester shall review the vendor’s documentation and validate that it contains the information required in VE05.36A.01 and the card returns status word '6A 80' when an invalid value in data field of the command is sent to the card.

AS05.36B: If the command is used to authenticate the card to the client application using a PIN-protected PIV key without prior PIN or OCC verification the PIV Card Application shall return the status word '69 82'.

VE05.36B.01: The vendor shall state in its documentation that the card supports the assertion made in AS05.36B .

TE05.36B.01: The tester shall review the vendor’s documentation and validate that it contains the information required in VE05.36B.01 and the card returns status word '69 82' whenever the command is used to authenticate the card to the client application using a PIN-protected key without prior PIN verification.

AS05.36C: If a card command other than the GENERAL AUTHENTICATE command is received by the PIV Card Application before the termination of a GENERAL AUTHENTICATE chain, the PIV Card Application shall rollback to the state it was in immediately prior to the reception of the first command in the interrupted chain.

VE05.36C.01: The vendor shall specify in its documentation that the card supports the assertion made in AS05.36C .

TE05.36C.01: The tester shall review the vendor’s documentation and validate that it states that the PIV Card Application reverts back to the state it was in if a command other than GENERAL AUTHENTICATE is received before the termination of a GENERAL AUTHENTICATE chain.

A.5.3 PIV Card Application Card Commands for Credential Initialization and Administration A.5.3.1 PUT DATA Card Command

AS05.37: The PUT DATA card command completely replaces the data content of a single data object in the PIV Card Application with new content. VE05.37.01: The vendor shall specify in its documentation the format, encoding, and the parameters of the PUT DATA command supported by the card.

TE05.37.01: The tester shall validate that the card complies with the PUT DATA command as defined in SP 800-73-4 , Part 2.

A.5.3.2 GENERATE ASYMMETRIC KEY PAIR Card Command

AS05.38: The GENERATE ASYMMETRIC KEY PAIR card command initiates the generation and storing in the card of the reference data of an asymmetric key pair, i.e., a public key and a private key.

VE05.38.01: The vendor shall specify in its documentation the cryptographic mechanism identifiers (specified in Table 5, Part 1 of SP 800-73-4 ) that have been implemented on the card.

TE05.38.01: The tester shall validate that the card implements the algorithms associated with identifiers specified as part of VE05.38.01 requirement and that the public key returned is formatted based on data object tags specified in Table 11, Part 2 of SP 800-73-4 .

AS05.39: The public key of the generated key pair is returned as the response to the command.

Note: This assertion is tested as part of AS05.38 .

AS05.40: If there is reference data currently associated with the key reference, it is replaced in full by the generated data.

TE05.40.01: The tester shall validate that the initial key pair is replaced in full by the generated data, by issuing a GENERAL AUTHENTICATE command following a GENERATE ASYMMETRIC KEY PAIR command and verifying the cryptographic results using the public key returned by the GENERATE ASYMMETRIC KEY PAIR command.

A.5.4 Secure Messaging (SM)

AS05.41-R4: When secure messaging is established, the PIV Card Application shall authenticate to the relying system and a set of symmetric session keys will be established. VE05.41-R4.01: The vendor shall specify in its documentation whether the card implements secure messaging.

Note: This assertion is tested as a part of establishing the VCI interface.

AS05.42-R4: When implemented, SM for non-card-management operations shall only be established using the PIV Secure Messaging key specified in Table 4b of SP 800-73-4 , Part 1, and the SM protocol in accordance with the specifications in SP 800-73-4 Section 4 of Part 2.

VE05.42-R4.01: The vendor shall specify in its documentation that secure messaging is implemented in accordance with AS05.42-R4 .

TE05.42-R4.01: The tester shall review the vendor’s documentation and validate that the SM for non-card-management operations shall only be established using the PIV Secure Messaging key.

AS05.43-R4: The SW protocol is the status byte of the overall secure messaging command and response processing. It indicates if the secure messaging was performed successfully. If the processing was successful, it shall be '90 00'; otherwise, it shall be as follows: '68 82' if secure messaging is not supported; '69 82' if the security status is not satisfied; '69 87' if the expected secure messaging data objects are missing; and '69 88' if the secure messaging data objects are incorrect. If the command processing was unsuccessful, the card shall return one of the above errors without performing further secure messaging.

VE05.43-R4.01: The vendor shall specify in its documentation that the card conforms to the assertion stated in AS05.43-R4 .

TE05.43-R4.01: The tester shall review the vendor’s documentation and validate that the PIV Card returns the applicable SW identified in AS05.43-R4 without performing further secure messaging if the command processing was unsuccessful.

AS05.44-R4: If the PIV Card supports secure messaging, the PIV Secure Messaging key shall be generated on the PIV Card and the PIV Card shall not permit exportation of the PIV Secure Messaging Key. VE05.44-R4.01: The vendor shall specify in its documentation that the card conforms to the assertion stated in AS05.44-R4 .

TE05.44-R4.01: The tester shall review the vendor’s documentation and validate that the PIV Secure Messaging key is generated on the PIV Card and the PIV Card does not permit exportation of the PIV Secure Messaging Key.

AS05.45-R4: The cryptographic operations that use the PIV Secure Messaging key shall be available through the contact and contactless interfaces of the PIV Card.

Note: This assertion is not separately tested since it is tested as a part of initiating the SM and VCI interfaces. PIV Client API Test Assertions

All tests in Appendices B.1 to B.10 are performed over the contact interface only except where stated otherwise. These tests apply to both PIV Middleware versions (with and without SM/VCI). Tests in Appendix B.11 are performed for PIV Middleware version “800-73-4 Client API with SM” only, using a contactless reader interface.

Test Assertion Template Purpose A quick description of the test and why it is being run. The PIV client API function call being tested. Reference(s) References to SP 800-73-4 or other relevant publications. Precondition(s) Anything that must be done or known prior to executing the scenario. Sequence of steps for making a function call. Expected Result(s) What the expected execution path yields in terms of data (if applicable) and response status codes. Postcondition(s) A description of the PIV Middleware’s client application and card application state once the test scenario completes.

B.1 pivConnect

B.1.1 Valid Path Test Assertions

B.1.1.1 Initiate Exclusive Connection Purpose Confirm that an exclusive connection can be obtained by a calling application to the PIV Card reader. pivConnect Reference(s) 1. SP 800-73-4 Part 3, Section 3.1.2 2. AS04.01 , AS04.02 , AS04.02A-R4 Precondition(s) 1. A valid connection description is provided for the card reader. 2. There exists a valid physical connection between an instance of the PIV Card and the client application. 3. No application is currently connected to the PIV Card Application.

8.1 Failure Review

Title

Control changed

Before · SP 800-85A-2

After · SP 800-85A-4

`8.1` Failure Review