ietf-smime
[Top] [All Lists]

Re: AES and PKCS #1 v1.5 Issue

2002-07-31 01:43:54

----- 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


<Prev in Thread] Current Thread [Next in Thread>