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