On Monday, July 24, 2017 at 2:50:22 AM UTC-7, Gervase Markham wrote:
> Hi Rick,
> 
> Some more thoughts on your post. I continue to invite community
> commentary on the issues we are discussing.
> 
> On 21/07/17 07:00, Rick Andrews wrote:
> > In our June 1 post, we stated that we would update the community after the 
> > end of the month. 
> 
> Indeed. I was more referring to the suggestions made in the meeting with
> Mozilla about when the public statement would be forthcoming. But no matter.
> 
> > Correct. However, as we indicated in our update, with a change of
> > this magnitude we believe that there will likely be material
> > compatibility and interoperability issues that will only come to
> > light once server operators begin the transition to the Managed CA
> > issued certificates. Recognizing this, we recommend that we establish
> > a clear process to evaluate exception requests that includes
> > consultations with the browsers to handle such corner cases.
> Operators who have initial difficulty with the transition can, of
> course, stay on their certificates issued from the old infrastructure.
> (It's worth noting that if all of those customers had recently renewed
> their certificates, as my proposal suggests, then there would not be a
> problem with their existing-infra certs expiring while they were
> attempting to make the transition.)

In practice, this is much more difficult. For larger organizations, PKI 
administration is often a dedicated function where administrators may have 
limited visibility into the applications using specific certificates. This 
makes communication along the lines of "well, for these types of applications, 
your existing certificates are fine, but in these others they need a change" 
much more subject to error and will likely lead to disruption and downtime.  

> How would you see such an exception process working, and how would it be
> implemented technically?

The details of this process would probably be best served in a separate thread. 
Essentially, such a process would involve a quick assessment by the community 
on the context and merits of the request by the customer, the impact of denying 
such a request, and a model to actually operationalize such a request (such as 
potentially white-listing some certificates for a period of time). In the ideal 
case, these requests that can only be resolved through an exception will not be 
common, but we believe that we should prepare for such contingencies given the 
scope of certificates covered, as we have learned with other transitions, such 
as the SHA1 transition. A placeholder of this type would allow us to reach 
closure on the operational aspects of the proposal. We can then later begin 
discussions regarding what such a process would look like. 

> > While this is true under the terms of the SubCA proposal, we do not
> > believe this is consistent with the spirit of Google’s and Mozilla’s
> > prior commentary on their intent regarding the SubCA proposal, which
> > is to limit the issuance of Symantec certificates under Symantec’s
> > existing infrastructure and governance.
> I'm not sure how you reach that conclusion. We want to end new issuance
> in December, you want it to continue until next May. How are our dates
> more inconsistent than yours with a desire to limit the issuance of
> Symantec certificates under the existing infrastructure and governance?
> We want to limit it earlier.

We may be more aligned on this point than your response suggests. We are in 
agreement with you that we will cease issuing certificates under the existing 
infrastructure and governance on December 1, 2017. At that point you could stop 
accepting the issuance of new certificates off the existing infrastructure and 
PKI. (See our last reply to this thread where we confirmed this point, but 
asked for an exception process.) Our point here is that if you also make 
December 1, 2017 the "distrust date" for all certificates issued off of 
Symantec’s current PKI before June 1, 2016 then, in effect, you will be forcing 
all customers to "double down" on the existing Symantec PKI and infrastructure 
because they would need to be issued early replacement certificates off of the 
current PKI. Alternatively, if the distrust date of all certificates issued 
before June 1, 2016 were to be moved to May 1, 2018 (as opposed to December 1, 
2017 as you currently propose) it would allow these replacement certificates to 
chain to the new PKI because they would be issued by the Managed CA(s) off of 
the new SubCA(s). This, we believe, was one of the intents of the original 
proposal which was to move users to the new infrastructure and PKI as quickly 
as possible. A December 1, 2017 distrust date (for certificates issued before 
June 1, 2016) would, in practice, have the opposite effect given that none of 
the replacement certificates could be issued off of the new PKI. 

