Re: WG Last Call:draft-ietf-smime-rcek-01.txt

[Russ Housley <housley@xxxxxxxxxx>]

I have two concerns about this document.

1.  The default transformation from a CEK to a KEK is reversing the order 
of the bits.  For a DES or 3DES key, this will cause parity bits to become 
keying material.  I would prefer a default transformation that did not mix 
parity and keying material since 3DES in the S/MIME mandatory to implement 
cipher.  I propose a bitwise NOT.

2.  The document defines three related attributes.  It does not tell the 
implementor how to deal with the situation where some (but not all) of the 
attributes are implemented.  I suggest that a single attribute that 
includes some OPTIONAL fields might be preferable.  Perhaps:

   CEKReference ::= SEQUENCE {
      ref				OCTET STRING,
      maxDecrypts		INTEGER OPTIONAL,
      kekDerivationAlg		OBJECT IDENTIFIER DEFAULT id-alg-bitwise-not,
      kekDerivationParam	ANY DEFINED BY kekDerivationAlg OPTIONAL  }

In addition to making it straightforward to discuss the interactions 
between the fields, this approach allows other KEK Derivation algorithms to 
be specified in the future without any modification to the 
specification.  If the bit order reversal algorithm is needed, a simple OID 
assignment and statement that parameters are not needed completes the 
task.  The PKCS#5 KEK derivation is an OID assignment where parameters are 
required.

Comments?

Russ