On Mon, Apr 10, 2017 at 10:55 AM, Steve Medin via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Issue D: Test Certificate Misissuance (April 2009 - September 2015)
>
> Symantec has provided complete investigation results for this issue. They
> can be found at
Hi Steve,
Quick questions:
1) Why was Symantec unable to operate the CRL service for Unicredit?
2) Pursuant to Section 5.7.1 of the Baseline Requirements, Symantec, and
all of its sub-CAs, are required to document business continuity and
disaster recovery procedures. Had Unicredit been operating
Hi Steve,
Quick question:
1) You identified that the root cause was related to a deprecated, but not
removed, interface. Your remediation was to remove that interface.
a) How many deprecated, but unremoved, interfaces does Symantec have, as
of 2017-04-10?
Hi Steve,
Some quick follow-ups:
1) You're arguing that "the issuance of this cert didn't impose risk on
anyone but this specific customer"
a) What factors lead you to that decision?
b) What process does Symantec have in place to make such determination?
c) Does such process continue to
Hi Steve,
Quick questions:
1) To confirm, your response states nothing about any improved procedures
or testing put into place regarding this.
a) Can you describe what, if anything, Symantec did, beside "fix the bug"?
b) What assurances should the community have regarding Symantec's
Hi Steve,
Quick questions:
1) You identified that Symantec believed that it was a responsibility to
ensure your customers' businesses remain interrupted.
a) What is Symantec's process for determining which of these concerns
(Baseline Requirements vs customer business) has priority?
b) Has
Hi Steve,
Quick questions:
1) What does Symantec believe is a reasonable timeframe to remedy these
issues?
2) You stated 18 months, but the issues were present from the 2013/2014
audits, the 2014/2015 audits, and the 2015/2016 audits, all as noted in
Issue V. In total, this period spans 30
Hi Steve,
Quick follow-up.
1) Your audit reports failed to identify what steps Symantec was taking to
proactively resolve these issues. As further demonstrated by Issue Q,
Symantec failed to remedy these issues.
a) What steps, if any, did Symantec take upon receiving a qualified audit?
b)
Hi Steve,
Quick questions:
1) What steps, specifically, has Symantec taken to ensure such clarity is
provided in the future?
2) What steps, specifically, has Symantec taken to ensure appropriate
review prior to the execution of such processes?
These questions apply to any process involving CA
On Monday, 10 April 2017 20:28:53 UTC+1, michael...@gmail.com wrote:
> A couple points of clarification please:
>
> 1) Mr. Byrne clarified his post to note that the flaws in the Symantec API
> would allow: retrieval of certificates that included private keys, not the
> private keys alone. Was
A couple points of clarification please:
1) Mr. Byrne clarified his post to note that the flaws in the Symantec API
would allow: retrieval of certificates that included private keys, not the
private keys alone. Was this possible?
2) You say, "it's not technically feasible", which implies
On Mon, Apr 10, 2017 at 02:57:41PM +, Steve Medin via dev-security-policy
wrote:
> In April 2015, security consultant Chris Byrne responsibly disclosed two
> potential vulnerabilities related to our Quick Invite feature, which
> enables a reseller to invite pre-selected customers to enroll
On Mon, Apr 10, 2017 at 10:56 AM, Steve Medin via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Issue L: Cross-Signing the US Federal Bridge (February 2011 - July 2016)
>
> Symantec, as well as VeriSign, has participated in the FPKI since 2006,
> and we take our
Issue B: 1024-bit Certificate Issued Directly From Root (Dec 2013 - Jan
2014)
The customer in question informed us of an issue in December 2013 that
threatened to seriously disrupt their primary business, and they sought our
assistance. The customer's non-browser implementation required a
Issue H: SHA-1 Issuance After Deadline (January 2016)
With respect to Issue H, Symantec has no additional comments regarding the
perspective outlined in the summary. Please see
https://cabforum.org/pipermail/public/2016-January/006519.html for further
detail on Symantec's previous commentary
Issue E: Domain Validation Vulnerability (October 2015)
With respect to Issue E, Symantec has no additional comments regarding the
perspective outlined in the summary. Please see
Issue Q: Symantec Audit Issues 2016 (December 2015 - November 2016)
In our 2014-2015 audits, certain issues were identified that we promptly took
action on, including addressing the test certificate incident. We continued
these efforts until the Point in Time audit was conducted. We split the
Issue N: Premature Manual Signing Using SHA-1 (July 2016)
This matter represents the first time any CA attempted to follow the exception
process which was developed over the course of weeks, beginning at the Bilbao
CABF face-to-face meeting in May 2016, and with the input of our partners.
Issue L: Cross-Signing the US Federal Bridge (February 2011 - July 2016)
Symantec, as well as VeriSign, has participated in the FPKI since 2006, and we
take our responsibility as a participant of this program very seriously. When
Symantec began participating in FPKI, FPKI rules required two-way
Issue P: UniCredit Sub CA Failing To Follow BRs (April - October 2016)
We are committed to keeping our customers, partners and ecosystem informed and
taking action when necessary. We recognize that there are issues we are
accountable for, such as our March 2016 CA Communication response
Issue V: RA Program Audit Issues (2013 or earlier - January 2017)
Symantec has had two different programs that involve delegated third parties
associated with publicly trusted TLS and subject to third-party audits: our
GeoRoot program and our RA/Affiliate program.
GeoRoot refers to our program
Issue R: Insecure Issuance API (2013 or earlier - November 2016)
In April 2015, security consultant Chris Byrne responsibly disclosed two
potential vulnerabilities related to our Quick Invite feature, which enables a
reseller to invite pre-selected customers to enroll for certificates, via
Issue T: RA Program Misissuances (January 2010 - January 2017)
Program Background:
Symantec has operated an RA program designed to deliver a superior customer
experience in global markets where language skills, understanding of local
business requirements, and physical local presence are
Issue X: Incomplete RA Program Remediation (February - March 2017)
The only Symantec RAs capable of authorizing and issuing publicly trusted
SSL/TLS certificates are: CrossCert, Certisign, Certsuperior and Certisur.
Symantec continues to maintain a partner program for non-TLS certificates.
Hi Steve,
Tiny nit-picky follow up question. You said: "it's technically not
feasible. This is because Symantec does not have access to our customers'
TLS server private keys.".
X.509 certificates can of course be used for things besides TLS, when you
say "TLS server private keys", is that
25 matches
Mail list logo
