As another biased developer of existing S/MIME product, the thought of
the 'big switch' to PKCS #7 v2.0 (after having a successful and
widespread implementation of v1.5), and having to deal with backwards
(in)compatibility (not to mention code maintenance), scares the hell out
of me too. Seeing Paul Hoffman's description of the IETF Working Group,
basing the upcoming IETF effort on an enhanced v1.5 to include algorithm
independence, is a welcome relief!
But then, this decision to build upon v1.5 within the IETF process (with
which I COMPLETELY approve!), makes me question the parallel track of
v2.0. The existing v1.5 is solid, widely implemented, and works!
Perhaps my lack of involvement in the v2.0 development process grossly
limits my perspective, but I question why v2.0 stands as an essential
rewrite, rather than building upon v1.5. How do we justify the parallel
rewrite track, while standardizing v1.5, which will only further promote
its implementation?
Regards,
Karen
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
--
Karen Rosenthal Email: karenr(_at_)premenos(_dot_)com
Premenos Tel#: 1-510-688-2928
1000 Burnett Ave Fax#: 1-510-602-2133
Concord, CA 94520 Visit: http://www.premenos.com