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.)
How would you see such an exception process working, and how would it be
implemented technically?
> 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.
> 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.
> 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.
> 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.
> 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.
> 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.
> 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.
> 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.
> 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.
Gerv