----- Original Message -----
From: "Jim Schaad" <jimsch(_at_)nwlink(_dot_)com>
To: "'Blake Ramsdell'" <blake(_at_)brutesquadlabs(_dot_)com>; "'Peter Gutmann'"
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
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.