Symantec response to Google proposal

[Gervase Markham]

https://www.symantec.com/connect/blogs/symantec-s-response-google-s-subca-proposal

Symantec have responded to the Google proposal (which Mozilla has
endorsed as the basis for further discussion) with a set of inline
comments which raise some objections to what is proposed.

Google will, no doubt, be evaluating these requests for change and
deciding to accept, or not, each of them. But Mozilla can make our own
independent decisions on these points if we choose. If Google and
Mozilla accept a change, it is accepted. If Google accepts it but we
decline to accept, we can add it to our list of additional requirements
for Symantec instead.

Therefore, I would appreciate the community's careful consideration of
the reasonableness of Symantec's requests for change to the proposal.

Gerv

[Steve Medin]

> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve_medin=symant...@lists.mozilla.org] On Behalf Of
> Gervase Markham via dev-security-policy
> Sent: Friday, June 02, 2017 10:54 AM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: [EXT] Symantec response to Google proposal
>
> https://www.symantec.com/connect/blogs/symantec-s-response-google-

Thank you for posting this, Gerv. We intended to post the following here.

********************

Posting on behalf of Symantec.

Today, after thoroughly reviewing Google's proposal and weighing its merits
against feedback we've heard from the broader community, including our CA
customers, we shared our response with Google and the community, and also
posted our full response on our blog at
https://www.symantec.com/connect/blogs/symantec-s-response-google-s-subca-pr
oposal

We anticipate that Google and the community will need some time to review
our feedback and share their reactions, and we welcome their continued input
as we work to reach an agreed-upon plan that can be implemented in a
reasonable timeframe and ensures minimal disruption for our customers. We
thank our customers and the community for their valuable contributions to
this important discussion, and we will continue working toward what we
believe is the best path forward for all stakeholders.

[Peter Kurrasch]

Hi Gerv--

Is Mozilla willing to consider a simpler approach in this matter? For example, it seems that much of the complexity of the Google/Symantec proposal stems from this new PKI idea. I think Mozilla could obtain a satisfactory outcome without it.

From: Gervase Markham via dev-security-policy Sent: Friday, June 2, 2017 9:54 AM To: mozilla-dev-s...@lists.mozilla.org Reply To: Gervase Markham Subject: Symantec response to Google proposal

https://www.symantec.com/connect/blogs/symantec-s-response-google-s-subca-proposal

Symantec have responded to the Google proposal (which Mozilla has
endorsed as the basis for further discussion) with a set of inline
comments which raise some objections to what is proposed.

Google will, no doubt, be evaluating these requests for change and
deciding to accept, or not, each of them. But Mozilla can make our own
independent decisions on these points if we choose. If Google and
Mozilla accept a change, it is accepted. If Google accepts it but we
decline to accept, we can add it to our list of additional requirements
for Symantec instead.

Therefore, I would appreciate the community's careful consideration of
the reasonableness of Symantec's requests for change to the proposal.

Gerv

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

[Martin Heaps]

As an incidental, I am negatively influenced by reading Symantecs response:

On Friday, 2 June 2017 16:48:45 UTC+1, Steve Medin wrote:

>
> https://www.symantec.com/connect/blogs/symantec-s-response-google-
> s-subca-proposal
>
>
>
> > Our primary objective has always been to minimize any potential business
> > disruption for our customers

So, Symantec's primary objective is not PK Security, PKI Trust, or Best Practise, or even Baseline Requirements?

> > Our CA business is led and staffed by experienced individuals around the world
> > who serve our customers while ensuring our issuance practices comply with
> > industry and browser requirements.

This is fundametally inaccurate, if this was true then the issues that Mozilla and others have discovered wouldn't have been there to find.


> > As the largest issuer of EV and OV certificates in the industry according to
> > Netcraft, Symantec handles significantly larger volumes of validation
> > workloads across more geographies than most other CA’s. To our knowledge, no
> > other single CA operates at the scale nor offers the broad set of capabilities
> > that Symantec offers today.

So what if Symantec is the largest? If I am the busiest barman in the West and serving thousands of drinks an hour, if these drinks are in fact diluted down, the VOLUME of drinks I serve does not make up for the QUALITY of the drinks I serve.

