I have done a lot of research and planning and now know the directions I want to go.  Since this is not something I normally do I was hoping there may be some outside counsel I could use to clarify a few points before solidifying the design.

 CURRENT STATE:

We are currently running our CA on Windows 2012 R2.  This was moved from Windows 2003.

Since this was migrated from a 2003 CA, we are still running Cryptograaphic Service Provider (CSP).  Only web and domain controller certificates have been issued from this environment.

DESIRED STATE:

We need to move from a CSP and SHA-1 to a Key Storage Provider (KSP) and SHA-2

I am in the process of architecting a new 2-Tier PKI environment on Windows 2012 R2 servers.  This will be replacing the role as the issuing certificate server for all new requests.  The root and issuing CA are both Windows 2012 R2 servers.  There will also be another Intermediate CA for our Web Filter solution

• I cannot see any compelling reason to take the Root CA offline.  It seems like much more of a pain than it is worth.  Am I missing something?
• Since I will be keeping the root online, do I install the Root CA as an Enterprise or Standalone CA?
• For the Root CA I plan to select SHA1 with a key length of 4096 for the cryptography.  Would you suggest I select SHA256?
• For the Issuing CA I plan to select SHA256 with a key length of 2048.  Is this what you would recommend?
• I plan to set the validity periods as 20-years for the Root CA, 10-years for the Issuing CA, and 5-years for issued certificates.  Do you foresee any issues with this?
• In order to remove the dependency on a server name I plan to publish the Root and Issuing AIA and CRL to the following locations, which will be hosted from the Issuing CA: http://certificate.DOMAIN.com/CertData/<CAName><DeltaCRLAllowed>.crl http://certificate.DOMAIN.com/CertData/<ServerDNSName>_<CAName><CertificateName>.crt

(4 files total) This will only be resolvable internally.  Any issues with the root and issuing CA publishing to the same location (Different file names)?

• When I have the new Root/Issuing servers online and configured I plan to disable all templates from the old certificate environment.  I will leave these 2 servers online until all issued certificates have expired.  Do you see any issues with this?
• We still have some XP and 2003 servers online.  They are in the process of being removed.  Is there any issue with specifying the AlternateSignatureAlgorithm=1 parameter in the new environment?

> I cannot see any compelling reason to take the Root CA offline

attack surface. Root CA is the most important piece in the PKI and shall be highly secured. If it is compromised, you cannot revoke it and/or tell customers about the issue in an automated way. Due to this, Root CA is a primary point for attacks. If it is offline and not attached to any network, then there are less chances that it will be broken programmatically. Of course, physical security is important as well and you should protect Root CA's private key from tampering. For example, to use hardware security module (HSM).

> For the Root CA I plan to select SHA1 with a key length of 4096 for the cryptography.  Would you suggest I select SHA256?

it depends on a client applications that will utilize certificates. If they do support SHA2, then I would suggest to move to SHA256.

> I plan to set the validity periods as 20-years for the Root CA, 10-years for the Issuing CA, and 5-years for issued certificates.

I don't think if there is a practical reason to set up CA for more than 10 years. You can have the same validity for Root and subordinate CAs. For example, we use 10 year validity for each.

> Any issues with the root and issuing CA publishing to the same location (Different file names)?

no, it is not an issue. But the issue is that you plan to host CRLs on CA server. CA server shall not host CRLs for clients. The recommendation is to get a highly available (possibly sort of NLB) web server where you can create either virtual directory or dedicated website to host CRLs.

> Is there any issue with specifying the AlternateSignatureAlgorithm=1 parameter in the new environment?

the recommendation is to not enable alternate signature format as it is "dead" format and is not supported widely. Only few applications (along with Windows Native Cryptography) supports it.

> I cannot see any compelling reason to take the Root CA offline

This partly depends on how "serious" - and secure - your PKI implementation needs to be. If you need to be credible (for auditors, stakeholders, shareholders, etc.) it really is a necessity. Look at all these big name organizations that are hacked - despite what they invest in security. Offline Root CA is the only way to be sure that it is inaccessible to intruders (assuming your physical security is robust as well).

You are right that it is a pain.  A real pain.

> Is there any issue with specifying the AlternateSignatureAlgorithm=1 parameter in the new environment?

Yes. Please do not do this. If you are 100% Windows, no problem. But if you are issuing certificates to third-party applications or appliances (firewall, network devices), there will be no end to troubleshooting problems. I did this once... and had to redo the issuing CA so the certs would work with some of our appliances.

EDIT - even if you are not planning to do this now (certs for applications or appliances), your organization might want to 1-5, etc., years from now. All in all, you gain nothing significant from setting that value to 1.

There is nothing wrong with the 20-10-5 periods you suggest (I've often seen this in the texts I've consulted) but I see opinions vary.

Otherwise, I second the recommendation on the load balanced web server.

It looks like you've done your research though - do you have Brian Komar's book? That's probably the single best reference out there although it is a little old now (I understand there's an updated version on the way).

> This partly depends on how "serious" - and secure - your PKI implementation needs to be

I have a good answer for this. Your CAs may issue identity certificates and impersonate any user. In other word, the cost of compromised CA may be equal to your IT infrastructure cost. One rogue certificate and entire domain with everything there (mail, files, databases etc., etc.) is destroyed. In short: your business is done (like it was with DigiNotar).

Thank you all so much. I really like hearing what everyone else is doing since this is something I really never have to expose myself to.

If its ok, I'm going to leave this open for a few more days just to see if anyone else can provide their experiences.