ietf-smime
[Top] [All Lists]

RE: Mandatory to Implement Algorithms in CMS

2001-07-18 12:17:44

I think that this is a bad idea.  I will counter this by proposing that the
Algorithm document be written in the same vein as the Certificate algorithm
draft.

1.  I would like the basic structures to get to the standard level so that
they are known stable by all entities.  If the algorithms are included in
the document, it is my belief that there will be a regular reset on the
status of this document.

2.  I believe the there should be no MUST implement algorithms for CMS.
This is an issue for the protocol itself to decide not for CMS to decide for
all protocols.  Different protocols will progress on accepting or mandating
new algorithms at different rates (look at how slow TLS has been on adopting
AES).  Thus it is the protocol not the underlying CMS objects that will
mandate what algorithms are to be used.

3.  You shoved this down my throat for Certificates (no manditory
algorithms), so I think you need to accept the consequences of logical
extensions.  If certificates, which may be common across multiple protocols
are not going to have a fixed set of manditory algorithms, why should CMS
based protocols be required to have a manditory set of algorithms.  The CMS
messages are not going to be jumping between protocols except on a very
specific level.  (Use of a CMS based SETI would not have these messages
suddenly appear as S/MIME email messages unless you had SETI specific code
to handle them.)

4.  Toolkits based on CMS are going to have to allow for addition of other
algorithms. This can be seen from the number of documents that have appeared
providing for other algorithms to be used with CMS. (Note that there has not
been any additional algorithms proposed for certificates beyond the EC
versions.)  Protocol specific code is going to be written to the manditory
algorithms while toolkeys must be extensible.

5.  Even if you specify manditory algorithms for CMS, you still have the
problem of dealing with protocols that will say.  Implement CMS, but the
manditory algorithms are X, Y and Z not A, B and C.  Thus providing a
manditory to implement for CMS only buys a small amount of breathing room
for protocols that don't override the manditory algorithms.

jim

-----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 Housley, 
Russ
Sent: Tuesday, July 17, 2001 4:25 PM
To: ietf-smime(_at_)imc(_dot_)org
Subject: Re: Mandatory to Implement Algorithms in CMS



I hoped that there would be considerable discussion on this
issue.  Maybe I
need to propose one extreme to get the debate rolling.

I proposed that the protocol and algorithm discussion be
placed in one
document.

Russ


At 09:13 AM 6/28/2001 -0400, Housley, Russ wrote:

Dear S/MIME WG:

A few weeks ago, Jim Schaad submitted a simple comment on
draft-ietf-smime-rfc2630bis-00.  Jim wrote:

2.  I have a sever problem with the following text
"However, implementations
of the CMS MUST support the mandatory to implement
algorithms specified in
[CMSALG], or its successor."  It is my believe that this
statement should be
removed for the following reasons:

a)  This violates the letter and spirit of the IETF process
rules for
pushing documents to standards.  In my opinion if this
becomes a standard
then CMSALG must also be a standard.  Also if CMSALG is
reset to draft, so
must this draft.  The words "MUST support" is extremely normative.

b)  If I create a toolkit or other system and publish that
I am STD [CMS]
conformant.  It does not make sense that by updating the
set of required
algorithms I loose conformance to that standard.  I was
compliant, I loose
compliance through no action of mine.  This argues that a
new standard
number should be applied.

c)  The reasoning behind not having a MUST for certificates
is even more
strongly appliciable here.  While certificates and
heirarchies can move
between different applications (thus making the arugment
that application
spaces should mandate algorithms a somewhat odd argument),
that is not the
case with CMS objects.  If S/MIME and CMS/SET were to specificy that
different content encryption algorithms be required, there is no
interactions between the spaces.  An S/MIME message would
never be consumed
(successfully) by a CMS/SET application nor would one
expect it to be used.

From this standpoint I think that not requiring a MUST on
algorithms from
CMS makes sense.

I have discussed this issue with both of the Security Area
Directors.  Only
one thing is clear: we cannot have a MUST statement that references
"[CMSALG], or its successor."

If we were to achieve Full Standard status with the
specification that we
are working on, then changing the mandatory to implement
algorithm would
reset the status of the updated protocol to Proposed
Standard.  I expect
such a change at some point, probably to change the
mandatory cipher from
Triple-DES CBC to AES CBC.

There are other protocols besides S/MIME that are using CMS.
 If CMS has
mandatory to implement algorithms, then many of the
interoperability issues
are handled by a simple reference.  On the other hand, if
CMS does not
include any mandatory to implement algorithms, then each
reference must
specify them.

As many of you know, I am arguing for a common set of cryptographic
algorithms throughout the IETF Security Area.  Having each
CMS referee
specify their own set of algorithms does not support this objective.

What do others think?

Russ



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