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:pzbo...@gmail.com] Sent: Wednesday, November 18, 2015 12:33 AM To: Richard Wang <rich...@wosign.com> Cc: Rob Stradling <rob.stradl...@comodo.com>; Peter Gutmann <pgut...@cs.auckland.ac.nz>; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: [FORGED] Name issues in public certificates On Tue, Nov 17, 2015 at 6:12 AM, Richard Wang <rich...@wosign.com> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
