Re: Updated draft

[Russ Housley <[e-mail]>]

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.