Likewise, Every time Symantec issues an EV or OV certificate, they are paid, they make money. That's business, but if Symantec then decide not to reinvest in their infrastructure to support that business, why on earth should the rest of the PKI infrastructure have to give them some sort of special leniency?

> > Google shared this new proposal for Symantec’s CA with the community on May
> > 15. We have since been reviewing this proposal and weighing its merits

> > against feedback we’ve heard from the broader community, including our CA

> > customers.

If Symantec customers (who DO NOT KNOW the technical or even broader details of the issues at hand) have an nifluence on the way Symantec acts, it's not going to be best interest for the wider PKI security because it's doubtful of the technical knowledge available to these influncers.


This whole blog post unfortuantely comes across as Symantec weasel-wording it's way out of self improvement or even real acceptance of the bad practise that has been documented so far.

Disappointing, but un-surprising.

I feel Symantec needs the associated potential business penalty of running the risk of lost business (which I'm sure they can afford, being the biggest EV and OV provider in the world) to remind them, and to underline to them the importance of adhereing to the Baseline requirements and keeping the PKI secure.

[Gervase Markham]

On 02/06/17 15:53, Gervase Markham wrote:
> https://www.symantec.com/connect/blogs/symantec-s-response-google-s-subca-proposal

I'm slightly surprised to see no engagement here. Perhaps it would be
help to break it down. Symantec's specific requests for modification are
as follows (my interpretation):

1) Scope of Distrust

Google proposal: existing CT-logged certificates issued after 1st June
2016 would continue to be trusted until expiry.
Symantec proposal: all CT-logged certificates should continue to be
trusted until expiry.
Rationale for change: if transparency is enough to engender trust, that
principle should be applied consistently. This also significantly
reduces the revalidation burden.

2) Timeline

Google proposal: a set of dates by which certain milestones must be
achieved.
Symantec proposal: no specific alternative dates (more info by the end
of June), but the Google dates are too aggressive.
Rationale: need to establish business relationships; capacity issues at
Managed CAs; international requirements further complicate things; the
revalidation burden is very large; writing solid code takes time.

3) SubCA Audit Type

Google proposal: SubCAs are audited with the standard audits.
Symantec proposal: treat SubCAs as Delegated Third Parties and so give
them BR section 8 audits (an audit by the CA not an auditor; 3% sampling).
Rationale: none given.

4) Validation Task Ownership

Google proposal: Symantec and its affiliates must not participate in any
of the information verification roles permitted under the Baseline
Requirements. They may, however, collect and aggregate information.
Symantec proposal: Symantec currently uses a 2-step process - validation
and review. Symantec should be allowed to do the first, with the SubCA
doing the second (with 100% review, not samplingh).
Rationale: reducing the burden on the SubCA, reducing the time for them
to ramp up, and (presumably) to allow the Symantec personnel to continue
to have jobs.

5) Use of DTPs by SubCA

Google proposal: SubCAs may not use Delegated Third Parties in the
validation process for domain names or IP addresses.
Symantec proposal: SubCAs should be allowed to continue to use them in
situations where they already do.
Rationale: SubCAs should not be required to rejig their processes to
work with Symantec.

6) SubCA Audit Timing

Google proposal: SubCAs are audited at 3 month intervals in the 1st
year, 6 months intervals in the 2nd year, and then yearly.
Symantec proposal: after the initial audit, only yearly audits should be
required.
Rationale: Because SubCAs are established CAs, once an audit has been
done to validate the transition, the subsequent audit schedule should be
the standard yearly one, not the high-frequency 3/6 month one proposed.

7) Detailed Audits

Google proposal: Symantec may be requested to provide "SOC2" (more
detailed) audits of their new infrastructure prior to it being ruled
acceptable for use.
Symantec proposal: such audits should be provided only under NDA.
Rationale: they include detailed information of a sensitive nature.

Gerv

[Alex Gaynor]

On Tue, Jun 6, 2017 at 10:02 AM, Gervase Markham via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On 02/06/17 15:53, Gervase Markham wrote:
> > https://www.symantec.com/connect/blogs/symantec-s-
> response-google-s-subca-proposal
>
> I'm slightly surprised to see no engagement here. Perhaps it would be
> help to break it down. Symantec's specific requests for modification are
> as follows (my interpretation):
>

