Mario Fabiano wrote:
> Try to see the matter from a different point of view.
Ok.
> Suppose that your CA is a big organisation which is supported by a large
> number of RA responsible to approve certificate requests from end users.
> The approval is made only against a face to face identity proof. These
> RA can also revoke the users' certificates according to a suitable
> policy. These people (the RA) have a high responsibilty in this trust
> model, but do not know the CA key unlock password. This king of
> knowledge is owned by a higher level officer (call him CA operator or CA
> manager), who signs the CRL. RA people are several and bear the heavy
> job (many revocations). The problem to track single revocations and to
> give RA people the proper permission is a problem that should be solved
> by the Certification Authority application, not embedded in the logic of
> the underlying libraries.
> Obviously the security model that each of us have in mind can be
> different, this is why I would prefer a certain degree of freedom.
I think the problem simply does not exists. If your application wants to
bypass the ca -revoke command, simply alter the index.txt db (that's
basically what the command do): the command is a facility, not a MUST
to be used.
Obviously, I suggest revoking to be NOT an automatic process even if you
have a very big organization, but this is a choice. Said that you
have to have CA operator authorization level to actually revoke certificates
and proof of it is the knowledge of the CA's password, simply ask for
it once, then the program will use that in every "challenge" section
(see the ca command about the challenge function... ).
C'you,
Massimiliano Pala ([EMAIL PROTECTED])
S/MIME Cryptographic Signature
