Russ Housley wrote:
Steve:
As I understand the ES DH description there are two separate OIDs:
id-alg-ESDHwithRC2 and id-alg-ESDHwith3DES. This specifies both the key
transport and the symmetric encryption algorithms. What if someone wants
to use a different symmetric algorithm? Do they need to register an
id-alg-ESDHwithXXX OID and does everyone need to change their code to
support it? If history is anything to go by this will result in lots of
incompatible id-alg-ESDHwithXXX OIDs used by different applications.
Yes, an new OID is needed for each ESDHwithXXX. We could have assigned one
OID with a parameter of the symmetric algorithm, but then the structure is
not quite right since the symmetric algorithm OID might require IVs or some
other parameter.
OK let me see if I've got this right. The message encryption key and
parameters (e.g. IV) come from the ContentEncryptionAlgorithmIdentifier
field.
The key encryption key algorithm and key transport algorithm is
determined implicitly from the keyEncryptionAlgorithm (which is now a
"key transport algorithm and key encryption algorithm") and the IV is
'A5' as mentioned in 12.6.2 (6).
This implies that the content encryption algorithm can be anything but
the key encryption algorithm can only be RC2 or triple DES unless and
until more OIDs are registered.
Although 3DES is mandatory for S/MIME I suspect someone is going to want
to use DES, Blowfish, Idea or maybe RC5 and would not want to implement
another symmetric algorithm just for the key wrap. Considering the
change in US crypto laws there may be good reasons why someone would
want to use DES for 56 bits to avoid possible patent problems with 56
bit RC2. IMHO we should at least provide some syntax where this can be
done without necessitating OID registration and the possible chaos of
multiple OIDs.
I agree that just using an AlgorithmIdentifier for the KEK algorithm is
not strictly speaking correct because the IV will be included but 'A5'
will be used for the IV. However this appears to be allowed for in
12.6.1:
Some key-encryption algorithm identifiers include an IV as part of
the parameters. The IV must still be the constant above.
Adding support for arbitrary key wrapping algorithms could be done in
two ways. One as you mention is to include the KEK algorithm in the
KeyEncryptionAlgorithmIdentifier parameters. The other is to change
KeyTransRecipientInfo to read:
KeyTransRecipientInfo ::= SEQUENCE {
version CMSVersion, -- always set to 0 or 2
rid RecipientIdentifier,
keyTransportAlgorithm KeyTransportAlgorithmIdentifier,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }
So that for example for triple DES KeyEncryptionAlgorithmIdentifier
would be id-alg-ESDH and KeyEncryptionAlgorithmIdentifier would be
des-ede3-cbc the IV present being ignored for the key wrap and 'A5' used
instead (or maybe even forcing the IV parameter to be 'A5' and returning
and error if it is not).
A similar thing could be done with the mailing list wrapping algorithms.
This would have the advantage that any wrapping algorithms could be
handled automatically (if the algorithm was supported) rather than
having to add algorithm specific code for each wrapping OID.
Steve.
--
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant.
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: shenson(_at_)drh-consultancy(_dot_)demon(_dot_)co(_dot_)uk
PGP key: via homepage.