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.
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.
>From the latest version it seems it's lot more easy to define new
interface and add new functionality that we want. 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>.
Thanks,
venki.
> 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
