>It seems to be that this behaviour is implied by the extensions: that is
>both certificates have the same subject and issuer names and they match
>each other: crl-sign however doesn't have permission to sign
>certificates but cert-sign does. Presumably this is intended to mean
>that you use the public key of cert-sign to check the signature of
>crl-sign.
Well Netscape can't verify the sig, but does let you import the cert.
IE5 can't verify the sig, but seems to let you import the cert.
(Gee, that doesn't seem like a good interface -- there should be a
screaming dialog box that says "invalid signature!")
OpenSSL can't verify the sig.
We (now) can.
Not that the last claim really means anything.
> A bit odd but it makes sense I suppose: I wouldn't like to
>guess as to which software will handle this properly though.
Yes, that is exactly what is going on.
It is *VERY* odd -- I'd argue it's broken.
>OpenSSL can't do this automatically at present because it ignores
>certificate extensions and its X509_LOOKUP mechanism can only return
>single matching certificates for a given subject name.
Perhaps the easiest fix would be, if signature verification fails, see if
there are any other certs with the same DN. Won't this be necessary when
a CA rekeys, anyway?
>The easiest solution is to give crl-sign a different subject name: then
>OpenSSL wont assume it is self signed and should use cert-sign to check
>it.
That is apparently not currently possible. :(
/r$
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