I suspect many of us are a bit exhausted by the discussion :-).
Particularly since at this point it feels like there's some divergence
between our goals of protecting security and not breaking the web. It's
clear that Symantec's actions for a much smaller CA would have resulted in
complete distrust (perhaps over time). That's not being pursued because
Symantec is too big too fail.

I'll try to engage on some specific points.

>
> 1) Scope of Distrust
>
> Google proposal: existing CT-logged certificates issued after 1st June
> 2016 would continue to be trusted until expiry.
> Symantec proposal: all CT-logged certificates should continue to be
> trusted until expiry.
> Rationale for change: if transparency is enough to engender trust, that
> principle should be applied consistently. This also significantly
> reduces the revalidation burden.
>

Transparency is not a magic solution to trust, though it is helpful. We
know that it primarily acts as a canary-in-the-coalmine, not perfect
coverage. Distrusting older certs issued under a less strict validation
regime makes sense.

>
> 2) Timeline
>
> Google proposal: a set of dates by which certain milestones must be
> achieved.
> Symantec proposal: no specific alternative dates (more info by the end
> of June), but the Google dates are too aggressive.
> Rationale: need to establish business relationships; capacity issues at
> Managed CAs; international requirements further complicate things; the
> revalidation burden is very large; writing solid code takes time.
>
>

I'm concerned that a lack of commitment to any particular date reflects a
lack of urgency for this process. Fundamentally, the legacy Symantec PKI
reflects risk for relying parties. Taking additional months or years to
move away from it is all time that RPs bear that risk.

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

Alex

[Gervase Markham]

On 06/06/17 15:12, Alex Gaynor wrote:
> I suspect many of us are a bit exhausted by the discussion :-).

That's fair enough! :-) I can understand that.

Gerv

[Alex Gaynor]

It was also pointed out to me that as Symantec have indicated they sent out
an RFP, any companies which are considering responding may be hesitant to
post.

Alex

On Tue, Jun 6, 2017 at 10:16 AM, Gervase Markham <ge...@mozilla.org> wrote:

> On 06/06/17 15:12, Alex Gaynor wrote:

> > I suspect many of us are a bit exhausted by the discussion :-).
>

[Gervase Markham]

Here are some thoughts from me:

On 06/06/17 15:02, Gervase Markham wrote:
> 1) Scope of Distrust

I have sought more information from Google on this.

> 2) Timeline

I think the question here is, what is our position, and on what basis do
we decide it? If we want to impose an aggressive but achievable
timeline, how do we determine what that is? Who do we ask for a second
opinion? How do we evaluate statements from Symantec?

> 3) SubCA Audit Type

This would be very difficult to agree to without good rationale; section
8 audits are very weak things compared to the normal ones.

> 4) Validation Task Ownership

I have sought more information from Google on this.

> 5) Use of DTPs by SubCA
>
> Google proposal: SubCAs may not use Delegated Third Parties in the
> validation process for domain names or IP addresses.
> Symantec proposal: SubCAs should be allowed to continue to use them in
> situations where they already do.

Our research in the last CA Communication suggests that only two small
CAs do any form of delegation of domain name or IP address ownership
validation. Therefore, it's not clear why Symantec would need this
ability, and my sense is to say No.

> 6) SubCA Audit Timing

I have sought more information from Google on this.

> 7) Detailed Audits
>
> Google proposal: Symantec may be requested to provide "SOC2" (more
> detailed) audits of their new infrastructure prior to it being ruled
> acceptable for use.
> Symantec proposal: such audits should be provided only under NDA.
> Rationale: they include detailed information of a sensitive nature.

If these audits are to be useful to Mozilla, we need to be able to make
them available to people of our choosing. They can be behind a login
system, if we are able to give out access credentials as we choose. But
an NDA is not acceptable.

Gerv

[Matthew Hardeman]

I broadly echo many of the comments and thoughts of Martin Heaps earlier in this thread.

