Re: Symantec Response X

[Jakob Bohm via dev-security-policy]

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 partner program for non-TLS certificates. 
E-Sign SA and MSC Trustgate are amongst these partners.



Please note that the Mozilla root program covers both SSL/TLS and
e-mail certificates (with slightly different inclusion policies).

Thus while the CABF BR rules may not apply to e-mail certificates,
Mozilla root program requirements do apply to such certificates and the
roots that are trusted to issue them.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Issues doc updated

[Jakob Bohm via dev-security-policy]

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, at what point do you believe it is appropriate for
the Mozilla Root Store to begin discussing what steps can or should be
taken with respect to the documented and supported incidents, which
Symantec has not provided counter-factual data?


Yes, fair enough. Rick and Steve: I will be taking Symantec's statements
to this group as of one week from today as the sum total of what you
have to say on the subjects under discussion. After that point, we will
draw conclusions based on the available data and decide on what course
of action we may take. I hope that by then you will be able to answer my
8 questions, and provide responses or comments to any of Ryan's or other
people's questions that you wish to address.

Kathleen is on vacation this week, and so no decisions could be taken
until next week at the earliest anyway.



Please consider the fact that this is Easter week, and most of the
industry, including many people (on both the Browser and Symantec sides
of the process) are likely to be unavailable for precisely this week of
the entire year.

In general, sending deadline mails (by paper, e-mail, process server or
otherwise) to anyone during a public holiday demanding actions during
that holiday is considered morally deficient at a minimum.




Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Response L

[Eric Mill via dev-security-policy]

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 Mozilla trusted root
> > program, between 2009 and 2016.
>
> And you think that's bad?
>

An (interactive) picture might help illustrate what I'm pointing to. This
is the Federal PKI:
https://fpki-graph.fpki-lab.gov

There's something like 200 civilian, military, and non-government CAs in
there, connected through a huge number of bridges and cross-signatures.
Despite the name, the Federal PKI contains more than the federal government
-- within that graph are signatures bridging over to sector-wide PKIs such
as SAFE-BioPharma. In the center is the Federal Common Policy CA, which
ultimately everything can be chained up to.

For the time that the cross-signature was active (the one in question is
here - https://crt.sh/?id=12638543 and was ~8 months beginning in December
2015), all 200 of those CAs were capable of issuing a certificate that
would be technically trusted by users of the Mozilla root store. I haven't
looked to see whether there were other cross-signatures issued by VeriSign
or Symantec since the cross-signer's parent CA was admitted to the Mozilla
root store around 2009.

All that's been said here by Symantec on this issue's impact is that the
discussion around this made it clear that browsers don't respect
certificate policy identifiers (OIDs). Those policy identifiers would have
been, as I understand it, the sole technical constraint capable of
protecting users of the Mozilla trust store from mis-issuance from any of
these 200 CAs, had clients respected them.

I'll leave it to others to opine on the severity of the mistake and the
quality of the response, but I do want to at least properly communicate the
impact.

-- Eric


> There were several discussions about including the FPKI roots during
> this time, and about the problems that might cause. I might expect
> someone reading those, who knew that we already trusted bits (or all?)
> of the FPKI due to their actions, to say something...
>
> Gerv
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



-- 
Eric Mill
Senior Advisor, Technology Transformation Service, GSA
eric.m...@gsa.gov, +1-617-314-0966 <(617)%20314-0966>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Next CA Communication

[Doug Beattie via dev-security-policy]

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 
Mozilla Policy.  
- Policy 2.4.1 adds a requirement that for the CA to be out of scope of the 
Mozilla policy the CA needs to have name constraints if the CA is capable of 
issuing secure email certificates.

Is this accurate?  If so, when does this new requirement apply to existing CAs?

Doug


> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of Kathleen
> Wilson via dev-security-policy
> Sent: Tuesday, April 4, 2017 4:13 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Next CA Communication
> 
> On Tuesday, April 4, 2017 at 10:38:28 AM UTC-7, Kathleen Wilson wrote:
> >
> > The email has been sent, and the survey is open.
> >
> 
> 
> Published a security blog about it:
> https://blog.mozilla.org/security/2017/04/04/mozilla-releases-version-2-4-ca-
> certificate-policy/
> 
> Cheers,
> Kathleen
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Issues doc updated

[urijah--- via dev-security-policy]

>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 characterization--looking at 
https://knowledge.symantec.com/support/ssl-certificates-support/index?page=content=INFO4154
it was more like "After approximately 3 weeks (Jan 19-Feb 12) they *decided* to 
shut down their RA program." 

