Re: Symantec Response X

On 10/04/2017 16:58, Steve Medin wrote: 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

Re: Symantec Issues doc updated

On 11/04/2017 18:53, Gervase Markham wrote: On 11/04/17 17:34, Ryan Sleevi wrote: Can you clarify what issues you believe this to be related? That is a fair question. And also hard work to answer :-) Given that Symantec has a routine habit of exceeding any reasonable deadline for response,

Re: Symantec Response L

On Tue, Apr 11, 2017 at 6:37 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > On 11/04/17 04:45, Eric Mill wrote: > > > But I think it's important to note that this relationship was not widely > > understood or publicly discussed as part of the

RE: Next CA Communication

Kathleen, Can you explain how policy 2.4 applies to existing CAs with respect to being Technically Constrained? This is my understanding: - Under policy 2.3 a CA that is technically constrained with EKU set to only secure email but without name constraints was considered out of scope of the

Re: Symantec Issues doc updated

>Within a few days of discovering these issues they shut down their >entire RA program. That seems pretty swift and comprehensive to me. The >fact that they didn't discover these issues for years is clearly a >problem, but it's not the same problem. I don't believe that's a fair

Re: Symantec Issues doc updated

On Tue, Apr 11, 2017 at 12:53 PM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > "to specifically address the > > GeoRoot audit status and remediation plan" - this was not reflected > within > > https://www.symantec.com/content/en/us/about/media/ >

Re: Symantec Response T

On Tue, Apr 11, 2017 at 12:42 PM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > In various rounds of questioning at the time we were focussing purely on > this incident, I asked Symantec what processes they had in place for > checking that the RAs were

Re: Symantec Response X

On 11/04/17 17:51, Ryan Sleevi wrote: > Also, search SSL. Not TLS :) Aha! > Further, its CPS states > > "MSC Trustgate.com is a “Processing Center,” as described in CP § > 1.1.2.1.2, which > means MSC Trustgate.com has established a secure facility housing, among > other > things, CA systems,

Re: Symantec Issues doc updated

On 11/04/17 17:34, Ryan Sleevi wrote: > Can you clarify what issues you believe this to be related? That is a fair question. And also hard work to answer :-) > Given that Symantec has a routine habit of exceeding any reasonable > deadline for response, at what point do you believe it is

Re: Symantec Response X

On Tue, Apr 11, 2017 at 12:33 PM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > E-Sign's CPS URL is given in its audit statement as: > https://www.e-sign.cl/uploads/cps_esign_388.pdf > > Grepping that document for "TLS" gives no hits. Can you help me

Re: Symantec Response T

On 11/04/17 17:18, Ryan Sleevi wrote: > 1) On the basis of the controls Symantec described, at no point was any > mention made of Symantec performing sampling audits to ensure their RA > partners complied with either the RA partner's CP/CPS or Symantec's CP/CPS. > a) Is it fair to conclude that

Re: Criticism of Google Re: Google Trust Services roots

On 11/04/17 14:05, Peter Kurrasch wrote: > Is there room to expand Mozilla policy in regards to ownership issues? Subject to available time (which, as you might guess by the traffic in this group, there's not a lot of right now, given that this is not my only job) there's always room to

Re: Symantec Issues doc updated

On Tue, Apr 11, 2017 at 6:49 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I have attempted to integrate the information provided by Symantec into: > https://wiki.mozilla.org/CA:Symantec_Issues > and started to draw some conclusions where that is

Re: Symantec Response X

On 11/04/17 16:23, Ryan Sleevi wrote: > The audits mention the CP/CPS has been evaluated as part of the scope of > the audit. Yep, OK. > The CP/CPS mentions the issuance of TLS certificates as part of the > hierarchy. For example, > > "E-Sign provides its services in accordance with its

Re: Symantec Response T

On Mon, Apr 10, 2017 at 10:57 AM, Steve Medin via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Issue T: RA Program Misissuances (January 2010 - January 2017) > > Program Background: > > Symantec has operated an RA program designed to deliver a superior > customer

Re: Symantec Response B

On Tue, Apr 11, 2017 at 11:44 AM, Kurt Roeckx via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > The reply indicated that it was a non-browser application. So I understand > that a browser should never see that certificate. > There's no way to objectively quantify or

Re: Symantec Response B

On 2017-04-11 17:20, Ryan Sleevi wrote: On Tue, Apr 11, 2017 at 6:02 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: Hi Ryan, On 10/04/17 16:38, Ryan Sleevi wrote: 1) You're arguing that "the issuance of this cert didn't impose risk on anyone but

