RE: AES and PKCS #1 v1.5 Issue

["Jim Schaad" <[e-mail]>]

Blake,



> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Blake Ramsdell
> Sent: Wednesday, July 31, 2002 1:37 AM
> To: [e-mail]; 'Peter Gutmann'
> Cc: [e-mail]
> Subject: Re: AES and PKCS #1 v1.5 Issue
> 
> 
> 
> ----- Original Message ----- 
> From: "Jim Schaad" <[e-mail]>
> To: "'Blake Ramsdell'" <[e-mail]>; "'Peter 
> Gutmann'" <[e-mail]>
> Cc: <[e-mail]>
> 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