Subject: Re: X942-03

From: Russ Housley <[email-masked]>
Date: Tue, 01 Dec 1998 10:00:13 -0500

Eric:

>> For consistency, please use the spelling that CMS inherited from PKCS#7
v1.5:
>> 	key-encryption key
>> 	content-encryption key
>All right.
Good.

>> I expected section 2.1.1 to include: g^q (mod p) == 1.
>I'm not sure that this is sufficient. However, it follows from
>the following criterion, (which I just added) which is listed 
>in FIPS-186
>
>      h is any integer with 1 < h < p-1 such that h(p-1)/q mod p > 1
>        (g has order q mod p)
Okay.

>> In section 2.1.2, you say: "algorithm is the ASN.1 algorithm OID of the
>> symmetric algorithm with which this KEK will be used."  I think it would be
>> more clear to say that is is the OBJECT IDENTIFIER protion of the symmetric
>> algorithm identifier; no parameters associated with the symmetric algorithm
>> identifier are used.
>How about:
>algorithm is the ASN.1 algorithm OID of the symmetric algorithm with which 
>  this KEK will be used. Note that this is NOT an AlgorithmIdentifier,
>  but simply the OBJECT IDENTIFIER. No paramters are used.
This is fine.

>> Later in section 2.1.2, you say: "Note that pubInfo is required in
>> Static-Static mode, but MAY appear in Ephemeral-Static mode."  I would
>> prefer to see the first half of the sentence reworded to include "MUST."
>Note that pubInfo MUST be used in Static-Static mode,
>but MAY appear in Ephemeral-Static mode.
Fine.

>> In section 2.1.5, you need to upcase "MAY NOT."
>Hmm... This makes me a little queasy. This is a descriptive, not
>prescriptive statement...
Okay.

>> In section 2.2, you say: " When symmetric ciphers stronger than DES are to
>> be used, a larer m may be advisable."  This screams for a paragraph in
>> Security Consderations.
Are you doing a paragraph?

>> Please add a section parallel to section 2.3 that describes Static-Static
>> Mode.  The term is used in the body of the document, so it probably needs a
>> description.
>All right.
Thanks.

>> Please add a paragraph is the security Considerations section regarding the
>> size of the private key, x, and the size of the generated symmetric keys.
>> In general, the private key need to be twices the size of the resulting
>> symmetric keys.  Note: KEA uses a 160 bit private key to generate 80 bit
>> SKIPJACK keys.
>I agree that you are correct here, but this puts us in very unpleasant
>waters: 
>The FIPS-186 key/parameter generation algorithm only describes how
>to generate for m==160. X9.42 DOES describe how to generate for
><arbitrary m. However, X9.42 isn't publicly available, so we shouldn't
>make a normative reference to it, but rather should describe the
>procedure inline.
>
>I suppose I could try to write something like:
>Follow FIPS-186, except substituting 'm' for 160, but I'm pretty
>nervous about that. 
>
>I'd like to get the sense of the group here.
Understand.  

Russ