ietf-smime
[Top] [All Lists]

Re: What version of PKCS #7?

1997-10-07 07:15:16
To me, backward compatibiltiy of signatures is more importnat than any of
the new capabilities that are embodied in PKCS#7 v2.0.

Russ

At 09:24 PM 10/5/97 -0700, Blake Ramsdell wrote:
There have been some interesting points that have been raised in other
threads about moving forward with PKCS #7 v2.0 and vSomethingElse.  Some
background (please feel free to correct any inaccuracies -- this is from
memory):

At one point, it was decided to make as few modifications to PKCS #7
v1.5 in order to fix some of the problems with PKCS #7 that were brought
to light when it was being considered if MSP would fit into the current
S/MIME framework.  These changes were along the lines of key management,
key identifiers and some other things such as security labels and
mailing list expansion histories.  I believe that this discussion took
place around the IETF meeting in Memphis.

During the PKCS #7 workshop that was put on by RSADSI, the question was
raised "does anyone care if the MSP-friendly version of S/MIME uses PKCS
#7 v2.0 or should we stick with 1.5?"  I have been told that at the time
there was no objection, so the direction shifted to using PKCS #7 v2.0.
I was not present at the meeting, so if someone else has a different
recollection feel free to correct me.

During the S/MIME Developer Workshop that was held recently, I brought
up the following point:  To the extent that backwards compatibility is
desired with existing S/MIME clients, it would be best to extend PKCS #7
v1.5 in such a way that IF the algorithm suites fit into the S/MIME v2
profile AND keys could be identified using the current means of
IssuerAndSerialNumber AND any new features that were used did not affect
existing S/MIME clients (such as security labels), THEN we should use
PKCS #7 v1.5.  It then became clear that having the ability to use PKCS
#7 v2.0 wasn't useful, since implementors had to implement PKCS #7 v1.5
for compatibility with older S/MIME v2 products, so we might as well
modify PKCS #7 v1.5 a little bit to accommodate the new features and
dump the use of PKCS #7 v2.0.

The bottom line is that however clean it would be to move to PKCS #7
v2.0 (and I agree 100% that it will be cleaner), you break compatibility
with the (growing!!) installed base.  This scares the hell out of me.  I
am in NO WAY saying that this direction shouldn't be explored.

I am also in NO WAY saying that I represent everyone, and I completely
qualified my statements at the time as being the opinion of a single
vendor (and not necessarily the most prominent vendor, either.  Maybe
the noisiest...).

The point is that we need to come up with a migration strategy of some
sort.  I'm not sure that Flipping the Big Switch to PKCS #7 v2.0 is the
best way to go.

There are certainly people that are more qualified than I am to discuss
the issues of "backwards compatibility" vs. "progressing forward", and I
invite those people to step forward now and speak their piece.  My bias
as a developer of S/MIME products is along the lines of protecting my
customer's investments in technology, so certainly my opinions are not
necessarily objective in this area.

This note really isn't meant to be inflammatory, and isn't directed at
anyone in particular.  dpkemp's comments served as the catalyst, and I
hope that some discussion happens about this, because it is an important
issue.

Blake


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