I am no PKI expert, but I have worked with ADCS a bit.
If all you have of the old CA is the certificate, then I would do (2) (i.e. create a whole new CA and retire the old one). An ADCS CA keeps a database of certificate templates, issued and revoked certificates, etc which it sounds like you no longer have for your old CA. In that case, you are going to have to rebuild, test, and troubleshoot the certificate templates you need for your environment -- this is where the real work lies. Once you have the templates working, it is quick to reissue certificates en masse.
If you try to do (1), you run the risk of confusion because it probably won't be clear which certificates were issued by the old CA vs the new CA. I also suspect that (1) is not a Microsoft-supported practice.
There is significant difference between Standalone and Enterprise CAs and each have its usage scenario.
Enterprise CAs
This type of CAs offer the following features:
- tight integration with Active Directory
When you install Enterprise CA in AD forest, it is automatically published to AD and each AD forest memeber can immediately communicate with CA to request certificates.
Certificate templates allows enterprises to standatize issued certificates by their usages or whatever else. Administrators configure required certificate templates (with appropriate settings) and put them to CA for issuance. Compatible recipients don't have to bother with manual request generation, CryptoAPI platform will automatically prepare correct certificate request, submit it to CA and retrieve issued certificate. If some request properties are invalid, CA will override them with correct values from certificate template or Active Directory.
- certificate autoenrollment
is a killer feature of Enterprise CA. Autoenrollment allows to automatically enroll certificates for configured templates. No user interaction is required, everything happens automatically (of course, autoenrollment requires initial configuration).
this feature is underrated by systems administrators, but is extremely valuable as a backup source for user encryption certificates. If private key is lost, it can be recovered from CA database if necessary. Otherwise, you will loose access to your encrypted content.
Standalone CA
This type of CA can't utilize features provided by Enterprise CAs. That is:
this means that every request must be manually prepared and must include all required information to be included in the certificate. Depending on certificate template settings, Enterprise CA may require only key information, the rest info will be automatically retrieved by CA. Standalone CA won't do that, because it lacks information source. The request must be literally complete.
- manual certificate request approval
Since Standalone CA do not use certificate templates, every request must be manually verified by a CA manager to ensure that request does not contain dangerous information.
- no autoenrollment, no key archival
Since Standalone CA do not require Active Directory, these features are disabled for this type of CAs.
Summary
Although, it may look that Standalone CA is a dead end, it isn't. Enterprise CAs are best suited to issue certificate to end entities (users, devices) and is designed for "high volume, low cost" scenarios.
On the other hand, Standalone CAs are best suited for "low volume, high cost" scnearios, including offline ones. Generally Standalone CAs are used to act as Root and Policy CA and they issue certificates only to other CAs. Since certificate activity is quite low, you can keep Standalone CA offline for a reasonable large time (6-12 months) and turn on only to issue new CRL or sign new subordinate CA certificate. By keeping it offline, you enhance its key security. Best practices suggest to never attach Standalone CAs to any network and provide good physical security.
When implementing enterprise-wide PKI, you should focus on a 2-tier PKI approach with offline Standalone Root CA and online Enterprise Subordinate CA that will operate in your Active Directory.
Best Answer
Unfortunately, Microsoft ADCS limits its supported keys to common NIST curves and don't allow to use Brainpool curves. If you manage to supply a certificate with non-supported curve, installer won't accept it. And there is no any workaround I could think of and which would work.