Jim & Steve:
16. Section 12.3.1.1 - In the KeyWrapAlgorithm is the IV present and
is its
value the constant 'A5' repeated n time? The IV was not present in the
previous versions but would appear to be present now. We still have
the IV
restriction on the key wrap algorithm however.
There is no field needed to carry the IV as it is always "A5...A5". For
3DES,
the parameter is always NULL, and for RC2 the parameter is the effective
key
length. Where do you see an IV?
OK -- I see where I got confused. I started with the second paragraph in
section 12.3.1 and made a leap of incorrectness into the fact that the
KeyWrapAlgorithm was going to be rc2-cbc not id-alg-RC2wrap. I don't see
any clarifications that need to be added to the text, I was just skimming
the changes too fast.
Just to add a little comment of my own since I suggested part of this.
My primary reason for this change is to allow algorithms other than RC2
and 3DES to be used with key agreement. In the case of RC2 and 3DES a
special algorithm identifier form is defined without the IV. In other
cases, such as (single) DES the normal algorithm identifier would be
used which would include an IV: but in this case it would be ignored
and A5 used.
Yes -- this is what I kind of expected to have happen. I would however make
an assert that the IV MUST be 'A5' and encoded as such.
Presetly, two key wrap algorithm identifiers are defined. They are:
id-alg-3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 3 }
id-alg-RC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 4 }
People who want to use E-S D-H with other algorithms are free to assign
additional algorithm identifiers for use in the KeyWrapAlgorithm. In fact,
these additional algorithms need not follow the technque specified in CMS
Secion 12.6. These additional assignments will not represent "must" implement
or "should" implement algorithms.
I consider this issue closed.
Russ