usnistgov / fips201 Goto Github PK

Organization Name (N/A, if individual): XTec, Incorporated

Organization Type (see below for codes): 2 = Industry

Reference (Include section/paragraph or pdf line number):
• Section 4.2.2.3, Line 1866
• Section 6.2.4, Line 2316

Comment (Include rationale for comment):

Please see attached document

Suggested Change:

Please see attached document

XTec, Incorporated - Comment for NOT Deprecating SYM-CAK - 01282021.docx

Organization Type: 1 = Federal, 2 = Industry, 3 = Academia, 4 = Self, 5 = Other

All Fields Are Required

Organization Name (N/A, if individual): DoD

Organization Type (see below for codes): 1 - Federal

Reference (Include section/paragraph or pdf line number): 2.9.3 PIV Card Activation Reset Line 1036

Comment (Include rationale for comment): This section establishes a requirement for PIVs that support OCC biometric comparison needing to do more to reset a PIN than successfully compare the biometrics. It is unclear what other requirements (i.e., connected to issuer operator and issuance operator authenticates the owner of PIV) must be met in this scenario and what specific risk is attempting to be mitigated.

Suggested Change: "DoD recommends NIST add clarity to this section about PIN resets by identifying two specific PIN reset function:

1. ""PIN reset to an unlocked/blocked PIN in which the user knows the PIN or leverages the OCC biometric comparison. This should not require connection to issuance infrastructure.""
2. ""PIN reset to a locked/block PIN which fits into the current language in this section."" "

Organization Type: 1 = Federal, 2 = Industry, 3 = Academia, 4 = Self, 5 = Other

All Fields Are Required

Organization Name (N/A, if individual): NASA

Organization Type (see below for codes): 1 - Federal

Reference (Include section/paragraph or pdf line number): Sec 2.7 Line 772

Comment (Include rationale for comment): No guidance has been forthcoming from the Department of State and such guidance has not been easily available in the past. Is it the intention of this document for the Department of State to issue guidance, similar to OPM issuing the final credentialing standard, for such issuance? Will the Department of State be establishing a group to support such identity proofing inquiries? Is this specifically for PIV-I credentials or is there an as yet unreleased method for issuing foreign nationals a PIV without an investigation and residency as required in the OPM Final Credentialing Standard?

Suggested Change:

Organization Type: 1 = Federal, 2 = Industry, 3 = Academia, 4 = Self, 5 = Other

All Fields Are Required

Organization Name (N/A, if individual): NSA Center for Cybersecurity Standards

Organization Type (see below for codes): 1 - Federal

Reference (Include section/paragraph or pdf line number): 2.9.1 Line 922

Comment (Include rationale for comment): : If the card has not been compromised, is collected and is destroyed, why is it necessary to revoke it (whatever it means to 'revoke' a card)? In addition, if the private keys have not been compromised, why is it necessary to revoke the keys on that card? [note: in the case of loss, stolen or compromised cards, I agree revocation is the only course]

Suggested Change:

Organization Type: 1 = Federal, 2 = Industry, 3 = Academia, 4 = Self, 5 = Other

All Fields Are Required

Organization Name (N/A, if individual): NASA

Organization Type (see below for codes): 1 = Federal

Reference (Include section/paragraph or pdf line number): Sec 2.4 Line 600, Sec 2.5 Line 836

Comment (Include rationale for comment): "Biometric" is used throughout the document for the purpose of comparison but only fingerprint biometric comparisons are ever detailed as an option (line 600). If the intention is to only allow fingerprint biometric comparison, that needs to be expressely stated. If the intention is to allow fingerprint, iris, or facial image biometric comparison (line 636) that needs to be explained.

Suggested Change: Clearly define the use of biometric comparison to either be limited to fingerprint biometric comparison or to allow comparison of all other biometrics (iris, facial image). Recommend allowing comparison of all biometric types captured during enrollments when a biometric comparison is needed.

Organization Type: 1 = Federal, 2 = Industry, 3 = Academia, 4 = Self, 5 = Other

All Fields Are Required

Organization Name (N/A, if individual): DoD

Organization Type (see below for codes): 1 - Federal

Reference (Include section/paragraph or pdf line number): 6. Applicability Line 79

Comment (Include rationale for comment): This section leaves open to interpretation whether a physical location can be classifed as a "National Security System". DoD recommends providing clarification.

Suggested Change: DoD recommends updating as follows: "This Standard is applicable to identification issued by federal departments and agencies to federal employees and contractors for gaining physical access to federally controlled facilities; and for gaining logical access to federally controlled information systems, except for “national security systems” as defined by 44 U.S.C. 3542(b)(2) and [SP 800-59]."

Organization Type: 1 = Federal, 2 = Industry, 3 = Academia, 4 = Self, 5 = Other

All Fields Are Required

Organization Name (N/A, if individual): NASA

Organization Type (see below for codes): 1- Federal

Reference (Include section/paragraph or pdf line number): Sec 2.7.1 Line 795

Comment (Include rationale for comment): "Requiring the station to be maintained in a controlled-access environment and monitored by staff limits options such as enrollment kits that can be mailed to the applicant or even remotely placed kiosks. Supervised remote should not rely on staff at a location but instead the process to securely access the enrollment service and the pre-registration and sponsorship of the individual to be enrolled. Requiring staff to monitor the equipment does not work for remote areas where population and need for enrollment is greatly reduced.

