Hi Russ,
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.
Good catch. However, you're caught yourself too!
The original reason to include bit reversal was: (raised by James Manger)
"One attack against this proposal springs to mind. An attacker knowing some
of the plaintext (a prefix in a field for instance) can use the
corresponding ciphertext block as the next encrypted CEK, i.e. as
KEKRecipientInfo.encryptedKey. Now the attacker know the next CEK. [note.
this attacks may be unfair - by attacking something the proposal was not
claiming to protect - but I am unsure what others believe the proposal does
protect]"
And I'm afraid that with bitwise-NOT and the DES complementarity property
(thanks to William Whyte for spotting this), the original bad feature raises
its head again (isn't key management fun:-).
William suggests byte reversal instead, which seems ok from both perspectives.
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.
Disagree. You MUST support CEKReference and CEKMaxDecrypts, and MAY support
KEKDerivationAlgorithm. (If that's not clear I will make it more so.)
CEKReference clearly has to be present or everything else is to be ignored.
CEKMaxDecrypts is only really a hint in any case, so if its not present the
recipient just keeps the CEKReference for a locally configured period (in
reality this'd be specified in some specification for the use case of this
trick).
KEKDerivationAlgorithm clearly has to be present if algorithms will change
for MSG2, otherwise not.
All in all, I disagreee that the implementer is left in limbo, but can add
text like the above if that helps.
I suggest that a single attribute that
includes some OPTIONAL fields might be preferable.
I think this is a matter of taste - you prefer a single "structured" attribute,
my preference is for a set of "flat" attributes (I think its easier to code for
most ASN.1 handlers). 'Course, I'll switch if that's the concensus (i.e. if a
few other folks chip in on the subject).
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.
That last point is fair enough. OTOH, the current syntax also has the
required extensibility via the attribute OID for KEKDerivationAlgorithm
(which maybe should therefore be called PKCS5KEKDerivationAlgorithm?).
Stephen.
--
____________________________________________________________
Stephen Farrell
Baltimore Technologies, tel: (direct line) +353 1 881 6716
39 Parkgate Street, fax: +353 1 881 7000
Dublin 8. mailto:stephen(_dot_)farrell(_at_)baltimore(_dot_)ie
Ireland http://www.baltimore.com