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
4.2. FIPS 151-2 Conformance Document Audit
4.2.2. Example of a PCD.1 Audit Procedure
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.7. Collection and Submission of Certification Report
6.8. Certificate of Validation
7.2. POSIX.1 Unspecified Features
7.3. FIPS 151-1 and FIPS 151-2 Certificates of Validation
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
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.
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.
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. .
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:
Four reports are provided by the NIST-PCTS:151-2.
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.
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.
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.
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.
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:
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.
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
This section specifies the procedures to be followed, when a Certificate of FIPS 151-2 Validation from The Open Group is desired.
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.
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.
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:-
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.
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.
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.
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.
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.
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.
To request a Certificate of Validation for FIPS 151-2 an applicant must provide to The Open Group the following items:
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
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.
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''.
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.
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.
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.
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.
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:
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.
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.
D | name, number, and date of applicable POSIX.1 standard | |||
D,N | international software standards | |||
NA->N | C-language differences from C Standard | |||
D | version of the C Standard supported | |||
NA->N | interface differences from C Standard | |||
NA->N | language binding differences from C Standard | |||
D,d | associating appropriate privileges with a process | |||
RD,N | character special files other than terminal device files | |||
D,N | structures of character special files | |||
RD,N | other file types | |||
D,N | additional criteria to assign process to file group class | |||
D | parent process ID assigned after parent ended | |||
D | interpretation of pathname that begins with two slashes | |||
D,N | resources returned when process terminates | |||
D | restrictions of interfaces on read-only file systems | |||
RD,N | effective GID returned by getgroups() | |||
RD,N | extended security controls | |||
RD,N | additional and alternate file access controls | |||
D,N | disabling alternate mechanism and chmod() | |||
D,N | additional time-related update specifications | |||
D,N | additional time-related update specifications | |||
D,N | updating time-related fields | |||
RD,N | additional errors | |||
D | reliable detection of [EFAULT] | |||
D | maximum file size allowed | |||
RD,N | additional type symbols ending in ``_t'' | |||
RD,N | other characters used for environment variable names | |||
RD,N | additional feature test macros | |||
D | limit for {NGROUPS_MAX} in <limits.h> | |||
D | run-time invariant values in <limits.h> | |||
D | changeable values in <limits.h> | |||
D | values {_POSIX_JOB_CONTROL}, {_POSIX_SAVED_IDS} | |||
RD,N | value of {_POSIX_CHOWN_RESTRICTED} in <unistd.h> | |||
RD,N | value of {_POSIX_NO_TRUNC} in <unistd.h> | |||
RD,N | value of {_POSIX_VDISABLE} in <unistd.h> | |||
RD | {_POSIX_CHOWN_RESTRICTED} value in <unistd.h> | |||
RD | {_POSIX_NO_TRUNC} value in <unistd.h> | |||
RD | {_POSIX_VDISABLE} value in <unistd.h> | |||
RD,N | sharing open directory streams between parent and child | |||
D,N | inheritance of process characteristics for fork(). | |||
RD,N | [ENOMEM] detection for fork(). | |||
D | execlp() or execvp() results on search without PATH. | |||
D,N | inheritance of process characteristics for exec elements. | |||
D,N | st_atime marked for update when exec fails. | |||
RD,N | execution of irregular files. | |||
RD,N | [ENOMEM] detection exec. | |||
D,N | order reporting status for two or more child processes. | |||
D,N | additional circumstances for reporting status. | |||
D,N | status value provided by wait() or waitpid() is [EINTR]. | |||
NA->N | result type for function _exit(). | |||
D | parent process ID assigned to child of terminated process. | |||
NA->N | support of {_POSIX_JOB_CONTROL} signals. | |||
RD,N | additional signals supported. | |||
D,N | action taken on blocked signal when action is SIG_IGN. | |||
D | signal delivered more than once if another signal is pending. | |||
D,N | delivery of multiple pending signals to process. | |||
D | details outside of POSIX.1 on generating signals. | |||
D,N | SIGFPE, SIGILL, or SIGSEGV signal ignored. | |||
D,N | action taken for SIGCHLD to SIG_IGN. | |||
D,N | action SIGFPE/SIGILL/SIGSEGV not from kill()/raise(). |
D,N | caught SIGCHLD signal and unwaited terminated child process. | |||
D,N | interrupted unsafe function calls an unsafe function. | |||
RD,N | send signals to processes of another user ID. | |||
D,N | excluded set of system processes when pid is 0. | |||
D,N | behavior of kill() when pid is -1. | |||
D,N | excluded set of system processes when pid is negative but not -1. | |||
D,N | restrictions on sending of non-POSIX.1 signals. | |||
D,N | object of type sigset_t not initialized but pointer to object supplied. | |||
RD,N | [EINVAL] detection for sigaddset(). | |||
RD,N | [EINVAL] detection for sigdelset(). | |||
RD,N | [EINVAL] detection for sigismember(). | |||
D,N | action taken by sigaction() when established by signal(). | |||
D,N | setting action to SIG_DFL for signal that cannot be ignored. | |||
D,N | SIGFPE, SIGILL, or SIGSEGV generated while blocked. | |||
RD,N | error conditions detected for sigpending(). | |||
D,N | SIGALRM generated during sleep() is ignored or blocked. | |||
D,N | SIGALRM is blocked from delivery. | |||
D,N | SIGALRM is not blocked or ignored. | |||
D,N | details (time, action, signal mask) SIGALARM interrupting sleep(). | |||
D,N | sleep() interrupted and siglongjmp() or longjmp() called. | |||
RD | appropriate privileges to change real, effective, saved setuids. | |||
RD | appropriate privileges to change real and effective group IDs. | |||
D,N | array entries and returned value from getgroups(). | |||
D,N | return value from getlogin() possibly overwritten. | |||
S->D,N,d | error conditions detected for getlogin(). | |||
NA->N | support for setpgid(). | |||
D | format of struct utsname members. | |||
RD,N | error conditions detected for uname(). | |||
RD,N,d | error conditions detected for time(). | |||
D,N | return value from times() overflow range of type clock_t. | |||
RD,N,d | error conditions detected for times(). | |||
D,N | return value from getenv() possibly overwritten. | |||
RD,N,d | error conditions detected for getenv(). | |||
D,N | return value from ctermid() possibly overwritten. | |||
RD,N,d | error conditions detected for ctermid(). | |||
D,N | return value from ttyname() possibly overwritten. | |||
RD,N,d | error conditions detected for ttyname(). | |||
RD,N,d | error conditions detected for isatty(). | |||
D,N | additional configuration system variables. | |||
D,N | internal format of directories. | |||
D,N | size of array d_name. | |||
D,N | file removed or added after opendir(). | |||
RD,N | [EMFILE] detection for opendir(). | |||
RD,N | [ENFILE] detection for opendir(). | |||
D,N | return value from readdir() possibly overwritten. | |||
D,N | readdir() buffers directory entries per read operation. | |||
D,N | using directory stream after exec type function call. | |||
D,N | parent and child call readdir(). | |||
D,N | passing a closed dirp argument to readdir(). | |||
RD,N | [EBADF] detection for readdir(). | |||
NA->N | result type for readdir(). | |||
D,N | removing and adding entries to a directory. | |||
D,N | passing a closed dirp argument to rewinddir() | . | ||
D,N | child and parent processes both using readdir() and rewinddir(). | |||
D,N | accessibility of object type DIR after call to closedir(). | |||
D,N | passing a closed dirp argument to closedir(). | |||
RD,N | [EBADF] detection for closedir(). | |||
D,N | behavior of getcwd() when buf is a NULL pointer. | |||
D,N | contents of buffer passed to getcwd() after an error. | |||
RD,N | [EACCES] detection for getcwd(). | |||
D,N | call to open() on a FIFO with O_RDWR set. | |||
D | group ID of new file set to group ID of its directory. |
D,N | open() with O_CREAT and bits other than mode bits are set. | |||
D,N | open() with O_EXCL and O_CREAT not set. | |||
D,N | block or character supporting nonblocking and O_NONBLOCK set. | |||
D,N | path not a block, character, or FIFO file and supports nonblocking. | |||
D | O_TRUNC on file types other than regular, FIFO, or terminal files. | |||
D,N | open() with O_TRUNC and O_RDONLY set. | |||
D | bits other than file permission bits in umask() argument. | |||
RD,N,d | link() across file systems. | |||
RD,N | appropriate privileges to link to a directory. | |||
RD,N,d | link() to directory. | |||
RD,N | access permission to access existing file for link() to succeed. | |||
D | effect of mkdir() of bits other than permission bits set in mode. | |||
D | group ID of new file set to group ID of its directory. | |||
D | effect of mkfifo() of bits other than permission bits set in mode. | |||
D | group ID of new file set to group ID of its directory. | |||
D | appropriate privileges for unlinking directories. | |||
RD,N | support for unlink() on directories. | |||
RD,N | [EBUSY] detection for unlink(). | |||
RD,N | rmdir(path) succeeds and path is root or current directory. | |||
RD,N | rmdir(path) fails and path is root or current directory. | |||
RD,N | [EBUSY] detection for rmdir(). | |||
RD,N,d | requires write permission to rename directory. | |||
RD,N | [EBUSY] detection for rename(). | |||
D,N | usage of field st_size in structure returned by stat() and fstat(). | |||
D,N | Ors bits other than those specified into the st_mode field. | |||
D,N | additional/alternate file access control mechanisms cause stat() fail. | |||
D,N | additional/alternate file access control mechanisms cause fstat() fail. | |||
RD,N | appropriate privileges to override file access control mechanism. | |||
D,N | appropriate privileges none of the execute bits for path are set. | |||
RD,N | [EINVAL] detection for access(). | |||
RD,N | appropriate privileges to change file mode. | |||
RD,N | ignore S_ISUID or S_ISGID bits. | |||
D | effect of file descriptors for files open at chmod() time. | |||
RD,N | appropriate privileges to change file owner. | |||
RD,N | effect of S_ISUID and S_ISGID bits on the file. | |||
RD,N | [EINVAL] detection for chown(). | |||
D,N | additional members of utimbuf structure. | |||
D,N | additional configurable pathname variables | |||
D,N | association of with other than a terminal file | |||
D,N | association of with file types other than a directory | |||
D,N | association of with file types other than pipe, FIFO, directory | |||
RD,N | [EINVAL] detection for pathconf() | |||
RD,N | [EACCESS] detection for pathconf() | |||
RD,N | [ENAMETOOLONG] detection for pathconf() | |||
RD,N | [ENOENT] detection for pathconf() | |||
RD,N | [ENOTDIR] detection for pathconf() | |||
D,N | association of with other than a terminal file | |||
D,N | association of with file types other than a directory | |||
D,N | association of with file types other than pipe, FIFO, directory | |||
RD,N | [EBADF] detection for fpathconf() | |||
RD,N | [EINVAL] detection for fpathconf() | |||
D,N | when close() is interrupted by a signal | |||
D,N | value of file offset after read() on file not capable of seeking | |||
D | read() interrupted after reading some data | |||
D | result of subsequent reads after read() returns end-of-file | |||
D | read() with value greater than {SSIZE_MAX} | |||
D,N | additional conditions for detecting [EIO] for read() | |||
D,N | write() when nbyte is zero and not a regular file | |||
D,N | value of file offset after write() on file not capable of seeking | |||
D | write() interrupted after writing some data | |||
D | write() with value greater than {SSIZE_MAX} | |||
D,N | additional conditions for detecting [EIO] for write() |
D,N | additional file status flags for F_SETFL for fcntl() | |||
D,N,d | advisory record locking for files other than regular files | |||
D,N | fcntl() for file locking when l_len is negative | |||
RD,N | [EDEADLK] detected for fcntl() | |||
D | behavior of lseek() on devices incapable of seeking | |||
D | device types supported by the general terminal interface. | |||
D,N | terminal has foreground process group when. | |||
D | session leader without a controlling terminal. | |||
D,N | close of last file descriptor associated with controlling terminal. | |||
D,N | session leader can reacquire a controlling terminal after. | |||
D,N,d | after controlling process terminates access. | |||
D | how controlling terminal for a session is allocated by session leader. | |||
D,N | {MAX_INPUT} limit. | |||
D,N | {MAX_CANON} limit. | |||
D,N | read() response when MIN is greater than {MAX_INPUT}. | |||
RD,N,d | buffers write output to terminal device. | |||
RD,N,d | START and STOP special characters can be changed. | |||
D,N | two or more special characters received which have same value. | |||
D,N | single bytes other than ... or multibytes have special meaning. | |||
D,N | EOF is returned or [EIO] is detected when modem disconnects. | |||
D,N | additional members of termios structure. | |||
D | break condition for non-asynchronous data transmissions. | |||
D | conditions under which START and STOP are transmitted. | |||
D | initial input control value after open() is specified. | |||
D | processing of output data by OPOST. | |||
D | initial output control value after open() is specified. | |||
D,N | non-asynchronous serial connection ignoring hardware modes. | |||
D | initial hardware control value after open() is specified. | |||
D,N | echoing details when no character exists to erase. | |||
D,N | details on erasing a line when ECHOK and ICANON are set. | |||
D,N,d | details on operation when IEXTEN is set. | |||
D | interaction of IEXTEN set with ICANON, ISIG, IXON, or IXOFF. | |||
D | initial local control value after open() is specified. | |||
NA->N | implementation ignores. | |||
D,N | value of NCCS. | |||
D,N,d | character values in c_cc indexed by START and STOP are ignored. | |||
D | initial values of all control characters. | |||
RD,N | error detection cfgetospeed(). | |||
RD,N | cfsetospeed() details on attempting to set unsupported baud rate. | |||
RD,N | error conditions detected for cfsetospeed(). | |||
RD,N | error conditions detected for cfgetispeed(). | |||
RD,N | cfsetispeed() returns error for unsupported baud rate. | |||
RD,N | error conditions detected for cfsetispeed(). | |||
RD,N,d | input and output baud rates that differ. | |||
D | period of time break signal is sent when tcsendbreak(). | |||
D,N | details on non-asynchronous data transmission and tcsendbreak(). | |||
NA->N | support for tcgetpgrp(). | |||
NA->N | support for tcsetpgrp(). | |||
NA->N | differences from C Standard. | |||
RD,N | other locales other than ``C''. | |||
D,N | string returned from setlocale() when locale is a NULL pointer. | |||
D,N | additional categories supported for setlocale(). | |||
D | LC_ALL not set or set to the empty string. | |||
NA->N | result type for longjmp(). | |||
NA->N | result type for clearerr(). | |||
NA->N | result type for rewind(). | |||
NA->N | result type for setbuf(). | |||
NA->N | result type for srand(). | |||
NA->N | result type for calloc(), free(), malloc(), and realloc(). | |||
NA->N | result type for abort(). | |||
NA->N | result type for exit(). | |||
NA->N | result type for bsearch() and qsort(). |
D | details of TZ environment variable beginning with a colon. | |||
D,N | meanings of any characters except. | |||
D,N | behavior of offset field of TZ environment variable. | |||
RD,N | error conditions detected for fileno(). | |||
D,N | additional values for the fdopen() type argument. | |||
RD,N | error conditions detected for fdopen(). | |||
D,N | details involving two or more handles. | |||
D,N | state of open file description when active handle not accessible. | |||
D,N | details on rules when file handles are not followed. | |||
D | conditions when applications will see all input exactly once. | |||
D,N | ftell() result when stream oppened in append mode. | |||
NA->N | result type for siglongjmp(). | |||
NA->N | result type for tzset(). | |||
D | TZ absent, default time-zone information used by tzset(). | |||
D | interpretation of null initial working directory field in user database. | |||
D | system default value for null initial user program field. | |||
D,N | return pointer from getgrgid() possibly overwritten. | |||
RD,N | error conditions detected for getgrgid(). | |||
D,N | return pointer from getgrnam() possibly overwritten. | |||
RD,N | error conditions detected for getgrnam(). | |||
D,N | return pointer from getpwuid() possibly overwritten. | |||
RD,N | error conditions detected for getpwuid(). | |||
D,N | return pointer from getpwnam() possibly overwritten. | |||
RD,N | error conditions detected for getpwnam(). | |||
D | interface to format-creating and format-reading utilities. | |||
D,N | media format and frames on the media in which the data appears. | |||
D,N | tape contents after two zero-filled end-of-archive indicator blocks. | |||
D,N | encoding used for names outside the portable filename character set. | |||
D | details on procedures for handling input of invalid file names. | |||
D,N | format-reading utility details on mode bits not in POSIX.1. | |||
D,N | typeflag field settings of CHARTYPE, BLKTYPE, or FIFOTYPE. | |||
D,N | devmajor and devminor fields. | |||
D,N | values for the c_dev and c_ino fields. | |||
D | character or block special files contained in c_rdev. | |||
D | details on procedures for handling input of invalid file names. | |||
D,N | value of c_filesize for special files other than FIFO, directory, trailer. | |||
D,N | contents of bytes in last block following ``TRAILER!!!''. | |||
D,N | store/extract file types other than C_ISDIR, C_ISFIFO, C_ISREG. | |||
D | file to read as next file after end-of-file or end-of-media condition. |
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.
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).
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
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_EXTENSION | test suite deficiency |
PCD_DOCUMENTED | test suite deficiency |
PCTS_FAILURE | test suite deficiency |
POSIX.1_FAILURE | permanent interpretation. |
POSIX.3_FAILURE | permanent 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
Test Suites | NIST PCTS only | VS* series of test suite |
Authorized version | 6 month overlap rule | 6 month overlap rule |
System Resources required | FIPS 151-2 only + 'C' | XPG4 Base |
Obtained from | NIST/ITL | The Open Group |
License fees | None | Contact The Open Group Sales |
Support | The Open Group (no fee) | The Open Group support contract |
Test labs | Accredited 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/A | 50% |
Royalties | None | Contact The Open Group Sales |
Interpretation template | See this document | See The Open Group web site |
Reference interpretations | Not permitted | Permitted |
Temporary Waivers | N/A | If granted as MSF |
Temporary Interpretations | N/A | If granted in lieu of IEEE |
Others | PINS and TSD only | All |
Certificate supplied | To AFTL | To client direct |
Certificate life | Indefinite | One year |
Trade Mark License | Not required | Required |
referenced environment | N/A specific platform | Binary family |
Software version | Specific version | range of versions. |