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.
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.
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.
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.
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.
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.)
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.
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.
I agree. Toolkits need to be algorithm agile.
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.
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