unsubscribe
Lippek, Andreas, IT-TR
Andreas.Lippek at DePfa.com
Fri May 10 08:59:02 CEST 2002
-----Original Message-----
From: Robert J. Hansen [mailto:rjhansen at inav.net]
Sent: Freitag, 10. Mai 2002 04:46
To: Brian M. Carlson
Cc: gnupg-devel at gnupg.org; rabbi at quickie.net
Subject: Re: force-v4-certs and digest-algo
> While this may be true, it is a de facto SHOULD, just like IDEA is.
Be careful. Going further down this road will lead us to the World of
Microsoft. There's a razor's edge between saying "we will support the
spec, including all SHOULDs" and saying "we will support the spec, plus
whatever additional things we feel are de-facto standards". The one way
is the Free Software/Open Source way. The other way is the Microsoft
Embrace and Extend way (q.v., their Kerberos implementation).
Unless the spec lists it as a MUST or a SHOULD, I honestly don't think
GnuPG should generate it. Be liberal in what you accept, but very
conservative in what you generate. (I know that Len says RIPEMD-160
isn't a SHOULD, and I have no reason to doubt him. However, I haven't
checked RFC2440/2015/3156 myself yet, so I'll hedge it with an
`unless'.)
> There is no reason that DSA couldn't use any other 160 bit hash.
Nevertheless,
Sure there is. If DSA used any other 160-bit hash, it wouldn't be DSA
anymore because the DSA spec demands SHA. Insofar as whether or not the
DSA spec could be changed to accept RIPEMD-160, and whether or not the
resulting system would still be secure... who knows? Cryptosystems are
fragile things; known-strong algorithms can interact with each other to
produce weak systems.
_______________________________________________
Gnupg-devel mailing list
Gnupg-devel at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
More information about the Gnupg-devel
mailing list