force-v4-certs and digest-algo

[Len Sassaman]

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
> `unless'.)

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:

http://search.ietf.org/internet-drafts/draft-ietf-openpgp-rfc2440bis-05.txt

> > 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.

--Len.