I also found some mistakes for the list: 1. I see some client certificate in the report that it say the email as common name is wrong; 2. IP address is allowed by BR; 3. IDN is allowed, but also in the report
Regards, Richard -----Original Message----- From: dev-security-policy [mailto:dev-security-policy-bounces+richard=wosign....@lists.mozilla.org] On Behalf Of Rob Stradling Sent: Tuesday, November 17, 2015 9:32 PM To: Peter Gutmann <pgut...@cs.auckland.ac.nz>; Peter Bowen <pzbo...@gmail.com>; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: [FORGED] Name issues in public certificates On 17/11/15 08:25, Peter Gutmann wrote: > Peter Bowen <pzbo...@gmail.com> writes: > >> There are a couple of rules that may create false positives, so >> please don't assume every certificate on the sheet is problematic. > > That's still pretty scary, nearly 50,000 names from a who's-who of > commercial CAs. Yet more evidence that, like the output from the EFF > SSL Observatory, we need independent assessment of browser PKI rather > than self-certification ("we define ourselves to be in full compliance > with everything we need to be compliant with, as far as we can tell"). > > Peter. Peter (G), I fully agree that independent assessment is useful, but independent assessments need to be assessed too (preferably before the press start quoting soundbites! :-) ) Peter (B), Thanks for doing this report. There are definitely some interesting findings. However, I would like to discuss several classes of (what I think are) false positives that cover a significant number of the "anomalies" you've found: - RFC5280 sections 7.2 and 7.3 do indeed talk about the need for dNSNames, domainComponents, etc, to only contain ASCII data. However, your report also flags Subject CNs with non-ASCII data - AFAICT, this is permitted by both RFC5280 and the BRs. It is common practice to put the "xn--" ASCII string in a dNSName and the UTF-8 string in the Subject CN. - You wanted to check that "public CAs were following the CA/Browser Forum baseline requirements" when issuing certs. However, some of the certs in your report were issued before any of the browsers / audit regimes demanded that public CAs be compliant with the BRs. Furthermore, some of the certs in your report were issued before the BRs even existed. - You wanted to check "server auth certificates issued by public CAs". However, I see some Code Signing Certificates in your report. I'm pretty optimistic that all of the "anomalies" issued by Comodo's CA system (except for the 8 mentioned in our recent incident report) will be found to fall into these categories, although I haven't done an exhaustive analysis yet. If there are any other "anomalies", they're a bit lost in the noise at present! -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
