Re: Symantec: Draft Proposal

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

On Monday, May 8, 2017 at 7:21:46 AM UTC-4, okaphone.e...@gmail.com wrote:
> Hi Rick,
> 
> I don't see a "May 4th post". Where was it posted? Not here it seems.


It's above--it links to 
https://www.symantec.com/connect/blogs/symantec-ca-continues-public-dialogue 

> 
> Also it's reasonable that Symantec wants to "address impact to their 
> customers" but what about impact to all of the browsers users? It may be a 
> good idea to try and address (in your proposals) that to.
> 
> So far I have not seen much more than "trust us, we take it seriously and 
> we'll do it right from now on". But what do you think of Eric's idea? He 
> seems to suggest a way forward that may be used to turn the whole debacle 
> into an advantage for you.
> 
> CU Hans
> 
> 
> On Monday, 8 May 2017 00:09:19 UTC+2, Rick Andrews  wrote:
> > I'm posting this on behalf of Symantec:
> > 
> > We would like to update the community about our ongoing dialogue with 
> > Google.  
> >  
> > Following our May 4th post, senior executives at Google and Symantec 
> > established a new dialogue with the intention to arrive at a new proposal 
> > for the community that addresses the substantial customer impact that would 
> > result from prior proposals. We urge Symantec customers and the browser 
> > community to pause on decisions related to this matter until final 
> > proposals are posted and accepted. The intent of both Google and Symantec 
> > is to arrive at a proposal that improves security while minimizing business 
> > disruption across the community.
> >  
> > We want to reassure the community that we are taking these matters and the 
> > impact on the community very seriously.

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

Re: Draft further questions for Symantec

[wizard--- via dev-security-policy]

In addition to requesting disclosure of intermediates that have been (even if 
not currently are) able to issue server certs, and the catchall, both of which 
seem excellent, I encourage Mozilla to consider asking these questions as part 
of an implemented remedy plan.

That is, put in motion Mozilla's plan of action given all the information 
available today, but note that certain modifications are possible should 
Symantec provide in responses to these queries additional information Mozilla 
considers useful and actionable.