("we have made the decision to terminate our partner RA program. We will 
continue to work with select partners that have local market contacts and 
expertise to facilitate an interface with customers and collection of relevant 
documentation, however Symantec personnel will validate 100% of all asserted 
identity data and control certificate issuance going forward. We have 
communicated this change to each of our RA partners, we are finalizing a 
transition plan, and intend to implement that transition quickly.")

Their latest update (approximately 3 months from the initial report) is that 
"Symantec announced the decision to wind down the RA program for publicly 
trusted SSL/TLS."

https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/dVMxrUVygS0/xeUCJ1kmDQAJ

While Symantec re-validating each issued cert from their RA's is good, and it 
appears CrossCert  is fully terminated, they clearly have not "shut down their 
entire RA program."

 



On Tuesday, April 11, 2017 at 12:53:56 PM UTC-4, 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, at what point do you believe it is appropriate for
> > the Mozilla Root Store to begin discussing what steps can or should be
> > taken with respect to the documented and supported incidents, which
> > Symantec has not provided counter-factual data?
> 
> Yes, fair enough. Rick and Steve: I will be taking Symantec's statements
> to this group as of one week from today as the sum total of what you
> have to say on the subjects under discussion. After that point, we will
> draw conclusions based on the available data and decide on what course
> of action we may take. I hope that by then you will be able to answer my
> 8 questions, and provide responses or comments to any of Ryan's or other
> people's questions that you wish to address.
> 
> Kathleen is on vacation this week, and so no decisions could be taken
> until next week at the earliest anyway.
> 
> > It's unclear from your remark "Started to draw some conclusions where that
> > is warranted" what you see as the process and next steps. Perhaps you could
> > clarify what you imagine happening next, and on what timeline, to provide
> > clarity both to Symantec and the general population here. I must admit, I'm
> > quite confused as to where things stand, given that many items have
> > conclusions to them.
> 
> See above. After one week, I will be taking stock of the assembled
> evidence, and will invite community members also to draw conclusions. I
> will then present a recommendation for what we should do next. As you
> know, Mozilla's process is a little fuzzy around the edges, but Kathleen
> is the final decision maker. (And she doesn't always agree with me :-)
> 
> > With respect to the conclusion to Issue T "Symantec's reaction to the
> > discovery of these problems was unarguably swift and comprehensive.", I 
> > would disagree with this. Symantec's response was not swift, relative to
> > other CAs that have been informed of issues. It was not comprehensive -
> > Symantec failed to identify the issues until question, and still maintains,
> > in the latest response, that there is a conclusion unsupported by the
> > evidence they have shared with the community. Their timeline for
> > responsiveness was not swift - we're still discussing this specific issue,
> > and it was first reported on Issue T. I would be happy to find evidence of
> > issues from other CAs that demonstrate a more thorough response or a more
> > timely response.
> 
> 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.
> 
> > With respect to the conclusion to Issue T, "Their case is that WebTrust
> > audit monitoring should have been sufficient," it's unclear if you are
> > agreeing with that conclusion or simply stating Symantec claims.
> 
> Stating Symantec's claims.
> 
> > With respect to the conclusion to Issue V, 
> 
> That's not part of my conclusion, that's a quotation from Symantec which
> I need to check the accuracy of with Kathleen.
> 
> > "to specifically address the
> > 

Re: Symantec Issues doc updated

[Ryan Sleevi via dev-security-policy]

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/
> repository/23_Symantec_GeoTrust_WTBR_period_end_11-30-2016.pdf
> > , the relevant audit for the roots, ending on 2016-11-30.
>
> I'm a little confused - I think Symantec are saying that the cover
> letter explains the plan to wind down the two sub-CAs, not that the
> audit does?


I believe you are correct that they are claiming the letter sent addresses
that.

I am highlighting, however, that such a statement was not recorded in their
audit, despite it being a violation of the Baseline Requirements during the
period of time in the audit.

That is, if you are accepting that such a letter is relevant to the
discussion (and I believe it's fair to consider it as part of that), then
you should also consider as relevant to the conversation the failure to
either disclose that to the auditors or for the auditors to note that
(whichever it may be).
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Response T

[Ryan Sleevi via dev-security-policy]

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 doing what they should. Their answer was
> "WebTrust audits". So I believe they have already said that no such
> examination was done. I'm sure they'd be happy to clarify, though.
>

In attempting to make an objective evaluation of the trustworthiness of
Symantec, in either its past operations or as a future predictor, we
essentially need to understand

1) That Symantec understood the gravity of the situation
2) That Symantec took it seriously and responded appropriately relative to
the trust it was granted
3) That Symantec remains committed to doing so in the future, and with
specific plans to identify and remedy the issues

On the basis of the information provided, I see no reason to believe the
answer to #1 is that they did not (or that they "disagreed"), the answer to
#2 is that "They did not", and the answer to #3 is "They are not, and have
no specific plans".

