Subject: Re: Mandatory to Implement Algorithms in CMS

From: "Housley, Russ" <[email-masked]>
Date: Tue, 17 Jul 2001 19:25:19 -0400

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

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 18 Jul 2001 12:17:38 -0700

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: [email-masked]
> [mailto:[email-masked]]On Behalf Of Housley, Russ
> Sent: Tuesday, July 17, 2001 4:25 PM
> To: [email-masked]
> Subject: Re: Mandatory to Implement Algorithms in CMS
>
>
>

---

From: "Housley, Russ" <[email-masked]>
Date: Wed, 18 Jul 2001 16:49:27 -0400

Jim:

I took that end of the spectrum because I knew that you would take the 
other.  Hopefully the result will be a good discussion that results in 
group consensus.

>the document, it is my belief that there will be a regular reset on the

I agree with this point, and it is the strongest reason to have no 
mandatory to implement algorithms for CMS.  However, no mandatory to 
implement algorithms forces each application of CMS to specify mandatory to 
implement algorithms, so the "reset" still happens, but it happens in 
another specification.

In the S/MIME case, the "reset" happens in the MSG specification.  Of 
course, there are other users of CMS, like CMC.

>mandate what algorithms are to be used.

As you point out above, this is the approach being taken for the PKIX 
certificate and CRL profile.  It is also the approach for the PKIX 
Attribute Certificate Profile.

I do get concerned if the using protocol is not being developed in the 
Security Area of the IETF.  People with the necessary background to provide 
algorithm advice may not be available.

>suddenly appear as S/MIME email messages unless you had SETI specific code

I understand your point.  I am not sure that I agree with the "you" in your 
first sentence, but I was certainly a part of those discussions.

>algorithms while toolkeys must be extensible.

I agree.  Toolkits need to be algorithm agile.

>for protocols that don't override the manditory algorithms.

I agree that applications of CMS should be able to select algorithms that 
are appropriate for their application.  On the other hand, specification of 
an mandatory to implement algorithm suite for CMS is one additional step 
closer to a common cryptographic algorithm suite for the whole IETF.  As 
you know, I have been an advocate for a common suite of algorithms for the 
IETF Security Area.  At the August 2000 IETF meeting, I made a presentation 
at the SAAG asking for the selection of such a suite after the announcement 
of the AES winner.

Russ

---

From: Eric Rescorla <[email-masked]>
Date: 18 Jul 2001 14:00:26 -0700

> mandate what algorithms are to be used.
I agree with Jim.

-Ekr