Subject: RE: Comments on x942-05 draft

From: "Linn, John" <[email-masked]>
Date: Fri, 19 Feb 1999 08:27:32 -0500

I'm trying to mind p's and q's here ;-).  I was questioning the last
sentence in 2.2's 2nd paragraph, which states "p must be a minimum of 160
bits long", recognizing X9.42's recommendation for a significantly larger p.
Earlier in the same paragraph, there's a separate statement about q being at
least 160 bits; I wasn't asking about that or private key sizes, just
specifically about p. 

--jl

> ----------
> From: 	EKR[SMTP:[email-masked]]
> Sent: 	Wednesday, February 17, 1999 5:19 PM
> To: 	Russ Housley
> Cc: 	[email-masked]; [email-masked]
> Subject: 	Re: Comments on x942-05 draft
> 
> Russ Housley <[email-masked]> writes:
> 
> > John said:
> > >> In 2.2, 2nd paragraph, suggest changing "...m MUST be >=160" -> "...m
> MUST
> > >> be >= 160 bits in length". Later in the paragraph, is 160 bits
> intended as
> > >> the appropriate minimum length for p?  (Note, by comparison, that
> X9.42
> > >> requires a multiple of 256 bits with a minimum of 512.)
> > 
> > Then Eric replied:
> > >I'd prefer 160. 512 seems like overkill, and has unpleasant performance
> > >tradeoffs.
> > 
> > I do not have a problem allowing people to have 512-bit private keys.
> The
> > performance impact is imposed on themselves.  I also think that we
> should
> > permit 160-bit private keys for those people that belive 80-bit security
> is
> > useful.
> > 
> > In summary, I think that we should allow private keys to be between 160
> and
> > 512 bits.
> That's no problem, but John indicates that X9.42 has a MINIMUM of 512,
> which I consider unacceptable.
> 
> As far as I'm concerned people should be allowed to go up to |p|
> 
> -Ekr
> 
> 
> -- 
> [Eric Rescorla                                   [email-masked]]
>

---

From: Russ Housley <[email-masked]>
Date: Fri, 19 Feb 1999 15:46:15 -0500

John:

You are correct.  There seems to be a typo.  p needs to be bigger than q and x.

Russ

---

From: Russ Housley <[email-masked]>
Date: Thu, 11 Mar 1999 16:19:48 -0500

Burt:

You are correct.  The corrent write-up does specify the content-encryption
algorithm OID.  I agree that we should replace the content-encryption
algorithm OID with the key-wrap algorithm OID.

Russ

At 01:07 PM 3/10/99 -0800, Burt Kaliski wrote:
>Dear Russ --
>
>Thanks for the CMS excerpt.
>
>My question is about the parameters to the X9.42 KDF, specifically the OID
>associated with the derived key. The field is defined as follows:
>
>	algorithm is the ASN.1 algorithm OID of the symmetric algorithm with
>which
>	     this KEK will be used. 
>
>I'm assuming that within CMS, the OID would be id-alg-CMS3DESwrap or
>id-alg-CMSRC2wrap.
>
>x942-05 is unclear about this, as "symmetric algorithm" might be interpreted
>as the OID for RC2 or triple-DES, not the key wrapping mechanism. I think
>it's better to identify the key wrapping mechanism, in case there's more
>than one with the same underlying symmetric algorithm. One risk, of course,
>is that the OID for the key wrapping mechansim might be too generic -- so
>there should be some way to include parameters (if any) to the key wrapping
>OID as input to the KDF.
>
>-- Burt
>
>
>> ----------
>> From: 	Russ Housley[SMTP:[email-masked]]
>> Sent: 	Friday, March 05, 1999 10:05 AM
>> To: 	Burt Kaliski
>> Cc: 	Eric Rescorla; [email-masked]
>> Subject: 	RE: Comments on x942-05 draft 
>> 
>> Burt:
>> 
>> Please take a look at CMS for this answer.  The AlgorithmIdentifier used
>> to
>> name Ephemeral-Static Diffie-Hellman has a parameter, and that parameter
>> specifies the key wrap algorithm.
>> 
>> Russ
>>