If you have a CA (private) key, which is the same as the one for the CSR you sign, then you create a self-signed certificate. If instead you create separate keys for the entity whose identity you wish to confirm and the CA used to confirm the identity, it's formally not a self-signed certificate anymore.
Self-signed certificates are mostly used for testing purposes and thus temporary. This can be enforced by limiting their validity period, but often isn't done in favor of convenience.
How the real-world CAs do it
The CAs will have a hierarchy of keys/certs (comprising the certificate chain you probably have heard of). If you - or your OS vendor - choose to trust a root CA cert it implies trust to Sub-CAs whose certs were signed with the root CA key.
What this means is that the root CA key requires the highest security, because it can be used to create any number of Sub-CAs which will be ultimately trusted if someone chose to trust the root CA cert.
Be sure to delete any temporary root authority certificates from the
Trusted Root Certification Authorities and Personal folders by
right-clicking the certificate, then clicking Delete.
Makes perfect sense now, if you consider that a root CA cert (with key) proper will have the biggest potential of being abused and create the biggest bang for the buck for an attacker. if compromised. You'll want to keep those stashed away securely unless you are using them right now to sign a Sub-CA CSR. Hence, remove them and keep a copy for later CSR signing purposes (if you need).
However, since the quote is clearly about "temporary root authority certificates", I think the clue is hidden in temporary and that's something you as the system administrator define for your own CAs and Sub-CAs (i.e. whether you intend to use them in the future or not).
Basically you can consider deleting a temporary CA cert/key as making it unavailable to an attacker, similar to the security measures of actual root CA keys. It assumes that this temporary CA won't be used to sign any more (development-use) certificates.
So that little word temporary implies a little more in the quote than it seems at first glance.
How this looks in practice
Let's say you have a root CA key that never expires (although in most cases it will simply be a relatively long period, like 20 years) and a corresponding root CA cert. You'll want to keep the key secure from any compromise, especially if the certificate is trusted by many many people. That is the case with the root CA certs of, say, Verisign or Comodo.
That root CA key will then be used solely to sign the cert of a Sub-CA (which has its own distinct key), thereby creating the first two links in a certificate chain which your browser or Microsoft's
signtool as well as many other utilities let you inspect. The root CA key would never be used directly to process your CSR and thus confirm your identity as an end-user/website/company.
Every respective Sub-CA will usually only be used for a particular purpose (there are extra fields for certain purposes, such as code-signing) and its validity period will be a subset of the root CA cert's.
But, and that's one difference between the root CA's key and the Sub-CA's key: the root CAs key can be stashed away securely (talking physical security here) most of the time, unless absolutely needed to sign the CSR for a new Sub-CA, while the Sub-CA key will likely be used on some kind of highly secured server to sign customer CSRs (when considering a real-life certification authority like Verisign). This means that the Sub-CA is more at risk than the root CA and why you want to apply different levels of security in the first place.
The advantage being that, should the Sub-CA ever get compromised, its certificate can be put onto a ARL/CRL (authority/certificate revocation list), whereas putting the root CA certificate on a ARL/CRL is only really warranted for technical reasons (e.g. using the now compromised MD5 hash, a key length not deemed secure anymore ...). The costs attached to either of these are the defining factor at several levels:
- costs for storing the keys securely, in particular the root CA key has to be secured the most
- costs when changing root CA certs versus changing Sub-CA certs
- costs when revoking (Sub-)CA certs