Bob,
Did I mention that sticking my arm into hornets nests is one of my favorite
hobbies. ;-) This nest look good and ripe...
Bob Jueneman wrote:
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.
I think that most of the "feature creep" to which you refer is in the realm of
options. There is still a fairly small core of S/MIME features that are MUSTs,
and nearly all of them have some core interoperability reason.
<snip>
Now allow me to (gently, I hope) take issue with some of your other
statements:
* 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.
Okay, but you're arguing against something that I'm not saying. I'm not saying
that anything should be MUST (in fact, I think the reverse should be the case).
I am also NOT saying that we should implement these algorithms because the
government says so (like Ada, etc.). What I'm saying is that two years ago WE
said is was good enough, cheap enough, etc. Now suddenly it isn't. What
gives. I'm trying to point out some intellectual disingenuousness, not arguing
for an end state.
* 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.
This seems a little overstated. As a developer, surely you have the latitude
to design your GUIs the way you want. That doesn't stop you from supporting
whatever algorithms you want, or auto-selecting based on the
'SMIMECapabilities'.
* 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.
The 'SMIMECapabilities' attribute is a MUST on reception, and a SHOULD on
origination.
On your second point, you have zeroed in on the point of my third bullet
admirably. If the MUST doesn't mean much, why are we debating it like it's a
meaningful decision?
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!
However, by this logic nothing ever improves. I'm not knowledgable enough to
say whether DSA/D-H is an *improvement* over RSA, or just another choice.
Nevertheless, I think this evaluation should be a factor. Somebody else asked
the question too. (?) Is DSA/D-H better? If not, then its okay to stick with
what's out there. If is it, then we've got to decide if it's better enough to
be worth upgrading the infrastructure. I have not even heard this point raised
yet. Why not?
All the best,
Chris sends...