Much of Symantec's response is disheartening, especially in the "inaccuracies": (the apparent dichotomy between how they have acted and their statement that they only employ the best people implementing best practice to ensure compliance, etc.)

There is one aspect, however, which I feel needs the greatest amount of attention:

Symantec has in multiple aspects raised what I believe to be reasonable concerns and doubts regarding the practicality of implementation of the proposed out-of-house managed CA transition in a timely fashion.

Symantec has made numerous claims as to necessary qualifications, necessary up-scaling, necessary integrations, etc.

Ultimately, I do think that the question which arises is:

Can an already third-party work with Symantec to stand up new infrastructure and processes and staffing and integration in a sufficiently timely manner to be relevant to this discussion?

If it takes so long to stand this up that Symantec could alternatively stand up a new, distinct root CA infrastructure and get that included faster.... does it even become relevant to migrate to a managed CA model for a period of time?

How much critical analysis of the potential marketplace and realities of achieving such a relationship with another CA and qualification that there exist a market of CAs who could timely handle the load, etc. can reasonably be performed by the browser programs and/or the larger relying party community?

Is what has been demanded of Symantec reasonable? Moreover... What if the requested remedy is actually infeasible? Where does that leave us and where does that leave Symantec? If a managed CA running their issuance for a time is demonstrably infeasible in a relevant time frame, what's the fallback position?

Matt

[Jakob Bohm]

On 06/06/2017 16:02, Gervase Markham wrote:
> On 02/06/17 15:53, Gervase Markham wrote:
>> https://www.symantec.com/connect/blogs/symantec-s-response-google-s-subca-proposal
>
> I'm slightly surprised to see no engagement here. Perhaps it would be
> help to break it down. Symantec's specific requests for modification are
> as follows (my interpretation):
>

Thanks for actually putting the information in the newsgroup, not in
linked documents. Makes responding much easier.

> 1) Scope of Distrust
>
> Google proposal: existing CT-logged certificates issued after 1st June
> 2016 would continue to be trusted until expiry.
> Symantec proposal: all CT-logged certificates should continue to be
> trusted until expiry.
> Rationale for change: if transparency is enough to engender trust, that
> principle should be applied consistently. This also significantly
> reduces the revalidation burden.
>

I think the period where trust is added because of CT logging doesn't
need to be limited.

There may be specific *other* dates before/after which Symantec
validation processes cannot be trusted, but a specific reason other than
availability of CT logs should be given for such dates.

> 2) Timeline
>
> Google proposal: a set of dates by which certain milestones must be
> achieved.
> Symantec proposal: no specific alternative dates (more info by the end
> of June), but the Google dates are too aggressive.
> Rationale: need to establish business relationships; capacity issues at
> Managed CAs; international requirements further complicate things; the
> revalidation burden is very large; writing solid code takes time.
>

Given how long this has dragged out, 3rd party CA negotiations may need
a slight extension, but not forever. 3rd party CAs approached for this
job may negotiate harder due to the deadline imposed on Symantec, but
that's a consequence of Symantec's actions, which Symantec must simply
suffer. It should be possible for Symantec to negotiate with other 3rd
party CAs to get a better deal later in the transitional (outsourced)
period, which would imply Mozilla and Chrome accepting new "Managed
SubCAs" being stood up as a consequence.

> 3) SubCA Audit Type
>
> Google proposal: SubCAs are audited with the standard audits.
> Symantec proposal: treat SubCAs as Delegated Third Parties and so give
> them BR section 8 audits (an audit by the CA not an auditor; 3% sampling).
> Rationale: none given.
>

Full audit should be required.

> 4) Validation Task Ownership
>
> Google proposal: Symantec and its affiliates must not participate in any
> of the information verification roles permitted under the Baseline
> Requirements. They may, however, collect and aggregate information.
> Symantec proposal: Symantec currently uses a 2-step process - validation
> and review. Symantec should be allowed to do the first, with the SubCA
> doing the second (with 100% review, not samplingh).
> Rationale: reducing the burden on the SubCA, reducing the time for them
> to ramp up, and (presumably) to allow the Symantec personnel to continue
> to have jobs.
>