Symantec is asserting its processes were trustworthy, but the evidence
provided wholly contradicts that conclusion (in my opinion). I'm looking to
develop a meaningful understanding of what Symantec did, so that it can
demonstrate that what it did was reasonable and expected, or to acknowledge
there were deficiencies that have a remediation plan. The current statement
appears to be that the processes were appropriate and no deficiencies -
despite the Baseline Requirements clearly contradicting this - and thus it
seems appropriate to suggest that Symantec should not be trusted and/or
have its trust meaningfully reduced to negate the impact that these
deficient practices have on the ecosystem.

The burden is two-fold:
1) Are the facts correct? It does not appear Symantec has disputed these,
except with respect to the RA partner audits (for which it provided
evidence that supports the current conclusions and refutes their
disagreement)?
2) Are there plans for the future, or an approach to the past, that is
meaningful to consider when evaluating the trustworthiness. At present,
Symantec's not shared such, beyond the RA remediation plans, which are at
conflict with the Baseline Requirements, its CP/CPS, and its Subscriber
Agreements.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Response X

[Gervase Markham via dev-security-policy]

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, including the cryptographic modules holding the private
> keys
> used for the issuance of Certificates. MSC Trustgate.com acts as a CA in
> the STN and
> performs all Certificate lifecycle services of issuing, managing, revoking,
> and
> renewing Certificates. "

That seems pretty clear. Perhaps Steve will be able to comment.

Gerv

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Issues doc updated

[Gervase Markham via dev-security-policy]

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 appropriate for
> the Mozilla Root Store to begin discussing what steps can or should be
> taken with respect to the documented and supported incidents, which
> Symantec has not provided counter-factual data?

Yes, fair enough. Rick and Steve: I will be taking Symantec's statements
to this group as of one week from today as the sum total of what you
have to say on the subjects under discussion. After that point, we will
draw conclusions based on the available data and decide on what course
of action we may take. I hope that by then you will be able to answer my
8 questions, and provide responses or comments to any of Ryan's or other
people's questions that you wish to address.

Kathleen is on vacation this week, and so no decisions could be taken
until next week at the earliest anyway.

> It's unclear from your remark "Started to draw some conclusions where that
> is warranted" what you see as the process and next steps. Perhaps you could
> clarify what you imagine happening next, and on what timeline, to provide
> clarity both to Symantec and the general population here. I must admit, I'm
> quite confused as to where things stand, given that many items have
> conclusions to them.

See above. After one week, I will be taking stock of the assembled
evidence, and will invite community members also to draw conclusions. I
will then present a recommendation for what we should do next. As you
know, Mozilla's process is a little fuzzy around the edges, but Kathleen
is the final decision maker. (And she doesn't always agree with me :-)

> With respect to the conclusion to Issue T "Symantec's reaction to the
> discovery of these problems was unarguably swift and comprehensive.", I   
> would disagree with this. Symantec's response was not swift, relative to
> other CAs that have been informed of issues. It was not comprehensive -
> Symantec failed to identify the issues until question, and still maintains,
> in the latest response, that there is a conclusion unsupported by the
> evidence they have shared with the community. Their timeline for
> responsiveness was not swift - we're still discussing this specific issue,
> and it was first reported on Issue T. I would be happy to find evidence of
> issues from other CAs that demonstrate a more thorough response or a more
> timely response.

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.

> With respect to the conclusion to Issue T, "Their case is that WebTrust
> audit monitoring should have been sufficient," it's unclear if you are
> agreeing with that conclusion or simply stating Symantec claims.

Stating Symantec's claims.

> With respect to the conclusion to Issue V, 

That's not part of my conclusion, that's a quotation from Symantec which
I need to check the accuracy of with Kathleen.

> "to specifically address the
> GeoRoot audit status and remediation plan" - this was not reflected within
> https://www.symantec.com/content/en/us/about/media/repository/23_Symantec_GeoTrust_WTBR_period_end_11-30-2016.pdf
> , the relevant audit for the roots, ending on 2016-11-30.

I'm a little confused - I think Symantec are saying that the cover
letter explains the plan to wind down the two sub-CAs, not that the
audit does?

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Response X

[Ryan Sleevi via dev-security-policy]

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 some more?
>

para Certificados de servidor Web - Table 4

Section 3.1.1.1 "subjectAltName" including type dNSName and iPAddress

Also, search SSL. Not TLS :)


> E-sign appear to be a Symantec SSL reseller:
> https://www.e-sign.cl/soluciones/seguridad
> but of course, I'm sure many companies are, and that's not necessarily a
> problem.
>

Sure, but then such activities would not be audited or part of its CP/CPS,
as that would be handled by the issuing CA that performs these roles.


