Subject: RE: RSA vs. DSA MUST

From: "Bob Jueneman" <[email-masked]>
Date: Tue, 28 Nov 2000 08:20:42 -0700

>"Blake Ramsdell" <[email-masked]> 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

---

From: "Ozan Gonenc" <[email-masked]>
Date: Tue, 28 Nov 2000 14:17:24 -0500

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: [email-masked]
[mailto:[email-masked]]On Behalf Of Bob Jueneman
Sent: November 28, 2000 10:21
To: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: RSA vs. DSA MUST

>been reality for the last few years.
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