For example, consider executing the planned phase out of all existing symantec 
certs by early next year, with distrust of all existing roots at that time, and 
a limit on new cert lifetimes of 13 months.  But should symantec become a 
leader in reducing cert lifetimes with the stand up of a clean PKI (cf. Eric 
Mill's proposal), then Mozilla would strive to (a) include the new roots by 
next year, and (b) accept certs with lifetime of 27 months. Or, should symantec 
be able to verifiably demonstrate other things (e.g. a complete map of their 
PKI inter-relations, and all parts that are non-BR compliant and thus should be 
distrusted), then the old ones might not be removed.

Yes, this is harder on the coders (I sympthasize), but how much longer can the 
current situation (and the risks it does pose *today*) go on?

On Monday, May 8, 2017 at 1:08:27 PM UTC-4, richm...@gmail.com wrote:
> On Monday, May 8, 2017 at 1:24:28 PM UTC+1, Gervase Markham wrote:
> > I think it might be appropriate to have a further round of questions to
> > Symantec from Mozilla, to try and get some clarity on some outstanding
> > and concerning issues. Here are some _proposed_ questions; feel free to
> > suggest modifications or other questions, and I will decide what to send
> > officially to Symantec in a few days. Please focus on formulating
> > questions which would have an effect on Mozilla's view of Symantec or
> > our response to the recent issues.
> 
> How about adding a catch all:
> 
> Are you aware of any information that might have an effect on Mozilla's view 
> of Symantec, our response to the recent issues or any of any further issues 
> that have not been disclosed to us so far?
> 
> Cheers
> 
> Rich.

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

Re: Draft further questions for Symantec

[richmoore44--- via dev-security-policy]

On Monday, May 8, 2017 at 1:24:28 PM UTC+1, Gervase Markham wrote:
> I think it might be appropriate to have a further round of questions to
> Symantec from Mozilla, to try and get some clarity on some outstanding
> and concerning issues. Here are some _proposed_ questions; feel free to
> suggest modifications or other questions, and I will decide what to send
> officially to Symantec in a few days. Please focus on formulating
> questions which would have an effect on Mozilla's view of Symantec or
> our response to the recent issues.

How about adding a catch all:

Are you aware of any information that might have an effect on Mozilla's view of 
Symantec, our response to the recent issues or any of any further issues that 
have not been disclosed to us so far?

Cheers

Rich.

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

RE: Email sub-CAs

[Doug Beattie via dev-security-policy]

Hi Gerv,

I wanted to get the latest Mozilla thoughts on the audit requirements for TCSCs 
based on the discussion we started last month.  I understand the BR requirement 
if the CA can issue server auth certificates, this was discussed here:
  
https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/ZMUjQ6xHrDA/ySofsF_PAgAJ

For TCSCs that can issue secure email certs, what are the requirements in the 
new policy, 2.4?  I think they were excluded from audit requirement before, but 
in the latest Mozilla policy these CAs need to have a WT for CA audit even if 
they are Name Constrained.  

So here my questions:

Was this an intentional change?  

Is the same true for TCSCs that can issue server auth certificates (even NC CAs 
need a webtrust for CA audit)?

Are previously issued TCSCs exempt, if not, when would the audit period for 
them start?

Do these CAs need to be publicly disclosed?

Related tickets:
   https://github.com/mozilla/pkipolicy/issues/36

   https://github.com/mozilla/pkipolicy/issues/69









> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of
> douglas.beattie--- via dev-security-policy
> Sent: Thursday, April 13, 2017 12:33 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Email sub-CAs
> 
> On Thursday, April 13, 2017 at 10:49:17 AM UTC-4, Gervase Markham wrote:
> > On 13/04/17 14:23, Doug Beattie wrote:
> > > In 3.2 the term Technically Constrained is not defined to be any
> > > different than the BRs (or perhaps even less restrictive).
> >
> > You mean 2.3, right?
> 
> Yes, 2.3.
> 
> > I would say Inclusion section, bullet 9 gives the definition of
> > technically constrained. For email certs, because of the bug described
> > in issue #69, it basically just says that it has to have the
> > id-kp-emailProtection EKU. It should say more, but it doesn't. That's
> > problematic, because just having an EKU isn't really a technical
> > constraint in the "TCSC" sense.
> >
> > > In 3.2
> > > this is all I can find regarding CAs that are capable of signing
> > > secure email certificates, section 9: "If the certificate includes
> > > the id-kp-emailProtection extended key usage, then all end-entity
> > > certificates MUST only include e-mail addresses or mailboxes that
> > > the issuing CA has confirmed (via technical and/or business
> > > controls) that the subordinate CA is authorized to use."
> > >
> > > There is no statement back to scope or corresponding audits.  Were
> > > secure email capable CAs supposed to be disclosed and audited to
> > > Mozilla under 2.3?
> >
> > If they did not include id-kp-serverAuth, I would not have faulted a
> > CA for not disclosing them if they met the exclusion criteria for
> > email certs as written.
> 
> OK.
> 
> > > and how it applies to Secure email, I don't see how TCSCs with
> > > secure email EKU fall within the scope of the Mozilla Policy 2.3.
> > > Can you help clarify?
> >
> > I think this is basically issue #69.
> > https://github.com/mozilla/pkipolicy/issues/69
> 
> OK, I look forward to a conclusion on that.  I hope that name constraining a
> secure email CA (either technically in the CA certificate or via business
> controls) is sufficient to avoid WebTrust Audits.  If Public disclosure helps 
> get
> us there then that would be acceptable.
> 
> > I don't think it was supposed to be the case that intermediates with
> > id-kp-emailProtection alone were supposed to be considered TCSCs.
> > After all, certs with id-kp-serverAuth alone are not TCSCs; they need
> > to have Name Constraints as well. But you are right, that's what the policy
> says.
> >
> > > OK, you're right, the number of negatives in that section got me.
> > > So, even when EKU permits just secure email, having name constraints
> > > does not exempt a CA from the Mozilla policy.  It does for BRs since
> > > email is not within scope (and discussed on the link you included in
> > > the response).  When I saw TCSC references I personally didn't
> > > realize that this was different than the BR definition of TCSC
> > > (maybe should have called this something different).
> > >
> > > Section 3.1.2.1 specifies that any CA capable of issuing secure
> > > email certificates must have a "WebTrust for CAs" audit (or
> > > corresponding ETSI audit).  This is a huge change from 3.2 and I
> > > wonder if all CAs understand this.  Even the Blog about this version
> > > does not highlight this substantial change:
> > > https://blog.mozilla.org/security/2017/04/04/mozilla-releases-versio
> > > n-2-4-ca-certificate-policy/
> >
> > I didn't realise it _was_ a substantial change. Are you saying that
> > you used to think it was fine for email-only sub-CAs to have no audits
> > at all? Is this because you considered all such CAs to be TCSCs (by
> > the Mozilla definition)?
> 
> Yes, we've been working hard to technically constrain all CAs and especially
> those 

Re: Draft further questions for Symantec

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

It may be necessary to expand that definition to intermediates that were 
capable of issuing certificates within the past year (or longer).

On Monday, May 8, 2017 at 9:31:21 AM UTC-4, Alex Gaynor wrote:
> I'm not the best way to phrase this, so please forgive the bluntness, but I
> think it'd be appropriate to ask at this point if Symantec has disclosed
> all necessary intermediates (I believe this would be defined as: chain to
> their roots in our trust store, are not expired, are not revoked, and are
> not technically constrained), and would they be willing to state that if
> new intermediate CAs are discovered beyond that point, it would reflect
> either dishonesty or serious mismanagement of their PKI.
> 
> Alex
> 
> 
> On Mon, May 8, 2017 at 9:20 AM, Kurt Roeckx via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > On 2017-05-08 14:24, Gervase Markham wrote:
> >
> >>
> >> 1) Did any of the RAs in your program (CrossCert and co.) have the
> >> technical ability to independently issue EV certificates? If they did
> >> not not, given that they had issuance capability from intermediates
> >> which chained up to EV-enabled roots, what technical controls prevented
> >> them from having this capability?
> >>
> >
> > It has a duplicate "not" there.
> >
> > Issue Y
> >> ---
> >>
> >> 3) Does Symantec agree that "VeriSign Class 3 SSP Intermediate CA - G2"
> >> and "Symantec Class 3 SSP Intermediate CA - G3", can issue certs which
> >> are trusted for SSL/TLS in Mozilla products (by chaining up to "VeriSign
> >> Universal Root Certification Authority") and yet do not have BR audits?
> >>
> >
> > I'm wondering if the intermediate CA certificates recently published in CT
> > should have it's own issue. As far as I know they should have been
> > disclosed much earlier. It seems that (at least now) they're all either
> > revoked by CRL on the 5th of May (but not disclosed as revoked) or expired
> > except for one (https://crt.sh/?id=132854209).
> >
> > I think they're all from "VeriSign Class 3 SSP Intermediate CA", not G2 or
> > G3, except that one that's not revoked.
> >
> > 4) These two intermediates have a number of sub-intermediates. Does
> >> Symantec agree that not all of these sub-intermediates are within the
> >> scope of even Symantec's NFSSP Webtrust for CAs audit?[1] If so, how
> >> many are in scope and how many are out of scope? If they are all in
> >> scope, why are they not listed in the audit document?
> >>
> >
> > The audit document says: "and the Symantec Non-Federal SSP – customer
> > specific CAs (collectively referred to as the “Non-Federal SSP CAs”)."
> >
> > For which it then says that "our examination did not extend to the
> > controls of external registration authorities."
> >
> > The management assertion also says:
> > "Controls have inherent limitations, including the possibility of  human
> > error and the circumvention or overriding of controls. Accordingly, even
> > effective controls can provide only reasonable  assurance with respect to
> > Symantec’s Non-Federal SSP CA operations. Furthermore, because of changes
> > in conditions, the effectiveness of controls may vary over time."
> >
> >
> > Kurt
> >
> >
> > ___
> > 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: Draft further questions for Symantec

[Alex Gaynor via dev-security-policy]

Thanks Kurt.

Alex

On Mon, May 8, 2017 at 11:22 AM, Kurt Roeckx via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 2017-05-08 15:31, Alex Gaynor wrote:
>
>> I'm not the best way to phrase this, so please forgive the bluntness, but
>> I
>> think it'd be appropriate to ask at this point if Symantec has disclosed
>> all necessary intermediates (I believe this would be defined as: chain to
>> their roots in our trust store, are not expired, are not revoked, and are
>> not technically constrained), and would they be willing to state that if
>> new intermediate CAs are discovered beyond that point, it would reflect
>> either dishonesty or serious mismanagement of their PKI.
>>
>
> This was part of the March 2016 action 2. In
> https://mozillacaprogram.secure.force.com/Communications/CAC
> ommResponsesOnlyReport?CommunicationId=a05o00iHdtx=Q4
> you can see that their response was "2016 Apr 18"
>
> And confirmed in the April 2017 response to action 8, see:
> https://mozillacaprogram.secure.force.com/Communications/CAC
> ommRespWithTextAndTotalsReport?CommunicationId=a05o03Wrz
> BC=Q00020=Q00026
>
>
>
> Kurt
>
> ___
> 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: Draft further questions for Symantec

[Alex Gaynor via dev-security-policy]

I'm not the best way to phrase this, so please forgive the bluntness, but I
think it'd be appropriate to ask at this point if Symantec has disclosed
all necessary intermediates (I believe this would be defined as: chain to
their roots in our trust store, are not expired, are not revoked, and are
not technically constrained), and would they be willing to state that if
new intermediate CAs are discovered beyond that point, it would reflect
either dishonesty or serious mismanagement of their PKI.

Alex


On Mon, May 8, 2017 at 9:20 AM, Kurt Roeckx via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 2017-05-08 14:24, Gervase Markham wrote:
>
>>
>> 1) Did any of the RAs in your program (CrossCert and co.) have the
>> technical ability to independently issue EV certificates? If they did
>> not not, given that they had issuance capability from intermediates
>> which chained up to EV-enabled roots, what technical controls prevented
>> them from having this capability?
>>
>
> It has a duplicate "not" there.
>
> Issue Y
>> ---
>>
>> 3) Does Symantec agree that "VeriSign Class 3 SSP Intermediate CA - G2"
>> and "Symantec Class 3 SSP Intermediate CA - G3", can issue certs which
>> are trusted for SSL/TLS in Mozilla products (by chaining up to "VeriSign
>> Universal Root Certification Authority") and yet do not have BR audits?
>>
>
> I'm wondering if the intermediate CA certificates recently published in CT
> should have it's own issue. As far as I know they should have been
> disclosed much earlier. It seems that (at least now) they're all either
> revoked by CRL on the 5th of May (but not disclosed as revoked) or expired
> except for one (https://crt.sh/?id=132854209).
>
> I think they're all from "VeriSign Class 3 SSP Intermediate CA", not G2 or
> G3, except that one that's not revoked.
>
> 4) These two intermediates have a number of sub-intermediates. Does
>> Symantec agree that not all of these sub-intermediates are within the
>> scope of even Symantec's NFSSP Webtrust for CAs audit?[1] If so, how
>> many are in scope and how many are out of scope? If they are all in
>> scope, why are they not listed in the audit document?
>>
>
> The audit document says: "and the Symantec Non-Federal SSP – customer
> specific CAs (collectively referred to as the “Non-Federal SSP CAs”)."
>
> For which it then says that "our examination did not extend to the
> controls of external registration authorities."
>
> The management assertion also says:
> "Controls have inherent limitations, including the possibility of  human
> error and the circumvention or overriding of controls. Accordingly, even
> effective controls can provide only reasonable  assurance with respect to
> Symantec’s Non-Federal SSP CA operations. Furthermore, because of changes
> in conditions, the effectiveness of controls may vary over time."
>
>
> Kurt
>
>
> ___
> 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: Draft Proposal

[Alex Gaynor via dev-security-policy]

Hi Rick,

Does Symantec plan to introduce new facts into the conversation, or is all
the information we are currently considering accurate and complete?

If there's no new information, I don't see why the community of
participants in m.d.s.p. should pause. I think it's a point of pride for
many of us that Mozilla operates a transparent root program, with strong
community input, and we want to continue that strong tradition.

Alex

On Sun, May 7, 2017 at 6:09 PM, Rick Andrews via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I'm posting this on behalf of Symantec:
>
> We would like to update the community about our ongoing dialogue with
> Google.
>
> Following our May 4th post, senior executives at Google and Symantec
> established a new dialogue with the intention to arrive at a new proposal
> for the community that addresses the substantial customer impact that would
> result from prior proposals. We urge Symantec customers and the browser
> community to pause on decisions related to this matter until final
> proposals are posted and accepted. The intent of both Google and Symantec
> is to arrive at a proposal that improves security while minimizing business
> disruption across the community.
>
> We want to reassure the community that we are taking these matters and the
> impact on the community very seriously.
> ___
> 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: Draft Proposal

[wizard--- via dev-security-policy]

It makes perfect sense if the game plan is to force continued delays of 
decisions on the part of root programs! Which appears to be exactly what is 
happening. After all, wait long enough, and it can be claimed that all possibly 
bad things would be expired, so don't distrust us, m'ok.

I think the idea of giving Symantec a path to keep 27 month certificates, e.g. 
Coupled to the standup of a new PKI, makes a lot of sense, since going to a new 
PKI would help get rid of the risks associated with the present PKI, and make a 
big player a leader in making shorter lifetimes a reality (In the absence of a 
new PKI it would seem 9 mo or 13 mo validity is needed to reduce ecosystem 
risk).

On Sunday, May 7, 2017 at 6:56:56 PM UTC-4, Eric Mill wrote:
> On Sun, May 7, 2017 at 6:09 PM, Rick Andrews via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > I'm posting this on behalf of Symantec:
> >
> > We would like to update the community about our ongoing dialogue with
> > Google.
> >
> > Following our May 4th post, senior executives at Google and Symantec
> > established a new dialogue with the intention to arrive at a new proposal
> > for the community that addresses the substantial customer impact that would
> > result from prior proposals. We urge Symantec customers and the browser
> > community to pause on decisions related to this matter until final
> > proposals are posted and accepted.
> 
> 
> This call for the browser community to not make any decisions until Google
> and Symantec finalize and accept a proposal completely marginalizes and
> ignores both Mozilla and the broader web community.
> 
> The "new dialogue" part also comes across as having gone over Ryan's head.
> This is unfortunately consistent with Symantec's latest blog post, which
> unprofessionally referred to proposals by "Mr. Sleevi" and "Mr. Markham".
> These statements personalize the issue and marginalize the proposals by
> casting them as individual opinions and not the views of their
> organization. They also reinforce the perception that Symantec sees their
> situation as the product of an unreasonable person or two and not the
> result of their own errors.
> 
> This list just spent the last two weeks focused on a large host of issues,
> curated by Mozilla on their wiki and discussed by the broader community
> here. So far, all Symantec has done to publicly respond to those is to send
> a single email per-issue, and then not otherwise participate in the
> discussion beyond blog posts.
> 
> Posting a call to Mozilla's community list asking for Mozilla and its
> community to pause while Symantec gets on the phone with senior Google
> executives to work it all out is a baffling tactic. I hope Mozilla
> continues to assert its stake in this process.
> 
> -- Eric
> 
> The intent of both Google and Symantec is to arrive at a proposal that
> > improves security while minimizing business disruption across the community.
> >
> > We want to reassure the community that we are taking these matters and the
> > impact on the community very seriously.
> > ___
> > 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: Draft further questions for Symantec

[Kurt Roeckx via dev-security-policy]

On 2017-05-08 14:24, Gervase Markham wrote:


1) Did any of the RAs in your program (CrossCert and co.) have the
technical ability to independently issue EV certificates? If they did
not not, given that they had issuance capability from intermediates
which chained up to EV-enabled roots, what technical controls prevented
them from having this capability?


