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



-----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 

   - 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 

Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
dev-security-policy mailing list

Attachment: smime.p7s
Description: S/MIME cryptographic signature

dev-security-policy mailing list

Reply via email to