Chris, I believe these points are important, and perhaps more important than
the particular issues at hand. So please allow me to wax philosophical.
As a consumer, all things being equal, I like products that support lots of
interoperability modes too. Beer, champagne, hot dogs, filet mignon, ice
cream, apple pie, floor wax and desert topping -- they're all great, at least
if you can afford them.
But as a vendor, I am increasingly concerned about the amount of feature creep
that we are seeing every day in both the PKIX and SMIME groups, apparently
almost unconstrained by business requirements. We need interoperability, and
that should not mean lowest common denominator, but it also shouldn't mean
being all things to all men.
Although the development cost of adding a particular feature tends to go up
linearly, the testing and interoperability costs tend to go up with the SQUARE
of the features, all of which generally have to be tested in all possible
combinations. That is both expensive and time consuming, and leads to products
that are either buggy or late, or typically both. And that clearly doesn't
benefit the consumer at all.
As a result, Product Management is increasingly inclined to "Just Say NO" to
these kinds of features, which ends up making IETF standards increasingly
irrelevant and making interoperability that much harder, rather than easier.
The real challenge in creating standards is therefore not to attempt to see how
many you can create with all of their rococo variations, but rather how few you
can get by with and still get the job done. To the extent that the IETF WGs
become self-justifying, self-perpetuating, and eternal, the less useful they
become, IMHO. We are becoming more and more like ISO every day, and maybe
worse.
Now allow me to (gently, I hope) take issue with some of your other statements:
"Bonatti, Chris" <BonattiC(_at_)ieca(_dot_)com> 11/29/00 02:58PM >>>
Reading through this thread, I am astonished at a couple of apparent
truisms that are emerging from the various earnest statements made. These
are
(employing a little editorial license):
* The implementation cost of DSA/D-H/3DES was acceptable when RSA was
patented, but now that some of us have actually built/tested this the cost
has gone up into the "too high" range.
I would disagree. The cost of the RSA license was minimal relative to other
development costs, and the RSA algorithm was effectively all there was in terms
of deployed PKI infrastructure. The fact that DSA and D-H were labeled MUST
was chalked up to IETF politics, and completely ignored by the vendor community
as not being worth the implementation cost in terms of revenue return. Granted,
it didn't meet some of the expressed desires of the US Government, but the USG
has always had a much bigger appetite than budget. (Remember Jovial? Ada? C2
by '92?) Money talks, and everything else walks. They imposed requirements,
but those requirements didn't stick when it came to real procurements.
* Specifying a single MUST algorithm suite was sufficient to make S/MIME
algorithm independent, but actually requiring two algorithms suites will cost
too
much. If we've really achieved algorithm independence in the sense that Dave
Kemp suggests, this should be a debate about a relatively small math module.
No, again I disagree. The math module isn't the problem. As a BSAFE licensee,
we already have all of the math modules we would need. The real issue is all
of the multitudinous GUI screens that have to be developed to allow the user to
choose this, that or the other algorithm within S/MIME, and then the same set
of choices in any PKI products, and then testing all of these options in every
conceivable combination, not just within a given product but in combination
with all of the other leading e-mail packages, plus the various PKI services
and toolkits as well. those costs dwarf the cost of the math module by a
couple of orders of magnitude.
* We have an 'SMIMECapabilities' attribute for which support is MUST, but
some implementations ignore it so we have to use the lowest common
denominator to force interoperability. What make anybody think a MUST on an
algorithm choice would be taken any more seriously?
Two issues. As I recall, the SMIMECapabilities is a MAY, not a MUST, although
I'll stand corrected if I'm wrong. And as I say, and Peter Gutmann said more
succinctly, MUST matters if and only if the vendor was inclined to implement
that option anyway. It might be sufficient to push someone over the fence who
was already 49% there, but not much more. Standards compliance doesn't pay the
rent -- customers do.
I don't think I actually have an opinion on this issue myself. I'm of the
mind set to mandate nothing and let Darwin decide. However, I find the
seeming
illogic of these collective opinions very troubling. It leads me to think
that we're not getting to the REAL reasoning behind this move.
I think Blake was closest to this in stating that there has been no
customer demand for DSA. Is this the REAL reason to dump DSA? Are customers
demanding RSA be used? Do customers express demand for any algorithms, or do
they just want it to be "secure"? Are we just drifting to the path of least
resistance?
Customers don't demand or specify algorithms. They just want it to be secure,
and trust that the vendor will figure out what that means. What they do insist
on, however, is that the product work well with the existing infrastructure in
order to reduce their total overall cost of ownership. The more sophisticated
customers realize that adding more and more features that they never use
significantly increases that TCO, so overburdening a product with unnecessary
features causes a significant backlash. Increased cost of development with
decreased sales. What a concept!
Personally, I favor products that support LOTS of interoperability
modes... not just lowest common denominators. Call me crazy, but...
Chris B.
This is really a case of Little Red Riding Hood's porridge. We want it to be
not too hot (needlessly feature rich), and not too cold (missing important
capabilities or security, forcing everyone to devolve to the lowest common
denominator), but rather just right. And that requires making intelligent
CHOICES.
I like mustard, and I like chocolate. But that doesn't mean that I want
chocolate on my hot dog, nor mustard on my ice cream, just because I have them
both in my refrigerator. :-)
Regards,
Bob