While interesting, this report is probably going to be used for a lot of misleading statements. There's lots to consider in this:
1) Considering that the 3-year validity cap was a recent requirement, I'm surprised your search only resulted in 50,000 certificates with all of the 5-10 year certificates that were issued. 2) Remember that the BRs were not binding on any CA until adopted by a browser. Mozilla was the first CA to adopt on ~Feb 15 2013. Despite the effective date of the BRs in July 2012, it's hard to say those certificates were not compliant at the time of issuance when the policies weren't required. Although I understand that this data shows compliance of with the current version of the BRs, I won't be too surprised to see the info taken out of context and say the certs were not issued properly. 3) No EKU was a recent CAB Forum debate that didn't have a resolution. They aren't technically covered by the BRs according to some CAs as they aren't intended for use in authenticating servers accessible through the Internet. I tried to fix this issue in the CAB Forum but the discussions and proposed solutions didn't go anywhere because of the RFCs and various jurisdictional requirements. I'd still love to see this remedied in the BRs at some point. 4) Can you explain where in the BRs it prohibits Ipv4 name in the dnsName? It shouldn't go there but there is a good reason for including it in the dnsName. One of the browsers used to choke if you use ipAddress instead of dnsName. (http://www.michaelm.info/blog/?p=1281) I'm sure there are more concerns, but that's just a few of the initial thoughts I had when looking through the info. Jeremy -----Original Message----- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert....@lists.mozilla.org] On Behalf Of Rob Stradling Sent: Tuesday, November 17, 2015 10:40 AM To: Peter Bowen Cc: [email protected]; Peter Gutmann Subject: Re: [FORGED] Name issues in public certificates On 17/11/15 16:25, Peter Bowen wrote: <snip> >> - 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. > > I read 7.2 again and it clearly calls out as only applying to > domainComponent attributes. I'll rerun with allowance for hostnames > with u-labels in CNs. Thanks. >> - 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. > > Yes, I should have been clearer here. The correct description should > be "determining if the names in unexpired certificates follow the > current BRs". As you point out, the BRs have changed over time and > didn't even exist when some of these were issued. That is why I > included the not before date; those examining the list should > determine their cutoff date. My concern is that many folks won't take the step of determining a sensible cutoff date. (Incidentally, this is why we deliberately only looked back at the past 1 year's worth of certs in the research we published last week). See how quickly even the esteemed Dr Gutmann seemed to be willing to take your report at face value - "That's still pretty scary, nearly 50,000 names from a who's-who of commercial CAs". ;-) >> - You wanted to check "server auth certificates issued by public CAs". >> However, I see some Code Signing Certificates in your report. > > I included all certificates that included the serverAuth EKU and all > those that had no EKU. Can you provide an example of a code signing > cert in the list so I can figure out why this test failed? CT knows about 2 certs issued by "COMODO RSA Code Signing CA", and your report flagged both of them, even though both certs contain the EKU extension with just the Code Signing OID. https://crt.sh/?Identity=%25&iCAID=2035 >> 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! > > I'll rerun the data in a few hours. I also will fix the encoding > issues; somehow the character encoding got messed up on import to > Google Sheets. Great. I tried importing the list into postgres but I couldn't persuade it to accept the invalid character encodings, so I gave up. > I will also add a field column to help identify where in the > certificates the issues are occurring. Hopefully these changes will > help remove the noise. Definitely. Thanks! > Thanks, > Peter -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