>
> MSC Trustgate's audit statement gives no CPS URL.
> https://cert.webtrust.org/SealFile?seal=2127=pdf


https://www.msctrustgate.com/repository.htm

https://www.msctrustgate.com/pdf/MSC%20Trustgate%20CPS%2001OCT2012%20V3%203%208%20final.pdf

Which has Symantec's logo on it. And states

"At this time, the domain-validated and organization-validated SSL
Certificates issued by MSC
Trustgate.com CAs under this CP are governed by the CABF Requirements. "

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, including the cryptographic modules holding the private
keys
used for the issuance of Certificates. MSC Trustgate.com acts as a CA in
the STN and
performs all Certificate lifecycle services of issuing, managing, revoking,
and
renewing Certificates. "
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Response T

[Gervase Markham via dev-security-policy]

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 no such examination if done?

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 doing what they should. Their answer was
"WebTrust audits". So I believe they have already said that no such
examination was done. I'm sure they'd be happy to clarify, though.

Most of your other questions are fairly stated (if perhaps rather broad
in scope - are you expecting a total dump of all their internal
procedure documents?). But particularly:

>   d) Is it fair to conclude that Symantec's belief is that it does not have
> to follow the Baseline Requirements that it disagrees with?

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Criticism of Google Re: Google Trust Services roots

[Gervase Markham via dev-security-policy]

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 reconsider policy. But what we need is
a clearly-stated and compelling case that changing the way we think
about these things would have significant and realisable benefits, and
that any downsides are fairly enumerated and balanced against those gains.

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Issues doc updated

[Ryan Sleevi via dev-security-policy]

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 warranted.
>
> There are of course still open questions from myself, Ryan and others,
> and so the truth relating to some incidents is not yet clear.
>

Can you clarify what issues you believe this to be related?

Many of my questions related to Symantec's approach to handling incidents,
which were unaddressed or meaningfully deficient in ways that undermines
trust substantially, but were limited related to the material facts.

The only point where I believe Symantec disagreed with the summary was
Issue W, but it does not appear Symantec was bothered to support that claim
with objective data, rather than with statements. That is, that Symantec
disagrees is useful to know, but if Symantec has failed to provide any
evidence with that disagreement, I do not believe it should block reaching
a conclusion.

Given that Symantec has a routine habit of exceeding any reasonable
deadline for response, at what point do you believe it is appropriate for
the Mozilla Root Store to begin discussing what steps can or should be
taken with respect to the documented and supported incidents, which
Symantec has not provided counter-factual data?

Does the Mozilla Root Program seek to consider the intent of the CA that
violated the Baseline Requirements repeatedly for a span of several years?
If so, does it have a process at which point it will stop considering
feedback, versus allowing a CA to indefinitely delay meaningful action to
protect users?

It's unclear from your remark "Started to draw some conclusions where that
is warranted" what you see as the process and next steps. Perhaps you could
clarify what you imagine happening next, and on what timeline, to provide
clarity both to Symantec and the general population here. I must admit, I'm
quite confused as to where things stand, given that many items have
conclusions to them.

With respect to the conclusion to Issue T "Symantec's reaction to the
discovery of these problems was unarguably swift and comprehensive.", I
would disagree with this. Symantec's response was not swift, relative to
other CAs that have been informed of issues. It was not comprehensive -
Symantec failed to identify the issues until question, and still maintains,
in the latest response, that there is a conclusion unsupported by the
evidence they have shared with the community. Their timeline for
responsiveness was not swift - we're still discussing this specific issue,
and it was first reported on Issue T. I would be happy to find evidence of
issues from other CAs that demonstrate a more thorough response or a more
timely response.

With respect to the conclusion to Issue T, "Their case is that WebTrust
audit monitoring should have been sufficient," it's unclear if you are
agreeing with that conclusion or simply stating Symantec claims.

With respect to the conclusion to Issue V, "to specifically address the
GeoRoot audit status and remediation plan" - this was not reflected within
https://www.symantec.com/content/en/us/about/media/repository/23_Symantec_GeoTrust_WTBR_period_end_11-30-2016.pdf
, the relevant audit for the roots, ending on 2016-11-30. Do you believe
this should play in with any determination about the reliability of KPMG
audits (to discover this) and/or to Symantec (to disclose this to their
auditors)?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Response X

[Gervase Markham via dev-security-policy]

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 Certificate Policy and
> Certification Practices Statement"

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 some more?

E-sign appear to be a Symantec SSL reseller:
https://www.e-sign.cl/soluciones/seguridad
but of course, I'm sure many companies are, and that's not necessarily a
problem.

MSC Trustgate's audit statement gives no CPS URL.
https://cert.webtrust.org/SealFile?seal=2127=pdf