It has a duplicate "not" there.


Issue Y
---

3) Does Symantec agree that "VeriSign Class 3 SSP Intermediate CA - G2"
and "Symantec Class 3 SSP Intermediate CA - G3", can issue certs which
are trusted for SSL/TLS in Mozilla products (by chaining up to "VeriSign
Universal Root Certification Authority") and yet do not have BR audits?


I'm wondering if the intermediate CA certificates recently published in 
CT should have it's own issue. As far as I know they should have been 
disclosed much earlier. It seems that (at least now) they're all either 
revoked by CRL on the 5th of May (but not disclosed as revoked) or 
expired except for one (https://crt.sh/?id=132854209).


I think they're all from "VeriSign Class 3 SSP Intermediate CA", not G2 
or G3, except that one that's not revoked.



4) These two intermediates have a number of sub-intermediates. Does
Symantec agree that not all of these sub-intermediates are within the
scope of even Symantec's NFSSP Webtrust for CAs audit?[1] If so, how
many are in scope and how many are out of scope? If they are all in
scope, why are they not listed in the audit document?


The audit document says: "and the Symantec Non-Federal SSP – customer 
specific CAs (collectively referred to as the “Non-Federal SSP CAs”)."


For which it then says that "our examination did not extend to the 
controls of external registration authorities."


The management assertion also says:
"Controls have inherent limitations, including the possibility of  human 
error and the circumvention or overriding of controls. Accordingly, even 
effective controls can provide only reasonable  assurance with respect 
to Symantec’s Non-Federal SSP CA operations. Furthermore, because of 
changes in conditions, the effectiveness of controls may vary over time."



Kurt

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

Draft further questions for Symantec

[Gervase Markham via dev-security-policy]

I think it might be appropriate to have a further round of questions to
Symantec from Mozilla, to try and get some clarity on some outstanding
and concerning issues. Here are some _proposed_ questions; feel free to
suggest modifications or other questions, and I will decide what to send
officially to Symantec in a few days. Please focus on formulating
questions which would have an effect on Mozilla's view of Symantec or
our response to the recent issues.

RAs and EV
--

1) Did any of the RAs in your program (CrossCert and co.) have the
technical ability to independently issue EV certificates? If they did
not not, given that they had issuance capability from intermediates
which chained up to EV-enabled roots, what technical controls prevented
them from having this capability?

