ietf-smime
[Top] [All Lists]

RE: RSA vs. DSA MUST

2000-11-28 12:17:49
Is there a study readily available comparing all these FIPS-140 approved
algorithms in question?  I'm sure each one of them have there unique
advantages and disadvantages (i.e. processing speeds, cryptanalysis).
Limiting ourselves to only one algorithm to lessen coding efforts and
simplifying interoperability may be detrimental as new attack methods evolve
day-to-day.  Yes customer-demands is what drives vendor development but what
do you think the customer will demand if a serious RSA vulnerability is
identified when new cryptanalysis technologies become available?  Even as a
rumor or a hoax (i.e. unproven/unofficial RSA crack), customers' demand will
be mail packages with multi-algorithm capability.  A mail agent's capability
to use a variety of algorithms is a major selling point.

I know this may be a little far-fetched but we should keep standards as
accomodating as possible for any future possiblities.  Maybe the limiting
factor should be FIPS approved algorithms...


Regards,

Ozan

______________________________

Ozan Gonenc
IT Security Consultant

AEPOS Technologies Corporation



-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of Bob Jueneman
Sent: November 28, 2000 10:21
To: pgut001(_at_)cs(_dot_)aucKland(_dot_)ac(_dot_)nz; 
ietf-smime(_at_)imc(_dot_)org;
dpkemp(_at_)missi(_dot_)ncsc(_dot_)mil; 
blake(_dot_)ramsdell(_at_)tumbleweed(_dot_)com
Subject: RE: RSA vs. DSA MUST


"Blake Ramsdell" <blake(_dot_)ramsdell(_at_)tumbleweed(_dot_)com> writes:

I do not care strongly, but the strawpoll at the last IETF indicated a
preference for "both", and that was the path we were headed down, and that
Russ summarized.  Personally, I don't implement it, and I haven't had any
customer complaints telling me I should, and the backwards compatibility
issues are almost the same as for Diffie-Hellman certs (that is, I have
not
seen anyone using them, so chucking them wouldn't break an installed base
of
significant size, if at all).

In case this is useful as a data point, in my general wandering around
looking
for certs on the net the only publicly available DSA certs I've ever found
were
some old Thawte ones, presumably created just to show'em (all the standard
Thawte certs are RSA, I don't think I've ever seen the DSA certs actually
used
to certify anything).  I've also very occasionally come across them being
used
in closed environments (ie ones where interoperability with the masses
isn't
really an issue).  I suspect the motivation for a lot of these is that
there's
a requirement to use a FIPS algorithm and DSA is the only choice.  I can't
see
a MUST RSA, MAY DSA as being any real problem, it's just recognising what
has
been reality for the last few years.

Peter.

That would certainly be my preference, unless some hitherto-unknown set of
customers waving gobs of money come running out of the woods.

Even MAY language is somewhat troubling -- I continue to believe that the
SMIME group has gotten seriously off track by introducing orphan algorithms
such as CAST, IDEA, symmetric key, password-encryption, etc., etc., that if
implemented would add only incrementally to the coding effort, but would
complicate interoperability testing exponentially.  I wouldn't object to MAY
for DSA, but I would strongly prefer that it not be a MUST.

If DSA is a MUST, then I strongly suspect that we and probably many other
vendors will simply be noncompliant, and that doesn't help anyone,
especially with respect to interoperability.  And isn't that what standards
are all about?

Regards,

Bob

Robert R. Jueneman
Security Architect
Novell, Inc. -- the leading provider of Net services software


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