Comment 69 for bug 376484

Revision history for this message
In , Brendan-webafrica (brendan-webafrica) wrote :

From my reading of the above, we're now following RFC's blindly with little regard for context. I posted bug 495339. Unfortunately, RFCs aren't infallible.

1. Bad CAs issuing * certs without proper verification? rm -f
2. Prove that removing backwards compatibility has tangibly improved security. Change this bug to REOPENED.
3a. Are regex's supported?
 b. If so, do any CAs support regex's or is this only for self-signed certs?
4. Don't "fix" the trailing dot - it ain't broke

1. Respectable commercial Cert providers shouldn't be issuing certificates for "*.com" or "*.co.za" or "*" or any other similar address. If there's a vendor that does issue these certificates they should be considered untrustworthy and removed from the CA repository.

The cert vendors I've worked with verify that the certificate is actually being issued to the domain administrator. The same applies here - if the CA isn't verifying that the certificate is being issued to the domain's owners then the CA must be removed from the CA repository.

Based on the above, I'd like to see how anyone might prove to a CA that they own the .com domain. If you're able to do it, remove that CA from the repository.

2. The example in my bug 495339 has an address under glodns.net. glodns.net has a certificate that has been issued to the administrators in charge of glodns.net. The administrators of glodns.net are asserting that the full address in question does in fact belong to the glodns.net network - only now we're interpreting things differently from before and the expected behaviour is broken.

Most certificate vendors describe their wildcard certificates as "unlimited subdomains". foo.bar.example.com is still a subdomain of example.com no matter how many dots inbetween the foo and example.

What is the purpose of removing the backwards compatibility here? Can you give me a plausible risk that having the wildcard NOT match the dot really mitigates? "Its RFC" isn't a good answer here. As I said above, RFCs aren't infallible and we've been ignoring it for a VERY long time without any complaints.

Please change this bug to REOPENED.

3a. Are regular expressions supported in any way as mentioned in comment 0? I'm not at work and I don't have the resources at hand to test this properly. I can test this Monday on a self-signed cert.

3b. Assuming regex's are supported, do any cert vendors support regex's?

4. Finally, it seems nobody wants to "fix" the trailing dot but it might come up again - it is the Internet root. In DNS, the . is always implied. Ignoring the trailing dot is fine. Here are my DNS dig results for "bugzilla.mozilla.org" and "bugzilla.mozilla.org.". Take note of the trailing dots in the results for both queries:

> [ brendan@swift : 08:07:17 : ~ ]
> :) dig bugzilla.mozilla.org | grep . | grep -v "^;"
> bugzilla.mozilla.org. 60 IN CNAME bugzilla-mozilla-org.geo.mozilla.com.
> bugzilla-mozilla-org.geo.mozilla.com. 1661 IN CNAME dyna-bugzilla.nslb.sj.mozilla.com.
> dyna-bugzilla.nslb.sj.mozilla.com. 600 IN A 63.245.209.72

> [ brendan@swift : 08:07:41 : ~ ]
> :) dig bugzilla.mozilla.org. | grep . | grep -v "^;"
> bugzilla.mozilla.org. 4 IN CNAME bugzilla-mozilla-org.geo.mozilla.com.
> bugzilla-mozilla-org.geo.mozilla.com. 1605 IN CNAME dyna-bugzilla.nslb.sj.mozilla.com.
> dyna-bugzilla.nslb.sj.mozilla.com. 544 IN A 63.245.209.72