2) We note that all four RAs advertised EV certificates on their
websites during 2016[0]. If they did not have direct EV issuance
capability, by what mechanism did they provide EV certificates to their
customers, and what validation (if any) did Symantec do of data provided
by the RAs?

Issue Y
---

3) Does Symantec agree that "VeriSign Class 3 SSP Intermediate CA - G2"
and "Symantec Class 3 SSP Intermediate CA - G3", can issue certs which
are trusted for SSL/TLS in Mozilla products (by chaining up to "VeriSign
Universal Root Certification Authority") and yet do not have BR audits?

4) These two intermediates have a number of sub-intermediates. Does
Symantec agree that not all of these sub-intermediates are within the
scope of even Symantec's NFSSP Webtrust for CAs audit?[1] If so, how
many are in scope and how many are out of scope? If they are all in
scope, why are they not listed in the audit document?

5) A statement from Symantec[2] suggests that customers of your NFSSP
program can perform RA duties for the issuance of certs for Windows
domain controllers and those RA activities are outside the scope of the
audit entirely. Is that correct? Please list all companies or
organizations which can issue publicly-trusted SSL/TLS certificates with
no audit oversight.

6) "VeriSign Universal Root Certification Authority" is EV-enabled. Are
there any mechanisms, technical or otherwise, which prevent NFSSP
customers from issuing EV certs by including the Symantec EV OID?