However, it certainly appears to be true that this company offers a
"Managed PKI for SSL" product:
https://www.msctrustgate.com/pdf/ManagedPKIforSSL_Agreement.pdf
and that they offer "VeriSign Class 3 organizational SSL Certificate"s,
and lets organizations apply for RA status within the Verisign Trust
Network.
The modification date of that document according to the webserver is
15th March 2012.

https://www.msctrustgate.com/product/ssl_id.htm also shows this.

They also have a Subscriber Agreement for SSL certificates:
https://www.msctrustgate.com/pdf/Class%203%20Organizational%20Certificate%20latest%20pdf.pdf
which are also "Symantec Class 3 organizational SSL Certificate"s.

The "Buy", "Renew" etc. links on the front page of
https://www.msctrustgate.com/ for SSL certs are all 404. According to
archive.org, they may have been that way for some time. Odd...

Steve?

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Response T

[Ryan Sleevi via dev-security-policy]

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 experience in global markets where language skills, understanding
> of local business requirements, and physical local presence are necessary.
> RA partners have supported various certificate types, including those for
> publicly trusted SSL/TLS.
>
> The RA program for publicly trusted SSL/TLS authorized appropriately
> trained personnel at select RA partners to complete all steps for
> authentication, review, and certificate issuance.
>
> In 2011, prior to ratification of the CA/Browser Forum Baseline
> Requirements, Symantec scaled back the scope of the RA program for publicly
> trusted SSL/TLS to support only those partners whose scale of business and
> investment in the future success of that business warranted the additional
> cost associated with supporting the then-new BRs. Since 2013, there have
> been only 4 RA partners still capable of processing and issuing publicly
> trusted SSL/TLS certificates: CrossCert, Certisign, Certsuperior, and
> Certisur.
>
> Symantec has had multiple controls in place to ensure these RAs'
> compliance with the BRs:
>
> Documentation:
> 1. Symantec operates an internal Knowledge Base ("KB") for its
> authentication staff and RA partners that contains detailed step-by-step
> procedures for performing each of the tasks required to validate the
> identity asserted in a certificate request.
> 2. The KB reinforces acceptable and unacceptable sources of validation
> information and processes using a subset of the information in the BRs.
> 3. The KB explains request flagging, flag reasons, and flag clearing
> procedures.
>
> Training & Exams:
> 1. Topics include BR changes, CPS changes, process changes resulting from
> industry incidents regardless of the CA involved, and a review of
> Symantec's procedures that extend the Baseline Requirements.
> 2. Exams are modified and retaken annually as criteria to renew individual
> access certificates or after significant internal or external process
> changes.
>
> Technology During Authentication:
> 1. Each request is screened for trade compliance, high-risk names,
> potential phishing (strings used in scam domains, high-profile brands), and
> other potentially risky content such as "test". Potential failures are
> flagged, preventing RA issuance, until and unless further review and
> analysis is completed.
> 2. Risk flags require manual override by authentication personnel -
> internal or RA personal as appropriate - for certificate issuance to
> proceed. Flag clearing privileges are only granted to personnel who are
> have completed the requisite training and passed appropriate exams.
>
> Technology Pre- and Post- Issuance:
> 1. Each request is screened to ensure elements outside of the subject
> information are BR compliant (e.g. SAN fields are complete, proper validity
> limits are in place, 2048 bit or higher key lengths are used, etc.). This
> scan is done after Authentication personnel approve the request and before
> it is issued. These checks cannot be overridden.
> 2. Daily, we rescan all certificates issued on the prior day using these
> same checks.
>
> Audit:
> 1. We requested independent WebTrust audit reports from RAs and assessed
> them for material findings pursuant to BR 8.4 regarding WebTrust audited
> Delegated Third Parties. See issue V addressing audits.
>
> Customer-Facing Controls:
> 1. Symantec supports Certification Authority Authorization, putting
> control of authorized CAs in the hands of customers.
> 2. Symantec logs publicly trusted certificates to Certificate Transparency
> Logs and offers a CT monitor to provide visibility for all customers to
> enable detection of suspect certificates.
>
> CrossCert Test Certificate Issue:
>
> On January 19, 2017, Andrew Ayer, an independent researcher posted the
> results of an analysis of public Certificate Transparency logs through
> which he identified roughly 270 instances of suspicious certificates issued
> by multiple CAs, including Symantec, containing the words "test" or
> "example" in the subject information.
>
> Symantec determined that 127 of these certificates were issued from
> Symantec operated CAs and that all 127 had been issued by the RA CrossCert.
> All but 31 had already expired or been revoked.
>
> Immediate Response
> Andrew Ayer's report was a certificate problem report under BR 4.9.5 which
> required us to begin an investigation within 24 hours, which we did. We
> determined that 127 certificates were in scope of the problem report.
>
> 1. On January 19, 2017, after becoming aware of this issue, Symantec
> disabled issuance privileges for all CrossCert staff.
> 2. On January 20, 2017, Symantec revoked the 31 still valid and active
> certificates. These 

