BaselineWatch
Desk

10.1 Generalized Credential Identifier

NIST PIV and digital identity SP 800-116 Rev. 1 against SP 800-116
All changes in this version
removed 10 Avoid long-term, side-by-side operation of deployed and PIV technologies. Once PIV part of 10

Title changed

Before · SP 800-116

Generalized Credential Identifier

After · SP 800-116 Rev. 1

Generalized Credential Identifier

Control changed

Before · SP 800-116

FIPS 201 states that the CHUID data object contains the FASC-N data element, “which uniquely identifies each card.” The FASC-N actually serves two purposes: 1) identifying a PIV Card (and by correspondence, the cardholder); and 2) binding PIV data objects to the same PIV Card, because the identical FASC-N is contained in the CHUID, the PIV Authentication Key certificate, the Card Authentication Key certificate, the fingerprint biometric record, and the facial image object. Within the FASC-N, the fundamental card identifier is the (Agency Code, System Code, and Credential Number) triplet called the FASC-N Identifier. Uniqueness of the triplet is derived from a hierarchical approach to number assignment. The Agency Code field is statically assigned to a department, agency, or bureau through a registration process, and the assigned Agency Code values are listed in NIST SP 800-87. [SP800-87] The PIV Card Issuer for the registered department, agency, or bureau can, in turn, assign the System Code and Credential Number. The FASC-N, as adopted and extended by FIPS 201, meets the objective of HSPD-12 to identify Federal employees and contractors. The success of the FIPS 201 technical standard has led other communities of interest to consider PIV-like identification systems. For some of these communities the FASC-N Identifier is not an appropriate solution since they are not agencies of the Federal government. Also, the data representation of the FASC-N was chosen for compatibility with deployed systems (fixed-length hexadecimal), and may not be optimal for binary identifier values prevalent in commercial systems today. For these reasons, the CHUID data object also contains the GUID data element for future use. The GUID is a 16-byte, or 128-bit, binary field. It therefore improves on both the length and representation limitations of the FASC-N. Unfortunately, the GUID is only present in the CHUID, and does not serve to bind other data objects together. If the GUID were used to identify a PIV Card, the standard in effect would still require the FASC-N in the other data objects. These issues lead to a number of questions. If a community outside the Federal government adopts PIV-like technology, what identifier format, registrar, and governance structure should they use? How could larger, binary identifiers be used with PIV-like technology? Could existing, standardized universal identifiers such as the Universal Unique Identifier (UUID), Internet Protocol version 6 (IPv6) addresses, OpenID identifiers, or Object Identifiers (OIDs) be used in place of the FASC-N, in all of its uses? If non-Federal-government communities adopt identifiers other than the FASC-N, could FIPS 201 be modified to recognize multiple types of identifiers? Recommendation: Agencies should collaborate to standardize an enhancement or replacement of the FASC-N that accomplishes both credential identification and object binding, and supports an extensible framework for subject identification.

After · SP 800-116 Rev. 1

FIPS 201 states that the CHUID data object contains the FASC-N data element, “which uniquely identifies each card.” The FASC-N actually serves two purposes: 1) identifying a PIV Card (and by correspondence, the cardholder); and 2) binding PIV data objects to the same PIV Card, because the identical FASC-N is contained in the CHUID, the PIV Authentication Key certificate, the Card Authentication Key certificate, the fingerprint biometric record, and the facial image object. Within the FASC-N, the fundamental card identifier is the (Agency Code, System Code, and Credential Number) triplet called the FASC-N Identifier. Uniqueness of the triplet is derived from a hierarchical approach to number assignment. The Agency Code field is statically assigned to a department, agency, or bureau through a registration process, and the assigned Agency Code values are listed in NIST SP 800-87. [SP800-87] The PIV Card Issuer for the registered department, agency, or bureau can, in turn, assign the System Code and Credential Number. The FASC-N, as adopted and extended by FIPS 201, meets the objective of HSPD-12 to identify Federal employees and contractors. The success of the FIPS 201 technical standard has led other communities of interest to consider PIV-like identification systems. For some of these communities the FASC-N Identifier is not an appropriate solution since they are not agencies of the Federal government. Also, the data representation of the FASC-N was chosen for compatibility with deployed systems (fixed-length hexadecimal), and may not be optimal for binary identifier values prevalent in commercial systems today. For these reasons, the CHUID data object also contains the GUID data element for future use. The GUID is a 16-byte, or 128-bit, binary field. It therefore improves on both the length and representation limitations of the FASC-N. Unfortunately, the GUID is only present in the CHUID, and does not serve to bind other data objects together. If the GUID were used to identify a PIV Card, the standard in effect would still require the FASC-N in the other data objects. These issues lead to a number of questions. If a community outside the Federal government adopts PIV-like technology, what identifier format, registrar, and governance structure should they use? How could larger, binary identifiers be used with PIV-like technology? Could existing, standardized universal identifiers such as the Universal Unique Identifier (UUID), Internet Protocol version 6 (IPv6) addresses, OpenID identifiers, or Object Identifiers (OIDs) be used in place of the FASC-N, in all of its uses? If non-Federal-government communities adopt identifiers other than the FASC-N, could FIPS 201 be modified to recognize multiple types of identifiers? Recommendation: Agencies should collaborate to standardize an enhancement or replacement of the FASC-N that accomplishes both credential identification and object binding, and supports an extensible framework for subject identification.