Subject: RE: More X942-03 Comments

From: "Jim Schaad (Exchange)" <[email-masked]>
Date: Wed, 2 Dec 1998 11:37:53 -0800

Russ,

I have been thinking about this for a while and I want to make sure that I
have this correct.  

1.  The X9.42 document is the correct place to put sizing on the UKM
material as it is going to be tied to items such as the hash algorithm being
used.  I think this means that that the last sentence in the paragraph (on
pubInfo) should be alted to be 
"In CMS, it is provided as a parameter in the UserKeyingMaterial field
(encoded as an OCTET STRING).  If provided this pubInfo MUST contain 512
bits."

2.  The number 512 represents a minimum value which is determined by looking
at the hash function and making sure that a complete buffer has been filled.

3.  The number 512 is not a maximum number.  There is no real limit but 1023
would be the maximum number that could possibly make sense as there is no
additional benifit to filling the buffer more than twice.

4.  If (sizeof(ZZ) + sizeof(OtherInfo) - sizeof(pubInfo)) % 512 = 256, you
fill out this complete block size with random material.  You then fill half
of the next block with random material and half with fixed material.  Not
knowing enough about how these things work, is there any true benifit to
make sure that the half of fixed material is really random material?  From
your message it would appear that the first fill is the most important
portion and thus the minimum from step 1 is really what ever is needed to
fill out the last block following ZZ.

jim

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: Wednesday, November 25, 1998 1:41 PM
> To: Jim Schaad (Exchange)
> Cc: 'EKR'; [email-masked]
> Subject: Re: More X942-03 Comments
> 
> 
> Jim:
> 
> >1.  Section 2.1.2 in the paragraph on pubInfo:  There is a 
> description that
> >appears to say CMS defined UserKeyingMaterial as a 512-bit 
> value.  There are
> >two problems with this: a) CMS does not say anything about 
> the length of ukm
> >and b) no justification is shown here for a length of 
> 512-bits.  Is this a
> >magic length?
> 
> 512 bits is the SHA-1 block size, so it is the maximum 
> entropy that can be
> inserted in this manner.
> 
> Russ 
>

---

From: Russ Housley <[email-masked]>
Date: Thu, 03 Dec 1998 09:13:10 -0500

>(encoded as an OCTET STRING).  If provided this pubInfo MUST contain 512

This is fine with me.

>at the hash function and making sure that a complete buffer has been filled.

Not quite.  The SHA-1 algorithm has an internal block size of 512 bits.
So, making the UKM longer than 512 bits does not add any additional entropy.

>additional benifit to filling the buffer more than twice.

There is not any limit.  SHA-1 will take arbitrary length inputs.  There is
diminishing benifit for values larger than 512 bits.

>fill out the last block following ZZ.

The SHA-1 block is internal to the SHA-1 algorithm.  There is no reason for
us to align with the internal block.  We are simply using SHA-1 to mix
entropy from pubInfo into the key value.

Russ