Eric:
I have a few comments. Most are nit-picks.
Russ
= = = = = = = = = =
Abstract
This document standardizes one particular Diffie-Hellman variant,
based on the ANSI X9.42 draft, developed by the ANSI X9F1 working
group. Diffie-Hellman is a key agreement algorithm used by two par-
ties to agree on a shared secret. An algorithm for converting the
shared secret into an arbitrary amount of keying material is pro-
vided. The resulting keying material is used as a symmetric encryp-
tion key. The D-H variant described requires the recipient to have a
certificate, but the originator may have a static key pair (with the
public key placed in a certificate) or an ephemeral key pair.
This is the only place you use the D-H abbreviation. Please spell it out.
2.1. Key Agreement
The first stage of the key agreement process is to compute a shared
secret number, called ZZ. When the same originator and recipient
public/private key pairs are used, the same ZZ value will result.
The ZZ value is then converted into a shared symmetric cryptographic
key. When the originator employs a static private/public key pair,
the introduction of public random values are used to ensure that the
resulting symmetric key will be different for each key agreement.
Please replace the last sentence. Since onlt partyAInfo is supported, only
one public random can be used:
When the originator employs a static private/public key pair,
the introduction of a public random value ensures that the
resulting symmetric key will be different for each key agreement.
2.1.1. Generation of ZZ
X9.42 defines that the shared secret ZZ is generated as follows:
ZZ = g ^ (xb * xa) mod p
Note that the individual parties actually perform the computations:
ZZ = yb ^ xa (mod p) = ya ^ xb mod p
Please pick one notation. I think this is the only place "(mod p)" is
used. My preference is:
ZZ = (yb ^ xa) mod p = (ya ^ xb) mod p
where ^ denotes exponentiation
ya is party a's public key; ya = g ^ xa mod p
yb is party b's public key; yb = g ^ xb mod p
xa is party a's private key
xb is party b's private key
p is a large prime
q is a large prime
g = h^{(p-1)/q} mod p, where
h is any integer with 1 < h < p-1 such that h{(p-1)/q} mod p > 1
(g has order q mod p; i.e. g^q mod p = 1 if g!=1)
j a large integer such that p=qj + 1
(See Section 2.2 for criteria for keys and parameters)
In [CMS], the recipient's key is identified by the CMS RecipientIden-
tifier, which points to the recipient's certificate. The sender's
key is identified using the OriginatorIdentifierOrKey field, either
by reference to the sender's certificate or by inline inclusion of a
key.
Please change "key" to "public key" in the last sentence.
2.1.2. Generation of Keying Material
[snip]
Note that these ASN.1 definitions use EXPLICIT tagging. (In ASN.1,
EXPLICIT tagging is implicit unless IMPLICIT is explicitly speci-
fied.)
Please move this note right before or right after the ASN.1.
To generate a KEK, one generates one or more KM blocks (incrementing
counter appropriately) until enough material has been generated. The
KM blocks are concatenated left to right in the obvious order. I.e.
KM(counter=1) || KM(counter=2)...
I think that "obvious order" is asking for trouble. You are better off
deleting the phrase if you cannot think of a better way to say it.
2.1.4. Keylengths for common algorithms
Some common key encryption algorithms have KEKs of the following
lengths.
3DES-EDE-ECB 192 bits
RC2-128 128 bits
RC2-40 40 bits
Please change "3DES-EDE-ECB" to "3-key 3DES". The mode does not determine
key lenght, but the number of keys does. You might want to include "2-key
3DES" to make this clear.
2.1.6. Example 1
ZZ is the 20 bytes 00 01 02 03 04 05 06 07 08 09
0a 0b 0c 0d 0e 0f 10 11 12 13
The key wrap algorithm is 3DES-EDE wrap.
No partyAInfo is used
Please add missing period.
Acknowledgements
The Key Agreement method described in this document is based on work
done by the ANSI X9F1 working group. The author wishes to extend his
thanks for their assistance.
The author also wishes to thank Burt Kaliski, Paul Hoffman, Stephen
Henson, Russ Housley, Brian Korver, John Linn, Jim Schaad, Mark
Schertler, Peter Yee, and Robert Zuccherato for their expert advice
and review.
You may wish to use alphabetical order here.
[PKIX] Housley, R., Ford, W., Polk, W., Solo, D., "Internet X.509 Public
Key Infrastructure Certificate and CRL Profile", RFC-XXXX.
RFC 2459. Also, add date.