Re: Symantec Response B

[Ryan Sleevi via dev-security-policy]

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 assess that, however. My question
still remains - what are the criteria for determining this, and what
process is in place for disagreement about this risk?


> The question is, can that certificate be used for authenticating something
> it shouldn't? And I guess that's not the case.
>

No. That is not the question.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Response B

[Kurt Roeckx via dev-security-policy]

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 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?



Sure. Consider the ecosystem risk where if every CA were to continue
issuing 1024-bit certs. This imposes a risk on the collective users of the
ecosystem, but notably Mozilla users, when accessing these sites, because
it provides a weaker security guarantee than other sites. That is, it means
the 'effective' security of the lock is gated on 1024-bit.

Similarly, if we accept that 1024-bit does no one but the subscriber any
harm, then it meaningfully prevents disabling 1024-bit support for leaf
certs, both for Mozilla and the ecosystem.


The reply indicated that it was a non-browser application. So I 
understand that a browser should never see that certificate.


The question is, can that certificate be used for authenticating 
something it shouldn't? And I guess that's not the case.



Kurt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Response V

[Ryan Sleevi via dev-security-policy]

>
>
> 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 took multiple audit periods to resolve these issues. In
order to establish for Relying Parties that Symantec is trustworthy and
competent, please supply additional details as to why it took so long.
  b) On the basis of the provided information, it does not appear Symantec
asked their GeoRoot partners for audits. This is also consistent with the
reports from UniCredits management, and we would be happy to reach out to
other GeoRoot partners regarding Symantec's communications over the past
several years. Given the issues such as Aetna, do you believe Symantec had
a material obligation to be diligent in obtaining an audit?
  c) What provisions, if any, did Symantec contractually have to ensure
such audits and compliance with Symantec's CP/CPS?
  d) Did such provisions include the ability for Symantec to revoke such
certificates for non-compliance, as required by the Baseline Requirements,
Section 9.6.3?
  e) If not, what steps have been taken to address this in all existing and
future business relationships?
  f) If it already existed, why did Symantec not exercise that option, as
required by the Baseline Requirements, Section 4.9.1.2?
  g) What assurances, if any, should Relying Parties have that Symantec
will execute its Baseline Requirements required obligations in the future,
given its documented failures in the past?

2) Symantec states "Because GeoRoot only operates under GeoTrust roots and
the associated CPS, the Symantec Trust Network and Thawte audits are fairly
stated."
  a) It has been identified that Symantec has failed to provide
BR-compliant audits for your RAs. Do you still believe this statement is
accurate?
  b) If so, why?
  c) If not, have you re-evaluated every statement Symantec has made in
response to these issues, to ensure that Symantec has not overlooked any
other material or contradictory evidence?

3) Do you believe the actions taken with respect to Aetna and Unicredit
were consistent with the Baseline Requirements?
  a) If so, specifically, what provisions?
  b) If not, what steps have you taken to ensure Symantec will abide by the
Baseline Requirements in the future, as is necessary and expected for
continued trust?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Response L

[Ryan Sleevi via dev-security-policy]

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 Baseline Requirements violation, which makes no such statements
> > regarding policy building. Further, no such browser has, except for EV,
> > made use of any policy IDs beyond path building.
>
> Can you clarify: are you asking if Steve believes that the BRs require
> _browsers_ to do such processing of certificate policy extensions?
>

No. I'm asking if Symantec, through Steve, is intending to sound like a
Scooby Doo villain , or
whether it's merely accidental that this reads as "I would have gotten away
with it, if not for you meddling browsers"

More specifically, Symantec has failed to respond as to whether or not they
agree with the facts presented and, if so, whether or not this represents a
Baseline Requirements violation, as suggested. The reply could be read as
suggesting "This was meaningfully technically controlled, it is simply that
browsers failed to enforce that."

This is problematic on multiple fronts, least of all because policy mapping
and IDs have never been a meaningful form of technical control in the Web
PKI, and so I'm hoping for further elaboration on the statement to ensure
it is it not misinterpreted.


> Or if he believes that cross-certifying into a hierarchy which relies
> upon such extensions is a BR violation?
>

This.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Response X

[Ryan Sleevi via dev-security-policy]

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 fails to make this distinction.
> For
> > example, audits are listed related to the issuance of of TLS
> certificates.
>
> The audits linked to from the wiki page relating to E-Sign and MSC
> TrustGate don't seem to have any mention of TLS certificates. Can you
> explain which audits you are referring to above that do mention them?
>

