On 17/11/15 14:12, Richard Wang wrote:
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;
Reserved IP Addresses are no longer permitted by the BRs. This is what
Peter's "_special_ipv4" rule refers to, IIUC.
Encoding an IP Address in a dNSName is not permitted by the BRs. This
is what Peter's "_ipv4_not_allowed_here" rule refers to, IIUC.
Public IP Addresses, encoded in the iPAddress field, are indeed
permitted. I think Peter's report correctly avoided flagging these as
3. IDN is allowed, but also in the report
IDN is allowed, as long as it's encoded correctly.
See the previous comments about RFC5280 sections 7.2 and 7.3.
Behalf Of Rob Stradling
Sent: Tuesday, November 17, 2015 9:32 PM
To: Peter Gutmann <pgut...@cs.auckland.ac.nz>; Peter Bowen
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").
I fully agree that independent assessment is useful, but independent
assessments need to be assessed too (preferably before the press start quoting
soundbites! :-) )
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
dev-security-policy mailing list
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
COMODO CA Limited, Registered in England No. 04058690
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ
This e-mail and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
sender by replying to the e-mail containing this attachment. Replies to
this email may be monitored by COMODO for operational or business
reasons. Whilst every endeavour is taken to ensure that e-mails are free
from viruses, no liability can be accepted and the recipient is
requested to use their own virus checking software.
dev-security-policy mailing list