"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