Blake,
-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Blake
Ramsdell
Sent: Wednesday, July 31, 2002 1:37 AM
To: jimsch(_at_)exmsft(_dot_)com; 'Peter Gutmann'
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: Re: AES and PKCS #1 v1.5 Issue
----- Original Message -----
From: "Jim Schaad" <jimsch(_at_)nwlink(_dot_)com>
To: "'Blake Ramsdell'" <blake(_at_)brutesquadlabs(_dot_)com>; "'Peter
Gutmann'" <pgut001(_at_)cs(_dot_)auckland(_dot_)ac(_dot_)nz>
Cc: <ietf-smime(_at_)imc(_dot_)org>
Sent: Tuesday, July 30, 2002 7:49 PM
Subject: RE: AES and PKCS #1 v1.5 Issue
4. [Blake] Specification purity says that key management and content
encryption documents should not restrict each other.
- Blake - I just completely disagree on this issue. I
think that each
type of algorithm can put restrictions and updates on usage for the
other type. I believe that it is perfectly reasonable for a content
encryption algorithm to impose limitations on what key management
algorithms are allowed. It could also modify the algorithms as
necessary (for example the original drafts change the key derivation
algorithm used with AES and D-H). I can get behind the
purity of one
algorithm-one document, but not that they cannot put restrictions on
each other.
I did not say that an algorithm profile could not put a
restriction its use with another algorithm. I said that if
the reason for the restriction is not specific to the
algorithm (in this case, the problems with PKCS #1 v1.5 are
not specific to its use with AES), then it doesn't make sense
to single it out in the algorithm profile.
Once again, the problem is not specific to the exact
combination of AES and PKCS #1 v1.5, and so we are not doing
the right thing if we have not covered it adequately in
either the CMS or MSG specification. If we're going to
preclude the use of PKCS #1 v1.5, we should do it completely
or not at all. It is unreasonable, redundant and wasteful to
mandate that all future symmetric algorithm profiles include
information about just how bad PKCS #1 v1.5 is, when we can
just provide guidance for the use / nonuse of PKCS #1 v1.5 in
CMS or MSG or some other general specification.
The point is not that AES should not use PKCS #1 v1.5, the
point is that if AES should not use PKCS #1 v1.5, then no
future symmetric algorithm should use PKCS #1 v1.5. Existing
algorithms can be grandfathered, and we progress using new
guidelines for key wrapping. For each draft author to take
their own individual stand on this issue and put their own
take on this into their draft doesn't seem productive.
In my mind, we are in one of two states at this point:
1. CMS and MSG are completely reasonable in their treatment
of PKCS #1 v1.5, and no language with respect to this is
required in the AES draft. If this is the case, I recommend
that we remove the PKCS #1 v1.5 specific language from the AES draft.
2. CMS and MSG are incomplete in their treatment of PKCS #1
v1.5, and the language in the AES specification is attempting
to remedy this. If this is the case, I recommend that we
remove the PKCS #1 v1.5 specific language from the AES draft,
and clarify the language accordingly in CMS and MSG.
Blake
First, I would argue that the language to deal with this in MSG must be
considered to be extranious and could be removed altogether as far as I
am concerned. Any argument based on it's presense in MSG is S/MIME
based on CMS based.
Second, CMS currently does not have any restrictions in RFC 2630 or its
follow on about algorithms. This is by design and I still feel is
proper.
Third, we cannot suddenly outlaw PKCS #1 v1.5 without doing great harm
to the current community. [Side note, I think that outlawing MD2 would
not cause great harm but that is a different problem.] I don't have any
reason to believe that 3DES, RC2 and other algorithms of the same
general strength need to have a prohibition on v1.5 as they are the
current set of standards and we don't have an easy attack based on the
current uses.
Fourth, with the introduction of AES we are, in theory, bumping up the
level of difficulty in dealing with content encryption algorithms and
should fix any known key transport problems at the same time. This is
what I have attempted to do.
Last, I would be happy to move this language to CMSALG, but am unclear
as to how it should be phrased. You MUST only use with the following
content encryption algoriths? This would mean that either the list
would need to be exhaustive (3DES, RC2, CAST-128, IDEA,...) and these
standards would all need to be either informational or moved up the
standards track. Or it would be small (3DES and RC2) and all of the
other algorithms would need to be re-issued saying, and me too. But
this also violates your sense of purity. I am unable to come up with a
good way to specify this without putting it into the AES draft and I
feel strongly that this needs to be specified.
Jim