If Symantec retains their ability to issue non-TLS certs in-house, the
excess validation team man-hours should be used to improve the
thoroughness of the validation of those other certificate types, in
preparation for using such better validation practices in the
post-transition new PKI. Other important uses for those excess
man-hours is security training, participating in design and beta-testing
the systems for the new PKI, and perhaps some paid vacations.

It would be bad long-term strategy for Symantec to fire specially
trained personnel that they will need again after rebuilding their
"factory". Paying people to just remain available during factory
downtime is a cost that any business risks, and Symantec will just have
to eat that cost.

> 5) Use of DTPs by SubCA
>
> Google proposal: SubCAs may not use Delegated Third Parties in the
> validation process for domain names or IP addresses.
> Symantec proposal: SubCAs should be allowed to continue to use them in
> situations where they already do.
> Rationale: SubCAs should not be required to rejig their processes to
> work with Symantec.
>

Maybe the 3rd party SubCAs should be allowed to still use RAs *only to
the extent* they do so for their own already included roots.

For example, they may use RAs to check local document types for OV and
EV certs, if they already do so.

They should not be allowed to use Symantec or any of the (former)
Symantec RAs as RAs for the "Managed SubCA" work.

They should be allowed to still use "Enterprise RAs" as defined in the
BRs.

> 6) SubCA Audit Timing
>
> Google proposal: SubCAs are audited at 3 month intervals in the 1st
> year, 6 months intervals in the 2nd year, and then yearly.
> Symantec proposal: after the initial audit, only yearly audits should be
> required.
> Rationale: Because SubCAs are established CAs, once an audit has been
> done to validate the transition, the subsequent audit schedule should be
> the standard yearly one, not the high-frequency 3/6 month one proposed.
>

Sounds fair.

> 7) Detailed Audits
>
> Google proposal: Symantec may be requested to provide "SOC2" (more
> detailed) audits of their new infrastructure prior to it being ruled
> acceptable for use.
> Symantec proposal: such audits should be provided only under NDA.
> Rationale: they include detailed information of a sensitive nature.
>

I don't see a problem in access to this being subject to a reasonable
NDA that allows Mozilla to show it to their choice of up to 50 external
experts (I don't expect to be one of those 50).



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

[Matthew Hardeman]

On Tuesday, June 6, 2017 at 9:03:29 AM UTC-5, Gervase Markham wrote:

> I'm slightly surprised to see no engagement here. Perhaps it would be
> help to break it down. Symantec's specific requests for modification are
> as follows (my interpretation):
>
> 1) Scope of Distrust
>
> Google proposal: existing CT-logged certificates issued after 1st June
> 2016 would continue to be trusted until expiry.
> Symantec proposal: all CT-logged certificates should continue to be
> trusted until expiry.
> Rationale for change: if transparency is enough to engender trust, that
> principle should be applied consistently. This also significantly
> reduces the revalidation burden.

At this point, it seems reasonable to trust the current certificates that were properly CT logged and include proper SCTs, at least up until we no longer trust new certificates issued from the current infrastructure.

>
> 2) Timeline
>
> Google proposal: a set of dates by which certain milestones must be
> achieved.
> Symantec proposal: no specific alternative dates (more info by the end
> of June), but the Google dates are too aggressive.
> Rationale: need to establish business relationships; capacity issues at
> Managed CAs; international requirements further complicate things; the
> revalidation burden is very large; writing solid code takes time.
>

It is believable that getting the new issuance infrastructure up and running could be a significant burden. The question may really become "Is it acceptable that a (possibly significant) period of time during which Symantec can issue no new / renewed certificates occur?" I note that Symantec even sets out that there is some material question as to whether there is even another participant within the qualified marketplace that could be prepared in a timely fashion to serve as the Managed CA.

> 3) SubCA Audit Type
>
> Google proposal: SubCAs are audited with the standard audits.
> Symantec proposal: treat SubCAs as Delegated Third Parties and so give
> them BR section 8 audits (an audit by the CA not an auditor; 3% sampling).
> Rationale: none given.

If we mean non-constrained SubCAs, those certainly should be subject to full WebTrust audit, whether in the scope of Symantec's audits or separately audited for the SubCA organization. Why would Symantec get a pass otherwise?

