The Open Group FIPS 151-2 Testing Policy--

Certificate of Validation Requirements for FIPS 151-2

Version 2.0 29 September 1997















(THIS DOCUMENT IS BASED ON THE PRE-EXISTING EQUIVALENT DOCUMENTS PUBLISHED BY NIST/ITL. CERTAIN LIMITED AND SPECIFIC CHANGES HAVE BEEN APPLIED TO THE TEXT TO REFLECT THE OPEN GROUP POLICIES. PLEASE CONTACT THE OPEN GROUP FOR FURTHER INFORMATION OR EXPLANATION OF THE DIFFERENCES BETWEEN THE NIST FIPS CERTIFICATION PROCESS, THE OPEN GROUP FIPS CERTIFICATION PROCESS AND THE OPEN BRAND)

CONTENTS

1. Introduction

2. Terminology

3. NIST-PCTS:151-2

3.1. Availability

3.2. Testing Resources

3.3. Reports Provided

4. Conformance Testing

4.1. Requirements

4.1.1. Test Reports

4.2. FIPS 151-2 Conformance Document Audit

4.2.2. Example of a PCD.1 Audit Procedure

4.3. FIPS 151-2 Conformance

5. The Open Group Certificate FIPS 151-2 of Validation

5.1. Testing Using the PCTS for FIPS 151-2 Certification

5.1.1. NIST PCTS Interpretations

5.1.2. AFTL PCTS Test Report Checklist

6. Application for FIPS 151-2 certification

6. Apllication for FIPS 151-2 certification

6.1 Certificate of Validation Apllication Form

6.2. Validated FIPS 151-2 Product

6.3 Configuration of SUT for FIPS 151-2 Conformance

6.4. Test Environment

6.5. Authorized Test Suite

6.6. Validation Review

6.7. Collection and Submission of Certification Report

6.8. Certificate of Validation

6.9. Reference File Number

7. Testing Policy Decisions

7.1. POSIX.1 Extensions

7.2. POSIX.1 Unspecified Features

7.3. FIPS 151-1 and FIPS 151-2 Certificates of Validation

7.4. PCD.1

7.5. PCD.1 Requirement Dropped

APPENDIX A: FIPS 151-2 Documentation Audit

APPENDIX B: Certificate of Validation Application Form

APPENDIX C: CERTIFICATE OF VALIDATION

APPENDIX D: Sources of Documents

APPENDIX E: NIST FIPS 151-2 PCTS INTERPRETATION REQUEST FORM.

APPENDIX F: Summary of differences between FIPS 151-2 testing, and The Open Brand

1 Introduction

General information on The Open Group FIPS 151-2 testing policy is provided in a separate document, The Open GroupTesting Policy for FIPS 151-2: General Information

Information on Accredited POSIX Testing Laboratories is provided in The Open Group Testing Policy for FIPS 151-2: General Information and in the National Voluntary Laboratory Accreditation Program-- Program Handbook-- Computer Applications Testing-- POSIX Conformance Testing.

This document presents information specific to conformance testing and Certificate of Validation requirements for the Federal Information Processing Standards Publication 151-2. All functions of the Certification Authority, as defined in The Open Group Testing Policy for FIPS 151-2: General Information, are conducted by The Open Group.

2 Terminology

Accreditation. Administrative act of recognizing that a testing laboratory is qualified to conduct conformance testing, having met specific technical and organizational criteria.

Approved Test Methods. An organized system under which, on a uniform and equitable basis, products or services may be certified to meet specified standards.

AFTL. Accredited FIPS 151-2 Testing Laboratory.

Assessors. Experts selected by NVLAP to conduct an on-site assessment of a particular laboratory for the purpose of accreditation.

Certificate of Validation. A document attesting that a product or a service is in conformance with specific standards or technical specifications as determined through use of a specified test method.

Certification Authority. The Open Group Conformance Quality Manager provides the overall direction for organizing, managing, directing, and administering the FIPS 151-2 testing program.

Client. As used in this plan, Client refers to any organization or person who requires FIPS 151-2 conformance testing for any purpose.

Conformance. The state of an implementation satisfying the requirements and specifications of a specific standard as tested by a test suite.

ITL. Information Technology Laboratory (within NIST).

FIPS. Federal Information Processing Standard as specified in a FIPS publication.

FIPS 151-1. Federal Information Processing Standard Publication 151-1, "FIPS 151-2: Portable Operating System Interface for Computer Environments".

FIPS 151-2. The colloquial name for FIPS 151-2 related Federal Information Processing Standards (FIPS).

IUT. Implementation under test. In the case of FIPS 151-2 conformance testing the software under assessment for conformity with the FIPS 151-2 standard.

MSF. Minor system fault. A minor non conformity with an The Open Group standard which is deemed to have negligible impact on application portability and thus be eligible for waiver of conformity by means of a Temporary Waiver. MSF's relate to The Open Brand and shall not be granted in connection with FIPS 151-2 certification.

NVLAP. National Voluntary Laboratory Accreditation Program (within NIST).

NIST. National Institute of Standards and Technology (formerly National Bureau of Standards (NBS)).

PCD. Posix Conformance Document. A document in which the vendor of an implementation Asserts the exact means by which its conformity to the IEEE 1003.1 standard has been achieved.

PCTS. NIST FIPS 151-2 Conformance Test Suite.

PIN. Permanent interpretation. A means by which an error or ambiguity in a standard can be formally defined and resolved, to enable certification to proceed despite the presence of one or more otherwise unacceptable test result codes in the test results related to that issue.

POSIX. The colloquial name for the collection of IEEE 1003 Standards, the first of which is IEEE Standard Portable Operating System Interface for Computer Environments, IEEE Std. 1003.1-1988.

SUT. System under test. The implementation under test in its system (hardware) environment.

Test Suite. A complete set of tests necessary to perform conformance testing for a target system, together with the information and instructions needed to run the tests.

TIN. Temporary Interpretation. An issue with respect to a base de jure standard in which The Open Group makes a temporary interpretation in lieu of a pending decision from the formal standards body. TIN's relate to The Open Brand and shall not be granted in connection with FIPS 151-2 certification.

TSD. Test Suite deficiency. A means by which an error or ambiguity in a test method can be formally defined and resolved, to enable certification to proceed despite the presence of one or more otherwise unacceptable test result codes in the test results related to that issue.

3. NIST-PCTS:151-2

3.1 Availability

The NIST-PCTS:151-2 tests the POSIX.3.1 assertions and additional assertions for requirements 'a-p' of FIPS 151-2. The Official NIST-PCTS:151-2 is distributed by NIST/ITL. The Open Group makes updates and fixes available to the original NIST PCTS as required for certification purposes such fixes are limited to correction of errors in the test suite. .

3.2 Testing Resources

The following resources are required to perform FIPS 151-2 conformance testing using the NIST FIPS 151-2 PCTS:

The following resources are optional, but when provided by the IUT must be tested:

3.3 Reports Provided

Four reports are provided by the NIST-PCTS:151-2.

4. Conformance Testing

The current official version of the NIST-PCTS:151-2 must be used whenever conformance testing for FIPS 151-2 is to be performed. The purchaser may utilize the NIST-PCTS:151-2 as they wish, modifying or enhancing it to provide added value. However, when a test for conformance is to be performed the UNEDITED version of the official NIST-PCTS:151-2 must be used.

4.1 Requirements

