BaselineWatch
Desk
Your fleet and your work Fleetyour releases and the hardware they run onTriagewhat needs a decisionWatchlistthe products and platforms you runSaved searchesthe lists you come back to
This instance Sourceswhat is read, how often, under what termsDigestthe daily or weekly summary, and alerts
How it is drawn Appearancethe look and the colour schemeBrandingthe mark this instance wears
Owner sign-in

8.1.1 Entity Registration Function (was: User Registration Function)

NIST platform security: roots of trust, firmware and secure enclaves SP 800-57 Part 1 Rev. 5 against SP 800-57 Part 1 Rev. 4
All changes in this version
modified 8 Transition: A transition plan should be developed and followed so that the changeover part of 8.1

Title changed

Before · SP 800-57 Part 1 Rev. 4

User Registration Function

After · SP 800-57 Part 1 Rev. 5

UserEntity Registration Function

Control changed

Before · SP 800-57 Part 1 Rev. 4

During user registration, an entity interacts with a registration authority to become an authorized member of a security domain. In this phase, a user identifier or device name may be established to identify the member during future transactions. In particular, security infrastructures may associate the identification information with the entity’s keys (see Sections 8.1.5 and 8.1.6 ). The entity may also establish various information during the registration function, such as email addresses, or role and authorization information. As with identity information, this information may be associated with the entity’s keys by the infrastructure to support secure application-level security services. Since applications will depend upon the identity established during this process, it is crucial that the registration authority establish appropriate procedures for the validation of identity. Identity may be established through an in-person appearance at a registration authority, or may be established entirely out-of-band. Human entities are usually required to provide credentials (e.g., an identification card or birth certificate), while system entities are vouched for by those individuals responsible for system operation. The strength (or weakness) of a security infrastructure will often depend upon the identification process. [ FIPS201 ] and [ SP800-63 ] address requirements for establishing identity. User and key registration (see Section 8.1.6 ) may be performed separately, or in concert. If performed separately, the user registration process will generally establish a secret value (e.g., a password, PIN, or HMAC key); the secret value may be used to authenticate the user's identity during the key registration step. If performed in concert, the user establishes an identity and performs key registration in the same process, so the secret value is not required.

After · SP 800-57 Part 1 Rev. 5

During user registration into a key management system, an entity interacts with a registration authority to become an authorized member of a security domain. In this phase, aan userentity identifier or device name may be established to identify the member during future transactions. In particular, security infrastructures may associate the identification information with the entity’s keys (see Sections 8.1.5 and 8.1.6 ). The entity may also establishsupply various information during the registration function, such as an email addressesaddress, orand the entity's role and authorization information may be established by the system administrator. As with identity information, this information may be associated with the entity’s keys by the infrastructure to support secure application-level security services. Figure 5: Key-management states and phases Since applications will depend upon the identity established during this process, it is crucial that the registration authority establish appropriate procedures for the validation of identity. Identity may be established through an in-person appearance at a registration authority(i.e., oridentity mayproofing) be established entirelyand out-of-bandused. HumanIdentity entitiesproofing areis usuallyoften requiredperformed toby providean credentialsorganization (e.g., an identificationby cardthe ororganization’s birthsecurity certificateoffice), while systembut entitiesmay arealso vouchedbe forperformed by thosea individualsregistration responsibleauthority for systemthe operationkey management system. The strength (or weakness) of a security infrastructure will often depend upon the identification process. [FIPS FIPS201201 ]92 and [SP SP800-63800-63 ]93 address requirements for establishing identity. UserEntity and key registration (see Section 8.1.6 ) may be performed separately, or in concert. If performed separately, the userentity registration process will generally establish a secret value (e.g., a password, PIN, or HMAC key); the secret value may be used to authenticate the user'sentity’s identity during the key registrationkey-registration step. If performed in concert, the userentity establishes an identity and performs key registration in the same process, so the secret value is not required.

92 FIPS 201, Personal Identity Verification (PIV) of Federal Employees and Contractors . 93 SP 800-63, Digital Identity Guidelines . Pre- Activation

Active (Protect Only Process Only Protect and Process)

Destroyed Deactivated Suspended

(Process only) Compromised (Process only) (Process only) Pre-Operational Phase

Operational Phase

Post-Operational Phase

Destroyed Phase