On 2015-10-28 22:30, Kathleen Wilson wrote:
According to the article, here is what Google is requiring of Symantec:
1) as of June 1st, 2016, all certificates issued by Symantec itself will
be required to support Certificate Transparency
I know this is directly copied from their blog about this, but I wonder
what it means for a certificate to support CT. Is the requirement
really that all certificates need to published in CT?
2) further update their public incident report with: A post-mortem
analysis that details why they did not detect the additional
certificates that we found. Details of each of the failures to uphold
the relevant Baseline Requirements and EV Guidelines and what they
believe the individual root cause was for each failure.
A few of the things that are currently unclear to me are:
- Could any of those certificates have been abused, as in was it
possible that the private key for any of those certificates was in the
hands of a person. There were indications that this might be the case
and I didn't see a reply about those.
- Are all certificates really found now and revoked? As above, the
current state is unclear.
- It says that they have a tool that "a limited number of privileged QA
personnel" can use and that this tool was misused (in this case). It
also talks about an "authentication team" that can issue test
certificates. Are this 2 different tools and does the "authentication
team" use the normal (non-QA) tools to issue test certificates but then
using a "specific review and approval process"?
- What is the difference between the "specific review and approval
process" and the normal process and why is this not the same?
- How is personnel trained?
- Why does the team training need to be changed if the tool does not
allow issuing certificates for non-Symantec domains?
- Why are those test certificates signed by a real CA and not a test CA?
5) The third-party security audit must assess:
-- The veracity of Symantec’s claims that at no time private keys were
exposed to Symantec employees by the tool.
-- That Symantec employees could not use the tool in question to obtain
certificates for which the employee controlled the private key.
It would also be nice to know that a 3rd party couldn't control the
private key.
-- That Symantec’s audit logging mechanism is reasonably protected from
modification, deletion, or tampering, as described in Section 5.4.4 of
their CPS.
So this looks to be their current "final" report:
https://www-secure.symantec.com/connect/sites/default/files/Test_Certificates_Incident_Final_Report_10_13_2015v3b.pdf
It still conflicts with itself, it first says that there were 3
certificate that shouldn't have been issued while the next paragraph
talks that there were 23. And then you have to go to the addendum to
see yet different numbers.
Kurt
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
