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 but how would you get the browsers 
to work back then? Chrome and IE did not process ipAddress properly.


> 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!
> _______________________________________________
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909

COMODO CA Limited, Registered in England No. 04058690 Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed.  If 
you have received this email in error please notify the sender by replying to 
the e-mail containing this attachment. Replies to this email may be monitored 
by COMODO for operational or business reasons. Whilst every endeavour is taken 
to ensure that e-mails are free from viruses, no liability can be accepted and 
the recipient is requested to use their own virus checking software.
dev-security-policy mailing list
dev-security-policy mailing list

Reply via email to