The audits mention the CP/CPS has been evaluated as part of the scope of
the audit.

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 Certificate Policy and
Certification Practices Statement"
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Response B

[Ryan Sleevi via dev-security-policy]

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) What factors lead you to that decision?
>
> Can you lay out for us a scenario where this issuance might impose risk
> on someone else?
>

Sure. Consider the ecosystem risk where if every CA were to continue
issuing 1024-bit certs. This imposes a risk on the collective users of the
ecosystem, but notably Mozilla users, when accessing these sites, because
it provides a weaker security guarantee than other sites. That is, it means
the 'effective' security of the lock is gated on 1024-bit.

Similarly, if we accept that 1024-bit does no one but the subscriber any
harm, then it meaningfully prevents disabling 1024-bit support for leaf
certs, both for Mozilla and the ecosystem.

Importantly though, I think the question highlights the principle at play
here - which is Symantec seems to view the Baseline Requirements as "The
Baseline Suggestions that should be Requirements for our Competitors but
Recommendations for Us". That is deeply problematic, and it's useful to
understand from Symantec what factors go in to such determinations, in
order to determine whether or not Symantec is, has been, or can be
trustworthy.


> > 2) You've noted that you did not disclose it due to "contractual
> > obligations to protect the customer's privacy", which "remains in force".
> >   a) If a contractual obligation is in conflict with the Baseline
> > Requirements, do you have a process defined to resolve that conflict? If
> > so, please fully describe it.
>
> Do you think this particular contractual obligation to privacy _is_ in
> conflict with the BRs? If so, which section?
>

The obligation itself, no, but the results of that obligation
unquestionably are.

I think it's in conflict with trustworthiness for Symantec to have policies
that would prevent it from meaningfully disclosing certificates that are
misissued (whether according to the Baseline Requirements or Symantec's
CP/CPS), because it prevents and impairs the ability to understand the
scope of the issues or the truthfulness of Symantec's claims.

I'm deeply concerned with the suggestion that details of BR violations
either cannot or should not be disclosed.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Response L

[Eric Mill via dev-security-policy]

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. I'll leave the opinions to
others with more historical familiarity with the relevant programs and
policies.

-- Eric
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Criticism of Google Re: Google Trust Services roots

[Peter Kurrasch via dev-security-policy]

  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 overlap, yes, but the general idea is to be more prescriptive in ownership than the current policy states.Is there room to expand Mozilla policy in regards to ownership issues?From: Gervase Markham via dev-security-policySent: Friday, April 7, 2017 4:50 AMTo: mozilla-dev-security-pol...@lists.mozilla.orgReply To: Gervase MarkhamSubject: Re: Criticism of Google Re: Google Trust Services rootsOn 06/04/17 18:42, Jakob Bohm wrote:> Here are some ideas for reasonable new/enhanced policies (rough> sketches to be discussed and honed before insertion into a future> Mozilla policy version):I'm not sure what's new or enhanced about them. Our current policies arenot this prescriptive so CAs have more flexibility in how they go aboutthings, but I believe they preserve the same security invariants.In general, I suggest that if others have policy problems they see, youlet them draft the solutions? :-)‎Gerv___dev-security-policy mailing listdev-security-policy@lists.mozilla.orghttps://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Response V

[Gervase Markham via dev-security-policy]

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 application. These subordinate CAs had
> been considered part of the "GeoRoot" program as well, and we had
> therefore excluded them (similar to the above externally operated
> ones) from the list of Symantec CAs in our audits.

If they were excluded from the Symantec audit, and were not one of the
five GeoRoot partners who had their own audits, did these subordinate
CAs fall under any audit at all in this period?

> Symantec provided the letter quoted below to Google, Mozilla,
> Microsoft, and Apple when we shared the Point in Time Audits on
> September 6, 2016 to specifically address the GeoRoot audit status
> and remediation plan.

Without seeming to doubt your word, can you tell me how you supplied
such a letter? Was it to certifica...@mozilla.org or directly to
Kathleen? A quick search can't find it in my email archive, so a
recipient, Subject and Date for the communication would be most appreciated.

> All of Certisign's audits are both WebTrust for CAs and SSL Baseline
> and were unqualified.

The Certisign audit provided was this one:
https://bug1334377.bmoattachments.org/attachment.cgi?id=8831929

It does say that Certisign complied with the Network Security Guidelines
but doesn't mention the BRs and, somewhat confusingly, also says:

"This report does not include any representation as to the quality of
CERTISIGN - CA's services beyond those covered by the Trust Service
Principles and Criteria for Certification Authorities..."

