A previous commit mistakenly conflated the wrapping parameters for
DES and DES3 cases, resulting in incorrect data being stored if the
storage was successful at all.  This broke ipa vault and probably
also token key archival and recovery.

This patch sets the right parameters for the 3DES case again.
Part of BZ# 1458043

Change-Id: Iae884715a0f510a4d492d64fac3d82cb8100deb4

Commit 633c7c6519c925af7e3700adff29961d72435c7f changed the PKCS #12
file handing to never deal with raw private key material.
PKCS12Util.addKeyBag() was changed to export the PrivateKey handle,
or fail.  This change missed this case where a PKCS #12 file is
loaded from file, possibly modified, then written back to a file,
without involving an NSSDB.  One example is pkcs12-cert-del which
deletes a certificate and associated key from a PKCS #12 file.

Fix the PKCS12Util.addKeyBag() method to use the stored
EncryptedPricateKeyInfo if available, otherwise export the
PrivateKey handle.

Fixes: https://pagure.io/dogtagpki/issue/2741
Change-Id: Ib8098126bc5a79b5dae19103e25b270e2f10ab5a

The server is modified to read the new OIDs in the PKIArchiveOptions
and handle them correctly.

Change-Id: I328df4d6588b3c2c26a387ab2e9ed742d36824d4

This patch implements the self-signed CMC requests, where the request is signed by the public key of the underlying request (PKCS#10 or CRMF). The scenario for when this method is used is when there was no existing signing cert for the user has been issued before, and once it is issued, it can be used to sign subsequent cert requests by the same user. The new enrollment profile introduced is : caFullCMCSelfSignedCert.cfg The new option introduced to both CRMFPopClient and PKCS10Client is "-y" which will add the required SubjectKeyIdentifier to the underlying request. When a CMC request is self-signed, no auditSubjectID is available until Identification Proof (v2) is verified, however, the cert subject DN is recorded in log as soon as it was available for additional information. Auditing is adjusted. More will come in the next couple CMC patches.

Part of: https://pagure.io/dogtagpki/issue/2610

Change-Id: Ic35a81c4c4dd49622bfdeb677d588641594b7ec6
(cherry picked from commit 507908d1aac8f9db6c380f5cae634521608043e8)

Update PKCS12Util to use AES-256-CBC to encrypt private keys.
Use JSS CryptoStore methods to ensure that all key wrapping and
unwrapping is done on the token.

Specifically, CryptoStore.getEncryptedPrivateKeyInfo replaces the
previous process where a symmetric key was generated, the private
key wrapped to the symmetric key, then decryted into Dogtag's
memory, then re-encrypted under the supplied passphrase.  Now the
key gets wrapped directly to the supplied passphrase.

Similarly, for import, the EncryptedPrivateKeyInfo was decrypted
using the supplied passphrase, then encrypted to a freshly generated
symmetric key, which was then used to unwrap the key into the token.
Now, the new JSS method CryptoStore.importEncryptedPrivateKeyInfo is
used to unwrap the EncryptedPrivateKeyInfo directly into the token,
using the supplied passphrase.

As a result, the PKCS12KeyInfo class, which previously stored
unencrypted key material (a PrivateKeyInfo object), it now only
deals with PrivateKey (an opaque handle to an PKCS #11 object)
on export and encoded (byte[]) EncryptedPrivateKeyInfo data on
import.  This split suggests that PKCS12KeyInfo should be decomposed
into two classes - one containing a PrivateKey and the other
containing a byte[] encryptedPrivateKeyInfo - but this refactoring
is left for another day.

Part of: https://pagure.io/dogtagpki/issue/2610

Change-Id: I75d48de4d7040c9fb3a9a6d1e920c191aa757b70
(cherry picked from commit 2e198ddbe9ec5000ee7e14df0aa364b600d3aa92)

Old CRMFPopClients add the OID for ECC public keys in the encryption
algorithm OID for no obvious reason (considering the OID was never
read on the server side to begin with).

Now that we do read and use that field, we need to set it properly,
and also special case on the server side to handle old clients.

Change-Id: I0d753e572206e9062746c879ce683978e5e657bd

Up to now, we have only ever used the same algorithm (DES3_CBC)
for key wrapping and encryption.  With  the change to use AES Keywrap
and AES CBC, we need to know which mechanism was used to encrypt/wrap
the secrets when returned to the client.

This means passing back more information to the client with the key
data, and also modifying the client to use this information to decode
the data correctly.

Change-Id: I7232085c1eedf38c63abad81db08acc912fa1da1

Also made a couple of small changes to WrappingParams.
* Set the wrapIV to null when AES KeyWrap is used.  Trying to unpack
  the PKIArchiveOptions package with this IV set to null fails.
* removed superfluous this modifiers.

Added a parameter KEY_WRAP_PARAMETER_SET which is set in /etc/pki/pki.conf.
If this parameter is set to 0, we will use the old DES3 algorithms.  This
can be set by clients talking to old servers.

CRMFPopClient has the ability to automatically submit requests to
a CA.  In this case, we shouldcontact the server and determine the
version using InfoClient, and choose the algorithm accordingly.
We will implement this in a separate patch.

Change-Id: Ib4a99545cb59b62a96c272311595e96dda10979e

* Refactor code in CryptoUtil to parametrize the algorithms used.
* Moved WrappingParams to utils jar to allow correct compilation.
* Removed code that created a PKIArchiveOptions structure from
  CRMFPopClient and replaced with calls to CryptoUtil methods.
  Note that the algorithms have been left as DES3.  They will be
  changed to AES in the next patch.
* Converted code in AuthorityKeyExportCLI to use the new methods
  in CryptoUtil.
* Removed DRMTest  this code is no longer maintained or used.

Change-Id: I8f625f0310877dca68f6a01285b6ff4e27e7f34a