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

March, 2007
APPENDIX D: Revisions
The original version of this document was published in August, 2005. In May, 2006, the
following revisions were incorporated:
1. The definition of security strength has been revised to remove “or security level”
from the first column, since this term is not used in the document.
2. In the footnote for 2TDEA in Table 2 of Section 5.6.1, the word “guarantee” has
been changed to “assessment”.
3. In the paragraph under Table 2 in Section 5.6.1, the phrase “or security strength”
has been inserted into line 3. In line 5, the phrase “and the security strength to be
provided by the digital signature” has been inserted.
4. In Table 3 of Section 5.6.1, a list of appropriate hash functions have been inserted
into the HMAC and Key Derivation Function columns. In addition, a footnote has
been included for the Key Derivation Function column.
5. The original text for the paragraph immediately below Table 3 has been removed.
In March, 2007, the following revisions were made to allow the dual use of keys during
certificate requests:
1. In Section 5.2, the following text was added:
“This specification also permits the use of a key transport or key agreement
private key to generate a digital signature for the following special case:
When requesting the (initial) certificate for a static key establishment key,
the associated private key may be used to sign the certificate request. Also
refer to Section 8.1.5.1.1.2.”
2. In Section 8.1.5.1.1.2, the fourth paragraph was originally as follows:
“The owner provides 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 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. Where a key pair
is intended to support key establishment, POP shall not be afforded by
generating and verifying a digital signature with the key pair.”
The paragraph was change to the following, where the changed text is indicated in
italics:
“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
141