>
> 4) Validation Task Ownership
>
> Google proposal: Symantec and its affiliates must not participate in any
> of the information verification roles permitted under the Baseline
> Requirements. They may, however, collect and aggregate information.
> Symantec proposal: Symantec currently uses a 2-step process - validation
> and review. Symantec should be allowed to do the first, with the SubCA
> doing the second (with 100% review, not samplingh).
> Rationale: reducing the burden on the SubCA, reducing the time for them
> to ramp up, and (presumably) to allow the Symantec personnel to continue
> to have jobs.

I think this question should be left to the Managed CA, with the Managed CA's understanding and acknowledgement that their own roots and trust will be held responsible for any mis-issuances detected. Let the Managed CA's own self interest set this where it actually needs to be.

>
> 5) Use of DTPs by SubCA
>
> Google proposal: SubCAs may not use Delegated Third Parties in the
> validation process for domain names or IP addresses.
> Symantec proposal: SubCAs should be allowed to continue to use them in
> situations where they already do.
> Rationale: SubCAs should not be required to rejig their processes to
> work with Symantec.

If it were on behalf of any one else, the other CA would have no new requirements. Why change that? Make any new / extra burdens fall upon Symantec, not the other CA partner.

>
> 6) SubCA Audit Timing
>
> Google proposal: SubCAs are audited at 3 month intervals in the 1st
> year, 6 months intervals in the 2nd year, and then yearly.
> Symantec proposal: after the initial audit, only yearly audits should be
> required.
> Rationale: Because SubCAs are established CAs, once an audit has been
> done to validate the transition, the subsequent audit schedule should be
> the standard yearly one, not the high-frequency 3/6 month one proposed.
>

Upon transition back to Symantec control, enforce a higher audit period then, based upon their prior misdeeds.

> 7) Detailed Audits
>
> Google proposal: Symantec may be requested to provide "SOC2" (more
> detailed) audits of their new infrastructure prior to it being ruled
> acceptable for use.
> Symantec proposal: such audits should be provided only under NDA.
> Rationale: they include detailed information of a sensitive nature.

To the extent that the audit includes supporting documentation as to facilities physical security details, etc, etc, I can see support for not distributing that widely. Is there any reason to believe that this type of audit will reveal anything beyond whether or not they are fully compliant without qualifications? I suspect they take access to their keys seriously, if for no other reason than self interest.

[userwithuid]

On Tuesday, June 6, 2017 at 2:03:29 PM UTC, Gervase Markham wrote:
>
> 1) Scope of Distrust
>
> Google proposal: existing CT-logged certificates issued after 1st June
> 2016 would continue to be trusted until expiry.
> Symantec proposal: all CT-logged certificates should continue to be
> trusted until expiry.
> Rationale for change: if transparency is enough to engender trust, that
> principle should be applied consistently. This also significantly
> reduces the revalidation burden.

As mentioned in the other Symantec thread, right now Firefox doesn't do CT so notBefore >=2016-06 is the non-CT way of at least partially distrusting the old/unknown PKI soon-ish. I don't think it's a good idea to just broaden this to 2015-01 unless we know we can do CT by 2018-02. (Not sure if we'd be able to defend 2016-06 alone if Google agrees to do 2015-01 though)

Then again, also in the other thread, you said "Mozilla would wish" the old PKI to be distrusted "sooner than November 2020" and you "expect it to be some time in 2018". Which I found to be a very bold proposition. Has Symantec commented on that yet? If not, can you make them? :-) In the event that we actually get 2018, allowing some older certs for a few more months might be worth conceding. A little less technically enforcable risk reduction from 2018-02 to 2018-?? in exchange for the "real deal" sooner than expected sounds good.

[Gervase Markham]

