||This program does 5 separate functions. By default, it does them all.
It can be told to do any subset of them.
It does them in this order:
1. Generate file of CRMF cert requests.
Generates 2 keys pairs, one for signing, one for encryption.
Can generate RSA or DSA (XXX - DSA is only useful for signing).
Generate a cert request for each of the two public keys.
Generate a single CRMF cert request message that requests both certs.
Leave the generated CRMF request message in file
2. Decode CRMF Request(s) Message.
Reads in the file configdir/CertReqMessages.der
(either generated by step 1 above, or user supplied).
Decodes it. NOTHING MORE. Drops these decoded results on the floor.
The CMMF response (below) contains a completely unrelated cert. :-(
3. CMMF "Stuff".
a) Generates a CMMF response, containing a single cert chain, as if
it was a response to a received CRMF request. But the cert is
simply a user cert from the user's local soft token, whose
nickname is given in the -p option. The CMMF response has no
relationship to the request generated above. The CMMF message
is placed in configdir/CertRepContent.der.
b) Decodes the newly generated CMMF response found in file
configdir/CertRepContent.der and discards the result. 8-/
c) Generate a CMMF Key Escrow message
needs 2 nicknames:
It takes the public and private keys for the cert identified
by -p nickname, and wraps them with a sym key that is in turn
wrapped with the pubkey in the CA cert, whose nickname is
given with the -s option.
Store the message in configdir/KeyRecRepContent.der
d) Decode the CMMF Key Escrow message generated just above.
Get it from file configdir/KeyRecRepContent.der
This is just a decoder test. Results are discarded.
4. Key Recovery
This code does not yet compile, and what it was intended to do
has not been fully determined.
Haven't analyzed this code yet.