On Tue, Nov 17, 2015 at 5:31 AM, Rob Stradling <rob.stradl...@comodo.com> wrote:
> 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 (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.
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.
> - 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.
> - 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?
> 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. 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.
Thanks,
Peter
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
