BaselineWatch
Desk
Your fleet and your work Fleetyour releases and the hardware they run onTriagewhat needs a decisionWatchlistthe products and platforms you runSaved searchesthe lists you come back to
This instance Sourceswhat is read, how often, under what termsDigestthe daily or weekly summary, and alerts
How it is drawn Appearancethe look and the colour schemeBrandingthe mark this instance wears
Owner sign-in

6 Test and Compliance Documentation

NIST PIV and digital identity SP 800-85A-4 against SP 800-85A-2
All changes in this version
modified 6 Test and Compliance Documentation

Title

Test and Compliance Documentation

Control changed

Before · SP 800-85A-2

There are two sets of compliance documentation: vendor required and test facility generated. The vendor-required documents consist of the following: Installation and Execution instructions (for PIV Middleware): The vendor provides technical instructions and other documentation to aid the testing personnel in installing and using the PIV Middleware implementation under test. The PIV Middleware implementation could be in any higher-level programming language. Since all the implementations have to be tested from a common test program, the PIV Middleware vendor submitting the product for testing may have to provide wrapper programs in some cases to the test facility. The purpose of the wrapper program is to translate the test execution calls made using the test program to the PIV Middleware implementation’s native program calls.

Technical documentation (for both PIV Card Application and PIV Middleware): The vendor-supplied technical documentation must include the detailed technical description and the design of the implementation to be tested. This document includes, at a minimum, all the required vendor information specified in DTRs in Appendix A of this document.

Security-related information: Security-related information such as the PIV Card Application PIN, the PIN unblocking PIN, the number of unsuccessful attempts the PIV Card Application will allow using the wrong Card Application and PIN unblocking PINs, the optional cryptographic algorithms supported by the PIV Card Application, etc. should be provided by the vendor.

The test facility-generated documents are required for performing and reporting the test process. The following are some of the examples:

Checklists. Checklists provide the tester with a list of actions and requirements to complete before the test starts. Information required in the preconditions section of the assertions is included in the checklists.

Test logs. A test log is kept for each test run on any component and is used to summarize the results of all the tests run.

Test reports. These provide the background (environmental information) for each of the test cases as well as summary of outcomes from test runs (from test logs) associated with each test case.

A test case is a sequence of command/function invocations that pertain to a given execution condition for the ‘command/function under test’. For example, if the GET DATA command is the command/function under test, then the execution condition ‘Invocation of this function after PIN verification’ will consist of the following sequence of command/function invocations – SELECT, VERIFY, GET DATA, and collectively constitutes a test case. There may be many test runs for this test case. The function invocations returning the expected return codes for a test case in all test runs indicates that the command/function has been implemented correctly.

After · SP 800-85A-4

There are two sets of compliance documentation: vendor required and test facility generated. The vendor-required documents consist of the following: + Installation and Execution instructions (for PIV Middleware): The vendor provides technical instructions and other documentation to aid the testing personnel in installing and using the PIV Middleware implementation under test. The PIV Middleware implementation could be in any higher-levelhigh-level programming language. Since all the implementations have to be tested from a common test program, the PIV Middleware vendor submitting the product for testing may have to provide Java wrapper programs in some cases to the test facility. The purpose of the wrapper program is to translate the test execution calls made using the test program to the PIV Middleware implementation’s native program calls.

 + Technical documentation (for both PIV Card Application and PIV Middleware): The vendor-supplied technical documentation must include the detailed technical description and the design of the implementation to be tested. This document includes, at a minimum, all the required vendor information specified in DTRs in Appendix A of this document.

 + Security-related information: Security-relatedThe following security related information suchshall asbe provided by the vendor: (a) PIV Card Application PIN, the(b) PIN unblockingUnblocking PIN,Key the(PUK), number(c) ofGlobal unsuccessfulPIN, attempts(d) thepairing PIVcode, Card(e) Applicationcryptographic willalgorithms allowsupported usingby the wrong Cardcard, Application(f) andminutia PINdata, unblockingand PINs,(g) the optionalnumber cryptographicof algorithmsunsuccessful supportedattempts byusing the(1) wrong PIV Card Application PIN, etc.(2) shouldwrong beGlobal providedPIN, by(3) thewrong vendorPUK, (4) and wrong minutia data.

 The test facility-generated documents are required for performing and reporting the test process. The following are some of the examples:

 + Checklists.: Checklists provide the tester with a list of actions and requirements to complete before the test starts. Information required in the preconditions section of the assertions is included in the checklists.

 + Test logs.: A test log is kept for each test run on any component and is used to summarize the results of all the tests run.

 + Test reports.: These provide the background (environmental information) for each of the test cases as well as summary of outcomes from test runs (from test logs) associated with each test case.

 A test case is a sequence of command/function invocations that pertain to a given execution condition for the ‘command/function under test’. For example, if the GET DATA command is the command/function under test, then the execution condition ‘Invocation of this function after PIN verification’ will consist of the following sequence of command/function invocations – SELECT, VERIFY, GET DATA, and collectively constitutes a test case. There may be many test runs for this test case. The function invocations returning the expected return codes for a test case in all test runs indicatesindicate that the command/function has been implemented correctly.