On 17/11/15 18:27, Jeremy Rowley wrote:
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.
[JR] I suppose that is true under 7.1.4.2.1 but how would you get the browsers
to work back then? Chrome and IE did not process ipAddress properly.
Jeremy, I don't recall any clause in the BRs that permits CAs to ignore
requirements that they or their customers don't like.
They are not Baseline Suggestions! ;-)
If (whilst the BRs have been in force) there's been a perceived need to
encode IP addresses in dNSName fields, then don't you think that the
correct thing to do would've been to take the matter to CABForum and
seek to update the BRs so that this practice is permitted?
Jeremy
Regards,
Richard
-----Original Message-----
From: dev-security-policy
[mailto:dev-security-policy-bounces+richard=wosign.com@lists.mozilla.o
rg] 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