> > dates.  Accordingly, our intention and expectation is that the
> > majority of certificates issued before June 1, 2016 that will need to
> > be replaced before their expiration under the current SubCA proposal
> > will occur after the Managed CA is implemented. This will ensure
> > there are no limitations on the replacement certificates that are
> > issued to affected customers, which limits the substantial risks of
> > implementation problems if our customers are not given the
> > appropriate time to plan and execute their certificate replacements.
> It may be appropriate for the limitations on current-infra issuance
> lifetime in the plan to be adjusted by a few months such that a
> certificate issued now can continue to work until the full distrust date
> of November 1st, 2018. This would effectively mean that there are no
> (additional) limitations on the replacement certificates.

We do not understand this comment. According to the SubCA proposal, which 
Google authored and Mozilla previously endorsed, any replacement certificate 
issued today off of the existing Symantec PKI will have up to the maximum 
lifetime currently permitted by the BR's (39 months). Our primary intent around 
this comment is to highlight that a significant percentage of replacement 
certificates issued today (e.g., certificates with more than 12 months' 
validity) will need to be reissued again prematurely if there is a full 
distrust of the current Symantec WebPKI on November 1, 2018. As an example, 
consider a website operator that was issued a 39 month certificate on May 1, 
2016 -- under your accelerated date proposal, that customer would need to be 
issued a replacement certificate between today and December 1, 2017 off of 
Symantec’s current WebPKI. Under that same proposal, they would then need to be 
issued a second replacement certificate by the Managed CA(s) off the new PKI 
before November 1, 2018. This would require they support two premature 
replacements. 

> > In our post we explained our rationale of why this period needs to be
> > a minimum of 9 months. It is important for the community to note the
> > significant operational burden and compatibility / interoperability
> > risks that our customers will face if they have to replace their
> > certificates once, let alone twice.
> Why do you see a compatibility and interoperability risk in the process
> of replacing a certificate with an identical certificate except that is
> a) definitely logged to CT, and b) has a later expiry date?
> 
> You may argue that it's a customer operational burden but again, if
> customers have difficulty replacing their SSL certs in a 4-month
> timeframe, then they are not well positioned to deal with a number of
> potential crises in the SSL system, such as compromise (and distrust) of
> an intermediate, or compromise of their webservers.

You are correct in that most customers are indeed not prepared to deal with 
potential crises in the SSL system. We have all witnessed this first hand with 
Heartbleed, the replacement of SHA1 certificates, etc. A four month replacement 
window for a forced replacement of this magnitude is unprecedented and we know 
that things will break. In the recent CA survey, most major CAs reported that 
replacing certificates annually is something that many organizations are not 
prepared for – a conclusion that is reinforced by the recent CA/Browser Forum 
vote rejecting ballot 185, which proposed to limit the maximum validity of 
SSL/TLS certificates issued by all CAs to 13 months. Do you have data leading 
you to believe that this replacement can be executed with limited Internet 
ecosystem disruption, particularly amongst the largest enterprises globally 
whose certificates would be impacted? If so, we would welcome seeing that 
data/rationale. The issues that we have all witnessed with other forced 
replacement events on much longer timelines indicate that the community is not 
yet at a place of automation to deal with such a transition, especially in a 
short timeframe. In this case, forcing a distrust date of December 1, 2017 (vs. 
our May 1, 2018 distrust date recommendation) for certificates issued prior to 
June 1, 2016 increases the total number of premature replacement certificates 
that would be need to be issued by approximately 50% and gives website 
operators substantially less time (4 months vs. 9 months) in which to plan and 
execute such a replacement. A December 1, 2017 distrust date for certificates 
issued prior to June 1, 2016 would introduce a known, actual, material risk to 
the Internet ecosystem given the industry’s prior experience with forced mass 
replacement episodes. We do not think the perceived benefit of accelerating 
distrust for Symantec certificates issued before June 1, 2016 from May 1, 2018 
to December 1, 2017 (5 months of validity) can possibly justify the significant 
ecosystem disruption that is likely to result from not accepting our proposed 
May 1, 2018 distrust date for certificates issued before June 1, 2016. We agree 
with your public comments on June 19, 2017 that it is not constructive to get 
into a date-based "negotiation" over the SubCA proposal. We have worked 
backwards from our best estimate for how long it would take us and our Managed 
CA partner(s) to implement the SubCA proposal in a manner that allows for an 
orderly transition of Symantec’s existing PKI infrastructure for SSL/TLS 
certificates to a Managed CA(s) while minimizing disruption to websites and web 
end-users, and have proposed aggressive, yet achievable deadlines accordingly. 
As such, while we are willing to go down the SubCA path overall, we strongly 
believe that this must be done in a way that aims to minimize website 
disruption.

