Hi Steve,

Thanks for posting this. I appreciate the level of detail provided,
which is useful in giving us a basis for discussion. It's a little
regrettable, though, that it was published a couple of weeks after we
were led to expect it...

One note before we start: Symantec's business dealings regarding its CA
business are not of concern to Mozilla other than relating to the
"change of ownership or control" provisions in Mozilla policy (policy
2.5 section 8). However, if dates are proposed or agreed for
implementation of the consensus plan, we would not expect those dates to
be renegotiated because of a change of ownership or control.

Am I right in saying that, in order to hit these dates you are
proposing, you would strongly desire to get consensus on them by August 1st?

On 18/07/17 19:22, Steve Medin wrote:
> New Certificate Issuance: We believe the dates for transition of validation 
> and issuance to the Managed CA that are both aggressive and achievable are as 
> follows:
> - Implement the Managed CA by December 1, 2017 (changed from August 8, 2017);
> - Managed CA performs domain validation for all new certificates by December 
> 1, 2017 (changed from November 1, 2017); and
> - Managed CA performs full validation for all certificates by February 1, 
> 2018. Prior to this date, reuse of Symantec authenticated organization 
> information would be allowable for certificates of <13 months in validity.

To summarise for those reading along: this represents a change of a
little less than 4 months for the first date, 1 month for the second
date, and the third date is as originally proposed.

Steve: to be clear, this means that browsers could implement a block on
certificates from Symantec's existing PKI as follows: after December
1st, 2017, they could dis-trust all certificates with a notBefore
greater than December 1st 2017?

Given the explanations Symantec has given as to why these dates are
reasonable, and the effort required to stand up the new PKI, I am minded
to accept them, particularly as they have managed to hit the third
originally-proposed date on the nose. However, I am still open to
community input.

> Replacement of Unexpired Certificates Issued Before June 1, 2016: There are 
> two major milestones that must be achieved after implementation of the 
> Managed CA in order to replace unexpired certificates issued before June 1, 
> 2016 that do not naturally expire before the distrust date(s) in the SubCA 
> proposal. Those include the full revalidation of certificate information and 
> then the customer replacement of those certificates. 

That is not necessarily so. The customers could replace their
certificates using new, CT-logged certificates from Symantec's old
infrastructure. This doesn't require any revalidation or any change in
the certificate chain, so should have excellent compatibility
properties, and it's something that could begin today. In fact, as I
understand it, Symantec has already been encouraging their customers to
do exactly this.

This would, of course, mean, that those certificates would need
replacing again at some point before the final total dis-trust of the
current Symantec PKI.

This activity would need to start during the December holiday season
when many organizations impose infrastructure blackout periods.  As
such, we believe that the only achievable timing for this transition is
after the holiday season. We understand that browsers may want to
technically enforce this transition and that multiple milestones may be
undesirable from a coding perspective. In order to accommodate a
simplified and cost efficient transition schedule (especially for
organizations that currently have certificates with notBefore dates of
both June 1, 2015 and June 1, 2016) and to allow impacted organizations
the time, as they will likely need to replace, test and operationalize
these replacement certificates in their infrastructure, we recommend
consolidating Chrome's distrust dates to a single date of May 1, 2018.
This would mean that Chrome's distrust of Symantec certificates issued
before June 1, 2015 would change from August 31, 2017 to May 1, 2018,
and that Chrome's distrust of Symantec certificates issued before June
1, 2016 would change from January 18, 2018 to May 1, 2018.

A key date for Mozilla is when we can tell our software to dis-trust any
certificate issued by the Symantec current PKI which was issued before
June 1st 2016, because certificates issued after that are guaranteed
(pretty much) to be in CT, and therefore are a bounded and known set.
Therefore pushing that date out to May 1st 2018 seems like a negative
from our perspective.

A two-stage strategy such as the one outlined above seems to us to be
worth investigating, as it would allow us to give Symantec more time to
transition its customers from the current to the new PKI (something
which might come with compatibility risk, as you have correctly noted)
without having to bear the risk of continuing to trust arbitrary and
unbounded sections of the current PKI.

So I would like to propose an alternative timeline based on those
principles. The exact dates could be discussed, but it might work
something like this:

December 1st, 2017: Dis-trust of all current PKI certificates issued
before June 1st, 2016. This means all Symantec customers with certs
older than this would need to implement a certificate change in the next
four months, but they could do so to near-identical certificates issued
from the same roots, intermediates and infra, a prospect which should
have excellent compatibility characteristics. Why December 1st? Well, it
matches with the other December 1st date (for standing up the new PKI),
and extending further beyond that seems to provide little value given
the holiday change freeze issue that is regularly raised.

November 1st, 2018: Total dis-trust of the current Symantec PKI. This
gives Symantec the full nine month window that you have requested (from
Feb 1, the target date for Managed CAs to be able to do validation, to
Nov 1) to transition their customers from the old PKI to the new PKI,
with new validations done by the Managed CA. In an improvement from the
existing plan, this nine months no longer contains a holiday blackout
period, and does not overlap the period when you are focussed on
standing up the new PKI. Mozilla feels more comfortable about allowing
an extended time for this transition because the set of old PKI
certificates that would need be trusted during this period would be
known and bounded because they would all be in CT.

I would like Symantec to seriously consider and comment on the
feasibility of a plan structured along these lines.

> We've also received feedback from some of our prospective Managed CA partners 
> that they would like Symantec validation staff to continue to perform 
> verification of identity under the baseline requirements. The Managed CA 
> would complete all domain validation and they would make the final decision 
> on certificate issuance. In this scenario, Symantec would continue to 
> undertake a baseline requirement audit and WebTrust audit for as long as it 
> operates that particular RA function.  Permitting Symantec to perform just 
> the organizational validation (not the domain validation) would give 
> customers an uninterrupted experience while still meeting the stated 
> objectives. We look forward to community feedback on this proposed change to 
> the SubCA proposal.

I think I prefer the proposal where Symantec staff work under the aegis
of the Managed CA, it is responsible for them, and they report to it.

Note that I am on holiday for a further week, but will try and check in
here from time to time.

dev-security-policy mailing list

Reply via email to