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, but has been updated. Thanks, Peter On Tue, Nov 17, 2015 at 6:07 PM, Richard Wang <[email protected]> wrote: > 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 > > > -----Original Message----- > From: Peter Bowen [mailto:[email protected]] > Sent: Wednesday, November 18, 2015 12:33 AM > To: Richard Wang <[email protected]> > Cc: Rob Stradling <[email protected]>; Peter Gutmann > <[email protected]>; [email protected] > Subject: Re: [FORGED] Name issues in public certificates > > On Tue, Nov 17, 2015 at 6:12 AM, Richard Wang <[email protected]> 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; > > I filtered for certificates that includes the serverAuth EKU or do not include > any EKUs. Can you provide an example of a clientAuth certificate that was > incorrectly included? > >> 2. IP address is allowed by BR; > > IP addresses are only allowed in the commonName or as IPAddress type in the > SAN extension. If the rule is _ipv4_not_allowed_here, then that means that an > IP address was included in a SAN as a DNS Name, which is disallowed. I will > also fix the IP check to differentiate between reserved IPs (as defined in the > BRs) and special purpose IPs (which are allowed if not reserved). The BRs do > not clearly state that 192.168.0.0/24, 172.16.0.0/12, and other special > purpose IPs are disallowed. > >> 3. IDN is allowed, but also in the report > > See my note to Rob; I'm fixing that. I misread RFC 5280 section 7.2. > > Thanks, > Peter > > _______________________________________________ > 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
