ietf-smime
[Top] [All Lists]

Re: Updated draft

1999-03-22 12:21:47
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.



<Prev in Thread] Current Thread [Next in Thread>
  • Re: Updated draft, Russ Housley <=