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

March, 2007
anchors. Trust anchor distribution through software installation does not require that the relying
party be a direct participant in the infrastructure. The user must trust the software distribution
mechanism to avoid installation of malicious code. Extending this trust to cover trust anchors for
that application may be reasonable, and allows the relying party to obtain trust anchors without
any additional procedures.
Where a user registers keys with the infrastructure, additional mechanisms are usually available.
The user interacts securely with the infrastructure to register its keys (e.g., to obtain certificates),
and these interactions may be extended to provide trust anchor information. This allows the user
to establish trust anchor information with approximately the same assurance that the
infrastructure has in the user’s keys. In the case of a PKI:
1. The initial distribution of the public key of a trust anchor should be performed in
conjunction with the presentation of a requesting entity's public key to a registration
authority (RA) or CA during the certificate request process. In general, the trust anchor's
public key, associated parameters, key use, and assurance of possession are conveyed as a
self-signed X.509 public key certificate. The certificate is digitally signed by the private
key that corresponds to the public key within the certificate. While parameters and
assurance of possession may be conveyed in the self-signed certificate, the trust anchor's
identity and other information cannot be verified from the self-signed certificate itself
(see item 2 below).
2. The trusted process used to convey a requesting entity's public key and assurances to the
RA or CA shall also protect the trust anchor information conveyed to the requesting
entity. In cases where the requesting entity appears in person, the trust anchor
information may be provided at that time. If a secret value has been established during
user registration (see Section 8.1.1), the trust anchor information may be supplied with
the requesting entity’s certificate.
8.1.5.1.1.2 Submission to a Registration Authority or Certification Authority
Public keys may be provided to a Certification Authority (CA) or to a registration authority (RA)
for subsequent certification by a CA. During this process, the RA or CA shall obtain the
assurances listed in Section 8.1.5.1.1 from the owner of the key or an authorized representative
(e.g., the firewall administrator), including the owner’s identity.
In general, the owner of the key is identified in terms of an identifier established during user
registration (see Section 8.1.1). The key owner identifies the appropriate uses for the key, along
with the parameters and any assurances of validity and possession. In cases where anonymous
ownership of the public key is acceptable, the owner or the registration authority generates a
pseudonym to be used as the identifier. The identifier shall be unique for the naming authority.
Proof of Possession (POP) is a mechanism that is commonly used by a CA to obtain assurance of
possession during key registration. In this case, the proof shall be provided by the reputed owner
of the key pair. Without assurance of possession, it would be possible for the CA to bind the
public key to the wrong entity.
The (reputed) owner should provide POP by performing operations with the private key that
satisfy the indicated key use. For example, if a key pair is intended to support key transport, the
owner may decrypt a key provided to the owner by the CA that is encrypted using the owner's
public key. If the owner can correctly decrypt the ciphertext key using the associated private key
95