which suggests this audit is only a WebTrust for CAs audit, not a BR
audit. Are there audit documents missing which show that they were
BR-audited? Can you clarify?

> Certsuperior's audits  state that their scope was WebTrust for SSL
> Baseline but do not state WebTrust for CAs. Prior to 2016,
> Certsuperior provided WebTrust SSL Baseline audits from an unlicensed
> auditor. Symantec's compliance organization identified the issue in
> 2016. For 2016, Certsuperior provided a qualified audit by Deloitte,
> a WebTrust licensed auditor in Mexico. Certsuperior's audit led to
> immediate sanction to solve the issues detected within 90 days and to
> provide a Point in Time audit. They provided such audit and it was
> unqualified. Further, Deloitte is required to examine certificate
> issuance as a normal part of the WebTrust program and they did not
> cite any problems with Certsuperior's validation work in either
> audit. Accordingly, we believe certificate issuance was inspected.

Are you saying that none of the deficiencies identified at Certsuperior,
in Symantec's view, had a material effect on the quality of certificate
issuance?

Given that Deloitte pointed out that the CPS was illegible and there was
a "lack of implemented and documented control for requested validations
sent by authorized personnel", on what grounds do you state that
"Deloitte ... did not cite any problems with Certsuperior's validation
work"? If they can't read the CPS, how can they tell if Certsuperior is
following it?

> Certisur's audits were WebTrust for CAs only. Symantec's compliance
> organization identified the issue and has requested that Certisur's
> next audit for calendar year 2016 explicitly include the criteria in
> both WebTrust for CAs and WebTrust Baseline.  All audits received
> were unqualified and performed by a licensed WebTrust auditor.

How long has it been the case that they did not have a BR audit?

> CrossCert's audits were WebTrust for CAs only through 2015. 

Same question.

Does Symantec agree that these RAs should have had a Baseline audit for
all periods when they were operating?

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Symantec Issues doc updated

[Gervase Markham via dev-security-policy]

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 not yet clear.

Please let me know if you see that I have included anything inaccurate
or misleading, or if an entry seems incomplete.

Gerv

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Questions for Symantec

[Gervase Markham via dev-security-policy]

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

Re: Symantec Response L

[Gervase Markham via dev-security-policy]

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 building. Further, no such browser has, except for EV,
> made use of any policy IDs beyond path building.

Can you clarify: are you asking if Steve believes that the BRs require
_browsers_ to do such processing of certificate policy extensions?

Or are you asking him if he believes that including such extensions in
the cross-cert was a BR violation?

Or if he believes that cross-certifying into a hierarchy which relies
upon such extensions is a BR violation?

Or something else? :-)

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Response X

[Gervase Markham via dev-security-policy]

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 from the wiki page relating to E-Sign and MSC
TrustGate don't seem to have any mention of TLS certificates. Can you
explain which audits you are referring to above that do mention them?

> 2) What technical restrictions, if any, exist to ensure that RAs do not
> issue TLS certificates?

This is a good question.

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Response B

[Gervase Markham via dev-security-policy]

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?

> 2) You've noted that you did not disclose it due to "contractual
> obligations to protect the customer's privacy", which "remains in force".
>   a) If a contractual obligation is in conflict with the Baseline
> Requirements, do you have a process defined to resolve that conflict? If
> so, please fully describe it.

Do you think this particular contractual obligation to privacy _is_ in
conflict with the BRs? If so, which section?

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Response R

[Nick Lamb via dev-security-policy]

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 
customer to validate control over example.com successfully and then simply 
substitute the CSR for one created by the reseller, to get a certificate for 
example.com with their chosen keys.

Unlike scenarios where a web host or DNS provider obtains and installs 
certificates autonomously on behalf of their customer, using their existing 
control over the customer's domain to validate, giving a reseller this access 
feels like an overstep to me, and if I'm right about it I'd like to see 
Symantec correct this. But I suspect it doesn't breach the BRs as they're 
written even if it would surprise customers.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Response J

[Kurt Roeckx via dev-security-policy]

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, interfaces does Symantec
have, as
of 2017-04-10?


Or in general, how many interfaces does Symantec have? Does Symantec
have a list of all the interfaces, and have they all been verified to
follow all the requirements?


Also related to this is, does Symantec have a list of all software it 
uses in the issuance process, where it all runs, and have procedures to 
update all the software or configurations?



Kurt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Response P

[Kurt Roeckx via dev-security-policy]

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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Response J

[Kurt Roeckx via dev-security-policy]

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 2017-04-10?


Or in general, how many interfaces does Symantec have? Does Symantec 
have a list of all the interfaces, and have they all been verified to 
follow all the requirements?


Why does the interface need to block this, and not the process that 
issues the certificate?



Kurt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy