On Fri, 2004-07-02 at 15:55, Michael Konietzka wrote:
Michael,
There is also an another way, but which is more involved in terms of code and process. What you think about defining a new interface (like ca, ra...) for dual key purpose -- say "key manager".
IMHO, the idea of backing up encryption certificate private key is to
unlock important resources (encrypted messages) when it get locked in
say employee X's public key who is lo longer in the organization or
something like that. So when we back up encryption cert private key we
need to ensure,
who is requesting for access to backed up private key? Is he/she authorized to request? max. no of download allowed? etc. Obviously my boss should able to decrypt again the document he sent, encrypted using my public key. Of course all are process related issues. But defining a new admin for key management purpose, making it offline for security reasons (like ca), if needed and keeping track of all the information makes the implementation more cleaner IMO.
Well, at the moment the process of gaining access to the backuped private keys is not completely defined. Of course a user should access his own private key if he lose it. If a user (employee in my PKI) leave a organization or is for example ill for 4 weeks, it should be suitable to access the backuped key to access some ressources. The process who will have access to those keys isnt defined yet.
One suggestion was not to backup the keys on the "drive" but to print the PEM-File with a ordinary printer and storage this paper in a vault in the "personnel department".
Any other suggestion are welcome. ;-)
When I attempted to do this sometime ago, the steps i planned 1)
Generate key/certs for dual key manager (KM) 2) when the user request
encryption cert ('basic_csr'), encrypt his key pairs using KM public key
and store in the db by defining new column or table. yeah, public key
encryption 3) keep a check against csr whether it gets approved in ra
and ultimately ca. 4) when you want to retrieve back, request via pub
interface like csr & crr 5)approve the request in KM based on some
criteria.
Maybe its friday and i worked too much this week, but i dont get what you wanna do. ;-)
But to define some "generic" interface to the keybackup is a good idea. At the moment there is no speciacl functionality on the batch-interface to keybackup system, isn't it?
My experience with openca was v0.8/0.9 era old, just today I got the cvs version working in my system. So you can excuse if doesn't make any sense <grin>
You have the cvs-version working with "verifying of signatures" working?
Best regards Michael
FollowUp-To: [EMAIL PROTECTED]
Michael Konietzka schrieb:
Chris Covell wrote:
Michael,
On Wed, 2004-05-19 at 11:32, Michael Konietzka wrote:
Ok, but how should I handle the different keyUsage in certification process?
The OpenCA way of doing this is to have a different "Role" for each certificate type. So I would have a "Sign" role where the key usage is set to: keyUsage = nonRepudiation, digitalSignature extendedKeyUsage: TLS Web client authentication, E-mail protection
and a "Encrypt" role where the key usage is set to: keyUsage = keyEncipherment, dataEncipherment, keyAgreement
OK, done it this way using two different roles and it worked. But I am using for both certificates the client-side generation. Michael Bell said, for key recovery of the decryption certs i should use the batch processor. So i will check this out.
In my PKI I'll have two User-Roles: User-Sign: where the keys are generated in the browser. User-Enc: where the keys are generated with the batchprocessor on CA
Using the batchprocessor(bp) in RC5 works fine for generation and enrollment of the pkcs12 on the CA.
But at the moment I have no "nice" workflow for handling the batch_new_process.txt batch_new_user.txt batch_process_data.txt files. I feed them "semi-manuell" which is no ideal solution.
My idea is to automatically feed the bp with data from the already generated User-Sign certificates. To do this I will lookup the certificate-Table for valid certificates with role="User-Sign". The cert-key of those User-Sign certs will be the user_id for the bp. The process-data for the User-Encryption cert can be the same data as the fields CN, Email stored in "certificate"
With these generated batch_new_process.txt, batch_new_user.txt, batch_process_data.txt I ll start the batchprocessors to generate keys and certifactes for the role "User-Enc".
To distribute the PKCS12 and the PIN one can use the User-Sign- certificate to generate an encrypted email like the CRIN-Email. The certificate for encryption then will be certifacte #$USER_ID because the user_id is the cert_key of the User-Sign certificate.
Advantage: + "One step" for a User to get the two certificates. + Using already RA-approved user-data for the batchprocessor. + PKCS12 and PIN can be transfered via encrypted email.
Disadvantage: - Using a User-Sign certificate for encryption, but the CRIN-Mails are doing this anyway. - ?
Does anyone see some mantraps or failures in this workflow before I start configuring and coding.
Best regards Michael
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Openca-Users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/openca-users
--
Dipl.-Inform. Michael Konietzka Schlund + Partner AG
- Development UNIX - Brauerstraße 48
Webservices D-76135 Karlsuhe
http://www.schlund.de/ Germany-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
OpenCA-Devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/openca-devel
