Andrew Cooke wrote:
> My comment is an observation, rather than an argument for changing: You
> are imposing a security model on users that a malicious party can
> circumvent by changing the code. This isn't really acceptable as part
> of a library (which may be assembled by others for a variety of security
> models), but then this is code in the apps directory, rather than in the
> library itself.
>
> In other words, I understand your argument, but if this was part of the
> SSL library I would argue that it is up to people using the library to
> put this kind of check in. But your code is in the ca utility rather
> than the library.
>
> If people want to use the utility routines as a "library" to build their
> own CA scripts, then it would be better, for example, to provide a
> separate routine that checks that they know the CA password. In that
> way the person writing the script has the choice of following your
> security model, or not.
>
> As I said, I am not arguing either way - I can see why you have done
> this, but I hope I have also explained why people who are using the apps
> as a library to use in their own scripts may object.
>
> Andrew
Sincerely I do not uderstand your observation: to issue a CRL you have to
load the CA secret Key (either using library routines) and if it has been
encrypted, you have to call for a "challenge" to get it (and providing the
encryption password). So if you don't know the protection password of the
CA key you can not issued CRLs ...
I don't know if I got your point, I hope so.
C' you,
Massimiliano Pala ([EMAIL PROTECTED])
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