> > Our recommendation for replacing certificates issued before June 1,
> > 2016 by May 1, 2018 (and preferably by February 1, 2019) enables a
> > single shift to our new PKI for SSL/TLS certificates and eliminates
> > any necessity for organizations to replace their certificates
> > multiple times.
> As noted above, I am not particularly impressed by arguments that
> "replacing our certificates twice in 2-3 years is too hard".
> 
> It's also worth noting that in the timeline you propose, organizations
> would have only 5 months (Dec 1 2017 - May 1 2018), including the
> holiday period, to test and deploy the actual certificates they would be
> using from the Managed CAs - those which do carry compatibility risk.
> And it's only 3 months if they want to replace with fully-validated
> non-DV certificates. My plan allows 9 uninterrupted months for that,
> which gives significantly more scope to deal with unexpected
> compatibility problems caused by new algorithms, new chains, etc. etc.
> If customers are asking for time to manage a transition to a new
> hierarchy, and that is your key concern, the plan I am proposing gives
> them significantly more of it than yours does.

Symantec has proposed timing changes that are consistent with the scope of 
distrust of the original SubCA proposal as proposed by Google and endorsed by 
Mozilla, which requires premature replacement of over 234,000 certificates 
based on our proposed May 1, 2018 distrust date for certificates issued before 
June 1, 2016, and optimizes for replacement certificates to be issued off the 
new Managed CA(s) infrastructure (avoiding the requirement for double early 
replacement for the same original validity period). We believe our proposal 
minimizes disruption to websites and web end-users while meeting the spirit of 
Google’s and Mozilla’s prior commentary on their intent regarding the SubCA 
proposal, which is to limit the issuance of Symantec certificates under 
Symantec’s existing infrastructure and governance.

In contrast, your suggestion results in an untold impact and millions of 
Symantec unexpired certificates having to be prematurely re-validated, 
re-issued and operationally replaced within the next 15 months, with several 
hundred thousand certificates having to be prematurely replaced with the next 4 
months (assuming an August 1, 2017 consensus SubCA plan).

Based on your experience in the PKI world and the feedback that you have 
received over the years from website operators, do you believe that this 
significant expansion of the scope of Symantec certificates to be distrusted 
and subject to premature replacement over the next 15 months minimizes 
disruption to websites and web end-users? 

> > The practical effect of this suggestion is to require up to two early
> > replacements for affected customers of certificates issued before
> > June 1, 2016
> I think you are overstating this somewhat. Given the industry move to
> 2-year lifetimes, many customers would have needed to make at least one
> replacement during the period concerned anyway.

Please see analysis above. Distrusting certificates issued before June 1, 2016 
before the Managed CA is in place is indeed forcing up to two early 
replacements. 

> > The earliest distrust date that is both aggressive and achievable is
> > May 1, 2018 for Symantec SSL/TLS certificates issued before June 1,
> > 2016.
> That is only true with a particular set of assumptions and goals; as
> noted early in the process, it is not necessarily the case that Mozilla
> will share or agree with all of Symantec's assumptions and goals, and
> this might lead to differing views of what is appropriate. This may be
> what is happening now.
> 
> There is a trade-off here between inconvenience to Symantec and, to some
> degree, to its customers in requiring cert replacements, and the
> security risks of continuing to trust Symantec's current PKI. It is
> understandable that there is a difference of opinion between Symantec
> and Mozilla as to how best to manage that trade-off.