On 06/06/17 19:59, Jakob Bohm wrote:
> I don't see a problem in access to this being subject to a reasonable
> NDA that allows Mozilla to show it to their choice of up to 50 external
> experts (I don't expect to be one of those 50).

The problem with an NDA is that if the audit reports significant holes
in Symantec's security story, we can't talk about them here.

Gerv

[tmcque...@gmail.com]

On Tuesday, June 6, 2017 at 10:03:29 AM UTC-4, Gervase Markham wrote:
> On 02/06/17 15:53, Gervase Markham wrote:
> > https://www.symantec.com/connect/blogs/symantec-s-response-google-s-subca-proposal
>
> I'm slightly surprised to see no engagement here.

I think many of us are worn out with the poor responses from Symantec, who seem to treat this as a matter easily resolved with negotiation rather than actually addressing the underlying technical and procedural concerns.

Symantec's slow responsiveness, attempt to limit community input by hosting responses outside the natural conversation threads (PDFs, blog posts that don't load on locked down browsers, etc), and apparent attempts to shield was should be a transparent process under the guise of "commercial secrets" would be cause for full loss of trust by any other CA. They have now had multiple chances to respond in an appropriate fashion and have failed to do so, so I don't see why the response here should be any different. Thus, at this point, if I were mozilla and Google, I would:

1) set a sunset date of 06/01/2018 for the ban to take effect.
2) immediately (next firefox/chrome release) add a small banner message (or similar) any time a Symantec certificate is found stating "Symantec certificates will soon be distrusted; if you are the site owner, <go here> to read more" Where go here goes to this and the intent thread @ Google. Site owners will get the message -- either directly by their own browsing, or from their customers. Note that this direct-to-user messages, while should be used sparingly, is the ~only mechanism available to browsers to make sure appropriate eyeballs see that a certificate change is needed by the site owner. I suspect it would greatly have helped with the Wosign distrust, for example.

Of course the above does not preclude Symantec from getting a separate/new managed PKI (from another CA) to be able to replace certificates for customers immediately, nor does it preclude the possibility of this new PKI transitioning back to symantec control once they demonstrate they have resolved the underlying issues.

But what the above does do is shift the risks from the relying parties (who are the ones with almost all the risk as symantec drags their feet), to Symantec (they either get their act together or exit the CA business).

So I, for one, have no particular interest in continuing to engage in a discussion with an uncooperative party. The time for softball has ended.

[Peter Kurrasch]

My thoughts:

2) Timeline.

I agree with Symantec that Google's original deadlines are far too aggressive, for 2 reasons. First, I do not think Symantec can move quickly without causing further damage. Second, I do not think Symantec's customers can move quickly at all ‎given that a majority of them are large corporations that have to coordinate budgets, staff, outsourcing firms, and so forth. These customers also need time to familiarize themselves with the new rules and identify a course of action that makes sense for their business environments and their user base. Even though I understand the desire to move quickly, in this situation it seems imprudent to do so.

Many will find this next bit unacceptable, but in the interest of providing an alternative, let me suggest a timeline of 6 different dates over the next 2 years (in case it really does take that long): the 21st day of February, May, and August of 2018 & 2019. Each of these dates represent a different milestone for changes in policy enforcement, certificate validation, software and systems, and whatever is identified as a deliverable in these ongoing discussions. The dates here are chosen specifically to acknowledge that many businesses operate on a quarterly system while avoiding complications that inevitably take place at the end of a quarter and the end of the year. And, yes, that would imply no action taken before Feb of next year.

1) Scope of Distrust

First a question: is removing the EV entitlements from the Symantec roots something that is still on the table for Mozilla products or has that been dismissed for some reason? I ask because it hardly ‎seems appropriate that a CA under sanction be entitled to all the benefits that are extended to CA's which are not under sanction. Doing so also inflicts some pain on Symantec (without breaking the global economy) until such time as they've resolved their issues to Mozilla's satisfaction.

Regarding the expiration of certificates, I do not agree that CT logging engenders trust so I disagree with Symantec on that. Frankly I don't entirely agree with Google on the phased dis-trust and CT logging items. Those seem to increase complexity in the PKI ecosystem ‎(which carries its own risk) without necessarily improving the ecosystem, but it's very likely I've missed some important details.

As to scope itself, my understanding is that Mozilla will eventually remove trust from all current Symantec roots (the "ubiquitous roots") and in its place use a set of "new roots", some of which will be under the purview of Symantec competitors. These new roots will be cross-signed to those ubiquitous roots so that new certs that chain up to these new roots will still validate properly on products that have not or cannot be updated to use the new roots.‎ (If my understanding is incorrect, I hope someone will correct me.)

