Re: [FORGED] Name issues in public certificates

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

RE: [FORGED] Name issues in public certificates

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

RE: [FORGED] Name issues in public certificates

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

RE: [FORGED] Name issues in public certificates

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 >

Re: [FORGED] Name issues in public certificates

On 17/11/15 16:25, Peter Bowen wrote: - 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

Re: [FORGED] Name issues in public certificates

On Tue, Nov 17, 2015 at 05:40:28PM +, Rob Stradling wrote: > > Great. I tried importing the list into postgres but I couldn't persuade it > to accept the invalid character encodings, so I gave up. When importing data in my postgres database I leave the fields NULL in case I really can't do

Re: [FORGED] Name issues in public certificates

On Tue, Nov 17, 2015 at 2:40 PM, Rob Stradling wrote: > On 17/11/15 17:54, Kurt Roeckx wrote: >> >> On Tue, Nov 17, 2015 at 05:40:28PM +, Rob Stradling wrote: >>> >>> >>> Great. I tried importing the list into postgres but I couldn't persuade >>> it >>> to accept

Re: [FORGED] Name issues in public certificates

On 17/11/15 22:47, Peter Bowen wrote: I've uploaded the original CSV file to https://s3-us-west-2.amazonaws.com/pzb-public-files/invalid-dnsname.csv I suspect it might work better than the CSV -> Google Sheets -> TSV path. Thanks, Peter Thanks Peter. -- Rob Stradling Senior Research &

Re: [FORGED] Name issues in public certificates

On 17/11/15 17:54, Kurt Roeckx wrote: On Tue, Nov 17, 2015 at 05:40:28PM +, Rob Stradling wrote: Great. I tried importing the list into postgres but I couldn't persuade it to accept the invalid character encodings, so I gave up. When importing data in my postgres database I leave the

Removed Certs Spreadsheet

All, We've added a new report, that is automatically generated from Salesforce: https://wiki.mozilla.org/CA:RemovedCAcerts Please note the caveat: The Removed Certs Spreadsheet currently only lists the cert removals that have happened since September 2014, which is when we began using

Re: [FORGED] Name issues in public certificates

Based on writing the code to these checks, I think it would be good for the CAB Forum to consider the following clarifications/changes: 1) for dNSname type GeneralNames, make sure implementers are aware that the "preferred name synatx" in RFC1034 does not allow a trailing period on a Domain Name

RE: [FORGED] Name issues in public certificates

I think we should update BR for IP address as dNSANames since the browser don't support IP address only, but many communication servers need the IP SSL certificate. We will test which browser don't support it. Best Regards, Richard -Original Message- From: Jeremy Rowley

Re: [FORGED] Name issues in public certificates

Richard, Please check the updated file I posted. My check to exclude certain certificates was broken in the first pass but the revised version properly excludes them. The content is still at https://docs.google.com/spreadsheets/d/1lJt-1tkgKcbw5woEr4-tcpqB-M-HKwjFNSdX2jla2EU/edit?usp=sharing,

RE: [FORGED] Name issues in public certificates

I checked your list that the excel list number are: 6653 -- 6662, 29830 -- 29841, 30434 -- 30437, they are all Client certificates without serverAuth EKU, but listed, please check it, thanks. The attached certificate is No. 6653, please check its EKU, thanks. Best Regards, Richard

RE: [FORGED] Name issues in public certificates

Yes, all Client certificates are removed, thanks. So WoSign only left IP address issue that we added both IP address and DNS Name since some browser have warning for IP address only in SAN. Best Regards, Richard -Original Message- From: Peter Bowen [mailto:pzbo...@gmail.com] Sent:

RE: [FORGED] Name issues in public certificates

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

RE: [FORGED] Name issues in public certificates

They were until Feb 2013 :) Sure - let's discuss these issues at the CAB Forum. Based on the spreadsheet, I'm pretty sure lots of CAs would like to re-address the elimination of all SANs except iPAddress and dNSANames. -Original Message- From: Rob Stradling