The NIST-PCTS:151-2 -- Installation and Testing Guide provides the documentation required to install, configure and execute the NIST-PCTS:151-2. The tester must use the implementation's PCD.1 to configure this PCTS. PCTS configuration files will reference specific sections of the PCD.1 when information on the behavior of the SUT is needed.

The NIST-PCTS:151-2 -- Installation and Testing Guide provides the FIPS 151-2 acceptable test result code for each POSIX.3.1 assertion. The Output Journal test result codes must match the FIPS 151-2 required test result codes. If report analysis verifies the implementation is non-conforming, these errors must be corrected in the SUT and the NIST-PCTS:151-2 rerun in its entirety. If report analysis shows that an installation file was not configured correctly, the configuration must be corrected and the NIST-PCTS:151-2 must be rerun in its entirety.

4.1.1 Test Reports

The Installation Report is generated by the NIST-PCTS:151-2 in the user's test directory with a filename of journal. The Raw Journal Report provides sufficient detail such that most failures can be identified with a specific line or block of the actual source code where the test failed. This report is produced for each element tested and is placed in /STD/POSIX.1_Section/adm/.element (where: element is the name of the element tested).

The Output Report provides the PCTS generated test result codes. The complete list of these codes are listed below as acceptable or unacceptable test result codes. The acceptable test result codes are:

Unacceptable test result codes must be resolved to an acceptable test code or an AFTL resolved test code before a successful conformance statement can be issued. The unacceptable test result codes are:

The Validation Report results are directed to stdout.

4.2 FIPS 151-2 Conformance Document Audit

The requirement for an audit of the PCD.1 for FIPS 151-2 validation was dropped (see 8.6). The PCD.1, for the SUT, must provide the documentation requirements of POSIX.3.1 and the additional requirement ``p'' of FIPS 151-2.

4.2.1 Additional FIPS 151-2 Documentation Requirements

The AFTL must ensure that the additional documentation requirement as specified in FIPS 151-2 Item ``p'' is met.

Implementations claiming conformance to FIPS 151-2 shall document, in the POSIX Conformance Document, the FIPS 151-2 conditional features implemented. (The term conditional features are the features or behaviors referred to in FIPS 151-2 that need not be present on all conforming implementations. IEEE Std 2003.1-1992 lists the documentation assertions for POSIX.1)

This requirement provides two necessary features:

4.2.2 Example of a PCD.1 Audit Procedure

When the implementation tested by the AFTL provides additional text based on an updated ISO/IEC 9945-1:1990 standard or to an approved IEEE standard that updates ISO/IEC 9945-1:1990, Section 7.5 provides the PCD.1 requirements for FIPS 151-2.

To provide some guidance for PCD.1 audits based on POSIX.3.1, a checklist is provided (see Appendix A). Each entry of the checklist corresponds to a POSIX.3.1 (sub)clause and documentation assertion number. This information must be presented in the PCD.1 in the (sub)clause as stated by the checklist.

The Allowable Resolution, of the checklist for each entry, is determined by the category of the assertion, the text of the assertion, the text of POSIX.1, and the additional requirements of FIPS 151-2.1. The Audit column of Appendix A is completed by the AFTL and must contain, for each entry, a 'd', 'D', or 'N'. Which identifier is used for an Audit entry is determined by the following rules.

d Specifies documentation is provided that states the conditional feature is NOT supported. The use of 'd' is restricted to those conditional documentation assertion entries where the NIST-PCTS:151-2 needs to know when support for the feature documented is provided.

D Documentation is provided.

N Documentation is NOT provided.

The following rules provide the rationale on the Allowable Resolution column for each entry.

The parameters specified by the AFTL for the configuration file <config> in the NIST-PCTS:151-2 must be consistent with the specifications of the PCD.1.

4.3 FIPS 151-2 Conformance

A claim of conformance to FIPS 151-2 asserts that the SUT test result codes resolve to a 'Pass' utilizing interpretations if necessary. In addition the SUT complies fully with the FIPS 151-2 documentation requirements. Statements claiming conformance to FIPS 151-2 should state the name and version of the official test suites that was used.

The Certificate of Validation for FIPS 151-2 is issued by The Open Group and is distributed through the AFTL

5. The Open Group Certificate FIPS 151-2 of Validation

This section specifies the procedures to be followed, when a Certificate of FIPS 151-2 Validation from The Open Group is desired.

5.1 Testing Using the PCTS for FIPS 151-2 Certification.

An Accredited FIPS 151-2 Testing Laboratory (AFTL) is a testing laboratory that has been accredited for FIPS 151-2 testing by NVLAP, or another accreditation agency recognized by The Open Group. AFTLs for FIPS 151-2 have demonstrated the proficiency required to use the NIST-PCTS:151-2 and may submit test results for a FIPS 151-2 Certificate of Validation.

Arrangements for conformance testing are between clients and AFTLs. Arrangements for evaluation of the test results, for the purpose of issuing a Certificate of Validation, are between the AFTLs and The Open Group.

The Official NIST-PCTS:151-2 is provided by the AFTL. The Official version of NIST-PCTS:151-2 must be used whenever the goal of the testing is to obtain a Certificate of Validation with the test results. The AFTL will cause the generation of all required output reports for the IUT. The Open Group will accept FIPS 151-2 PCTS Test Reports only from AFTLS.

Test results submitted to The Open Group for validation must be the results of testing conducted by the AFTL after it has formally received notification of accreditation from NVLAP (see NVLAP Handbook, Appendix E). The Open Group schedule reviews of certification reports in the order in which they are received from AFTLs. The Open Group issues a Certificate of Validation upon successful completion of the validation procedure.

5.1.1 NIST PCTS Interpretations

It is the responsibility of the AFTL to investigate any unacceptable test result codes encountered in testing. Where justified these may be resolved to one that is acceptable for obtaining a Certificate of FIPS 151-2 Validation from The Open Group. To obtain a Certificate of Validation when the test result codes reported do not match the acceptable FIPS 151-2 test result codes and the AFTL deems that the reason for the discrepancy is not the fault of the SUT, the AFTL must resolve each discrepancy by means of submitting a formal interpretation request to The Open Group. The interpretation request form for issues encountered in testing using the NIST FIPS 151-2 PCTS is included in appendix E and is also availble from The Open Group Web site http://www.opengroup.org/testing/fips/pinterp. If The Open Group agrees to grant an interpretation this will enable certification to proceed even in the presence of an otherwise unacceptable test result code. This policy is not designed to waive or ignore actual errors, but rather to permit acceptance of implementations which meet the intent of the standard, but through some set of errors or discrepancies fails to meet a specific encoding of a test (i.e., resolve false negatives).

When test failures occur due to hardware malfunctioning, the AFTL is expected to rerun the NIST-PCTS:151-2 in its entirety on properly functioning hardware. It will not be possible for the AFTL to resolve test codes to cover the failure of a test due to hardware malfunction. The inherent assumption of a Certificate of Validation is that the hardware functions properly and was demonstrated to do so during the conformance testing.

AFTL provided Certification Reports must consist of unmodified test results supported as necessary by a reference to one or more a granted interpretations. Each submission by the AFTL of an interpretation request will be examined by The Open Group on its individual merits. When The Open Group has granted an interpretation, the actual test result code will not be an impediment to the issue of a Certificate of FIPS 151-2 Validation. If The Open Group does has not accepted a formal interpretation request then it follows that, a Certificate of FIPS 151-2 Validation will not be issued. An AFTL shall NEVER alter the reports generated by an Official NIST-PCTS:151-2 run that is to be used for requesting a Certificate of Validation from The Open Group.

