Le vendredi 14 octobre 2016 22:21:44 UTC+2, Ryan Sleevi a écrit :
> On Thursday, October 13, 2016 at 9:50:02 AM UTC-7, Kathleen Wilson wrote:
> > 1) Distrust certificates chaining up to Affected Roots with a notBefore
> > date after October 21, 2016. If additional back-dating is discovered (by
> > any means) to circumvent this control, then Mozilla will immediately and
> > permanently revoke trust in the Affected Roots.
> > -- This change will go into the Firefox 51 release train .
> > -- The code will use the subject key id (hash of public key) to identify
> > the Affected Roots, so that the control will also apply to cross-certs of
> > the Affected Roots.
> > 2) Add the previously identified backdated SHA-1 certs chaining up to the
> > Affected Roots to OneCRL.
> > 3) No longer accept audits carried out by Ernst & Young Hong Kong.
> > 4) Remove the Affected Roots from NSS after the SSL certificates issued
> > before October 1, 2016, have expired or have been replaced.
> Hi Kathleen,
> I appreciate the thoughtfulness and time spent on reviewing and considering
> the feedback and the incident. At the risk of asking you to do even more
> work, would it possible to ask that you expand a bit more on the reasoning
> behind this proposal?
> In particular, I'm hoping to expand upon the choice to allow existing certs
> to continue to be accepted and to not remove the affected roots until 2019.
> >From an outsider perspective, it would appear the reasoning is to minimize
> >any negative impact on existing WoSign customers, which in turn minimizes
> >any impact on Firefox users, by assuming that all (but a few) of the
> >existing certificates were correctly issued and reamin trustworthy. Is that
> >a fair statement?
> It seems to accomplish this, you're willing to continue to trust that WoSign
> will not demonstrate any of the past behaviours it already demonstrated -
> such as backdating and misissuance, but not to issue new certificates. Is
> that correct?
> I ask because it seems to be a very challenging position - we don't
> necessarily trust that new certificates will abide by the policies, but at
> the same time, we need to trust that they'll abide by the new policies and
> not issue any new certificates. Is that a fair statement of the conflict?
The job of a CA is not only to issue or not issue certificates, it's also to
maintain revocation status for the previously issued certificates, receive and
consider revocation requests from anybody, and revoke certificates the CA knows
are not valid anymore (for a number of reasons listed in the BR at least in
It's agreed that revocation checking is far from perfect, and that's why Google
and Mozilla have developed CRLSets and OneCRL, which depends on the revocation
status information published and/or declared by the CAs.
It's then important that the Affected Roots and their subordinate CAs continue
to follow good practices regarding revocation of subscriber certificates.
dev-security-policy mailing list