| Question # |
Date |
Posted by | Category |
| 66 |
2005-10-20 15:06:07 |
Chad Blomquist |
editorial |
| Question: |
| Section 5.4.2 states: "All certificates issued to support PIV Card authentication shall be issued under" the Common Policy. I assume that this statement is referring to all PIV-defined keys and their corresponding certificates. However, this statement could be interpreted to mean only the card authentication key and perhaps the PIV authentication key must follow the Common Policy (i.e., not the encryption key b/c it's not used for "PIV Card authentication"). Please clarify. |
|
| Answer: |
| The intent of this statement is that all certificates in the PIV data model shall be issued under the Common Policy. |
|
| 68 |
2005-11-14 15:23:29 |
Ketan Mehta |
editorial |
| Question: |
PIV mandates the use of the Federal Common Certificate Policy. The CCP defines the appropriate uses for that certificate (authentication, signature, encryption, etc.). However, some certificates may be appropriate or inappropriate for certain tasks within these confines.
For instance: in a procurement office financial transactions could be digitally signed with the digital signature key. Perhaps the CA is at a medium assurance level and its certificates can only be trusted to sign $10K transactions (I made that number up). Another agency has a CA at high assurance and its certificates are trusted to sign $100K transactions. Another agency has to sign $1M transactions every day and must have assurance higher than even the “high” level of assurance.
Is this addressed by any policies under the Federal PKI? I could imagine that it could be solved by either adding additional CPs to the certificate or by entering into relying party agreements between the CAs and relying parties. The use of additional CPs raises interoperability issues and relying party agreements don’t seem feasible since the relying party could be anyone in the Federal PKI. Neither seem to be covered in FIPS 201 or the Common Cert Policy.
|
|
| Answer: |
There is an optional field in certificates, called subject directory attributes, that can be used to hold authorities, privileges, attributes, or anything you could put in a directory. In principle, attribute certificates could also be used. Current PKI guidance generally seems to go against use of identity certificates to hold attributes because it means a big increase in revocations. However, current policy does not prohibit them.
Attribute certificates seem to be good in principle but is rarely used in practice. Attributes are more often put in a secure (meaning authenticated) LDAP server so that the certificates are used to establish the authenticity of peer entities performing high value business transactions. The LDAP server provides information to one entity about the attributes of the peer entity. Perhaps a pointer to the definitive LDAP server for an individual could be inserted in the cert, perhaps in the SDA if there is not already an extension for that. |
|
| 71 |
2005-10-18 08:53:57 |
Erika McCallister |
editorial |
| Question: |
For the purposes of this question we will assume that the key management keys encrypt and decrypt documents, not symmetric keys.
At any given time a user may have at most one key management key pair. When these keys expire and are renewed they are replaced by a new key management key pair. In order to read documents encrypted under the old public key you need the old private key.
I see two ways to facilitate this, both with big problems:
1) Old keys must be stored on the card (in addition to a database somewhere). Unfortunately the old keys can't be stored within the PIV space because they have no assigned key reference value. If the keys are in a separate undefined non-PIV space I expect many vendor-specific spaces will crop up, recreating the same old vendor-specific problems PIV was intended to solve.
2) Before his old keys expire the user must manually decrypt data encrypted under old keys and re-encrypt under new keys. This is annoying at best for individual files on a desktop, but may not possible for data residing within other applications (e.g., encrypted email within Oulook).
Perhaps there is another approach I have not thought of. Has this been addressed?
|
|
| Answer: |
SP 800-73 section 1.9.4 provides a description of the optional key management key pair and asserts that the primary purpose of the key management key pair is for confidentiality in the management of keys, such as during key transport. SP 800-73 also explicitly states that “this key pair is escrowed by the issuer for key recovery purposes.” Thus, the scenario you described should not arise.
However, since the key management key and certificate were created without ties to a particular application, it is conceivable that the key management key pair could be used for encryption purposes with a PC application. Another option would be to load an additional card application onto the card that interacts with a PC application for encryption purposes. Both of these options are outside of the PIV infrastructure. Thus, with either case, specific questions arising from the use of asymmetric keys in these applications, which are outside the scope of FIPS 201, should be decided at the agency level. Agencies may use SP 800-57 Part 2 to assist them in the development of key management policies related to the use of these additional applications. |
|
| 91 |
2005-10-20 15:17:38 |
Chad Blomquist |
corrections |
| Question: |
| Could you please explain why the minimum contactless command requirements was changed to 9 byte select and get data. This would disqualify DESFire which was the main contactless IC that most vendors were developeing support for. The change does not seem to add any significant advantage but causes a significant change in the possible credential that could be used. |
|
| Answer: |
The PIV card application specification was designed to provide maximum interoperability across agencies. The resulting design goals include technology neutrality, full compliance with ISO standards, a unified card interface, and internationally recognized namespaces for PIV data objects.
The PIV specifications cannot achieve these goals while being specifically tailored to one commercial product. It is also important to note that this concern was not raised during any of the public comment periods on the PIV specifications. |
|
| 100 |
2007-05-03 15:35:47 |
Hildegard Ferraiolo |
editorial |
| Question: |
| Does the [FIPS 201 Part 1] self-certification have to be signed by the agency head? Or can it be delegated to the executive with management oversight of HSPD-12 implementation? |
|
| Answer: |
Section 2.3 of FIPS 201 reads, in part, "The issuance and maintenance process used when issuing credentials shall be accredited by the department as satisfying the requirements below and approved in writing by the head of the Federal department or agency."
|
|
| 102 |
2005-10-19 09:32:30 |
Erika McCallister |
editorial |
| Question: |
Some of the specified ECC algorithms are patented by CertiCom. The NSA has negotiated a special deal with CertiCom that covers vendors developing software covered by CertiCom's patents for deployments into U.S. federal, state and local governments, plus select additional national governments. We find this approach to be at odds with the U.S. government's policy of switching from GOTS to COTS products... We request clarification of the scope of the NSA-CertiCom agreement. Specifically, does it apply (extend) to COTS products intended for commericial and basic robustness government deployments?
|
|
| Answer: |
NSA has licensed the rights to 26 patents held by Certicom Inc. covering a variety of elliptic curve (EC) technology. Under the license, NSA has a right to sublicense vendors building equipment or components in support of US national security interests. The NSA will not grant sublicenses to vendors who intend to sell their equipment for use in other areas such as the entertainment industry or general corporate security. These are not considered national security applications and are not eligible for the sublicense. To determine if your use of patented EC technology qualifies for a sublicense as a U.S. national security interest, please contact the Business Affairs Office of the NSA/CSS Commercial Solutions Center. For further information visit: http://www.nsa.gov/ia/industry/cep.cfm.
Vendors may also contact Certicom directly to inquire about the NSA sublicense:
http://www.certicom.com
|
|
| 103 |
2006-02-27 15:10:43 |
Donna Dodson |
editorial |
| Question: |
Both X.509v3 CRLs and OCSP are mandatory certificate status mechanisms. Can you provide additional guidance (scenarios) on use of CRLs and OCSP? For example, is there external policy that determines whether or not the more expensive OCSP mechanism is used? Must OCSP always be tried first, with CRLs being considered a fall-back mechanism? FIPS 201 describes OCSP as "supplementary to CRLs," but it's not clear when/why OCSP would be invoked after a CRL is checked. Is it proper to assume that OCSPs or CRLs will incorporate digital signatures, and as such, does that mean that the government PKI mechanisms will be changed to support ECC as well? How will this rollout be timed?
|
|
| Answer: |
The relying party determines which status mechanism to use, based on the resources that are available in its environment. We might expect a physical access system for visitors to rely on OCSP responses, while an intra-agency application might functioon more efficiently using CRLs. Application developers may select the apporpiate mechanism.
There is no scenario where a relying party is expected to check both the CRL and request status from an OCSP server. The same information should be available to a relying party using either mechanism.
Both CRLs and OCSP responses are digitally signed, and the FPKI will support ECC in addition to the RSA algorithms identified in 800-78. Relying parties that wish to maximize interoperability will need to verify signatures from both families. Systems with a limited community of users may choose to rely on a more limited set. |
|
| 155 |
2005-11-16 12:40:32 |
Ketan Mehta |
editorial |
| Question: |
| Were comments on the standard sought from the public and other federal agencies? |
|
| Answer: |
| DoC/NIST and OMB held several public meetings to discuss the technical and policy issues related to the standard. DoC/NIST released the draft standard on November 8, 2004, and on Dec. 20, 2004, released two drafts of supporting technical documents. Public meetings were held on Oct. 7 and 8, 2004; Nov. 18, 2004; and Jan. 19, 2005. DOC/NIST worked closely with other federal agencies, including OMB, the Office of Science and Technology Policy, and the Departments of Defense, State, Justice, and Homeland Security, as well as private industry. As a result, comments were received from more than 80 organizations and individuals. These comments were carefully considered and led to many changes in the standard. (Comments are available at http://csrc.nist.gov/piv-project/FIPS201-Public-Comments.html) |
|
| 156 |
2007-09-27 08:28:58 |
Hildegard Ferraiolo |
editorial |
| Question: |
| Which agencies are responsible for implementing the directive? |
|
| Answer: |
| Four federal agencies have specific responsibilities for implementing this directive: Department of Commerce, Office of Management and Budget (OMB), General Services Administration (GSA), and Office of Personnel Management (OPM). DoC’s NIST is establishing standards, recommendations, guidelines, and conformance tests for components of the PIV system. OMB is responsible for overseeing agency implementation of the directive and will develop implementation guidance for federal agencies. GSA is responsible for assisting agencies in procuring and operating PIV sub-systems such as card and biometric readers. OPM is responsible for assisting agencies in authenticating and vetting applicants for the PIV card. |
|
| 157 |
2005-11-16 12:42:57 |
Ketan Mehta |
editorial |
| Question: |
| What must agencies do and when in order to meet HSPD-12 and FIPS 201 requirements? |
|
| Answer: |
Key activities that each agency must perform include—
• establish a program to ensure that the identification issued by their organization meets the PIV standard (within four months of the issuance of the standard);
• identify any additional applications (beyond the scope of the standard) for which the standard also should be used and report them to the Assistant to the President for Homeland Security and the Director of the Office of Management and Budget (within six months of the issuance of the standard);
• comply with the first phase of the PIV standard within eight months of the issuance of the standard; and
• comply with the second phase of the PIV standard on a timetable to be established by OMB.
|
|
| 158 |
2005-11-16 14:54:08 |
Ketan Mehta |
editorial |
| Question: |
| How is security being improved? |
|
| Answer: |
The standard was designed so that compliant components and systems will provide improved security over many existing practices and systems for federal facilities and information systems—both the “identity proofing” process and technical security mechanisms.
In the PIV “identity proofing” process, government agencies must obtain and review for each applicant at least two identity documents issued by approved government entities. At least one of the documents must be a government-issued photo ID. The standard also mandates that agencies vet an applicant through an OPM background investigation process, the National Agency Check with Written Inquiries (NACI). This is not a new requirement for employees; it is new for some contractors. Government policy has required this check for all employees since the 1950s.
The technical security mechanisms include the use of smart card, cryptography, and biometrics technologies to achieve graduated levels of security for agency applications. Identity credentials are securely stored and protected on the Integrated Circuit Chip (ICC). Cryptographic key material and a Personal Identification Number (PIN) on the card provide for the protection of sensitive stored and communicated data using NIST approved algorithms. When used with the card—“something you have,” biometrics provide an additional layer of security in the form of “something you are.” The standard includes requirements to protect the privacy of PIV cardholders.
The PIV standard enhances the overall security of the system by supporting the following objectives:
• A credential is issued only to an individual whose true identity has been ascertained by the issuer.
• Only an individual with a background investigation on record is issued a credential.
• An individual is issued a credential only after presenting two identity source documents, at least one of which is a valid federal or state government issued picture ID.
• Fraudulent identity source documents are not accepted as genuine and unaltered;
• A person suspected or known to the government as being a terrorist is not issued a credential.
• No substitution occurs in the identity proofing process. More specifically, the individual who appears for identity proofing, and whose fingerprints are checked against databases, is the person to whom the credential is issued.
• No credential is issued unless requested by proper authority.
• A credential remains serviceable only up to its expiration date. More precisely, a revocation process exists such that expired or invalidated credentials are swiftly revoked.
• A single corrupt official in the process may not issue a credential with an incorrect identity or to a person not entitled to the credential.
• An issued credential is not modified, duplicated, or forged.
|
|
| 159 |
2005-11-16 14:55:46 |
Ketan Mehta |
editorial |
| Question: |
What are the primary requirements for an agency to implement FIPS 201?
|
|
| Answer: |
The FIPS 201 requires issuance of identity credentials that consist of public key infrastructure (PKI) and biometrics technology on a smart card. The high-level requirements as specified in FIPS 201, in accordance with HSPD 12, are as follows:
• identify the facilities, systems, and other applications that will use the PIV standard;
• obtain the services of an accredited PIV card issuer;
• review and revise procedures for PIV card applicants to provide acceptable identity source documents (i.e., OPM I-9) and complete PIV card application;
• obtain services for capturing biometric information as specified in the FIPS 201;
• obtain PIV card readers with biometric readers as needed;
• procure cards, readers, and PKI services conforming to FIPS 201;
• enable applications to use the PIV card; and
• operate and maintain a PIV card authentication and personal identity verification system.
|
|
| 160 |
2005-11-16 14:57:16 |
Ketan Mehta |
editorial |
| Question: |
How does FIPS 201 protect privacy?
|
|
| Answer: |
Protecting personal privacy is a core requirement of the presidential directive. Many of the requirements in the standard for hiring federal employees are based on longstanding privacy law and policy. For example, agencies are required to appoint a PIV privacy official, assess their PIV systems to ensure privacy is protected, identify information to be collected about individuals and how the information will be used, assure that systems containing personal information adhere to fair information practices, and audit systems for compliance with privacy policies and practices. Also, the Office of Management and Budget will provide additional implementation guidance for federal agencies concerning privacy.
The government will not establish a central database to track movement of employees and contractors or the systems they access. Personally identifiable information stored on the card is minimal. Personally Identifiable information such as electronic fingerprints will be cardholder protected (e.g. requires a PIN to unlock) while stored on a PIV card.
The technology on the card does not allow for tracking movement of contractors and employees while moving throughout a building. Because of the wireless capability of the PIV card, concern has been expressed that data can be inadvertently or maliciously captured. To alleviate this concern, employees will be required to keep the card in an electronically opaque sleeve when not in use to minimize the risk of unauthorized reading of data from the card without the consent of the cardholder.
|
|
| 161 |
2005-11-16 14:58:24 |
Ketan Mehta |
editorial |
| Question: |
What is the rationale behind the selection of smart card, fingerprint, and PKI technologies?
|
|
| Answer: |
The presidential directive required a standard for secure and effective identification and authentication of federal employees and contractors but did not specify how to achieve it. DoC/NIST proposed using a single form factor (credit-card-sized printable badge) containing one or more integrated circuit chips in order to create a portable means to store and process data in a secure manner. Many organizations already have adopted smart card standards and technology for identity verification. Cryptography can be used to provide data integrity and confidentiality protection for data communications and storage. A Public Key Infrastructure can provide the support system needed to deploy and protect the cryptographic keys.
Of the several potential means of personal biometric marker verification (e.g., DNA, iris scans, hand geometry, handwritten signatures, facial images, or fingerprints), fingerprints were chosen as being the least invasive and most cost-effective, reliable, repeatable, and accurate means of verification available using publicly available technology. While the best fingerprint capture, storage, and matching algorithms are still a matter of debate, NIST fingerprint experts recommended the use of two fingerprints for storage on the card as the most acceptable for inclusion in the standard. To minimize storage requirements, storage of an electronic facial image is not required but is optional. A facial image is required to be printed on the card for visual verification.
Agencies may choose to augment the minimum requirements of the standard.
|
|
| 162 |
2005-11-16 15:36:38 |
Ketan Mehta |
editorial |
| Question: |
Does FIPS 201 apply to all agencies including the smaller agencies (e.g. micro-agencies)?
|
|
| Answer: |
All federal departments and agencies and all their contractors requiring access to federal facilities and systems must comply with this standard and the specifications in the supporting documents, except that the standard shall not apply to identification associated with national security systems as defined by law. Small agencies may join with other agencies (and are encouraged to do so when cost effective) to implement and use FIPS 201 complying components and systems.
|
|
| 167 |
2005-11-16 15:43:18 |
Ketan Mehta |
editorial |
| Question: |
What documents/programs are currently available to help agencies implement FIPS 201?
|
|
| Answer: |
• NIST Special Publication 800-73 specifies PIV card interface characteristics.
• Draft NIST Special Publication 800-76 specifies PIV card biometric characteristics.
• NIST Special Publication 800-78 specifies cryptographic algorithm requirements and characteristics
• NIST Special Publication 800-79 provides guidance for PIV issuer accreditation.
• OMB provides implementation guidance on HSPD-12 in memorandum M-05-24.
• GSA memorandum of August 10, 2005 specifies the procedures for ordering goods and services in compliance with the Presidential Directive.
• NIST Special Publication 800-85 provides conformance tests for validating PIV components as complying with SP 800-73.
• Subject to funding support, NIST will provide technical assistance to support implementing and operating a PIV system that complies with FIPS 201.
|
|
| 171 |
2005-11-16 16:00:10 |
Ketan Mehta |
editorial |
| Question: |
Will PIV documents stress that Personal Identity Verification is different than access authorization and just having a PIV card or achieving identity verification should not entitle the cardholder to physical or logical access?
|
|
| Answer: |
Identification/authentication and access control are very distinct processes.
The PIV card provides a means for the cardholder to verify his or her identity by authentication of a cardholder’s PIV card, credentials, and comparison of biometric markers stored on the card with those captured from the current card holder.
The decision of who will have access to which facility or computer system is outside the scope of the standard. Each agency will continue to decide who is allowed access to their specific resources and facilities. More specifically, all cardholders will not have access to all federal buildings or information systems.
|
|
| 172 |
2005-11-16 16:21:54 |
Ketan Mehta |
editorial |
| Question: |
Will agencies maintain records of access to facilities by individuals?
|
|
| Answer: |
The standard does not address this. We anticipate that agencies will continue to maintain records, in accordance with the Privacy Act, of access to and unsuccessful attempts to access their facilities and systems as required for their security and audit needs.
|
|
| 176 |
2005-11-16 16:31:20 |
Ketan Mehta |
editorial |
| Question: |
Why is the standard divided into 2 parts?
|
|
| Answer: |
The standard is divided into two parts so agencies can make an orderly migration—in terms of both technology and "identity proofing" from their current systems to the requirements established by the standard and meet the ambitious deadlines established by the President in HSPD #12.
We first focus on the most important goal: improved security. The first part, to be implemented within eight months of the standard's issuance, focuses on security objectives, to include "identity proofing." With all agencies meeting the same security objectives, there will be a basis for trust among agencies with regard to the mutual recognition of their employee and contractor credentials.
The second part of the standard, which will take longer to implement because of the many varying electronic credential systems now in place, focuses on the common technical interoperability requirements of HSPD #12. When fully implemented, a card from one agency can be electronically recognized by any other agency so that a decision of whether to grant the cardholder access can be made.
|
|
| 177 |
2005-11-16 16:33:00 |
Ketan Mehta |
editorial |
| Question: |
What information is required to be stored on the card?
|
|
| Answer: |
Only a minimal amount of information is required to be electronically stored on the card. The PIV Card must contain only the following data:
1. Personal Identification Number (PIN)—this data is used to authenticate the cardholder to the card--in the same way a PIN is used with an ATM card. The PIN never leaves the card, and it cannot be read from the card.
2. A Cardholder Unique Identifier (CHUID)—this number uniquely identifies the individual within the PIV system.
3. Two fingerprint biometrics that are PIN protected.
4. One asymmetric cryptographic key pair used to authenticate the card to the PIV system.
The standard does not require any other personal information such as the cardholder's SSN, address, or phone number to be stored on the card. Release of biometric information and use of the private key can take place only AFTER the cardholder provides the correct PIN number. Only the Cardholder Unique Identifier is required by the standard to be available through the contactless interface.
|
|
| 179 |
2005-11-18 16:00:39 |
William MacGregor |
editorial |
| Question: |
| How can agencies assess their existing infrastructure to tell if they are FIPS 201 complaint? do you have any specific publication (like 800-53) |
|
| Answer: |
| FIPS 201 is a Federal Information Processing Standard, and therefore is itself the authoritative reference for conformance. The standard extends, however, to additional, more specific documents. The PIV infrastructure consists of three broad subsystems: the front-end subsystem, the card issuance and management subsystem, and the access control subsystem. The front-end subsystem includes PIV Cards, card readers, biometric devices, and terminal equipment. SP800-85 describes conformance tests for PIV Cards and middleware, and these are implemented by the NPIVP testing laboratories. The card issuance and management subsystem includes user enrollment workstations and equipment, the PKI infrastructure used to produce certificates, PIV workflow and records management elements, and PIV Card personalization and delivery elements. SP800-79 describes the commissioning and accreditation processes for card issuance and management subsystems. The access control subsystem includes logical and physical access control elements, such as network login and building access. Currently, there are no released NIST documents pertaining to the access control subsystem. |
|
| 203 |
2006-02-27 14:55:06 |
Donna Dodson |
editorial |
| Question: |
The FPKI Common Policy limits CA keys to a 6 year lifetime. Subscriber keys are limited to a maximum of half that (3 years). FIPS 201 allows credentials to be valid for up to 5 years. Given these facts, it seems impossible for an agency to issue a 5-year card that will not require maintenance during its existence (PIV certificate reissuance)Is this correct? Was it intentional? What are the mitigating factors here? Are there plans to change either FIPS 201 or the Common Policy to address this issue?
Thanks,
Kenner Brent
Cygnacom Solutions for the U.S State Department
202 203 7609 |
|
| Answer: |
You are correct. To use a PIV card for the maximum five years, new PKI credentials will need to be obtained. A five year certificate lifetime may result in unmanageable CRLs, and PKIs are designed to support renewal based on currently valid credentials.
We have no current plans to modify either FIPS 201 or the Common Policy. However, an agency could choose to issue smart cards every three years and align it with the PKI certificate issuance cycle. |
|
| 204 |
2006-01-11 15:54:54 |
Ketan Mehta |
corrections |
| Question: |
Figure 4-1 in Section 4.1.4 Visual Card Topography states that the upper right Reserved Area can be used once it is verified as printable by the card and/or printer manufacturer, but provides no guidance on what is recommended for this space when printing can be done.
Reverse transfer printers are recognized by card vendors as completely safe for printing over imbedded contactless chips as well as the reverse side of contact chips. Therefore it is proposed that the Reserved Area be the recommended optional position for the Agency Seal. This provides increased readability for both the identifying information in Zones 8, 10, 13 and 14 and the Agency Seal itself.
|
|
| Answer: |
| The cautionary guidance regarding the reserved area stands. Use of reverse transfer printers that are determined to be completely safe for printing over embedded contactless chips to print optional information would, therefore, be permitted. Designating the reserved area as an optional position for the Agency Seal would require a change to the FIPS. Any such change must go through the full FIPS revision process (including public review, EOP review, and Secretarial signature). |
|
| 205 |
2006-01-11 16:21:58 |
Ketan Mehta |
editorial |
| Question: |
Figures 4-1 through 4-8 in Section 4.1.4 Visual Card Topography all show or imply a 2.5 mm border between the card edges and the various data zones. This appears to be in consideration of the capabilities of direct-to-card printers and patch-type laminates.
Are organizations that have full edge-to-edge printing and laminating capability restricted from utilizing this border space when designing their card layouts and graphics? I.E. can the dimensions of the various data zones be extended all the way to their near card edges?
|
|
| Answer: |
Any changes to the dimensions of the various data zones must go through the full FIPS revision process (including public review, EOP review, and Secretarial signature). Therefore, dimensions specified in FIPS 201 stands as current standard.
|
|
| 207 |
2006-02-17 11:34:44 |
|
editorial |
| Question: |
| FIPS 201 requires that remote unlocking of a smartcard or remote re-issuance of certificates requies biometric authentication. How do you see this working? Do you see any other solutions? The agency I work for operates a medium assurance FBCA cross certified CA, if the user was given unlock codes at the in-person vetting to be used if they lock their smartcard or need certificate re-issuance, do you see that meeting FIPS 201? |
|
| Answer: |
| FIPS 201 states that a PIN may be reset if the card is locked due to exceeding number of bad PIN tries. FIPS 201 requires that the biometrics on the card be checked to ensure the card belongs to the cardholder. Updates to the card are not allowed without proper access control. Therefore, providing the user an ability to unlock the card will not meet FIPS 201 requirements. |
|
| 215 |
2006-01-31 16:22:46 |
Erika McCallister |
editorial |
| Question: |
| Does the PIV Sponsor, Registrar, PIV Card Approval and the PIV issuer have to be all different people or can one person have multiple roles? |
|
| Answer: |
The Appendix A role-based model provides an example of a proofing, registration, and issuance process that satisfies the PIV control objectives. If you choose to use this model, then each role must be performed by a different person.
FIPS 201 states that "the PIV identity proofing, registration and issuance process shall adhere to the principle of separation of duties to ensure that no single individual has the capability to issue a PIV credential without the cooperation of another authorized person." Thus, the standard states that separation of duties must occur, but it does not explicitly state how separation of duties must be implemented.
SP 800-79 provides further guidance on the certification and accreditation of PIV card issuing organizations. |
|
| 216 |
2007-12-27 09:22:49 |
Hildegard Ferraiolo |
editorial |
| Question: |
Is FIPS-201 intended to be the only system requirements issued for HSPD-12 guidelines?
What guidelines cover secure communication of user identity from the Access Control sub-system to the electronic resource? What requirements govern this authentication functionality? |
|
| Answer: |
HSPD-12 calls for the establishment of "common identification standard" for federal employees and contractors. FIPS 201 and accompanying special publications provide the standard for common identification by providing the requirements for the PIV smart card and its interfaces.
The PIV card will be used with physical and logical access control systems, which are covered by FISMA and other legislation. FISMA requires each federal agency to develop, document, and implement an agency-wide program to provide information security for the information and information systems that support the operations and assets of the agency, including those provided or managed by another agency, contractor, or other source. FIPS 199 and accompanying special publications provide further guidance for general information security.
|
|
| 223 |
2006-02-27 14:59:49 |
Donna Dodson |
editorial |
| Question: |
Does a legacy PKI issuing PIV certificates have to implement an OCSP server before January 1, 2008? Section 5.4.4 of FIPS 201 states that legacy PKIs cross certified with the FBCA at Medium-HW or High Assurance Level can continue to assert department or agency-specific policy OIDs, and have until January 1, 2008 to come under the Common Policy and assert the id-CommonHW or id-CommonAuth policy OIDs. However, section 5.4.5 of FIPS 201 states that every CA that issues PIV authentication certificates shall operate an OCSP server. Since legacy PKIs will initially be issuing PIV certificates that do not assert the id-CommonAuth policy OID, do they need begin operating an OCSP server as soon as they begin issuing PIV certificates, or can they wait until they begin issuing PIV certificates in conformance with the Common Policy?
|
|
| Answer: |
| A legacy PKI issuing PIV certificates needs to implement an OCSP server by January 1, 2008 at the latest. The OCSP server needs to be operational when the agency begins issuing certificates that assert id-CommonAuth policy OID, since these certificates are required to include the URL of the authoritative OCSP server. |
|
| 224 |
2006-02-02 10:08:04 |
|
editorial |
| Question: |
FIPS 201 A.2.8 and FIMH 2.3.3.1 & 2.3.3.3 state that upon PIV card issuance, the applicant's fingerprints should be matched against their fingerprint record in the IDMS. FIMH 2.3.2.4 states that the applicant's fingerprints should be matched against the fingerprint records in the PIV card. FIPS 201 5.3.1 and FIMH 4.6.2 & Appendix B state that either of the above is acceptable, while FIPS 201 A.2.2 states that both are required. FIMH 2.3.2.4 also contradicts itself by later suggesting that the check of the applicant's fingerprints by the PIV Issuer isn't mandatory after all.
Should the applicant's fingerprints be matched against the enrollment record, the PIV card biometrics, either, or both? Is this actually mandatory? |
|
| Answer: |
The FIPS 201 requirements dominate.
Note that Appendix A of FIPS 201 is informative rather than mandatory.
Section 5.3.1 of FIPS 201 is mandatory.
|
|
| 227 |
2006-02-17 14:49:18 |
|
editorial |
| Question: |
FIPS 201 A.2.6 and FIMH 2.3.3.2 & 2.3.3.3 require demographic information and scans of identity documents to be incorporated into the enrollment record for the IDMS, but don't specify how.
What is the format for the document scans? What is the format for the final enrollment record (which encapsulates biometric records, document scans, demographic information, etc.)? How should the final enrollment record be transmitted to the IDMS? |
|
| Answer: |
| The standards permit individual departments and agencies to select the format most appropriate to their operations. The FIMH is not normative (not mandatory). Appendix A.2 of FIPS 201 is informative, not normative (not mandatory). |
|
| 229 |
2006-02-17 14:52:14 |
|
editorial |
| Question: |
FIPS 201 A.1.1.2 and FIMH 2.3.2.3 state that if all identity source documents are verified, the PIV Registrar should record specific information for each identification source, then "sign the record and keep it on file".
Does this only apply to pen-and-paper records, or does this information need to be included in the electronic enrollment record? If the latter, do scans of the identity source documents satisfy this requirement, or does additional information need to be added to the enrollment record? If so, how? |
|
| Answer: |
| The requirement applies to both paper and electronic storage. The method is left to individual departments and agencies. If cryptographic signature processes are employed, they must conform to the requirements of NIST standards and guidelines. |
|
| 230 |
2006-10-11 12:01:12 |
Ketan Mehta |
editorial |
| Question: |
FIPS 201 4.4.1 states that in cases where no fingerprints of acceptable quality can be captured, asymmetric cryptography can be used for authentication instead of a fingerprint biometric.
Does this means that no fingerprint biometric records will be placed on the PIV card for such applicants? What about the case where only one acceptable fingerprint can be captured? If fewer than two fingerprint biometric records can appear on the PIV card, what special accommodations need to be made during the registration, issuance, and access control scenarios for these applicants? |
|
| Answer: |
| As stated in SP 800-76, if good quality fingerprint is not collected in four tries, then select the best available set. The collected fingerprint biometric template record shall be placed on the PIV card. FIPS 201 states that if acceptable quality can not be captured, use alternative mechanism for authentication. |
|
| 231 |
2006-02-17 15:18:18 |
|
editorial |
| Question: |
FIMH 5.1.5.2 & 5.1.5.3 suggest that some biometric other than fingerprints should be collected by the PIV Issuer and stored on the PIV card if fingerprints are unavailable, but no specific alternative is offered, and this requirement isn't mentioned anywhere else in the documentation.
Is this actually a requirement? If so, what should the alternative biometric be, and how should it be handled throughout the registration and issuance process? |
|
| Answer: |
| The FIMH is not normative (not mandatory) and is not a NIST document. |
|
| 233 |
2006-02-17 15:22:26 |
|
editorial |
| Question: |
FIPS 201 5.3.1, A.1.1.2, A.2.2, A.2.8, & A.2.10 and FIMH 2.3.2.3, 2.3.3.1, 2.3.3.3, 2.3.5, 2.5.3.2.3, 4.4.3.2, 4.6.2, & App. B state that the PIV Registrar must make elements of the applicant's enrollment record available to both the PIV Issuer and the PIV Digital Signatory through a secure process. Presumably this will be done via the IDMS.
How should the PIV enrollment systems, issuance systems, and other clients communicate with and transfer these records to and from the IDMS? |
|
| Answer: |
| The use of an automated IDMS is not specified. Appendix A.2 (informative) does provide an example of an IDMS. No government-wide protocol for IDMS is specified. |
|
| 235 |
2006-02-07 12:59:21 |
|
editorial |
| Question: |
FIPS 201 A.1.1.1 states that the roles of PIV Applicant, Sponsor, Registrar, and Issuer are mutually exclusive – no individual may hold more than one of these during the proofing and registration process.
Are any electronic checks required to verify that the Applicant, Issuer, and/or Registrar are not the same person? |
|
| Answer: |
| The method for verification is not specified. Different departments and agencies may employ different approaches. |
|
| 236 |
2006-02-17 15:27:43 |
 |
editorial |
| Question: |
| Is support for PIV card logical access mandatory on enrollment systems and/or issuance systems? If so, is PIV card verification required for all operator logins? And if that's the case, how do you resolve the paradox of getting the first operator enrolled in order to receive a PIV card? |
|
| Answer: |
| Credential-based identification support is specified in FIPS 201. Use of the identity credentials for specific access control applications is not. Please refer to NIST Special Publication 800-37 for C&A requirements and to NIST Special Publication 800-53 for required logical access security controls. |
|
| 237 |
2006-02-17 15:30:07 |
|
editorial |
| Question: |
FIPS 201 2.4 states that only personnel with a legitimate need for access to IIF in the PIV system are authorized to access it.
Do PIV systems require any specific support for this on the technical end beyond the standard login process? If so, what are the requirements? |
|
| Answer: |
Please refer to NIST Special Publication 800-53, Recommended Security Controls for Federal Information Systems, and to FIPS 199, Standards for Security Categorization of Federal Information and Information Systems.
|
|
| 240 |
2006-05-17 11:13:16 |
Ketan Mehta |
editorial |
| Question: |
FIPS 201 4.4.1 lists the preferred order for selecting fingers to use for PIV card biometric templates, but states that substitutes should only be used if the index fingers cannot be imaged.
What if one or both index fingers can only be imaged with an NFIQ score of 4 or 5? Is an index finger with a high NFIQ score preferable to a substitute finger with a lower score? Should the choice of which fingers to use be automatic, or should the operator have the final say? |
|
| Answer: |
FIPS 201 called out index fingers because of their ease of presentation on single finger imaging devices. Quality 4 and 5 fingerprints will often be matched well: The NFIQ scale is not linear and certainly should not be construed
as running between 1 and 0 chance of matching. NFIQ was specified in section 3.2 of 800-76 only as mechanism for selecting the best of a set of repeated acquisitions, and not as a means of reprioritizing the order specified in
FIPS 201 4.4.1. |
|
| 250 |
2006-02-17 15:40:44 |
|
editorial |
| Question: |
| Our agency's data system used to collect and store information related to the personal identity verification process currently does not meet the requirements specified in section II.B.1. of OMB M-03-22. Is a PIA necessary? |
|
| Answer: |
|
|
| 253 |
2006-02-08 13:49:02 |
|
editorial |
| Question: |
A few questions about the two different models you supply in Appendix A of FIPS 201:
Q1: Why do you use different terminology to describe the roles in Section A.1, Role-Based Model, and Section A.2, System-Based Model? In A.1, the main roles are Applicant, Sponsor, Registrar, and Issuer. But in A.2, the roles are Applicant, Employer/Sponsor, Enrollment Official, Approval Authority, and Issuer. The role names and descriptions in A.1 are more clear-cut and obvious. The roles in A.2 are not as clear-cut and there is no description of why the names and duties are different from those in A.1. Also, the role names in A.1 are provided in the glossary, but the role names in A.2 are not. Is there any way to make the role names the same in both models?
Q2: In Section A.1, Role-Based Model, it says that "the roles of PIV Applicant, Sponsor, Registrar, and Issuer are mutually exclusive; no individual shall hold more than one of these roles in the identity proofing and registration process." However, in Section A.2, System-Based Model, there is no statement about whether the same individual or organization can hold more than one of the roles. Can an individual or organization hold more than one role in a system-based model?
Q3: In Section A.1, there is no statement about whether the roles may be performed by accredited service providers; whereas in Section A.2 it says that all roles and processes may be provided by accredited service providers compliant with this standard. Can roles and processes be provided by accredited service providers in a role-based model?
Q4: Does "accredited service provider" mean contractor?
Q5: Are the two models mutually exclusive? Couldn't an agency use both models (i.e., use an IDMS system described in A.2 with roles described in section A.1)?
Q6: Could you provide more examples of why/when an agency would choose one model over another?
Q7: In Section A.2.7, it says "The IDMS shall conduct the appropriate verification and validation using government-wide databases and services in accordance with HSPD-11." Does this mean that the IDMS will perform background screening? If not, where in the A.2 process is the background screening performed? If this does mean background screening, how would an IDMS conduct a background check, especially if the IDMS is a computer system and especially if the IDMS is a contractor? Doesn't OPM conduct all background checks? (Also, if this sentence does refer to background screening, you might want to change the reference to HSPD 11, since that is very specific to terrorist-related screening and not the typical NAC/NACI background checks.)
Q8: Is the "PIV Card Issuance and Management Subsystem" shown in Figure 3-1 and described in Section 5 of FIPS 201 the same as the "Identity Management System" shown in Figure A-1 and described in Section A.2.2?
|
|
| Answer: |
A1: Section A.1 describes the general case and employs government-wide terminology. Section A.2 describes a specific system employed by the Department of Defense (DoD), and it employs the DoD terminology. The Section A.2 system-based model is not intended to apply across the Federal government, though there is no prohibition against its use by other departments or agencies.
A2: Yes, so long as the constraint that no single individual can issue a credential without the participation of another individual who exercises a different role.
A3: Yes.
A4: An "accredited service provider" can be either a contractor or a Federal government entity.
A5: An agency may use an IDMS with roles described in section A.1. It would then conform to Section A.1 and would not be the specific DoD system described in Section A.2.
A6: No.
A7: No. The organization performs the screening in accordance with FIPS 201, Section 2.
If not, where in the A.2 process is the background screening performed?
See FIPS 201, Section 2.
It does not mean background screening.
OPM conduct all background checks.
A8: The "PIV Card Issuance and Management Subsystem" shown in Figure 3-1 and described in Section 5 of FIPS 201 is not the same as the "Identity Management System" shown in Figure A-1 and described in Section A.2.2.
|
|
| 320 |
2006-10-26 10:38:16 |
Hildegard Ferraiolo |
editorial |
| Question: |
With the recent change to FIPS-201, we now have the NACI status flagged in users certificates. What is the recommended procedure when the cardholder's NACI check is subsequently approved? Should the cardholder be able to install an upgraded certificate, or do they have to replace the entire card? Existing guidance seems to imply that certs cannot be replaced - the card must be reissued. Given that it seems likely that a high proportion of PIV cards will be issued before the checks are complete, the implication is that most cards will have to be reissued within the first 6 months. Is this the intention? If so, there are significant cost implications, boith in terms of cards and process. Clarification would be appreciated!
|
|
| Answer: |
| FIPS 201 does not require nor does it restrict the certificate update upon completion of NACI checks. Therefore, an agency may decide to keep original certificate, update the certificate on the card, or replace the card. |
|
| 332 |
2006-10-11 17:15:22 |
Ketan Mehta |
editorial |
| Question: |
Can an Agency create the X.509 certificates and load the signed objects onto the PIV card prior to the cardholder biometrics being verified or this step must be done after?
Scenario:
1) The Agency creates the required X.509 certificates and loads the signed objects onto the card. The card is locked with a transport key.
2) Upon PIV card issuance, the applicant's fingerprints are matched against their fingerprint record before unlocking the card using the transport key.
3) The cardholder selects a PIN.
|
|
| Answer: |
| FIPS 201-1 does not specify any particular steps for card issuance. The requirements are designed to allow agencies operational flexibility and meet HSPD-12 objectives. The issuance steps should take advantage of the existing process and infrastrucure while meeting all the FIPS 201-1 requirements. It is not clear, from a brief description, that your process will meet all the requirements. |
|
| 694 |
2007-04-25 08:39:12 |
Hildegard Ferraiolo |
editorial |
| Question: |
FIPS 201 5.3.2.3 PIV Card PIN Reset states "Before the reset PIV Card is provided back to the cardholder, the card issuer shall ensure that the cardholder’s biometric matches the stored biometric on the reset PIV Card."
Does an in-person visual match with a facial image stored on the chip meet this requirement? Does an in-person visual match with the facial image printed on the face of the card meet this requirement? |
|
| Answer: |
FIPS 201 in section 4.4 "Biometric Data Specification" lists the facial image as biometric data. However, FIPS 201 section 6.2, PIV Card Authentication Mechanisms, does not describe the facial image (either the stored electronic or the printed image) as a biometric authentication mechanism.
In FIPS 201 and associated Special Publication, the electronic facial image use-case is to support/augment "VISUAL authentication" (VIS, section 6.2.1), while the on-card fingerprint template are used as the biometrics use-cases (BIO, BIO-A ).
As such, if FIPS 201 specifies a "biometric match" in section 5.3.2.3, a fingerprint template match is implied (BIO-use case), because the electronic facial image is not considered a BIO-use case and only supports VIS.
|
|