7) Does Symantec agree that Issue Y is very serious? What are Symantec's
plans to remedy this? Why have they not been communicated up to now?
When will they be executed?

Audits
--

8) Please explain how the Management Assertions for your December 2014
-> November 2015 audits contain documentation of issues ("Failure to
maintain physical security records for 7 years", "Failure to review
application and system logs" and "failure to refresh background checks
every 5 years") that, according to you, were only discovered in January
or February 2016[3]. Is it not the case that you submit Management
Assertions to your auditor and they then opine upon the correctness of
those assertions? What is the "last change date" of those management
assertions? What point in the audit cycle does that date correspond to?

Issue L
---

9) During the approximately five years that Symantec cross-signed the
Federal PKI, thereby making any certificate within it have a path to
trust in Mozilla browsers, which of the following best represented
Symantec's understanding of the situation:

a) Symantec didn't realise that your actions had the effect of making
the entirety of the FPKI trusted in Mozilla browsers; or

b) Symantec knew that your actions had the effect of making the entirety
of the FPKI trusted in Mozilla browsers and didn't realise the
implications for your own audits and disclosures and the WebPKI; or

c) Symantec knew that your actions had the effect of making the entirety
of the FPKI trusted in Mozilla browsers and did realise the
implications, but didn't think it was necessary to tell Mozilla about it

