7. Section 2.1.2: Identifying an algorithm by an OID rather than an
AlgorithmID risks losing some specifics about the algorithm. For instance,
in a variable-key-size block cipher (e.g., RC5), the AlgorithmID carries the
key size, so this information would be lost. As a result, it may be possible
for an opponent to substitute a key of one size for a key of a different
size, which may lead to an attack that recovers the key one part at a time.
Presumably, the reason for avoiding a full AlgorithmID is that some of its
parameters are message-specific, such as IVs, but perhaps there is some
middle ground. Including the key size as an optional field of OtherInfo is
one possibility. Other parameters that will be lost in the case of RC5 are
the block size and the number of rounds.
I think this is weird, but this is how X9.42 does it, so our
choices are kind of limited.
This worries me. If there is a substitution attack that can recover the
key, I think we need to look at it VERY CAREFULLY. Has this same topic been
discussed on the X9.42 list? If so, can someone summarize the result? If
not, why not?
Having noted this, the field selections and names seem inappropriate: the
fact that keyInfo varies for a given key is contradictory. A preferable
organization would be to have keyInfo include the algorithm and optional
pubInfo, and put the counter in a field of its own, called keyPart, as in:
OtherInfo ::= SEQUENCE {
keyInfo KeySpecificInfo,
keyPart INTEGER(1..2^32-1) }
KeySpecificInfo ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
pubInfo OCTET STRING OPTIONAL,
keySize INTEGER OPTIONAL }
This structure is basically lifted from X9.42, so changing the
structure isn't really feasible for compatability reasons.
Changing the names while keeping the same ASN.1 doesn't seem
to add clarity.
I disagree: implementors can often be led astray by field names.
--Paul Hoffman, Director
--Internet Mail Consortium