Hi,

On Thu, Jun 9, 2011 at 06:14, Martin Bosslet
<Martin.Bosslet / googlemail.com> wrote:
> I think your patch is good! But there is one thing I don't like
> about OpenSSL itself here - why do they hardcode the digest algorithm
> in the first place?

They're using the hash of name for c_rehash. You see files something
like hex encoded in certs dir of OpenSSL;

d2adc77d.0@
d537fba6.0@
d78a75c7.0@
d8274e24.0@
ddc328ff.0@

(e.g. /etc/ssl/certs/ in Ubuntu)

For that purpose, algorithm should be fixed so they don't get Digester
as a parameter for X509_NAME_hash and X509_NAME_hash_old I guess.

Besides this, I don't know the reason why they change base digester
from MD5 to SHA1 at the version bump from 0.9.8 to 1.0.0.

> There are situations where neither MD5 nor SHA-1 fits, OCSP requests
> are a good example: The requested CertID is defined as
>
> CertID =A0 =A0 =A0 =A0 =A0::=3D =A0 =A0 SEQUENCE {
> =A0 =A0 =A0 hashAlgorithm =A0 =A0 =A0 AlgorithmIdentifier,
> =A0 =A0 =A0 issuerNameHash =A0 =A0 =A0OCTET STRING, -- Hash of Issuer's D=
N
> =A0 =A0 =A0 issuerKeyHash =A0 =A0 =A0 OCTET STRING, -- Hash of Issuers pu=
blic key
> =A0 =A0 =A0 serialNumber =A0 =A0 =A0 =A0CertificateSerialNumber }
>
> This implies trouble for any SHA-2 family "hashAlgorithm".

I can understand it but it should be different problem for them I
think. issuerNameHash has variable length, not fixed to 32bit integer.

> In addition to applying your patch I'd favor a Name#hash implementation
> that takes an optional OpenSSL::Digest that specifies the hash algorithm
> to be used.
> This would of course mean that we would have to implement the functionali=
ty
> of X509_name_hash on our own. What do you think - would the benefit of a
> cleaner solution outweigh the (partial) code duplication?

I like 'X509::Name#hash' to be a wrapper of 'X509_NAME_hash' and
'X509::Name#hash_old' is for 'X509::Name::hash_old'. I prefer to have
another name for hashing X509::Name if it's needed.

Regards,
// NaHi