?


Gerv


[0] http://web.archive.org/web/20161223000146/http://www.crosscert.com/
http://web.archive.org/web/20160428051833/https://www.certsuperior.com/SecureSiteProEV.aspx
http://web.archive.org/web/20161114232112/https://www.certisur.com/soluciones/sitios-seguros
http://web.archive.org/web/2016110634/https://www.certisign.com.br/certificado-servidor/ssl-validacao-avancada

[1] The following intermediates, at least, are not listed in that audit
as being covered: https://crt.sh/?id=19602740 1,
https://crt.sh/?id=19602709, https://crt.sh/?id=19602733 3,
https://crt.sh/?id=19602720, https://crt.sh/?id=19602670 5,
https://crt.sh/?id=19602679, https://crt.sh/?id=19602705 7,
https://crt.sh/?id=19602730 .

[2] https://bug1334377.bmoattachments.org/attachment.cgi?id=8860216 ,
section 2, first bullet numbered 2.

[3] https://bug1334377.bmoattachments.org/attachment.cgi?id=8860216 ,
section 5.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec: Draft Proposal

[okaphone.elektronika--- via dev-security-policy]

Hi Rick,

I don't see a "May 4th post". Where was it posted? Not here it seems.

Also it's reasonable that Symantec wants to "address impact to their customers" 
but what about impact to all of the browsers users? It may be a good idea to 
try and address (in your proposals) that to.