The option to allow a shippable enrollment kit (cameras, readers, etc.) would be useful and the only change to the existing requirements would be the first bullet under supervised remote identity proofing. The recommended change would allow for the current proposed implementation of staffing (maintained in a secure manner) and would also allow options for a kit to be securely shipped to an applicant or even a kiosk to be placed at a specific location. The process for using an enrollment kit could be the following: kit is shipped and tracked by issuer; kit is recevied; enrollment is scheduled; operator and applicant connect via video conferencing; operator provides code to unlock kit; applicant sets up kit in view of operator; applicant performs enrollment with oprator guidance; enrollment is completed; kit is placed back in package and sealed using tamper-resistant tap; video conference is ended; kit will then be shipped and tracked back to issuer."

Suggested Change: Change the first bullet under supervised remote identity proofing requirements to: "The station SHALL be maintained in a secure manner and SHALL be monitored by an operator while it is being used."

Organization Type: 1 = Federal, 2 = Industry, 3 = Academia, 4 = Self, 5 = Other

I noticed several right single quotes (’, U+2019) in the Markdown documents. Should these be replaced with apostrophes (', U+0027)? There may be other non-ASCII characters as well. I'm unsure if non-ASCII will cause an issue when converting back into PDF.

All Fields Are Required

Organization Name (N/A, if individual): DoD

Organization Type (see below for codes): 1 - Federal

Reference (Include section/paragraph or pdf line number): 5.4 Line 2111

Comment (Include rationale for comment): "While DoD agrees with the removal of the term ""legacy PKI"" from FIPS-201, as currently written, FIPS-201 does not accurately address the distinction between Federal department and agency PKIs that are cross-certified with the Federal PKI and those that are operated under the Common Policy itself. Cross certification happens after the two PKIs are deemed comparable, but asserting a policy OID means that the certificate fully meets the requirements. DoD recommends incorporating language to support interoperability while maintaining the sovereignty of department and agency PKIs.

Specifically, DoD recommends continuation of the existing requirement that PIV-Authentication certificates assert the fpki-common-authentication policy, but not to add a new requirement for asserting common policy OIDs in signature and key management certificates."

Suggested Change: "DoD recommends replacing the current text with the following:

5.4 Agency PKIs

Note: this section was formerly entitled ""Legacy PKIs.""

Departments and agencies that operate their own agency CAs MAY specify their own policy OIDs in lieu of or in addition to [COMMON] policies in certificates associated with private keys for Digital Signing and Key Management certificates provided that the agency PKI is cross certified with the Federal Bridge CA or Federal Common Policy CA and the asserted agency policy OIDs map to the [COMMON] policy OIDs specified in 5.2.1."

Organization Type: 1 = Federal, 2 = Industry, 3 = Academia, 4 = Self, 5 = Other

All Fields Are Required

Organization Name (N/A, if individual): NSA Center for Cybersecurity Standards

Organization Type (see below for codes): 1 - Federal

Reference (Include section/paragraph or pdf line number): 2.9.1 and 2.10

Comment (Include rationale for comment): Neither of these sections address the requirements for derived PIV credentials when the PIV is re-issued. The minimum would be to say that the original issuance method shall be followed.

Suggested Change:

Organization Type: 1 = Federal, 2 = Industry, 3 = Academia, 4 = Self, 5 = Other

All Fields Are Required

Organization Name (N/A, if individual): DoD

Organization Type (see below for codes): 1 - Federal

Reference (Include section/paragraph or pdf line number): 2.2 Credential Requirement Line 557

Comment (Include rationale for comment): Lines 557-559, should reference the Office of Personnel Management (OPM) Credentialing Standards Procedures memorandum, titled “Credentialing Standards Procedures for Issuing Personal Identity Verification Cards under HSPD-12 and New Requirement for Suspension or Revocation of Eligibility for Personal Identity Verification Credentials,” dated December 15, 2020. This OPM memorandum includes information that could be considered to the contrary of how Section 2.2 is drafted. For example, in the case of non-citizen U.S. Federal employees hired and working in foreign locations, such as local nationals working at an overseas DoD Installation, a Tier 1 investigation is improbable.

Suggested Change: "DoD recommends updating language to: “The minimum requirement for PIV Credential eligibility determination for U.S. nationals worldwide and for non-U.S. nationals at locations within the United States is a completed and favorably adjudicated Tier 1 investigation, formerly called a National Agency Check with Written Inquiries (NACI). The minimum requirement for non-U.S. nationals at locations outside the United States are established in OPM Credentialing Standards for Issuing Personal Identity Verification…"".

DoD also recommends adding reference to document (footnote or otherwise)."

Organization Type: 1 = Federal, 2 = Industry, 3 = Academia, 4 = Self, 5 = Other

• a [REAL-ID] compliant Driver's license or ID card issued by a state or possession of the United States;

makes it unclear if an ID card needs to be Real-ID compliant, or only a driver's license.

All Fields Are Required

Organization Name (N/A, if individual): DoD

Organization Type (see below for codes): 1 - Federal

Reference (Include section/paragraph or pdf line number): 2.9.2 PIV Card Post-Issuance Update Requirements Line 974

Comment (Include rationale for comment): This section requires remote update of PIVs be conducted over mutually authenticated communication between the issuance infrastructure, user's web browser, and user's PIV. DoD has seen significant dropped transactions and errors in our remote update capability implementing a similar requirement. DoD is migrating to a solution that will allow more transactions to be conducted successfully and still provide a secure mechanism. DoD recommends adding language to cover DoD's emerging post-issuance implementation, which DoD believes provides sufficient mechanism to perform those transactions securely while decreasing failures.

Suggested Change: DoD recommends adding the following to this section: "Remote post-issuance updates are sufficiently secure when performed over a server-side only TLS session used in conjunction with the Global Platform Secure (GP) channel where the keys used to establish the GP channel are known only to the issuer and are housed in a FIPS 140 Level 3 device."

Organization Type: 1 = Federal, 2 = Industry, 3 = Academia, 4 = Self, 5 = Other

All Fields Are Required

Organization Name (N/A, if individual): DoD

Organization Type (see below for codes): 1 - Federal

Reference (Include section/paragraph or pdf line number): PIV Identity Proofing and Registration Requirements Line 731

Comment (Include rationale for comment): This section creates a new requirement for driver licenses used for identity proofing be REAL ID Act compliant. There are serveal mitigating factors for PIV card issuance, including that PIV card applicants must present a secondary ID proofing document, complete a FBI records check, and complete background investigation. Many U.S. states continue to issue both REAL ID Act compliant and non-compliant ID cards. Given scope/applicability of REAL ID Act and existing mitigating factors, DoD recommends against this requirement.

Suggested Change: DoD recommends NIST remove the requirement for a REAL ID Act compliant ID cards in the ID proofing process.

Organization Type: 1 = Federal, 2 = Industry, 3 = Academia, 4 = Self, 5 = Other

Organization Name: HID Global

Organization Type: 2-Industry

Reference: Section: 5.5.1 Certificate and CRL Distribution, first paragraph

Comment (Include rationale for comment): The Standard requires the use of HTTP. Some may infer that HTTPS is also supported or even preferred. Using HTTPS adds complexity to shared hosting of supporting services so it would be good to clarify if it's indeed included.

Suggested Change: Add a phrase to the first paragraph stating if HTTPS is also supported or even encouraged or if it’s a deliberate choice to limit the protocol to HTTP.

All Fields Are Required

Organization Name (N/A, if individual): DoD

Organization Type (see below for codes): 1 - Federal

Reference (Include section/paragraph or pdf line number): 2.6 PIV Enrollment Record Line 642

Comment (Include rationale for comment): It is DoD's understanding that NIST's intent for the PIV enrollment record is to identify items that could be included but leave most of implementation to Federal PIV issuers. DoD recommends adding specific language to this section to provide clarification and to emphasize this intention.

Suggested Change: DoD recommends the following be added to this section, "As long as data can be retrieved when needed by the PIV issuer, then there is no requirement for data that may reside in other authoritative system to be duplicated in the PIV issuance system."

Organization Type: 1 = Federal, 2 = Industry, 3 = Academia, 4 = Self, 5 = Other

All Fields Are Required

Organization Name (N/A, if individual): DoD

Organization Type (see below for codes): 1 - Federal

Reference (Include section/paragraph or pdf line number): 4.3.1 Activation by Cardholder Line 2008

Comment (Include rationale for comment): "This new requirement seems to expect the PIV card (and/or PIV issuance system) to ensure the user does not select various PIN combinations. Meeting this mandate would require the development of a new on-card capability and FIPS 140 re-certification.

Additionally, the current safeguards appear to be enough to mitigate this perceived risk for a credential used for UNCLASSIFIED/CUI material. The knowledge about the PIN should be that of the PIV cardholder and the actual card. There are a combination of factors (e.g., the length of the PIN, there is a three failed PIN counter, and physical hardware token) that go into meeting the FIPS 140 1:1M probability of an adversary selecting an accurate PIN. As such, it is difficult to understand how this requirement (implement on the card or within the issuance system) would significantly change this equation and those layered security techniques. "

Suggested Change: DoD recommends the requirement be removed or made optional.

Organization Type: 1 = Federal, 2 = Industry, 3 = Academia, 4 = Self, 5 = Other

All Fields Are Required

Organization Name (N/A, if individual): DoD

Organization Type (see below for codes): 1 - Federal

Reference (Include section/paragraph or pdf line number): General Line 2461

Comment (Include rationale for comment): Interoperability continues to be a major challenge for Federal Agencies. DoD has a mission need to support interoperability with other Federal mission partners by exchanging attributes about individuals to assist in the account request/authorization, account provisioning, and account management processes within DoD IT assets. Currently, there are no specific federal solutions to support that activity. DoD plans to begin a production deployment of pilot Backend Attribute Exchange (BAE) implementation that mirrors the Federal ICAMSC BAE 2.0 documentation, but there are no other federal PIV issuers subscribers.

Suggested Change:
DoD recommends NIST codify the ICAMSC BAE 2.0 initiative for federal PIV issuers to share attributes.  Each Federal PIV issuerer should be required to expose an Agency BAE broker so that other federal PIV issuers can exchange identity attributes and PIV records, where needed.

Organization Type: 1 = Federal, 2 = Industry, 3 = Academia, 4 = Self, 5 = Other

Organization Name: HID Global

Organization Type: 2-Industry

Reference: Section: 6.3. PIV Support of Graduated Authentication Assurance Levels

Comment (Include rationale for comment): At the beginning of section 6 it is stated that graduated authenticator assurance levels are also applicable to derived PIV credentials, but Section 6.3 only mentions the PIV Credential. It would be useful to include examples of acceptable derived credentials.

Suggested Change: Add a Table after current Table 6-1. Acceptable Examples of Derived Credentials for Physical Access; and include for the different PAL an example of a valid derived credential, for example a FIDO Level 2 authenticator with resident keys capabilities.

Add a Table after current Table 6-2. Acceptable Examples of Derived Credentials for Logical Access; and include the different authentication assurance levels with examples like accessing a native mobile application or a Web Page in a mobile device as well as a regular desktop through a Web browser.

All Fields Are Required

Organization Name (N/A, if individual): DoD

Organization Type (see below for codes): 1 - Federal

Reference (Include section/paragraph or pdf line number): Appendix C Line 2656

Comment (Include rationale for comment): There is no definition of Authenticator in Appendix and the concept is referenced in various places throughout the document (e.g., Sections 2.10.1 (Line 1108) and 3.1.2 (Line 1261)).

Suggested Change: DoD recommends adding a definition of Authenticator to differentiate for the reader the difference between an authenticator and credential.

Organization Type: 1 = Federal, 2 = Industry, 3 = Academia, 4 = Self, 5 = Other

All Fields Are Required

Organization Name (N/A, if individual): DoD

Organization Type (see below for codes): 1 - Federal

Reference (Include section/paragraph or pdf line number): Section 2.9.1 Line 922 Section 2.9.4 Line 1071

Comment (Include rationale for comment): This revision appears to allow certificate to not be revoked if the PIV is collected and destroyed by the card issuer. While destruction of the PIV cards ensures loss of private keys, it does not address potential user behavior issues with email clients (e.g., potential for an unrevoked public key from a collected/destroyed PIV to be available for use in encryption transactions) and confusion (potential for user to recover an unrevoked encryption certificate for a destroyed PIV and continue to use it) when it comes to encryption keys.

Suggested Change: DoD recommends a 4th item be added to the revocation process to ensure there are no user behavior issues: "Even if the PIV card was collected and destroyed, the certificate corresponding to the key management key SHALL be revoked, if the key management key is present."

Organization Type: 1 = Federal, 2 = Industry, 3 = Academia, 4 = Self, 5 = Other

All Fields Are Required

Organization Name (N/A, if individual): Department of Veteran's Affairs (VA)

Organization Type (see below for codes): 1

Reference (Include section/paragraph or pdf line number):

1. Line 989, Section 2.9.3 PIV Card Activation Reset
2. Line 1040, Section General Computing Platform
3. Line 1075, Section 2.9.4 PIV Card Termination Requirements
4. After line 1530, Table 4-1. Name Examples
5. After line 1530, Table 4-1. Name Examples

Comment (Include rationale for comment):

Suggested Change:

1. Would not refer to this as Card Activation. It is a PIV card PIN and/or data reset.
2. "The operator authenticates the owner of the PIV Card through an independent procedure." Vague wording, would recommend adding examples for clarity.
3. "Per OPM guidance, the Central Verification System (or successor) SHALL be updated to reflect the change in status." Just wanted to comment that this may be difficult for some agencies to implement. CVS can be managed by a different office responsible for adjudications/suitability. If a case management system is not in place, they may not get a notification indicating the user has been terminated or separated from the agency. In which case, the notification and CVS change will have to be a manual data entry.
4. Example column is empty.
5. Page 40, Bottom left, seems to have a formatting issue with a long Contractor name in green.

Organization Type: 1 = Federal, 2 = Industry, 3 = Academia, 4 = Self, 5 = Other

All Fields Are Required

Organization Name (N/A, if individual): DoD

Organization Type (see below for codes): 1 - Federal

Reference (Include section/paragraph or pdf line number): 5.2.1 Line 2080

Comment (Include rationale for comment): While DoD agrees with the removal of the term "legacy PKI" from FIPS-201, as currently written, FIPS-201 does not accurately address the distinction between Federal department and agency PKIs that are cross-certified with the Federal PKI and those that are operated under the Common Policy itself. Cross certification happens after the two PKIs are deemed comparable, but asserting a policy OID means that the certificate fully meets the requirements. DoD recommends incorporating language to support interoperability while maintaining the sovereignty of department and agency PKIs.

Suggested Change: DoD recommends replacing the first sentence with the following: "The required contents of X.509 certificates associated with PIV private keys are based on [PROF]. The relationship is described below for certificates issued under [COMMON], and is described in Section 5.4 for certificates issued by department and agency PKIs that operate under department and agency specific Certificate Policies."

Organization Type: 1 = Federal, 2 = Industry, 3 = Academia, 4 = Self, 5 = Other

All Fields Are Required

Organization Name (N/A, if individual): DoD

Organization Type (see below for codes): 1 - Federal

Reference (Include section/paragraph or pdf line number): 5.5.1 Line 2132

Comment (Include rationale for comment): Does the specification of HTTP for publishing CA certificates preclude the usage of HTTPS? Considering RFC 5280, it probably should.

Suggested Change: Suggest the following text be added, "the usage of HTTPS for publishing CA certificates be prohibited in this standard to avoid the issues specified in Section 8 of RFC 5280, one example of which is "relying parties ... MUST be prepared for the possibility that this will result in unbounded recursion."

Organization Type: 1 = Federal, 2 = Industry, 3 = Academia, 4 = Self, 5 = Other

All Fields Are Required

Organization Name (N/A, if individual): DoD

Organization Type (see below for codes): 1 - Federal

Reference (Include section/paragraph or pdf line number): 2.9.4 PIV Card Termination Requirements Line 922

Comment (Include rationale for comment): Update this section to provide consistency between this section and lines 1085-1086.

Suggested Change: DoD recommends adding the following to this section, "In addition, the PIV Card termination procedures SHALL ensure all derived PIV credentials bound to the PIV account are invalidated as specified in Section 2.10.2."

Organization Type: 1 = Federal, 2 = Industry, 3 = Academia, 4 = Self, 5 = Other

All Fields Are Required

Organization Name (N/A, if individual): DoD

Organization Type (see below for codes): 1 - Federal

Reference (Include section/paragraph or pdf line number): 2.6 PIV Enrollment Record Line 642

Comment (Include rationale for comment): It is DoD's understanding that NIST's intent for the PIV enrollment record is to identify items that could be included but leave most of implementation to Federal PIV issuers. The SHALL requirements for the PIV enrollment record are spread across the document. DoD recommends providing all SHALL requirements for the PIV enrollment records in this section. This will ensure PIV issuers can clearly identify the requirements that must be implemented (SHALL) vs. the ones that SHOULD or COULD be implemented.

Suggested Change: "DoD recommends that this section include all SHALL requirements for the PIV enrollment records. Our review identified the following items:

• Line 566
• Line 938

Organization Type: 1 = Federal, 2 = Industry, 3 = Academia, 4 = Self, 5 = Other

Organization Name: HID Global

Organization Type: 2-Industry

Reference: Section 7.2 Second Paragraph

Comment (Include rationale for comment): OpenID Connect is a well known federation standard that is worth including in the suggested references.

Suggested Change: Extend the last phrase in the second paragraph to read: For example, the information can be presented using technologies defined in [RFC 8485] or [SAML-AC] or [OpenID Connect].

Add the corresponding references to OpenID Connect Federation and OpenID Connect for Identity Assurance

All Fields Are Required

Organization Name (N/A, if individual): NASA

Organization Type (see below for codes): 1 - Federal

Reference (Include section/paragraph or pdf line number): Sec 2.2 Line 557

Comment (Include rationale for comment): The minimum requirement for issuance of a PIV is submission of the investigation and completion of the FBI NCHC, as explained in the following paragraph. These paragraphs need to be modified to address the minimum and address continued eligibility for the PIV credential.

Suggested Change: "The minimum requirement for PIV Credential eligibility determination is a completed and favorably adjudicated FBI NCHC and a submitted Tier 1 investigation. Continued PIV eligibility is determined by the completed and favorably adjudicated Tier 1 investigation."

Organization Type: 1 = Federal, 2 = Industry, 3 = Academia, 4 = Self, 5 = Other

All Fields Are Required

Organization Name (N/A, if individual): NASA

Organization Type (see below for codes): 1 - Federal

Reference (Include section/paragraph or pdf line number): Sec 2.8.2 Line 876

Comment (Include rationale for comment): Is NIST proposing a solution for how enrollment records can be shared between organizations so these operations can be accomplished? Currently there is no single location where enrollment records reside or can be bridged (e.g., FPKI bridge, CVS for investigations). Can this be a mandatory item and can this be somehow managed by a central Agency (e.g., DCSA)?

Suggested Change:

Organization Type: 1 = Federal, 2 = Industry, 3 = Academia, 4 = Self, 5 = Other

All Fields Are Required

Organization Name (N/A, if individual): Intercede

Organization Type (see below for codes): 2

Reference (Include section/paragraph or pdf line number): section 4.2.2 top of page 58 on the November 2020 pdf draft, lines 1800 to 1804

Comment (Include rationale for comment):
The text below the bold section "PIV Card application administration key" seems to be mixing up concepts that relate to the "PIV card application administration key" and the "Secure Messaging key" - certainly it is at odds with sections 4.2.2.6 and 4.2.2.7

Suggested Change:
I think this may be a formatting/markup issue, where page 58 intends to list "PIV Card application administration key" and "Secure Messaging key" as 2 separate bold-headed sections to indicate 2 separate keys, but an issue with the markup makes it seem to merge into a single section that looks like it is mixing the 2 different keys together.

Organization Type: 1 = Federal, 2 = Industry, 3 = Academia, 4 = Self, 5 = Other

All Fields Are Required

Organization Name (N/A, if individual): Office of Information & Technology (OI&T), Office of Information Security (OIS)

Organization Type (see below for codes): 1 = Federal

Reference (Include section/paragraph or pdf line number): line 1379 (page 35)

Comment (Include rationale for comment): Reference to “American Association of Motor Vehicle Association’s”

Suggested Change: This should likely be “American Association of Motor Vehicle Administrators”

Organization Type: 1 = Federal, 2 = Industry, 3 = Academia, 4 = Self, 5 = Other

All Fields Are Required

Organization Name (N/A, if individual): DoD

Organization Type (see below for codes): 1 - Federal

Reference (Include section/paragraph or pdf line number): 4.2.2.1 PIV Authentication Key Line 1836 4.2.4 PIV Unique Identifiers Line 1969

Comment (Include rationale for comment): It has become more and more difficult to support authentication interoperability between different federal agency PIV cards as many applications use User Principal Names (UPNs) as a mechanism to provision and manage accounts. Some Federal agencies implement UPNs that are constructed as e-mail addresses while other use random agency specific identifiers. This does not guarantee uniqueness nor decrease the possibility of duplicates. Additionally, there is no federal-wide requirement for all federal agencies to maintain a identity service provider (IdP) and until such is implemented federal-wide, these interoperability challenges need to be addressed through other mechanisms . Positive adjudication of this comment will significant enhance interoperability (for example, this will aid DoD-VA interoperability and onboarding new federal entities to the Federal Electronic Health Record system).

Suggested Change: "DoD recommends adding as a mandatory element to the PIV authentication certificate a UPN in the Subject Alternate Name field that conforms with an existing FIPS 201/SP 800-73 attributes (i.e., the last 16 digits of the Federal Agency Smart Card Number (FASCN), i.e., cardholder specific identifier). The construction of the UPN should be the last 16 digits of the FASCN@federal agency abbreviation (e.g., last 16 digits of FACSN@mil or last 16 digits of FASCN@va).
"

Organization Type: 1 = Federal, 2 = Industry, 3 = Academia, 4 = Self, 5 = Other

All Fields Are Required

Organization Name (N/A, if individual): NSA Center for Cybersecurity Standards

Organization Type (see below for codes): 1 - Federal

Reference (Include section/paragraph or pdf line number): Section 3.1.1, lines 1238-1241

Comment (Include rationale for comment): It seems so strange to see a card writer in a section called 'PIV Front-End Subsystem'. An end user is not classically using a card writer (printing/loading cards). Change 'card reader' to 'card reader/writer' in Figure 3-1. Change sentences 1 and 2 to: "Card writers may be used to perform remote PIV Card updates (see Section 2.9.2)."

Suggested Change:

Organization Type: 1 = Federal, 2 = Industry, 3 = Academia, 4 = Self, 5 = Other

All Fields Are Required

Organization Name (N/A, if individual): Intercede

Organization Type (see below for codes): 2

Reference (Include section/paragraph or pdf line number): section 4.3.1 "Activation by cardholder" line 2008

Comment (Include rationale for comment):
Quote - "The PIN should not be easily guessable or otherwise individually identifiable in nature (e.g., part of a Social Security Number or phone number)"
This is a very sensible line in its intent, but it is problematic in implementation. Ultimately it is the cardholder that chooses the PIN, although the allowable values is limited by the card itself and the software between the user and the card.
The card itself clearly cannot enforce this rule (as it does not know the users SSN or phone number and since these are only examples, there is no concrete rule that it can implement)
The software between the user and card (e.g. the card issuance system) - could try to do something to implement this rule, but it is problematic:

• it is woolly what the matching rules are/what is allowed or disallowed (e.g. SSN)
• in order for software to implement the check of the PIN against this data which is personally identifiable information (PII) either the PIN would need to be sent to the backend system to check it is allowed (bad idea to distribute the PIN), or additional PII (e.g. phone number, SSN) would need to be sent to the client for the check on the client (unnecessary additional distribution of PII).
• The example of checking against SSN implies distribution of SSN, and possibly even additional capture of SSN in software that may not be storing the SSN already. sp800-122 (regarding PII) on page ES-2 is stating that "OMB M-07-168 specifically requires agencies to: .. Establish a plan to eliminate the unnecessary collection and use of SSNs"
• There are many bits of software that could cause a PIN to be chosen for the PIV card - not just the issuance system, but PIN change could be performed on a disconnected system as only the current PIN is needed to authorize a PIN change. A disconnected system would be unable to enforce such a rule that the PIN does not match e.g. SSN/phone number, as it would have no access to that info (and nor should it)

Suggested Change:
I believe the intent of this statement is that the cardholder is ultimately responsible (and in fact the only part of the system that can enforce this rule), although as written it implies that it is a problem for software to solve (which as written above could cause more problems than it solves).
Therefore I suggest changing to:
"The cardholder should not choose a PIN that is easily guessable or otherwise individually identifiable in nature (e.g., part of a Social Security Number or phone number)."

Organization Type: 1 = Federal, 2 = Industry, 3 = Academia, 4 = Self, 5 = Other

All Fields Are Required

Organization Name (N/A, if individual): NASA

Organization Type (see below for codes): 1 - Federal

Reference (Include section/paragraph or pdf line number): Sec 6.2.5 Line 2341

Comment (Include rationale for comment): Use of the CHUID should still be allowed within the authentication perimeter (layered access control). For instance, once I have authenticated to a controlled/limited/exclusion space with PKI I should be able to use CHUID to access areas of equal or lesser security requirements within the perimeter.

Suggested Change: Deprecate section 6.2.5, Authentication Using the CHUID but do not remove it. Speficy that use of the CHUID for authentication should only be used after an initial authentication using one of the other approved methods.

Organization Type: 1 = Federal, 2 = Industry, 3 = Academia, 4 = Self, 5 = Other

All Fields Are Required

Organization Name (N/A, if individual): NSA Center for Cybersecurity Standards

Organization Type (see below for codes): 1 - Federal

Reference (Include section/paragraph or pdf line number): Section 4.2, line 1726

Comment (Include rationale for comment): How is this asymmetric key set different than either the card authentication data or the PIV authentication data? Is there a use case that can't be handled by the 2 mandatory asymmetric key sets?

Suggested Change:

Organization Type: 1 = Federal, 2 = Industry, 3 = Academia, 4 = Self, 5 = Other

Organization Name: HID Global

Organization Type: 2-Industry

Reference: Section 4.2 PIV Card Logical Characteristics

Comment (Include rationale for comment): Add the ability for a PIV card to optionally support the FIDO2 protocol, that is widely supported by the industry. This would have benefits including:

• Such FIDO enabled PIV card would natively work with many applications that don’t support PIV today; for example, a PIV cardholder could use the FIDO capability on his PIV card to authenticate to a cloud application on his phone using the NFC antenna embedded in the phone without using a derived credential (while still leveraging the FIPS 140 certification of the PIV card for protection of the crypto materials).
• The PIV issuance system could configure the FIDO assertion certificate on the PIV card using the PIV digital signatory so that an Identity Provider could be configured to only accept FIDO credentials issued by the agency or the US Federal government at large.
• It would be possible for the PIV PIN and FIDO PIN to be one and the same inside the PIV card so that there is no new PIN management to add for the FIDO part.

Suggested Change: Add to the fourth paragraph that states "This Standard also defines optional data elements for the PIV Card data model. These optional data elements include" a bullet saying:

• A FIDO2 compliant credential including asymmetric keys, attestation and other data required for FIDO2 compliance

All Fields Are Required

Organization Name (N/A, if individual): NIST, Elaine Barker

Organization Type (see below for codes): 1 - Federal

Reference (Include section/paragraph or pdf line number): See word.doc attachment

Comment (Include rationale for comment): See word.doc attachment

Suggested Change: See word.doc attachment

Comments on FIPS 201.docx

Organization Type: 1 = Federal, 2 = Industry, 3 = Academia, 4 = Self, 5 = Other

All Fields Are Required

Organization Name (N/A, if individual): Generic Smart Cards LLC

Organization Type (see below for codes): 2 - Industry

Reference (Include section/paragraph or pdf line number): 5.5.3

Comment (Include rationale for comment): Unlike logical access, PACS solutions generally leverage a credential identifier from which access privileges and other services are then linked. Having a lightweight revocation solution for PACS that conveys issuer trust status, searchable by credential identifier, would provide many benefits

Suggested Change: See Document "FIPS201-3 Contribution Clause 5.5.3 UUID Canceled List v2.pdf" sent with this spreadsheet

FIPS201-3 Contribution Clause 5.5.3 UUID Canceled List v2.pdf

Organization Type: 1 = Federal, 2 = Industry, 3 = Academia, 4 = Self, 5 = Other

Organization Name: HID Global

Organization Type: 2-Industry

Reference: Section 2.7.1 Supervised Remote Identity Proofing. Fourth paragraph

Comment (Include rationale for comment): FIPS 201 should allow supervised remote identity proofing like SP800-63, at locations that do not provide controlled access; e.g.: the ability to do supervised remote identity proofing from the applicant’s home. SP800-63 allows it as long as the remote person supervising the identity proofing can see both the applicant and the hardware used to enroll the applicant, which is something achievable today with the availability of high-quality cameras, high bandwidth and Internet connected devices.

Suggested Change: Change the first bullet from “The station SHALL be maintained in a controlled-access environment and SHALL be monitored by staff at the station location while it is being used.” into “The station SHALL be monitored by the remote live operator while it is being used by the applicant.”

All Fields Are Required

Organization Name (N/A, if individual): NSA Center for Cybersecurity Standards

Organization Type (see below for codes): 1 - Federal

Reference (Include section/paragraph or pdf line number): 2.9

Comment (Include rationale for comment): This section is mostly silent on derived PIV credentials (2.9.4, lines 1085 and 1086 is the exception). If all derived PIV requirements are in 2.10, then there should be requirements that cover all of the Section 2.9 subsections.

Suggested Change:

Organization Type: 1 = Federal, 2 = Industry, 3 = Academia, 4 = Self, 5 = Other

All Fields Are Required

Organization Name (N/A, if individual): DoD

Organization Type (see below for codes): 1 - Federal

Reference (Include section/paragraph or pdf line number): 5.5 Line 2121

Comment (Include rationale for comment): Does the specification of HTTP for publishing CA certificates preclude the usage of HTTPS? Considering RFC 5280, it probably should.

Suggested Change: Suggest the following text be added, "the usage of HTTPS for publishing CA certificates be prohibited in this standard to avoid the issues specified in Section 8 of RFC 5280, one example of which is "relying parties ... MUST be prepared for the possibility that this will result in unbounded recursion."

Organization Type: 1 = Federal, 2 = Industry, 3 = Academia, 4 = Self, 5 = Other

All Fields Are Required

Organization Name (N/A, if individual): NSA Center for Cybersecurity Standards

Organization Type (see below for codes): 1 - Federal

Reference (Include section/paragraph or pdf line number): Section 4.2.2, line 1798

Comment (Include rationale for comment): Please define 'retired'. Or replace it with 'expired and revoked' (because sadly revocation is required when replacing these keys).

Suggested Change:

Organization Type: 1 = Federal, 2 = Industry, 3 = Academia, 4 = Self, 5 = Other

All Fields Are Required

Organization Name (N/A, if individual): DoD

Organization Type (see below for codes): 1 - Federal

Reference (Include section/paragraph or pdf line number): PIV ID Proofing Line 718

Comment (Include rationale for comment): This section states "When they are available, cryptographic security features SHOULD be used to validate evidence." DoD recommends providing clarification on meaning or intent, as it is currently unclear what "cryptographic security feature" is intended to cover.

Suggested Change: "DoD recommends clearly defining cryptographic security features by adding ""A cryptographic security feature could include, but is not limited to PKI mutual authentication, MRZ signature validation of passports,…"" or other relevant examples.
"

Organization Type: 1 = Federal, 2 = Industry, 3 = Academia, 4 = Self, 5 = Other

All Fields Are Required

Organization Name (N/A, if individual): DoD

Organization Type (see below for codes): 1 - Federal

Reference (Include section/paragraph or pdf line number): 2.2 Credential Requirement Line 564

Comment (Include rationale for comment): This section states "once the investigation is completed… report the final eligibility determination to the Central Verification System (or successor). This determination SHALL be record in the PIV enrollment record to reflect PIV eligibility for the PIV cardholder and, if applicable, their enrollment in the Continuous Vetting Program." DoD recommends clarification to better align this section with other language in the document about the PIV enrollment record and clarify that how it is constructed (or stored) is within the Federal PIV issuers purview.

Suggested Change: DoD recommends the sentence to updated to the following: "...This determination SHALL be recorded in (or available for) the PIV enrollment record..."

Organization Type: 1 = Federal, 2 = Industry, 3 = Academia, 4 = Self, 5 = Other

All Fields Are Required

Organization Name (N/A, if individual): NASA

Organization Type (see below for codes): 1

Reference (Include section/paragraph or pdf line number): 2.3

Comment (Include rationale for comment): 2.3 is vague. Needs further explanation of biometric data and it's use prior to this and the following sections using biometrics.

Suggested Change:
Further define Biometric Data and is use

Organization Type: 1 = Federal, 2 = Industry, 3 = Academia, 4 = Self, 5 = Other

Organization Name: HID Global

Organization Type: 2-Industry

Reference: Section 2.6.3 Authentication Using PIV Asymmetric Cryptography

Comment (Include rationale for comment): With WebAuthn and FIDO specifications reaching maturity and being available in all major platforms, the opportunity to leverage a widely available mechanism for authentication emerges and we believe there is value on recommending its usage.

Suggested Change: Add a section with guidance for using FIDO, for example like this:

6.2.3.x Authentication with a Derived FIDO Credential (FIDO-PK)

A FIDO credential could be created following the guidelines provided in Section 2.10 where a valid PIV card is used establish cardholder identity. The derived FIDO credential is then scoped and stored only by the relying party that would use it for subsequent re-authentication.

The following steps SHALL be performed for FIDO-PK:

• The relying system issues a navigator.credentials.get WebAuthn request to obtain an identity assertion. It is also possible that the relying party issues directly a lower level authenticatorGetAssertion to the authenticator, for example in an embedded system that does not have a WebAuthn API layer. This request includes the relying party id and MAY include a user id. If there is no user id in the request, this means that a FIDO Resident Key is expected to provide both identity and authentication.
• The relying system verifies that the returned assertion is valid. This includes verifying that the user identity verification information satisfies the relying system request.
• The relying system validates that the PIV certificate the FIDO-PK credential is bound to is valid using certificate path validation as specified in [RFC 5280]

Some of the characteristics of the FIDO-PK based authentication are as follows:

• Same benefits as the PKI-AUTH mechanism
• The relying system can control the types of authenticators it accepts during derived credential binding.
• The relying system can verify or request specific user verification mechanisms that can include PIN or biometric verification.
• Derived FIDO credentials can reside in roaming or embedded authenticators that work with desktop and mobile platforms.

All Fields Are Required

Organization Name (N/A, if individual): DoD

Organization Type (see below for codes): 1 - Federal

Reference (Include section/paragraph or pdf line number): 2.6 PIV Enrollment Record Line 642

Comment (Include rationale for comment): The draft FIPS 201-3 upgrades the requirements for PIV enrollment record (i.e., chain of trust) from optional to mandatory. At the same time, there remains confusion on the definition of PIV enrollment records vs. PIV accounts. DoD recommends additional clarification.

--

Suggested Change: "DoD recommends the definitions for PIV enrollment record and PIV account be added to the front of this section. Additionally, DoD recommends an update to those definitions to the following:

""PIV enrollment record is a sequence of related enrollment data sets that can be a specific record or a layer of abstraction for PIV issuers to maintain or assemble when needed to support distribution and auditing. The PIV enrollment record typically contains data collected at each step of the PIV identity proofing, registration, and issuance processes.""

""PIV account is the logical record containing credentialing information for a given PIV cardholder. It is not directly related to PIV enrollment records, but nomenclature to describe system/application accounts supported by PIV authentication. It could additionally be related to an account maintained in an Agency's Identity Federation Service Provider to support federated authentication transactions."""

Organization Type: 1 = Federal, 2 = Industry, 3 = Academia, 4 = Self, 5 = Other

All Fields Are Required

Organization Name (N/A, if individual): DoD

Organization Type (see below for codes): 1 - Federal

Reference (Include section/paragraph or pdf line number): 4.1.4.1 Mandatory Items on the Front of the PIV Card

Comment (Include rationale for comment): DoD requests that NIST add additional language to provide acceptable alternative approaches for Zone 2F: Name.

Suggested Change: DoD recommends adding the following to this section: "Line 1 contains Last Name only, using 10pt Arial Bold. If is is too long, the font size is lowered until it does fit. Line 2 contains First Name, Middle Name, Suffix. If it is too long, the Middle Name is reduced to Middle Initial. If it is still too long, font size is lowered until it does fit. 7pt is the lowest the font size used."

Organization Type: 1 = Federal, 2 = Industry, 3 = Academia, 4 = Self, 5 = Other

All Fields Are Required

Organization Name (N/A, if individual): DoD

Organization Type (see below for codes): 1 - Federal

Reference (Include section/paragraph or pdf line number): 2.10.1 Line 1111

Comment (Include rationale for comment): This Section requires the issuer of the PIV card and of a derived credential be one and the same entity; this definition is too narrow to account for Agencies where the issuers of derived credentials are not the organization that manages the PIV issuance. (REF: The "[d]erived PIV credentials SHALL be bound to the cardholder's PIV account only by the organization that manages that PIV account", and the binding is described as follows, "[i]issuance of a derived PIV credential is an instance of the post-enrollment binding".)

Suggested Change: "DoD recommends changing 1111-1113 as follows, ""Derived PIV credentials SHALL be bound to the cardholder’s PIV account only by the organization
that manages that PIV account life-cycle management bound to the cardholder’s PIV account or eligibility."""

Organization Type: 1 = Federal, 2 = Industry, 3 = Academia, 4 = Self, 5 = Other