On Sat, Sep 10, 2011 at 3:47 AM, Heinrich Strauss <heinrich@hstrauss.co.za> wrote:
On 2011/09/10 05:06, Michael DeMan wrote:
I though wildcards were limited to having a domain off a TLD - like '*.mydomain.tld'. The root CAs are have no technical limitation in regards to what kind of certificates they can issue. There is no inherent reason that technical limitations cannot be imposed... there are mechanisms available to do this, if the original CA certificates were issued with restrictions: http://tools.ietf.org/html/rfc3280#section-4.2.1.11
Special limitations or "security warnings" can be raised by individual browsers above and beyond the certificate validation rules. I would be in favor of each root CA certificate being name constrained to CNs of one TLD per CA certificate, so that root CA orgs would need a separate CA cert and separate private key for each TLD that CA is authorized to issue certificates in. It would be useful if the name restriction would be extended further to allow 2nd level wildcards to be prohibited such as "CN=*.com" or "CN=*.*.com" Browsers will honor "*" in hostname components of the CN field as required by the RFCs.. however a "*.mydomain.tld" certificate does not match www.mydomain.tld, "*.*.mydomain.tld" does. Some CAs have partaken in problematic practices such as issuing SSL certificates with RFC1918 IP addresses, or "unofficial" TLDs in the CN or subject alternative names section. see https://wiki.mozilla.org/CA:Problematic_Practices#Issuing_SSL_Certificates_f... If all the root CA certificates become name constrained, such problematic practices should cease. -- -JH