Thank you very much for your, as always, thorough review.

Let me start by saying I agree there is an opportunity for improving the
policies around how key transfers such your recent transfer and Google's
are handled.

It is my hope we can, through our respective recent experiences performing
such transfers, help Mozilla revise their policy to provide better guidance
for such cases in the future.

As for your specific questions, my responses follow:

pzb: First, according to the GTS website, there is no audit using the
WebTrust Principles and Criteria for Certification Authorities – Extended
Validation SSL.  However the two roots in the Mozilla CA  program currently
are EV enabled and at least one subordinate CA under them is issuing EV

rmh: Prior to our final stage of the acquisition we contacted both Mozilla
and Microsoft about this particular situation.

At this time, we do not have any interest in the issuance of EV SSL
certificates, however GlobalSign does. Based on our conversations with
representatives from both organizations we were told that since:


   The EV OID associated with this permission is associated with GlobalSign
   and not Google and,

   GlobalSign is active member in good standing with the respective root
   programs and,

   Google will not be issuing EV SSL certificates,

   Google will operate these roots under their own CP/CPS’s and associated

   Google issuing a certificate with the GlobalSign OIDs would qualify as

That it would be acceptable for us not to undergo a EV SSL audit, and that
GlobalSign could keep the EV right for the associated subordinate CA for
the remaining validity period to facilitate the transition (assuming
continued compliance).

As a former manager of a root program, this seems an appropriate position
to take. And as one who has been involved in several such root transfers I
think differences in intended use are common enough that they should be
explicitly handled by policy.

pzb:  Second, according to the GTS CPS v1.3, "Between 11 August 2016 and 8
December 2016, Google Inc. operated these Roots according to Google Inc.’s
Certification Practice Statement."  The basic WebTrust for CA and WebTrust
BR audit reports for the period ending September 30, 2016 explicitly state
they are for "subordinate CA under external Root CA" and do not list the
roots in the GTS CPS at all.

rmh: I believe this will be answered by my responses to your third and
fourth observations.

pzb: Third, the Google CPS says Google took control of these roots on
August 11, 2016.  The Mozilla CA policy explicitly says that a bug report
must be filed to request to be included in the Mozilla CA program.  It was
not until December 22, 2016 that Google requested inclusion as a CA in
Mozilla's CA program (
This does not appear to align with Mozilla requirements for public

rmh: As has been mentioned, timing for a transaction like this is very
complicated. The process of identifying candidates that could meet our
needs took many months with several false starts with different
organizations. That said, prior to beginning this process we proactively
reached out to both Microsoft and Mozilla root programs to let them know we
were beginning the process. Once it looked like we would be able to come to
an agreement with GlobalSign we again reached out and notified both
programs of our intent to secure these specific keys. Then once the
transaction was signed we again notified the root programs that the deal
was done.

As you know the process to ensure a secure, audited and well structured key
migration is also non-trivial. Once this migration was performed we again
notified both root programs.

Our intention was to notify all parties, including the public, shortly
after the transfer but it took some time for our auditors, for reasons
unrelated to our audit, to produce the associated audit letters.

Once we received said letters, we then filed the bugs.

This is, although not our ideal timeline, and based on our understanding,
in compliance with the Mozilla root program in that since these roots were
already members they did not require us to publicly disclose the above
negotiation, contracting, planning, migration and other intermediate steps.

pzb: Fourth, the audit reports linked in the bug explicitly set the scope
of "subordinate CA operated under external Root CA" and do not include any
indication of controls around the issuance of subordinate CA certificates.
These audit reports do not have an appropriate scope for a root CA.

rmh: Yes, we were also concerned about this topic, especially with the
recent scope issues with audits. As such, we discussed this with both our
auditors, and the the root programs prior to acquisition of the key

When looking at this issue it is important to keep in mind Google has
operated a WebTrust audited subordinate CA under Symantec for quite a long
time. As part of this they have maintained audited facilities, and
procedures appropriate for offline key management, CRL/OCSP generation, and
other related activities. Based on this, and the timing of both our audit,
and key transfer all parties concluded it would be sufficient to have the
auditors provide an opinion letter about the transfer of the keys and have
those keys covered by the subsequent annual audit.

We have provided these letters directly to the root programs and have
recently secured permission from the auditors to release them publicly (I
will add them to the bug).

For those not familiar with the process, If Google had never been a WebPKI
CA, this situation would have been addressed with a pre-issuance audit and
a subsequent full audit 90 days later.

Since Google is a long-time WebTrust audited CA and our audits and
acquisition were going to happen approximately at the same time, this would
have provided no new evidence to the root programs or the community.

The purpose of the audit is to provide assurances to the root program and
community that best practices are being followed and the relying parties
best interests are being met. In this case following the procedure defined
for an new CA would not have aided that goal.

As an example, consider the case of a WebPKI trusted root with one key
already trusted, they can generate a new key and include it in its next
audit without the need to do the pre-issuance audit.

I think this is an appropriate position to take and an opportunity to
clarify the Mozilla root program to better inform similar cases in the

It's my hope these answers sufficiently addressed your concerns, if not let
me know if there are any clarifications I can make.

Thanks again,

Ryan Hurst

Google, Inc.

On Thu, Feb 9, 2017 at 2:06 AM, Gervase Markham <> wrote:

> On 09/02/17 05:31, Peter Bowen wrote:
> > Third, the Google CPS says Google took control of these roots on
> > August 11, 2016.  The Mozilla CA policy explicitly says that a bug
> > report must be filed to request to be included in the Mozilla CA
> > program.
> But the Mozilla CA policy does not require that the organization on the
> receiving end of a root transfer must re-apply for inclusion for
> already-included certificates.
> > It was not until December 22, 2016 that Google requested
> > inclusion as a CA in Mozilla's CA program
> > (  This does not
> > appear to align with Mozilla requirements for public disclosure.
> We require disclosure of root ownership transfer, but not _public_
> disclosure. Kathleen would need to speak regarding dates, but I know
> Mozilla was made aware of these transfers significantly before the
> inclusion request was filed.
> Apart from this, however, it seems at first glance that the other
> assertions made in Peter's post here in are
> correct. So CCing Ryan Hurst of GTS for a response.
> Gerv
dev-security-policy mailing list

Reply via email to