So far I have not seen much more than "trust us, we take it seriously and we'll 
do it right from now on". But what do you think of Eric's idea? He seems to 
suggest a way forward that may be used to turn the whole debacle into an 
advantage for you.

CU Hans


On Monday, 8 May 2017 00:09:19 UTC+2, Rick Andrews  wrote:
> I'm posting this on behalf of Symantec:
> 
> We would like to update the community about our ongoing dialogue with Google. 
>  
>  
> Following our May 4th post, senior executives at Google and Symantec 
> established a new dialogue with the intention to arrive at a new proposal for 
> the community that addresses the substantial customer impact that would 
> result from prior proposals. We urge Symantec customers and the browser 
> community to pause on decisions related to this matter until final proposals 
> are posted and accepted. The intent of both Google and Symantec is to arrive 
> at a proposal that improves security while minimizing business disruption 
> across the community.
>  
> We want to reassure the community that we are taking these matters and the 
> impact on the community very seriously.

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

Re: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

[Dimitris Zacharopoulos via dev-security-policy]

On 8/5/2017 1:18 μμ, Gervase Markham wrote:

On 05/05/17 19:44, Dimitris Zacharopoulos wrote:

  * MUST include an EKU that has the id-kp-emailProtection value AND
  * MUST include a nameConstraints extension with
  o a permittedSubtrees with
  + rfc822Name entries scoped in the Domain (@example.com) or
Domain Namespace (@example.com, @.example.com) controlled by
an Organization and

It's this part that I'm looking for good wording for to make sure I
don't accidentally exclude valid use cases.


  + dirName entries scoped in the Organizational name and location

Help me understand how dirName interacts with id-kp-emailProtection?


When the Subscriber belongs to an Organization that needs to be included 
in the subjectDN.



Dimitris.




(a) For each rfc822Name in permittedSubtrees, the CA MUST confirm that
the Applicant has registered the Domain or Domain Namespace or has been
authorized by the domain registrant to act on the registrant's behalf in
line with the verification practices of section 3.2.2.4.
(b) For each DirectoryName in permittedSubtrees the CA MUST confirm the
Applicants and/or Subsidiary’s Organizational name and location such
that end entity certificates issued from the subordinate CA Certificate
will be in compliance with section 7.1.2.4 and 7.1.2.5.

Does anyone see problems with this language?

Gerv


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

Re: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

[Dimitris Zacharopoulos via dev-security-policy]

On 6/5/2017 1:19 πμ, Peter Bowen via dev-security-policy wrote:

One other question: Does your proposal allow a TCSC that covers both
ServerAuth and EmailProtection for the domains of the same organization?

Or put another way, would your proposed language force an organization
wanting to run under its own TCSC(s) to obtain two TCSCs, one for their
S/MIME needs and another for their TLS needs?

Yes, it allows a single TCSC that does both.  The little three diamond
symbol means parallel, so both legs are evaluated at the same time.
If both get to "Goto B", then it is a single TCSC that can issue both
serverAuth and emailProtection certs.


As Gerv pointed out in previous messages, this issue is described in 
https://github.com/mozilla/pkipolicy/issues/26. The current Mozilla 
policy does not force separating Intermediate CAs for serverAuth and 
emailProtection certs.