To put it another way, all existing certs that chain up to ‎the ubiquitous roots will eventually stop working--many before their date of normal expiration. As such, there needs to be a ramp up of new cert issuing capacity while at the same time a phasing out of the existing certs. Combining that with the above "alt-timeline" would look something like the following. The exact makeup of the root bundles and CA groups are TBD.

Milestone 1 (Feb 21, 2018) - EV entitlement removed from the ubiquitous roots, new root cert bundle A ‎is ready to go, and CA group 1 is approved to begin issuing against the roots in bundle A. No new end entity certs have been issued yet.

Milestone 2 (May 21, 2018) - New root bundle B is ready to go and CA group 2 is approved to begin issuing against bundle B, but has not yet done so.

Milestone 3 (Aug 21, 2018) - New root bundle C is ready to go and CA group 3 is approved to begin issuing against bundle C, but has not yet done so.

Milestone 4 (Feb 21, 2019) - New root bundle D is ready to go and CA group 4 is approved to begin issuing against bundle D, but has not yet done so. In addition, some analysis should be performed to evaluate the ‎overall health of the new root solution (for example, how many total certs have been issued, any reports of major disruptions to end users, etc.).

Milestone 5 (May ‎21, 2019) - The fifth, and final, bundle E of new roots is ready to go and CA group 5 is approved to begin issuing against them but has not yet done so. This would also represent the earliest date that Symantec is allowed to be included in any of the CA groups.

Milestone 6 (Aug 21, 2019) - Final removal of trust for the original Symantec roots.

I know that some of this represents a significant departure from what Google and Symantec have previously discussed but I thought there might be some utility in having an alternate framework from which to draw.

 

From: Gervase Markham via dev-security-policy‎

Sent: Tuesday, June 6, 2017 9:03 AM‎

On 02/06/17 15:53, Gervase Markham wrote:
> https://www.symantec.com/connect/blogs/symantec-s-response-google-s-subca-proposal

I'm slightly surprised to see no engagement here. Perhaps it would be

[Jakob Bohm]

Notes on your below suggested timeline:

1. I see no reason to have that many new root bundles from Symantec.
Ideally, there would be just two bundles: A transitional root bundle
which signs the outsourced SubCAs only, and a final bundle intended
to become the new long-term Symantec roots. The transitional root
bundle would be made in a subset of the current Symantec
infrastructure, while the final bundle would be generated in the
new higher security infrastructure isolated from any historic bugs
in the old infrastructure.

2. For any certificate bundle that needs to be incorporated into the
Mozilla root stores, a significant period (3 to 6 months at least)
will be needed between acceptance by Mozilla and actual trust by
Mozilla users. This would involve time to complete the following:

2.1 Adding the new roots to the NSS store source code.

2.2 Actually incorporating that updated NSS store into release candidate
builds of all Mozilla products.

2.3 Releasing those builds of Mozilla products to the general public

2.4a Waiting for the majority of users (especially those with telemetry
and other phone-home behavior disabled) to install the updated Mozilla
products.

2.4b Waiting for enterprise users to incorporate the updated Mozilla
products into new system images and rolling out those system images.

2.4c Waiting for users to migrate beyond Firefox ESR 52 due to
disrupting non-PKI changes (feature removals) made at that point.
Similar for future feature-disrupting Mozilla product changes.

(Note this is not a complaint about the breaking changes beyond Fx ESR
52, just an observation that such actions by other Mozilla teams can
cause a significant delay in the deployment of NSS root store changes).

> *From: *Gervase Markham via dev-security-policy‎
> *Sent: *Tuesday, June 6, 2017 9:03 AM‎

[Gervase Markham]

On 20/06/17 01:21, Jakob Bohm wrote:
> 2. For any certificate bundle that needs to be incorporated into the
> Mozilla root stores, a significant period (3 to 6 months at least)
> will be needed between acceptance by Mozilla and actual trust by
> Mozilla users.

Not if the roots were cross-signed by the old PKI.

Gerv

[Jakob Bohm]

Then they don't "need to be incorporated into the Mozilla root stores",
although incorporating them may be useful as part of removing the old
roots.