The complete list of test codes that may result in interpretation is defined below:

POSIX.1_EXTENSION:

In this case the AFTL considers that the SUT supports an allowable extension that was not handled properly by the NIST-PCTS:151-2 and this extension has been properly documented in the SUT's PCD.1. The AFTL; shall submit an interpretation request for a test suite deficiency that clearly and accurately describes the problem with the Official NIST-PCTS:151-2. For acceptance by The Open Group of an such an interpretation, the interpretation request must contain:

PCD_DOCUMENTED:

In this case the AFTL considers that an unsuccessful result was caused by the PCTS improperly handling an implementation defined condition, the AFTL verified that the required documentation is provided in the appropriate place in the PCD.1, and that the unsuccessful result reported by the PCTS is consistent with the documentation provided. The AFTL; shall submit an interpretation request for a test suite deficiency that clearly and accurately describes the problem with the Official NIST-PCTS:151-2. For acceptance by The Open Group of an such an interpretation, the AFTL interpretation request must contain:

PCTS_FAILURE:In this case the AFTL considers that the Official NIST-PCTS:151-2 has a "bug" that impeded the SUT from properly performing the required test. The AFTL; shall submit an interpretation request for a test suite deficiency that clearly and accurately describes the problem with the Official NIST-PCTS:151-2, an may suggest corrective code that allows the test to perform successfully on the SUT, and shall quote from the PCD.1 the statements that apply. For acceptance by The Open Group of an such an interpretation, the AFTL interpretation request must contain:

POSIX.1_FAILURE:

In this case the AFTL considers that that the ISO/IEC 9945-1:1990 has an error or inconsistency that was resolved by an IEEE interpretation or an official update to ISO/IEC 9945-1:1990. The AFTL; shall submit an interpretation request for a permanent interpretation that clearly and accurately describes the problem. For acceptance by The Open Group of an such an interpretation, the AFTL interpretation request must contain:

POSIX.3_FAILURE:

In this case the AFTL considers that that the IEEE Std 2003.1-1992 has an error or inconsistency that was resolved by an IEEE interpretation or an official update to IEEE Std 2003.1-1992. The AFTL; shall submit an interpretation request for a permanent interpretation that clearly and accurately describes the problem. For acceptance by The Open Group of an such an interpretation, the AFTL interpretation request must contain:

POSIX_VERSION_UPDATE:

In this case the value of {_POSIX_VERSION} provided by the implementation corresponds either to an updated version of ISO/IEC 9945-1:1990 or to an approved IEEE standard that updates ISO/IEC9945-1:1990. POSIX_VERSION_UPDATE is an AFTL resolved test code that can be used ONLY for assertion sym_const[05]. The AFTL shall apply for a permanent interpretation.

5.1.2 AFTL PCTS Test Report Checklist

When the NIST-PCTS:151-2 reports comply with the requirements below, the AFTL is ready to request The Open Group FIPS 151-2 certification. The AFTL acts as the applicant on the client's behalf. They assert that:-

6 Application for FIPS 151-2 certification.

6.1 Certificate of Validation Application Form

The application form provides information that will appear on the Certificate of Validation (Appendix C). A sample Certificate of Validation Application Form is provided as Appendix B and a template for this form is provided by the NIST-PCTS:151-2 as file ./CERT_data/NPTP_appendixB. This template must be fully and accurately completed.

6.2 Validated FIPS 151-2 Product

The applicant must provide the name of the supplier of the software product tested and must accurately identify the product.

The identification must include the name of the product and any other product designations needed to uniquely define the tested product. The product identified represents the IUT. This product must contain, if needed, automated procedures for configuration control during installation. Implementations requiring that the IUT be manually patched, cannot be identified as required and will not be validated. (i.e., An operating system that requires a type definition of typedef int ssize t; be added to /usr/include/sys/types.h to PASS all the tests is not a conforming implementation. This code must be provided by the operating system during installation.) Products need not automate configuration details required for providing FIPS 151-2 optional features nor for performing FIPS 151-2 validation testing.

6.3 Configuration of SUT for FIPS 151-2 Conformance

The applicant must specify the installation procedures required to configure the software product identified the application for FIPS 151-2 conformance. This specification is to be retained in file ./CERT_data/config_SUT and is limited only to those procedures needed to obtain FIPS 151-2 conformance. References to specific sections in the SUT's associated system documentation is acceptable. When the SUT is such that FIPS 151-2 conformance is not dependent on installation procedures, then the applicant shall state:

Operating system is not dependent on installation procedures for FIPS 151-2 conformance.

as the data for ./CERT_data/config_SUT.

6.4 Test Environment

Four types of POSIX.1 implementations have been identified:

The type of the implementation tested must be stated.

The hardware implementation employed to test the product must be identified. The identification must include the name of the implementation and any other designations needed to uniquely define it (i.e., Name, Model, Release). If the product tested was on a co-operating implementation, then both the target and the development implementations must be identified. Other required details are:

The complete hardware configuration is required. This includes memory provided, cpu's available, controllers installed, and the number and types of disk drives.

The applicant must also provide the name and supplier of the FIPS 160 conforming compiler and the identification scheme to uniquely identify it (Name, Release, etc).

These specifications should follow the format as shown by the following example.

Implementation Tested

Supplier: POSIX Products, Inc.

Product: PROD_456, Version 1.3, August 1993

PCD: POSIX Conformance Document, August 1993

System Tested

Type: Native

Computer Hardware Supplier: Hardware Inc.

Computer Hardware Product: TRUE_blue, Model Red_White_Blue, 48MB, 1cpu

1 - Graphics box, Model See_It_Quick

Disk Controller: Integrated SCSI controller

1 - 665MB disk drive, Model RWB_1

2 - 1.2GB disk drive, Model RWB_3

Terminal Controller: Never_a_Miss, Model RWB,

C Compiler Supplier: POSIX Products, Inc.

C Compiler Product: PROD C Compiler, Version 1.0, August 1993

The Open Group will attempt to automate the generation of the Certificate of Validation based on the input provided by the applicant and the Output Report from the Test Suite. Applicants should make every effort to retain the designated format when preparing the application form file ./CERT_data/NPTP_appendixB.

6.5 Authorised Test Suite.

Applicants may submit test reports only from the authorized version of the test suite. The requirements for determining the authorized version of the NIST-PCTS:151-2 and the Open Group test suites have been harmonized. There is a six month overlap period when the current and previous versions of the test suite are both authorized for use. After the updated test suite has been availble for six months the previous version ceases to be supported and to be acceptable for certification purposes. The currently authorized versions of the NIST-PCTS:151-2 is defined on The Open Group Web site http://www..opengroup.org/testing/branding/dates.htm.

6.6 Validation Review

The Open Group will strive to process a problem-free Certification Report and provide the Certificate of Validation within three weeks after the report and its associated Certificate of Validation Application Form are received. The certificate of validation will be provided to the client via the AFTL.

A Certification Report which requires an update to the supporting material provided with the PCTS must be resubmitted in its entirety. If the Certificate of Validation Application Form is found to be in error, it must be resubmitted along with the updated Certification Report. The Open Group will not retain Certification Reports that require additional updates. These reports may be destroyed. The applicant must adhere to the requirements of this document in their entirety in order to avoid having to rerun and repay for a Certificate of Validation.