Microsoft's Policy 
 
currently says:


"/New/ intermediate CA certificates under root certificates submitted 
for distribution by the Program must separate Server Authentication, 
S/MIME, Code Signing and Time Stamping uses. This means that a single 
intermediate issuing CA must not be used to issue both server 
authentication, S/MIME, and code signing certificates. A separate 
intermediate must be used for each use case."


It would be ideal if both policies were aligned to either allow both 
serverAuth and emailProtection from the same Intermediate CA, or 
separate them. As we are today, CAs that participate in Mozilla and 
Microsoft Root program need to comply with the more restrictive policy.



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

Re: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

[Gervase Markham via dev-security-policy]

On 05/05/17 19:44, Dimitris Zacharopoulos wrote:
>  * MUST include an EKU that has the id-kp-emailProtection value AND
>  * MUST include a nameConstraints extension with
>  o a permittedSubtrees with
>  + rfc822Name entries scoped in the Domain (@example.com) or
>Domain Namespace (@example.com, @.example.com) controlled by
>an Organization and

It's this part that I'm looking for good wording for to make sure I
don't accidentally exclude valid use cases.

>  + dirName entries scoped in the Organizational name and location

Help me understand how dirName interacts with id-kp-emailProtection?

> (a) For each rfc822Name in permittedSubtrees, the CA MUST confirm that
> the Applicant has registered the Domain or Domain Namespace or has been
> authorized by the domain registrant to act on the registrant's behalf in
> line with the verification practices of section 3.2.2.4.
> (b) For each DirectoryName in permittedSubtrees the CA MUST confirm the
> Applicants and/or Subsidiary’s Organizational name and location such
> that end entity certificates issued from the subordinate CA Certificate
> will be in compliance with section 7.1.2.4 and 7.1.2.5.

Does anyone see problems with this language?

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

Re: Email sub-CAs

[Gervase Markham via dev-security-policy]

On 05/05/17 18:58, Peter Bowen wrote:
>> Right now the policy does not require disclosure of CA-certificates
>> that the CA deems are technically constrained.  

I believe this was made the case for some mix of the following reasons:

a) the CA did not want to reveal every customer it had;
b) this would significantly increase the volume of disclosure required;
c) we didn't think we needed to know about these.

>> We have seen numerous
>> cases where the CA misunderstood the rules or where the rules had
>> unintentional gaps an disclosing the certificate as constrained will
>> allow discovery of these problems.  For example the current policy
>> says "an Extended Key Usage (EKU) extension which does not contain
>> either of the id-kp-serverAuth and id-kp-emailProtection EKUs" which
>> means a certificate that has EKU extension with only the
>> anyExtendedKeyUsage KeyPurposeId fall outside of the scope.  This is
>> obviously wrong, but would not be discovered today.

Is it obviously wrong? Firefox doesn't respect anyEKU. OTOH, Kathleen
recently told me that she feels that because the Mozilla root store is
used by others, we should continue to keep anyEKU intermediates in
scope. But do you think Mozilla also needs to know about these for
Firefox/Thunderbird purposes? If so, why?

>> The flow chart at https://imagebin.ca/v/3LRcaKW9t2Qt shows my proposal for 
>> disclosure; it is a
>> revised version from the one I posted to the CA/Browser Forum list and
>> depends on the same higher level workflow

Apologies that your message got held up.

Looking at that flowchart:

* Does "Log certificate" mean "in CT"?
* The "Subject/Key list" is the list of intermediate certs which need to
  be disclosed?
* This diagrem represents your proposal, not the status quo?

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

Re: Changing CCADB domains

[Rob Stradling via dev-security-policy]

On 06/05/17 10:25, Jesper Kristensen via dev-security-policy wrote:


Mozilla could CNAME from ccadb.org to .force.com, and then
declare that the ccadb.org URLs are the official ones.

Is that what you meant, Peter?


You cannot set up a CNAME without configuring Salesforce, since they
would not know your Host/SNI header, and they would not serve a cert
that is valid for your domain.


Ah.


You can set up a new domain in Salesforce while keeping the old
mozillacacommunity.force.com without premium support, as long as the new
domain is a custom domain and not a force.com domain.


Or Mozilla could setup https://login.ccadb.org to simply return an HTTP 
temporary redirect to .force.com.


--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

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