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