force-v4-certs and digest-algo
rabbi at quickie.net
Fri May 10 20:11:02 CEST 2002
On 9 May 2002, Robert J. Hansen wrote:
> > 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).
To further clarify what I was saying:
The entire point of the IETF, and of the RFC system, is to eliminate the
"de facto standards" mess, and give us actual standards.
> 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
Well, 2015/3156 don't cover this, so that's easy. But if you want to see
for yourself, it's section 9.4 of RFC2440bis5:
> > There is no reason that DSA couldn't use any other 160 bit hash.
> 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.
You are confusing DSA (the algorithm) with DSS (the standard). DSS
mandates DSA and SHA-1. DSA, however, could be used with any strong hash
function that is sufficiently long.
More information about the Gnupg-devel