Part 1: General - Computer Security Resource Center - National ...

March, 2007
and then provide evidence that the key was correctly decrypted (e.g., by encrypting a random
challenge from the CA, then the owner has established POP. However, when a key pair is
intended to support key establishment, POP may also be afforded by using the private key to
digitally sign the certificate request (although this is not the preferred method). The key
establishment private key shall not be used to perform signature operations after certificate
issuance.
As with user registration, the strength of the security infrastructure depends upon the methods
used for distributing the key to an RA or CA. There are many different methods, each
appropriate for some range of applications. Some examples of common methods are:
1. The public key and the information identified in Section 8.1.5.1.1 is provided by the
public key owner in person, or by an authorized representative of the public key owner.
2. The identity of the public key owner is established at the RA or CA in person or by an
authorized representative of the public key owner during user registration. Unique,
unpredictable information (e.g., an authenticator or cryptographic key) is provided at this
time by the RA or CA to the owner as a secret value. The public key and the information
identified in Section 8.1.5.1.1 is provided to the RA or CA using a communication
protocol protected by the secret value. The secret value should be destroyed by the key
owner as specified in Section 8.3.4 upon receiving confirmation that the certificate has
been successfully generated. The RA or CA may maintain this secret value for auditing
purposes, but the RA or CA should not accept further use of the secret value to prove
identity.
When a specific list of public key owners are pre-authorized to register keys, identifiers
may be generated in bulk. In this case, it is critical to protect the secret value from
disclosure, and the procedures must demonstrate that the chain of custody was
maintained. The secret value’s lifetime should be limited, but must allow for the public
key owner to appear at the RA or CA, generate their keys, and provide the public key
(under the secret value’s protection) to the RA or CA. Since it may take some time for
the public key owner to appear at the RA or CA, a two or three week lifetime is probably
reasonable.
When public key owners are not pre-authorized, the RA or CA shall generate the
identifier in the user’s presence. In this case, the time limit may be much more restrictive,
since the public key owner need only generate their keys and provide the public key to
the CA or RA. In this case, a 24-hour lifetime for the secret value would be reasonable.
3. The identity of the public key owner is established at the RA or CA using a previous
determination of the public key owner’s identity. This is accomplished by “chaining” a
new public key certificate request to a previously certified digital signature key pair. For
example, the request for a new public key certificate is signed by the owner of the new
public key to be certified. The signing private key used to sign the request should be
associated with a verification public key that is certified by the same CA that will certify
the new public key. The request contains the new public key and any key related
information (e.g., key use and parameters). In addition, the CA shall obtain assurance of
public key validity and assurance that the owner possesses the associated private key.
96