Microsoft deems all DigiNotar certificates untrustworthy, releases updates

Sat Sep 10 09:17:33 UTC 2011

On Sat, Sep 10, 2011 at 3:47 AM, Heinrich Strauss
<heinrich at 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_for_Internal_Domains

If all the root CA certificates become name constrained,  such
problematic practices should cease.

--
-JH