When a resolution of a test result code is determined to be dependent on a not-yet-completed IEEE interpretation the applicant will be informed of this matter and the report will be destroyed. Once the required procedures are completed and the outcome is now in compliance with the results obtained from the SUT, the applicant can update the report to include the decisions rendered. The applicant must adhere to the requirements of this document in their entirety in order to avoid having to rerun and repay for a Certificate of Validation.

An applicant should not submit documentation for obtaining a Certificate of Validation, when interpretations are known to be required. When this condition arises, the applicant should attempt to get the interpretation problem favorably resolved prior to submitting the application to The Open Group.

6.7 Collection and Submission of Certification Report

To request a Certificate of Validation for FIPS 151-2 an applicant must provide to The Open Group the following items:

  1. Certification Fee ($1000, For existing VSX test suite licensees the fee will be waived during the first year of the operation of the program)
  2. The test report output. Signed sections must be submitted in Hardcopy, other sections must be submitted via FTP.
  3. The PCD. This document must be in existence, but need not be submitted to the Open group. The requirement to audit this document was dropped from the NIST program and this remains the case for The Open Group FIPS 151-2 Certification.
  4. A covering letter cross referencing any referenced interpretations to the relevant test result codes. This may be submitted in hard copy or via FTP.
  5. The Certificate of Validation Application Form (See appendix B) This must be submitted in hard copy.
  6. Documentation specifying additional installation procedures performed or installation options selected to obtain the environment for testing the implementation for FIPS 151-2 conformance. When system documentation is referenced (e.g., Technical Notes, manual pages, etc.), either a copy of this documentation must be provided or a summary of the referenced document must be contained within this report. When copies of system documents are provided, these will be returned when validation procedures are completed. This may be submitted in hard copy or via FTP.

The NIST-PCTS:151-2 -- Installation and Testing Guide documents the file names to use for the required reports and the procedures available for generating them. The AFTL shall not modify any files excepting as explicitly defined in the test suite documentation.

The Open Group conformance administrator should be contacted by electronic mail on conformance@opengroup.org prior to submitting the application. The Conformance Administrator will ensure that FTP access is provided for this purpose. The specified templates of Appendices A, B, and C must be used when submitting a Certification Report. These templates are also available on The Open Group Web site http://www.opengroup.org/testing/fips/templates. Certification Reports which improvise on the format of these templates will not be accepted.

The applicant must be able to reproduce paper copies of the Certification Report if requested by The Open Group

6.8 Certificate of Validation

A Certificate of Validation is issued by The Open Group based on the official test suite reports. Samples of a Certificate of Validation are provided in Appendix C. Many of the items on the Certificate of Validation are those specified by the applicant in the Certificate of Validation Application Form.

Additional Certificate of Validation information is available from The Open Group on:

The maintains a web based register called The Open Group Testing Laboratories and Validated Products which lists current AFTLs and The Open Group certified FIPS 151-2 products http://www.opengroup.org/testing/fips/Products. As additional products are validated, they are added to the register.

6.9 Reference File Number

Each Certificate of Validation is assigned a Reference File Number. The Reference File Number is determined by the concatenation of; the text ``151-2'', a unique three letter mnemonic for each operating system supplier, and a three digit number which starts at 001 for each operating system supplier and incremented for each Certificate of Validation issued. A Reference File Number of 151-2DCC001 would be assigned to the initial Certificate of Validation for the fictitious ``Data Computer Company''.

7. Testing Policy Decisions

This section specifies the policy decisions that have been made pertaining to the testing for conformance to FIPS 151-2. These existing policy decisions are subject to change and if additional policy decisions are needed they will be placed in this section.

The NIST PCTS Test FIPS 151-2 which is not an updated POSIX.1-1990 standard. No testing requirement, as determined by FIPS 151-2 (and its associated IEEE Std 2003.1-1992 testing standard), will be altered because an update of the POSIX.1-1990 standard, deleted or made optional a requirement of POSIX.1-1990.

7.1 POSIX.1 Extensions

The issue of conformance testing for implementations providing POSIX.1 extensions, is a problem area. As products are being prepared, vendors, users, and testers are concerned about how The Open Group will resolve conformance testing problems involved by POSIX.1 extensions.

Until we determine and document what action to take for an extensively documented and acceptable POSIX.1 extension, we will not validate systems based on inadequately specified issues as related to POSIX.1.

7.2 POSIX.1 Unspecified Features

ISO/IEC 9945-1:1990 allows conforming implementations to contain unspecified features. Unspecified features provided in implementations under POSIX.1 umbrellas such as those introduced in Sections 2.2.2.4, 2.3.1, and2.3.2- which allow implementation-defined, alternate, or extended behavior while completely omitting the details for this behavior - may cause unacceptable test results when tested.

The NIST-PCTS:151-2 tests conformance to FIPS 151-2 based on the assertions (modified as needed to adhere to the additional requirements of FIPS 151-2) in the latest POSIX.3.1 document available when FIPS 151-2 was approved. Implementations with unacceptable test results, because the implementation incorporated unspecified features when tested, will not be issued a Certificate of Validation.

Vendors requiring a Certificate of Validation for implementations that provide unspecified features must ensure these features do not cause the test suite used to become errant. AFTL's must ensure that the implementation tested is the unaltered implementation identified on the Certificate of Validation Application Form. The AFTL should capture any installation setup details outside the scope of the test suite that are needed to ensure the successful run. These details will be needed if a rerun of the conformance testing is required in the future.

7.3 FIPS 151-1 and FIPS 151-2 Certificates of Validation

An implementation that attains a FIPS 151-2 Certificate of Validation is conforming to both FIPS 151-2 and FIPS 151-1. The ISO/IEC 9945-1:1990 was defined by P1003.1 as the update to IEEE Std 1003.1-1988 which contained only corrections and additional text to explain the intended meaning of the 1988 standard. The tests of the NIST-PCTS:151-2 therefore, can be used as the tests for FIPS 151-1.

