The new version of Mozilla's CA Certificate Policy formalizes the browser maker's position on the issuing and use of sub-CA certificates and might indirectly improve security in enterprise environments, said Ivan Ristic, director of application security research at security firm Qualys, which runs the SSL Labs and SSL Pulse projects.
The technical constraints for sub-CA certificates that Mozilla refers to include the name constraints extension. This is a special extension that can be used to restrict a sub-CA certificate's usage to a particular domain name. For example, a CA can issue a sub-CA certificate with a name constraints extension that allows it to only be used to sign digital certificates for a single domain name.
This type of sub-CA certificates can be useful in corporate environments that use domain names internally and have internal SSL-enabled websites.
"In my experience many companies have lots of internal certificates and more often than not they are self-signed, they're invalid and there's no central control over who's issuing them," Ristic said. "As a result, if you visit some of these internal websites, it's often that security is not very good, the encryption keys are small and so on. If you have to use self-signed certificates every day it sort of limits the advantage of using SSL in the first place."
"If we go forward into a different world where restricted sub-CA certificates are affordable, then we might actually see a security improvement overall," Ristic said. However, there are some issues with the name constraints feature, because not all modern browsers support name constraints the way they should, he said.
Apple Safari and iOS devices do not respect name constraints, meaning that even if restricted in this manner, sub-CA certificates could still in theory be used to launch man-in-the-middle SSL attacks against Safari and iOS users, Ristic said. In practice, this won't be very useful for mounting large scale attacks, but could be used in targeted attacks against users of that software, he said.
The problem stems from the fact that not all clients -- browsers and other software that supports SSL -- understand name constraints.
Certificate extensions can be set as critical or non-critical, Ristic said. RFC 5280, which defines the "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" specifies that if the name constraints extension is used, it must be marked as critical. At the same time, conforming clients must reject a certificate if it has an extension marked as critical that they don't understand.