Our proposed timing is not based on avoiding inconvenience to Symantec, but 
rather managing widespread Internet ecosystem risk and business disruption to 
our customers and website users from implementation of the original SubCA 
proposal.  By our estimates, Symantec secures up to 80% of the world’s 
ecommerce transactions through its certificate infrastructure.  I believe we at 
least have the shared goal of not causing widespread disruption and 
compatibility/interoperability failures for browser users. That shared goal 
directly translates into implementing a SubCA proposal where our customers, who 
represent the majority of banking, ecommerce, and other business-oriented sites 
that users depend on, are given a reasonable path to succeed in this 
transition. The May 1, 2018 date was carefully calculated to allow this 
transition to succeed based on the data we discussed in our response. We 
believe your proposed dates will result in significant Internet ecosystem 
disruption. 

> > The introduction of a new “total distrust” condition to the SubCA
> > proposal – a November 1, 2018 total distrust date for Symantec’s PKI
> > for SSL/TLS
> I must push back on the suggestion that this is a new idea. Mozilla has
> said since the beginning that we are keen to close the door on
> Symantec's current PKI, and would wish to do so some time during 2018 at
> the very latest. We made this clear in the message "Mozilla requirements
> of Symantec" posted to m.d.s.p. and Steve Medin on 7th June 2017.
> https://groups.google.com/d/msg/mozilla.dev.security.policy/C45hQChFLyc/lC46UTnnAAAJ
> .. November 1st 2018 is fairly late in 2018 already. This was also, I
> believe, brought up in the face-to-face meeting we had.
> 
> This also made the point that Mozilla is not currently able to make
> CT-based decisions as Google is, and so continued trust based on CT
> logging may not be an option for us.

This is a new idea in the context of the consensus SubCA proposal because it 
fundamentally disrupts the path of continuity and compatibility that were at 
the core of the proposal. Distrusting the roots effectively negates core 
principles of the proposal. Symantec has invested substantial resources in 
executing against this proposal in good faith. Many other members of the CA 
community have also invested significant resources in executing against this 
proposal in good faith as SubCA RFP respondents.

> > That’s a punitive result for customers that replace such unexpired, 
> > pre-June 1, 2016 issued certificates with new Symantec certificates.
> 
> If having to replace one's certificates is as strong as "punitive", then
> there's something very wrong, and it's not Mozilla's policy.

“Punitive” is our interpretation based on the premature replacements your ideas 
would impose.

> > More importantly, however, this newly introduced "total distrust"
> > date condition to the SubCA proposal is completely contrary to a
> > fundamental principle of the original SubCA proposal authored by
> > Google and endorsed by Mozilla, which Symantec has relied upon in
> > good faith in evaluating whether and how to implement the SubCA
> > proposal – namely, that “existing certificates issued on or after
> > June 1st 2016 would still be trusted, provided they comply with the
> > Chrome CT policy."  On May 23, 2017, Google confirmed on Blink that
> > Symantec certificates issued after June 1, 2016 would not be “be
> > constrained in any way (such as reduced validity, no EV treatment,
> > etc.)."  On July 7, 2017, Mozilla confirmed on Blink: "Mozilla
> > continues to support the proposal as originally written (with the
> > exception of questions about timeline, which remain to be agreed)."
> That sentence was in the context of Symantec's proposed changes to the
> proposal, which we had evaluated and decided not to proceed with.
> Mozilla has always, as noted above, made it clear that we wish to close
> the door on Symantec's current PKI some time in 2018.
> 
> This intention was signalled and the Mozilla full-distrust date of Nov
> 1st 2018 is pretty late for "some time in 2018". So that date cannot be
> the cause of the disquiet. The December 1st suggested date for the
> ceasing of issuance from Symantec's existing PKI would need to be agreed
> by other participants in the plan, and may have to be tweaked to fit
> better with particular release dates for the various browsers involved;
> so perhaps we should wait to hear what they have to say.

We look forward to the broader community weighing in on this. We urge the 
community to validate our points, especially the website operators that are 
being forced to execute this plan. The implementation of a forced plan that 
introduces material risks on an unrealistic timeline is inappropriate and 
dangerous. We ask the community to carefully consider again the dates that we 
have proposed. We believe any other dates could lead to a massive disruption 
event for browser users and website operators.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to