FIPS 151-2 became effective on October 15, 1993. NIST/ITL ceased processing FIPS 151-1 Certification Reports. The `The Open Group FIPS certification program, is thus restricted to FIPS 151-2.

7.4 PCD.1

To harmonize the PCD.1 requirements of FIPS 151-2 with that of ISO/IEC 9945-1:1990 and its official updates, the FIPS 151-2 PCD.1 requirements are:

7.5 PCD.1 Requirement Dropped

IEEE Interpretations has stated that a conflict exists between the requirements of IEEE Std 1003.1-1990 and the documentation assertions as stated in IEEE Std 2003.1-1992. On August 30, 1994, the audit of the PCD.1 was no longer required to obtain a Certificate of Validation for FIPS 151-2 from NIST/ITL and this remains the case for certification to FIPS 151-2 from The Open Group.

The two unchanged requirements associated with the PCD.1 for FIPS 151-2 certification will be the documentation of its identification in the Certificate of Validation Application Form, and the retention of the PCD.1 as part of the official test results file. Specification of the PCD.1 identification is confirmation by the applicant that the PCD.1 was utilized when testing was performed.

APPENDIX A FIPS 151-2 Documentation Audit

Documentation Audit Tables Symbols:

, Separation notation used for listing of acceptable symbols.

S POSIX.1 conditional feature is supported.

d Documentation provided specifies conditional feature NOT supported.

D Documentation provided.

N Documentation NOT provided.

NA Documentation assertion is not applicable to FIPS 151-2 requirements.

S ®D If conditional feature is supported, then documentation is required.

RD Implied required FIPS 151-2 conditional feature, documentation required.

RD,N Required FIPS 151-2 conditional feature, documentation need not be provided.

NA®N Documentation shall not be provided.

POSIX.3.1 (Sub)clause
#
Allowable Resolution
PCTS Conditional Feature
Audit D,N,d
1.3.1.1
1
D
POSIX.1 environment
1.3.1.2
2
Dname, number, and date of applicable POSIX.1 standard
1.3.1.2
3
D,Ninternational software standards
1.3.3
4
NA->N C-language differences from C Standard
1.3.3.2
5
Dversion of the C Standard supported
1.3.3.3
GA1
NA->Ninterface differences from C Standard
1.3.3.3
6
NA->Nlanguage binding differences from C Standard
2.2.2.4
1
D,dassociating appropriate privileges with a process
2.2.2.9
2
RD,Ncharacter special files other than terminal device files
2.2.2.9
3
D,Nstructures of character special files
2.2.2.27
4
RD,Nother file types
2.2.2.30
5
D,Nadditional criteria to assign process to file group class
2.2.2.55
6
Dparent process ID assigned after parent ended
2.2.2.57
7
Dinterpretation of pathname that begins with two slashes
2.2.2.68
8
D,Nresources returned when process terminates
2.2.2.69
9
Drestrictions of interfaces on read-only file systems
2.2.2.83
10
RD,Neffective GID returned by getgroups()
2.3.1
1
RD,N extended security controls
2.3.2
2
RD,N additional and alternate file access controls
2.3.2
3
D,N disabling alternate mechanism and chmod()
2.3.5
4
D,N additional time-related update specifications
2.3.5
5
D,N additional time-related update specifications
2.3.5
6
D,N updating time-related fields
2.4
1
RD,N additional errors
2.4
2
D reliable detection of [EFAULT]
2.4
3
D maximum file size allowed
2.5
1
RD,N additional type symbols ending in ``_t''
2.6
1
RD,N other characters used for environment variable names
2.7.2
1
RD,N additional feature test macros
2.8.3
1
D limit for {NGROUPS_MAX} in <limits.h>
2.8.4
2
D run-time invariant values in <limits.h>
2.8.5
3
D changeable values in <limits.h>
2.9
1
D values {_POSIX_JOB_CONTROL}, {_POSIX_SAVED_IDS}
2.9
2
RD,N value of {_POSIX_CHOWN_RESTRICTED} in <unistd.h>
2.9
3
RD,N value of {_POSIX_NO_TRUNC} in <unistd.h>
2.9
4
RD,N value of {_POSIX_VDISABLE} in <unistd.h>
2.9.4
5
RD {_POSIX_CHOWN_RESTRICTED} value in <unistd.h>
2.9.4
6
RD {_POSIX_NO_TRUNC} value in <unistd.h>
2.9.4
7
RD {_POSIX_VDISABLE} value in <unistd.h>
3.1.1.2
1
RD,Nsharing open directory streams between parent and child
3.1.1.2
2
D,Ninheritance of process characteristics for fork().
3.1.1.4
3
RD,N[ENOMEM] detection for fork().
3.1.2.2
1
Dexeclp() or execvp() results on search without PATH.
3.1.2.2
2
D,Ninheritance of process characteristics for exec elements.
3.1.2.2
3
D,Nst_atime marked for update when exec fails.
3.1.2.4
4
RD,Nexecution of irregular files.
3.1.2.4
5
RD,N[ENOMEM] detection exec.
3.2.1.1.2
1
D,Norder reporting status for two or more child processes.
3.2.1.1.3
2
D,Nadditional circumstances for reporting status.
3.2.1.1.4
3
D,Nstatus value provided by wait() or waitpid() is [EINTR].
3.2.2.1
1
NA->Nresult type for function _exit().
3.2.2.2
2
Dparent process ID assigned to child of terminated process.
3.3.1.1
1
NA->Nsupport of {_POSIX_JOB_CONTROL} signals.
3.3.1.1
2
RD,Nadditional signals supported.
3.3.1.2
3
D,Naction taken on blocked signal when action is SIG_IGN.
3.3.1.2
4
Dsignal delivered more than once if another signal is pending.
3.3.1.2
5
D,Ndelivery of multiple pending signals to process.
3.3.1.2
6
Ddetails outside of POSIX.1 on generating signals.
3.3.1.3
7
D,NSIGFPE, SIGILL, or SIGSEGV signal ignored.
3.3.1.3
8
D,Naction taken for SIGCHLD to SIG_IGN.
3.3.1.3
9
D,Naction SIGFPE/SIGILL/SIGSEGV not from kill()/raise().

POSIX.3.1 (Sub)clause
#
Allowable Resolution
PCTS Conditional Feature
Audit D,N,d
3.3.1.3
10
D,Ncaught SIGCHLD signal and unwaited terminated child process.
3.3.1.3
11
D,Ninterrupted unsafe function calls an unsafe function.
3.3.2.2
1
RD,Nsend signals to processes of another user ID.
3.3.2.2
2
D,Nexcluded set of system processes when pid is 0.
3.3.2.2
3
D,Nbehavior of kill() when pid is -1.
3.3.2.2
4
D,Nexcluded set of system processes when pid is negative but not -1.
3.3.2.2
5
D,Nrestrictions on sending of non-POSIX.1 signals.
3.3.3.1.2
1
D,Nobject of type sigset_t not initialized but pointer to object supplied.
3.3.3.3.4
1
RD,N[EINVAL] detection for sigaddset().
3.3.3.4.4
1
RD,N[EINVAL] detection for sigdelset().
3.3.3.5.4
1
RD,N[EINVAL] detection for sigismember().
3.3.4.2
1
D,Naction taken by sigaction() when established by signal().
3.3.4.2
2
D,Nsetting action to SIG_DFL for signal that cannot be ignored.
3.3.5.2
1
D,NSIGFPE, SIGILL, or SIGSEGV generated while blocked.
3.3.6.4
1
RD,Nerror conditions detected for sigpending().
3.4.3.2
1
D,NSIGALRM generated during sleep() is ignored or blocked.
3.4.3.2
2
D,NSIGALRM is blocked from delivery.
3.4.3.2
3
D,NSIGALRM is not blocked or ignored.
3.4.3.2
4
D,Ndetails (time, action, signal mask) SIGALARM interrupting sleep().
3.4.3.2
5
D,Nsleep() interrupted and siglongjmp() or longjmp() called.
4.2.2.1.2
1
RDappropriate privileges to change real, effective, saved setuids.
4.2.2.2.2
1
RDappropriate privileges to change real and effective group IDs.
4.2.3.2
1
D,Narray entries and returned value from getgroups().
4.2.4.3
1
D,Nreturn value from getlogin() possibly overwritten.
4.2.4.4
2
S->D,N,derror conditions detected for getlogin().
4.3.3.2
1
NA->Nsupport for setpgid().
4.4.1.2
1
Dformat of struct utsname members.
4.4.1.4
2
RD,Nerror conditions detected for uname().
4.5.1.4
1
RD,N,derror conditions detected for time().
4.5.2.3
1
D,Nreturn value from times() overflow range of type clock_t.
4.5.2.4
2
RD,N,derror conditions detected for times().
4.6.1.3
1
D,Nreturn value from getenv() possibly overwritten.
4.6.1.4
2
RD,N,derror conditions detected for getenv().
4.7.1.3
1
D,Nreturn value from ctermid() possibly overwritten.
4.7.1.4
2
RD,N,derror conditions detected for ctermid().
4.7.2.1.2
1
D,Nreturn value from ttyname() possibly overwritten.
4.7.2.1.4
2
RD,N,derror conditions detected for ttyname().
4.7.2.2.4
1
RD,N,derror conditions detected for isatty().
4.8.1.2
1
D,Nadditional configuration system variables.
5.1.1
1
D,N internal format of directories.
5.1.1
2
D,N size of array d_name.
5.1.2.1.2
1
D,Nfile removed or added after opendir().
5.1.2.1.4
2
RD,N[EMFILE] detection for opendir().
5.1.2.1.4
3
RD,N[ENFILE] detection for opendir().
5.1.2.2.2
1
D,Nreturn value from readdir() possibly overwritten.
5.1.2.2.2
2
D,Nreaddir() buffers directory entries per read operation.
5.1.2.2.2
3
D,Nusing directory stream after exec type function call.
5.1.2.2.2
4
D,Nparent and child call readdir().
5.1.2.2.4
5
D,Npassing a closed dirp argument to readdir().
5.1.2.2.4
6
RD,N[EBADF] detection for readdir().
5.1.2.3.1
1
NA->Nresult type for readdir().
5.1.2.3.2
2
D,Nremoving and adding entries to a directory.
5.1.2.3.2
3
D,Npassing a closed dirp argument to rewinddir() .
5.1.2.4.2
4
D,Nchild and parent processes both using readdir() and rewinddir().
5.1.2.4.2
1
D,Naccessibility of object type DIR after call to closedir().
5.1.2.4.2
2
D,Npassing a closed dirp argument to closedir().
5.1.2.4.4
3
RD,N[EBADF] detection for closedir().
5.2.2.2
1
D,Nbehavior of getcwd() when buf is a NULL pointer.
5.2.2.3
2
D,Ncontents of buffer passed to getcwd() after an error.
5.2.2.4
3
RD,N[EACCES] detection for getcwd().
5.3.1.2
1
D,Ncall to open() on a FIFO with O_RDWR set.
5.3.1.2
2
Dgroup ID of new file set to group ID of its directory.

POSIX.3.1 (Sub)clause
#
Allowable Resolution
PCTS Conditional Feature
Audit D,N,d
5.3.1.2
3
D,Nopen() with O_CREAT and bits other than mode bits are set.
5.3.1.2
4
D,Nopen() with O_EXCL and O_CREAT not set.
5.3.1.2
5
D,Nblock or character supporting nonblocking and O_NONBLOCK set.
5.3.1.2
6
D,Npath not a block, character, or FIFO file and supports nonblocking.
5.3.1.2
7
DO_TRUNC on file types other than regular, FIFO, or terminal files.
5.3.1.2
8
D,Nopen() with O_TRUNC and O_RDONLY set.
5.3.3.2
1
Dbits other than file permission bits in umask() argument.
5.3.4.2
1
RD,N,dlink() across file systems.
5.3.4.2
2
RD,Nappropriate privileges to link to a directory.
5.3.4.2
3
RD,N,dlink() to directory.
5.3.4.2
4
RD,Naccess permission to access existing file for link() to succeed.
5.4.1.2
1
Deffect of mkdir() of bits other than permission bits set in mode.
5.4.1.2
2
Dgroup ID of new file set to group ID of its directory.
5.4.2.2
1
Deffect of mkfifo() of bits other than permission bits set in mode.
5.4.2.2
2
Dgroup ID of new file set to group ID of its directory.
5.5.1.2
1
Dappropriate privileges for unlinking directories.
5.5.1.2
2
RD,Nsupport for unlink() on directories.
5.5.1.4
3
RD,N[EBUSY] detection for unlink().
5.5.2.2
1
RD,Nrmdir(path) succeeds and path is root or current directory.
5.5.2.2
2
RD,Nrmdir(path) fails and path is root or current directory.
5.5.2.4
3
RD,N[EBUSY] detection for rmdir().
5.5.3.2
1
RD,N,drequires write permission to rename directory.
5.5.3.4
2
RD,N[EBUSY] detection for rename().
5.6.1
1
D,N usage of field st_size in structure returned by stat() and fstat().
5.6.1.2
2
D,NOrs bits other than those specified into the st_mode field.
5.6.2.1.2
1
D,Nadditional/alternate file access control mechanisms cause stat() fail.
5.6.2.2.2
1
D,Nadditional/alternate file access control mechanisms cause fstat() fail.
5.6.3.2
1
RD,Nappropriate privileges to override file access control mechanism.
5.6.3.2
2
D,Nappropriate privileges … none of the execute bits for path are set.
5.6.3.4
3
RD,N[EINVAL] detection for access().
5.6.4.2
1
RD,Nappropriate privileges to change file mode.
5.6.4.2
2
RD,Nignore S_ISUID or S_ISGID bits.
5.6.4.2
3
Deffect of file descriptors for files open at chmod() time.
5.6.5.2
1
RD,Nappropriate privileges to change file owner.
5.6.5.2
2
RD,Neffect of S_ISUID and S_ISGID bits on the file.
5.6.5.4
3
RD,N[EINVAL] detection for chown().
5.6.6.2
1
D,Nadditional members of utimbuf structure.
5.7.1.1.2
1
D,Nadditional configurable pathname variables
5.7.1.1.2
2
D,Nassociation of … with other than a terminal file
5.7.1.1.2
3
D,Nassociation of … with file types other than a directory
5.7.1.1.2
4
D,Nassociation of … with file types other than pipe, FIFO, directory
5.7.1.1.4
5
RD,N[EINVAL] detection for pathconf()
5.7.1.1.4
6
RD,N[EACCESS] detection for pathconf()
5.7.1.1.4
7
RD,N[ENAMETOOLONG] detection for pathconf()
5.7.1.1.4
8
RD,N[ENOENT] detection for pathconf()
5.7.1.1.4
9
RD,N[ENOTDIR] detection for pathconf()
5.7.1.2.2
1
D,Nassociation of … with other than a terminal file
5.7.1.2.2
2
D,Nassociation of … with file types other than a directory
5.7.1.2.2
3
D,Nassociation of … with file types other than pipe, FIFO, directory
5.7.1.2.4
4
RD,N[EBADF] detection for fpathconf()
5.7.1.2.4
5
RD,N[EINVAL] detection for fpathconf()
6.3.1.2
1
D,Nwhen close() is interrupted by a signal
6.4.1.2
1
D,Nvalue of file offset after read() on file not capable of seeking
6.4.1.2
2
Dread() interrupted after reading some data
6.4.1.2
3
Dresult of subsequent reads after read() returns end-of-file
6.4.1.2
4
Dread() with value greater than {SSIZE_MAX}
6.4.1.4
5
D,Nadditional conditions for detecting [EIO] for read()
6.4.2.2
1
D,Nwrite() when nbyte is zero and not a regular file
6.4.2.2
2
D,Nvalue of file offset after write() on file not capable of seeking
6.4.2.2
3
Dwrite() interrupted after writing some data
6.4.2.2
4
Dwrite() with value greater than {SSIZE_MAX}
6.4.2.4
5
D,Nadditional conditions for detecting [EIO] for write()

POSIX.3.1 (Sub)clause
#
Allowable Resolution
PCTS Conditional Feature
Audit D,N,d
6.5.2.2
1
D,Nadditional file status flags for F_SETFL for fcntl()
6.5.2.2
2
D,N,dadvisory record locking for files other than regular files
6.5.2.2
3
D,Nfcntl() for file locking when l_len is negative
6.5.2.4
4
RD,N[EDEADLK] detected for fcntl()
6.5.3.2
1
Dbehavior of lseek() on devices incapable of seeking
7.1
1
D device types supported by the general terminal interface.
7.1.1.2
2
D,Nterminal has foreground process group when.
7.1.1.3
3
Dsession leader without a controlling terminal.
7.1.1.3
4
D,Nclose of last file descriptor associated with controlling terminal.
7.1.1.3
5
D,Nsession leader can reacquire a controlling terminal after.
7.1.1.3
6
D,N,dafter controlling process terminates access.
7.1.1.3
7
Dhow controlling terminal for a session is allocated by session leader.
7.1.1.5
8
D,N{MAX_INPUT} limit.
7.1.1.6
9
D,N{MAX_CANON} limit.
7.1.1.7
10
D,Nread() response when MIN is greater than {MAX_INPUT}.
7.1.1.8
11
RD,N,dbuffers write output to terminal device.
7.1.1.9
12
RD,N,dSTART and STOP special characters can be changed.
7.1.1.9
13
D,Ntwo or more special characters received which have same value.
7.1.1.9
14
D,Nsingle bytes other than ... or multibytes have special meaning.
7.1.1.10
15
D,NEOF is returned or [EIO] is detected when modem disconnects.
7.1.2.1
1
D,Nadditional members of termios structure.
7.1.2.2
2
Dbreak condition for non-asynchronous data transmissions.
7.1.2.2
3
Dconditions under which START and STOP are transmitted.
7.1.2.2
4
Dinitial input control value after open() is specified.
7.1.2.3
5
Dprocessing of output data by OPOST.
7.1.2.3
6
Dinitial output control value after open() is specified.
7.1.2.4
7
D,Nnon-asynchronous serial connection ignoring hardware modes.
7.1.2.4
8
Dinitial hardware control value after open() is specified.
7.1.2.5
9
D,Nechoing details when no character exists to erase.
7.1.2.5
10
D,Ndetails on erasing a line when ECHOK and ICANON are set.
7.1.2.5
11
D,N,ddetails on operation when IEXTEN is set.
7.1.2.5
12
Dinteraction of IEXTEN set with ICANON, ISIG, IXON, or IXOFF.
7.1.2.5
13
Dinitial local control value after open() is specified.
7.1.2.6
14
NA->Nimplementation ignores.
7.1.2.6
15
D,Nvalue of NCCS.
7.1.2.6
16
D,N,dcharacter values in c_cc indexed by START and STOP are ignored.
7.1.2.6
17
Dinitial values of all control characters.
7.1.3.1.4
1
RD,Nerror detection cfgetospeed().
7.1.3.2.2
1
RD,Ncfsetospeed() details on attempting to set unsupported baud rate.
7.1.3.2.4
2
RD,Nerror conditions detected for cfsetospeed().
7.1.3.2.4
1
RD,Nerror conditions detected for cfgetispeed().
7.1.3.4.2
1
RD,Ncfsetispeed() returns error for unsupported baud rate.
7.1.3.4.4
2
RD,Nerror conditions detected for cfsetispeed().
7.2.1.1.2
1
RD,N,dinput and output baud rates that differ.
7.2.2.1.2
1
Dperiod of time break signal is sent when tcsendbreak().
7.2.2.1.2
2
D,Ndetails on non-asynchronous data transmission and tcsendbreak().
7.2.3.2
1
NA->Nsupport for tcgetpgrp().
7.2.4.2
1
NA->Nsupport for tcsetpgrp().
8.1
1
NA->N differences from C Standard.
8.1.3.2
1
RD,Nother locales other than ``C''.
8.1.3.2
2
D,Nstring returned from setlocale() when locale is a NULL pointer.
8.1.3.2
3
D,Nadditional categories supported for setlocale().
8.1.3.2
4
DLC_ALL not set or set to the empty string.
8.1.6.1
1
NA->Nresult type for longjmp().
8.1.7.1
1
NA->Nresult type for clearerr().
8.1.36.1
1
NA->Nresult type for rewind().
8.1.40.1
1
NA->Nresult type for setbuf().
8.1.47.1
1
NA->Nresult type for srand().
8.1.48.1
1
NA->Nresult type for calloc(), free(), malloc(), and realloc().
8.1.49.1
1
NA->Nresult type for abort().
8.1.50.1
1
NA->Nresult type for exit().
8.1.52.1
1
NA->Nresult type for bsearch() and qsort().

POSIX.3.1 (Sub)clause
#
Allowable Resolution
PCTS Conditional Feature
Audit D,N,d
8.1.56.1
1
Ddetails of TZ environment variable beginning with a colon.
8.1.56.1
2
D,Nmeanings of any characters except.
8.1.56.1
3
D,Nbehavior of offset field of TZ environment variable.
8.2.1.4
1
RD,Nerror conditions detected for fileno().
8.2.2.2
1
D,Nadditional values for the fdopen() type argument.
8.2.2.4
2
RD,Nerror conditions detected for fdopen().
8.2.3
1
D,N details involving two or more handles.
8.2.3
2
D,N state of open file description when active handle not accessible.
8.2.3
3
D,N details on rules when file handles are not followed.
8.2.3
4
D conditions when applications will see all input exactly once.
8.2.3
5
D,N ftell() result when stream oppened in append mode.
8.3.1.2.1
1
NA->Nresult type for siglongjmp().
8.3.2.1
1
NA->Nresult type for tzset().
8.3.2.2
2
DTZ absent, default time-zone information used by tzset().
9.1
1
D interpretation of null initial working directory field in user database.
9.1
2
D system default value for null initial user program field.
9.2.1.1.3
1
D,Nreturn pointer from getgrgid() possibly overwritten.
9.2.1.1.4
2
RD,Nerror conditions detected for getgrgid().
9.2.1.2.3
1
D,Nreturn pointer from getgrnam() possibly overwritten.
9.2.1.2.4
2
RD,Nerror conditions detected for getgrnam().
9.2.2.1.3
1
D,Nreturn pointer from getpwuid() possibly overwritten.
9.2.2.1.4
2
RD,Nerror conditions detected for getpwuid().
9.2.2.2.3
1
D,Nreturn pointer from getpwnam() possibly overwritten.
9.2.2.2.4
2
RD,Nerror conditions detected for getpwnam().
10.1
1
D interface to format-creating and format-reading utilities.
10.1
2
D,N media format and frames on the media in which the data appears.
10.1.1
1
D,N tape contents after two zero-filled end-of-archive indicator blocks.
10.1.1
2
D,N encoding used for names outside the portable filename character set.
10.1.1
3
D details on procedures for handling input of invalid file names.
10.1.1
4
D,N format-reading utility details on mode bits not in POSIX.1.
10.1.1
5
D,N typeflag field settings of CHARTYPE, BLKTYPE, or FIFOTYPE.
10.1.1
6
D,N devmajor and devminor fields.
10.1.2.1
1
D,Nvalues for the c_dev and c_ino fields.
10.1.2.1
2
Dcharacter or block special files contained in c_rdev.
10.1.2.2
3
Ddetails on procedures for handling input of invalid file names.
10.1.2.4
4
D,Nvalue of c_filesize for special files other than FIFO, directory, trailer.
10.1.2.4
5
D,Ncontents of bytes in last block following ``TRAILER!!!''.
10.1.2.5
6
D,Nstore/extract file types other than C_ISDIR, C_ISFIFO, C_ISREG.
10.1.3
7
D file to read as next file after end-of-file or end-of-media condition.

APPENDIX B Certificate of Validation Application Form

Client

Name: ____________________________________

Address: ____________________________________

Implementation Tested

Supplier: Vendor's name who supplied the tested operating system Product: Identification of operating system tested

PCD: POSIX.1 Conformance Document identification

System Tested

Type: Native, Hosted, Co-operating-Hosted, or Co-operating

Native, Host, or Target Computer System:

Supplier: Vendor's name

Product: Identification RAM CPUs

Disk Controller: Identification

Identification of devices on disk controller

Terminal Controller: Identification

Identification of devices on terminal controller

Host and/or Development Operating System (If applicable)

Supplier: Vendor's name

Product: Identification

Development Computer System (If applicable)

Supplier: Vendor's name

Product: Identification

Compiler Information

C Compiler Supplier: Vendor's name

C Compiler Product: Identification

AFTL Name & Number: ____

NVLAP Signatory: _____________________________ Date: ________

____________________

This Appendix represents a sample of the actual form. The actual form is provided on The Open Group web site http://www.opengroup.org/testing/fips/Templates.

APPENDIX C CERTIFICATE OF VALIDATION

This Certificate of Validation verifies that the product identified below has been tested using the Official POSIX Conformance Test Suite (NIST FIPS 151-2 PCTS) for the Federal Information Processing Standards Publication 151-2 (NIST-PCTS:151-2, mm/dd/yr) and that the test results obtained have been validated by The Open Group. The Testing Laboratory was (Name_of_Lab) (status of lab if AFTL).

IMPLEMENTATION TESTED

Supplier: Vendor's name who supplied the validated software product

Product: Identification of system tested

PCD: POSIX.1 Conformance Document Identification

Primary Conditional Features:

General Terminal Interface Devices NOT Provided by Product

Mountable File System Supported by Product

Modem Control NOT Provided by Product

Appropriate Privileges Supported by Product

SYSTEM TESTED:

Computer Hardware Supplier: Vendor's name

Computer Hardware Product: Identification of native implementation

Disk Controller: Identification

Terminal Controller: Identification

C Compiler Supplier: Vendor's name

C Compiler Product: Identification




__________________

For The Open Group Date

Additional information is available from The Open Group on conditional features, configuration details, and granted interpretation of test results codes(if appropriate).

APPENDIX D Sources of Documents

American National Standards Institute (ANSI), 1430 Broadway, New York, NY 10018, telephone 212/354-3300, order FAX 212/302-1286, information FAX 212/398-0023.

Institute of Electrical and Electronics Engineers (IEEE), 345 East 47th Street, New York, NY 10017-2394, telephone 212/705-7900, Standards Orders 800/678-4333.

National Institute of Standards and Technology (NIST), Information Technology Laboratory, NIST POSIX Certification Authority, Bldg 820 Room 517, Gaithersburg, Md 301-975-3276, FAX

National Technical Information Service (NTIS), 5285 Port Royal Road, Springfield, VA 22161, telephone 703/487-4650, FAX 703/321-8547.

National Voluntary Laboratory Accreditation Program (NVLAP), National Institute of Standards and Technology, Bldg 820 Room 282,Gaithersburg,MD 20899, telephone 301/975-4016, FAX 301/926-2884.

The Open Group, Apex Plaza, Forbury Road, Reading, Berkshire, RG1 1AX, England

APPENDIX E NIST FIPS 151-2 PCTS INTERPRETATION REQUEST FORM.

Only Sections A and B of this form are filled out when filling a request. The remaining sections are for X/Open use only.

SECTION A - ORIGINATOR DETAILS

Please insert your details below

Applicant name:

AFTL name:

Mailing address:

Telephone number:

Fax number:

email address;

SUT DETAILS

Please insert the System Under Test details below

Computer type:

Computer Model

Operating system name:

Operating System Issue:

Operating System Version:

REQUEST DETAILS

Please insert a unique reference number for this request to the following line. This helps us discuss the request with you.

Your reference:

Please insert today's date to the following line. Please use ISO format. For example 1998 Jan 23

Date:

SECTION B - TEST RESULT DETAILS

Please insert the NIST PCTS version number to the following line.

Version:

Please insert the test(s) involved to the following line (please be precise and

unambiguous)

Test reference:

INTERPRETATION REQUEST RATIONAL

The possible reasons for an interpretation to be granted and associated codes are:-

Reason Code
POSIX.1_EXTENSIONtest suite deficiency
PCD_DOCUMENTEDtest suite deficiency
PCTS_FAILUREtest suite deficiency
POSIX.1_FAILUREpermanent interpretation.
POSIX.3_FAILUREpermanent interpretation.
POSIX_VERSION_UPDATE permanent interpretation.

Please insert the request reason code to the following line.

Application Reason Application Code

If you believe the reason for this request is exactly the same as that stated in another request granted by X/Open, please insert the granted request number to the following line. Otherwise leave the following line unchanged.

Previous granted Request identification

Please include output from a test run supporting this request between the lines below. Output for every test case and test number is normally require



Please include your justification why the request should be granted and any supportive information available between the lines below.



If more than one test case (testset) is being reported please include a complete list of the test cases (testsets) and associated test numbers in this section.

If you wish to, you may include a code change to the test suite that gets around the deficiency between the lines below. This is optional.



MAKE NO CHANGES BELOW THIS LINE WHEN SUBMITTING A REQUEST


Section C - Comments on Requests - The Open Group use only





Section D - Decision - The Open Group use only

APPENDIX F Summary of differences between FIPS 151-2 testing using the NIST PCTS, and The Open Brand

Issue
FIPS 151-2 (PCTS)
The Open Brand
Test SuitesNIST PCTS only VS* series of test suite
Authorized version 6 month overlap rule6 month overlap rule
System Resources required FIPS 151-2 only + 'C' XPG4 Base
Obtained fromNIST/ITL The Open Group
License feesNone Contact The Open Group Sales
SupportThe Open Group (no fee) The Open Group support contract
Test labsAccredited third party laboratory only First or third party, accredited or not.
Application fee$1000 (if applicable) Contact The Open Group Sales
Discount for accredited lab N/A50%
RoyaltiesNone Contact The Open Group Sales
Interpretation template See this document See The Open Group web site
Reference interpretations Not permittedPermitted
Temporary WaiversN/A If granted as MSF
Temporary Interpretations N/AIf granted in lieu of IEEE
OthersPINS and TSD only All
Certificate supplied To AFTLTo client direct
Certificate lifeIndefinite One year
Trade Mark License Not requiredRequired
referenced environment N/A specific platformBinary family
Software versionSpecific version range of versions.