Re: Symantec Response V

> > > Hi Steve, Some follow-up questions: 1) Symantec stated "This information was in their management assertions, and repeated in the audit findings. So the poor audit situation was ongoing and known." a) Symantec did not meaningfully provide any explanation, now, or in the past, as to why it

Re: Symantec Response L

On Tue, Apr 11, 2017 at 6:31 AM, Gervase Markham wrote: > Hi Ryan, > > On 10/04/17 17:03, Ryan Sleevi wrote: > > 2) You stated that "browsers didn't process certificate policy extensions > > content during path building". This fails to clarify whether you believe > it > > was a

Re: Symantec Response X

On Tue, Apr 11, 2017 at 6:21 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi Ryan, > > On 10/04/17 17:20, Ryan Sleevi wrote: > > 1) You stated that this partner program applies to non-TLS certificates. > > The audit for both STN and for the RAs

Re: Symantec Response B

On Tue, Apr 11, 2017 at 6:02 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi Ryan, > > On 10/04/17 16:38, Ryan Sleevi wrote: > > 1) You're arguing that "the issuance of this cert didn't impose risk on > > anyone but this specific customer" > > a)

Re: Symantec Response L

On Tue, Apr 11, 2017 at 6:37 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi Eric, > > Perhaps you are being intentionally non-directive, in which case perhaps > you can't answer my questions, but: > Yes, I am being intentionally non-directive.

Re: Criticism of Google Re: Google Trust Services roots

I think Jacob was merely attempting to provide a more thought out alternative to my proposal basically requiring potential CA owners to first be "accepted" into the Mozilla trusted root program. There is some

Re: Symantec Response V

Hi Steve, Thank you for this. Issue V was indeed somewhat confused - my apologies. I have split it into Issue V, covering GeoRoot, and Issue W, covering the RAs. On 10/04/17 15:58, Steve Medin wrote: > Separately, Symantec operates two subordinate CAs solely for NTT > DoCoMo in an enterprise PKI

Symantec Issues doc updated

I have attempted to integrate the information provided by Symantec into: https://wiki.mozilla.org/CA:Symantec_Issues and started to draw some conclusions where that is warranted. There are of course still open questions from myself, Ryan and others, and so the truth relating to some incidents is

Re: Questions for Symantec

Hi Steve and Rick, Just to confirm: even after reviewing your extensive responses to the issues list, I feel that all the 8 questions on my questions list are still outstanding and require answers. Thanks :-) Gerv ___ dev-security-policy mailing list

Re: Symantec Response L

Hi Ryan, On 10/04/17 17:03, Ryan Sleevi wrote: > 2) You stated that "browsers didn't process certificate policy extensions > content during path building". This fails to clarify whether you believe it > was a Baseline Requirements violation, which makes no such statements > regarding policy

Re: Symantec Response X

Hi Ryan, On 10/04/17 17:20, Ryan Sleevi wrote: > 1) You stated that this partner program applies to non-TLS certificates. > The audit for both STN and for the RAs fails to make this distinction. For > example, audits are listed related to the issuance of of TLS certificates. The audits linked to

Re: Symantec Response B

Hi Ryan, On 10/04/17 16:38, Ryan Sleevi wrote: > 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? Can you lay out for us a scenario where this issuance might impose risk on someone else? >

Re: Symantec Response R

My understanding is that the QuickInvite system doesn't distinguish the reseller from their customer in terms of access to the order. It's not very clear from Symantec's documentation, and Tarah never got back to me in the thread about it, but I think a reseller absolutely can wait for their

Re: Symantec Response J

On 2017-04-11 11:15, Kurt Roeckx wrote: On 2017-04-10 17:52, Ryan Sleevi wrote: 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,

Re: Symantec Response P

On 2017-04-10 16:57, Steve Medin wrote: Because our customers are our top priority, we attempted to minimize business disruption I think you have your top priority wrong, and this seems to be a reoccurring reason why you do things. Kurt ___

Re: Symantec Response J

On 2017-04-10 17:52, Ryan Sleevi wrote: 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